자바스크립트 async

[ㅎ(211.234)]

콜백함수 promise arrow function다 이해한 입장으로
Promise가 더 가독성 있게 느껴지는데 then을 계속 써주니까
비동기식을 동기식 문법으로 async 써버리니까 더 이해 안되는데 정상?

[해당 댓글은 삭제되었습니다.]

해당 댓글은 삭제되었습니다.

[ㅎ(211.234)]

내가 쓴 글이 어려워?

[익명(106.102)]

이게 먼 소리여

[익명(39.119)]

promise 체인이 길어지면 그것도 콜백 헬처럼 복잡해짐

[익명(39.119)]

그리고 then 콜백 안의 변수나 값을 다음 체인에서 사용하려면 promise resolve 인자로 해당 변수 값도 같이 넘겨주든가 아니면 then 콜백 안에서 promise then을 또 선언해야 함.

[익명(39.119)]

promise 체인 헬도 문제긴 한데 무엇보다도 저 콘텍스트, 변수 문제가 큼. await는 동기와 사실상 '프로그램의 흐름'을 동일하게 구현할 수 있기 때문에 동기식 프로그래밍에서 하던 모든 기법을 그대로 사용할 수 있음.

[익명(49.1)]

근데 그런 코드는 async-await을 쓰기보다는 그냥 ES6 이전 문법을 쓰는게 낫다고 봄. 명시적으로 볼 때 예전의 동기식 코드가 예쁨 이견 있음?

[익명(39.119)]

ㄴ 나 분명히 예전에도 이 질문, 이 글을 똑같이 봤던 것 같은데

[익명(39.119)]

ㄴ 왜 처음으로 다시 돌아갔냐?

[익명(49.1)]

정리해서 말하면 동기 코드로 짜도 될껄 비동기로 짜면 그게 가독성 파괴되지 않냐는 말..

[익명(49.1)]

예전에 제가 님인지는 모르겠는데 ES6 이전이면 동기식이 낫다고 말하긴 했는데 글쓴이가 다른 사람인듯

[익명(49.1)]

그러니 필요한 상황에 대해서만 동기로 짠다고 표현하는게 낫지 않겠냐는 말

[익명(39.119)]

ㄴ 그런가. 아무튼 당연한 얘기를 대단한 것처럼 말하길래 뭔가 싶었네.

[익명(49.1)]

당연한데 글쓴이는 당연한걸 모르니 질문했겠지 ㅇㅅㅇ

[익명(39.119)]

js 비동기가 애초에 싱글 스레드 기반의 js에서 I/O 작업을 멀티 스레드 활용해서 하기 위해서 생긴 건데 굳이 동기로 할 걸 비동기로 만들 필요는 없지. 다만, 일부러 늦추거나 비동기로 만들 경우가 있다고는 봄.

[익명(49.1)]

그런 부분에 대해서는 적극 동의하는 바임 ㅇㅅㅇ

[익명(49.1)]

윗 글 처럼promise 체인을 정리하려고 쓰는 거 아님?

[익명(49.1)]

디자인 패턴 중에 빌더 함수 같은 것도 너무 많아지면 안티패턴이라, 생성자를 이용해서 쓰거나, 파사드 패턴을 택할 수 있는데, 프론트앤드는 아는 것처럼 nodejs같은 경우가 아니면 프론트 자체가 자주 바뀔 수 있어서 객체 지향은 꺼려지는 스타일이라, 결국에 파사드 패턴이 강제되는데, 이를 해결하기 위한 방법이라 생각함. 단순한 promise-chain은 님 말대로 promise 가 나을 수도 있음.

[익명(180.71)]

갠적으로 동기식으로 처리하는게 깔끔하다고 처리하는 이유는 indent를 안봐도 되고, return값을 명시할 수 있기 때문이야. 이게 프로그래밍할때 참 안정을 많이줘.

[익명(180.71)]

Promise로 썼을 때 안정을 느끼는 이유는 Promise스펙이 애초에 동기식으로 그대로 교체해도 문제가 없이 만들어져있기 때문에, Promise를 잘 쓴다면 애초에 동기식 논리를 가진것과 다를바가 없어. async await는 신택스 슈가 역할만 하는것뿐..

[익명(180.71)]

요지는 글쓴이가 안정감을 느끼는 포인트는 async/await나 Promise나 같을것이라고 추측함.

[익명(180.71)]

언제까지나 필요한만큼만 쓰면되는거지 무조건 대체할 필요는 없다 생각해. Promise 객체로 처리하는게 도움될때가 있어

[익명(122.37)]

그게 복잡하면 async가 문제가 아니라 함수가 너무 긴거임