mongodb 컬렉션이 두 개 있는데 하나는 사용자이고 다른 하나는 게시물이고 해당 사용자 정보가 게시물 목록에 표시되는 경우 기존의 비동기 처리가 너무 중첩되어 이를 해결한 결과에도 문제가 있음을 발견했습니다.
이 방법이 맞나요? 해결된 것 같은데 항상 뭔가 잘못된 것 같은 느낌이 듭니다,,,
Promise는 최종 솔루션이 아니며 콜백보다 반드시 더 우아하지는 않습니다
3가지 포인트가 있습니다. db_conn의 then에 직접 위 코드를 작성한 후 이를 반환합니다. 가장 바깥쪽 레이어에서 catch를 사용하여 예외를 캡처합니다. console.log를 삭제하세요. 이상해 보입니다.
으아아아
마지막으로 findOneData매개변수 수신 방식을 변경해 보세요. 더 나아졌나요?
findOneData
이게 눈에 더 좋아 보이지 않나요?
이게 눈에 더 좋나요?
Promise 솔루션은 언어 요소를 추가하지 않고 비동기 콜백 문제를 해결하므로 몇 가지 제한 사항이 있을 것입니다.
Promise는 원래 콜백 위에 콜백 레이어를 하나 이상 추가하기 때문에 질문 주제처럼 원래 콜백 체인이 매우 짧은 경우 레이어가 하나만 있으면 별 장점이 없는 것 같습니다. Promise를 사용하는 것은 정상적인 현상입니다.
더 복잡한 상황과 더 많은 중첩 수준을 접하게 되면 Promise 사용의 가치를 알 수 있습니다.
위층 분들이 모두 좋은 글쓰기 방법을 제공해 주셨으니 더 이상 말씀드리지 않겠습니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Promise는 최종 솔루션이 아니며 콜백보다 반드시 더 우아하지는 않습니다
.3가지 포인트가 있습니다. db_conn의 then에 직접 위 코드를 작성한 후 이를 반환합니다.
가장 바깥쪽 레이어에서 catch를 사용하여 예외를 캡처합니다.
console.log를 삭제하세요. 이상해 보입니다.
으아아아
마지막으로
findOneData매개변수 수신 방식을 변경해 보세요. 더 나아졌나요?으아아아
이게 눈에 더 좋아 보이지 않나요?
으아아아이게 눈에 더 좋나요?
Promise 솔루션은 언어 요소를 추가하지 않고 비동기 콜백 문제를 해결하므로 몇 가지 제한 사항이 있을 것입니다.
Promise는 원래 콜백 위에 콜백 레이어를 하나 이상 추가하기 때문에 질문 주제처럼 원래 콜백 체인이 매우 짧은 경우 레이어가 하나만 있으면 별 장점이 없는 것 같습니다. Promise를 사용하는 것은 정상적인 현상입니다.
더 복잡한 상황과 더 많은 중첩 수준을 접하게 되면 Promise 사용의 가치를 알 수 있습니다.
위층 분들이 모두 좋은 글쓰기 방법을 제공해 주셨으니 더 이상 말씀드리지 않겠습니다.