약속이 뭐가 문제야?맹세합니다.모든 ()❓

나는 최근에 v8 블로그에서 Promise combinators이라는 글을 읽었다.이것은 Promise API에서 곧 나타날 두 가지 방법인 Promise.allSettled()과 Promise.any()에 관한 것이다.나는 낙담했다.내가 보기에 이러한 방법의 디자인은 현재의 Promise API와 일치하지 않는다.다음은 나의 관점을 나눌게요.

약속할게.모든 것이 해결되었다
기사 기준:

Promise.allSettled gives you a signal when all the input promises are settled, which means they're either fulfilled or rejected.

예를 들어, 여러 API 호출을 보내고 모든 호출이 완료될 때까지 기다립니다.

const promises = [
  fetch('/api-call-1'),
  fetch('/api-call-2'),
  fetch('/api-call-3'),
];

await Promise.allSettled(promises);

removeLoadingIndicator();

물론 이것은 쓸모가 있다.하지만 이 임무는 .map()와 Promise.all()로 쉽게 해결할 수 있다.변화가 적습니다.

const promises = [
  fetch('/api-call-1'),
  fetch('/api-call-2'),
  fetch('/api-call-3'),
].map(p => p.catch(e => e)); // <-- the only change

await Promise.all(promises);

removeLoadingIndicator();

몇 줄의 코드만으로도 해결할 수 있는 새로운 핵심 방법을 실현하는 것이 가치가 있습니까?핵심 API 방법이 아닌 라이브러리 특성입니다.
그러나 더 중요한 것은 Promise.allSettled 추가적인 추상화를 가져왔고 코드의 복잡성을 증가시켰다.Promise.all와 달리 순수한 약속치가 아닌 포장 대상 수조{status, reason}를 사용한다.개발자로서 나는 그것을 좋아하지 않는다.나는 유사한 명칭을 가진 방법.all()/.allSettled()의 행위 방식이 유사하기를 바란다.근데 없어요.
그 밖에 Promise.allSettled가 있는 코드는 더 나쁜 오류 제어를 장려한다.오류는 전통적으로catch 블록에서 처리되지 않고 최종 결과에서 필터해야 합니다.이것은 반대로 다음과 같은 단점이 있다.

오류 발생 시 즉시 처리되지 않습니다.만약 몇 가지 관련 오류가 발생한다면, 너는 어느 것이 원래의 잘못인지 알 수 없을 것이다.로그에 잘못된 시간 스탬프가 포함됩니다.

최소한 한 가지 약속이 영원히 끊어지면 오류를 처리하지 않습니다.

currentPromise.all의 방법을 사용하면 이런 일을 허락하지 않는다.

약속할게.어떤

Promise.any gives you a signal as soon as one of the promises fulfills.

다시 말하면 Promise.any는 Promise.race가 거절을 소홀히 하는 것이다.
예를 들면 여러 개의 끝점을 검사하고 첫 번째 성공한 끝점에서 데이터를 얻는 것이다.

const promises = [
  fetch('/endpoint-a').then(() => 'a'),
  fetch('/endpoint-b').then(() => 'b'),
  fetch('/endpoint-c').then(() => 'c'),
];
try {
  const first = await Promise.any(promises);
} catch (error) {
  // All of the promises were rejected.
  console.log(error);
}

나는 때때로 그것이 유용할 수도 있다는 것에 동의한다.그런데 얼마나 자주 해요?몇 개의 항목에서, 당신은 이 모드를 사용하여 같은 데이터를 같은 단점에 여러 개의 병렬 요청을 보냅니까?댓글에 공유하신 것을 환영합니다.하지만 내 시야에서 볼 때--자주는 아니야.지역사회에 있어 현지에서 실현bluebird'sPromise.each()나Promise.delay()가 더 유용하지 않겠는가?
그 밖에 Promise.any에 새로운 유형의 오류가 도입되었다-AggregateError.모든 약속이 거부되면, 이 오류는 다른 오류를 가리키는 링크를 포함합니다.오류 처리 방법이 하나 더 있어요!그것은 Promise.allSettled와는 달리 후자는 성공 결과에서 오류를 추출한다.그것도 Promise.all/Promise.race 과 다르고, 후자는 단지 하나의 Error 실례만을 거절한다.만약 모든 새로운 Promise API 방법이 새로운 오류 처리 방식을 도입한다면 자바스크립트는 어떻게 될까요?그럼에도 불구하고 the proposal is on a very early stage 방향이 걱정입니다.
현재의 Promise API를 바탕으로 Promise.any의 실현은 좀 까다롭지만 실제로는 two lines of code:

const reverse = p => new Promise((resolve, reject) => Promise.resolve(p).then(reject, resolve));
Promise.any = arr => reverse(Promise.all(arr.map(reverse)));

도서관 땅에 남겨두고 핵심 API를 깨끗하고 간단하게 유지해야 하지 않겠는가?

과 모순
왜 Promise.all랑 Promise.race랑 이렇게 예뻐요?
그들의 행동은 매우 일치하기 때문에 일반적인 약속과 비슷하다. 단지 하나의 값만 있으면 실현할 수 있고, 단지 하나의 잘못만 있으면 거절할 수 있기 때문이다.포장치가 없고 누적 오류가 없고 별도의 복잡성이 없습니다.
왜 Promise.allSettled와Promise.any가 나한테 이렇게 이상해?

Promise.allSettled 상태와 원인을 포함하는 대상 그룹을 사용하여 기본 약속치를 실현한다.거절은 영원히.

Promise.any 단일 값을 만족시키고 중간 거부를 무시합니다.모든 약속이 거절된 경우에만 모든 잠재적인 원인을 포함하는 누적된 이유로 거절할 수 있다.

이런 새로운 방법들은 정말 내 머릿속에 나타나기 어렵다.현재 Promise API와 크게 다르기 때문입니다.
2020년에는 핫한 구직 면접 문제가 있을 것으로 예상됩니다.
이 네 가지 방법은 무엇이 다릅니까?

Promise.all()

Promise.allSettled()

Promise.race()

Promise.any()

멋진 질문이지만 핵심 API가 이런 복잡성을 장려해서는 안 된다고 생각한다.

명명
나는 명명에도 실망했다.네 가지 행동이 조금 다른 방법에는 명확한 명칭이 있어야 한다.그렇지 않으면 코드에서 그것들을 만날 때마다 나는 반드시 다시 검사해야 한다. MDNPromise.any 의 proposal:

It clearly describes what it does

나는 동의하지 않는다.나에게Promise.any의 이름은 곤혹스럽다.

만약 어떤 약속이 실행된다면 그것을 실행합니까?그래.

어떤 약속도 거절당하면 거절합니까?번호

어떤 약속도 실천할 수 있다면 실천할 수 있습니까?상황을 보고 결정하다.

와 Promise.race는 어떤 차이가 있습니까?은마르코프 모형.

나는 모든 방법의 명칭은 이 방법이 만족하는 조건을 명확하게 정의해야 한다고 생각한다.다음과 같은 명명 규칙을 사용하는 것이 좋습니다.

Promise.all        -> Promise.allFulfilled
Promise.allSettled -> Promise.allSettled
Promise.race       -> Promise.oneSettled
Promise.any        -> Promise.oneFulfilled

그것은 약속 상태의 네 가지 가능한 조합을 반영했다.그것은 왜 이런 방법들이 제안에서 조합어라고 불리는지 설명했다.
물론, 이러한 이름 변경은 불가능하다. Promise.all 과 Promise.race 은 이미 로그인되어 많은 응용 프로그램에서 사용되고 있기 때문이다.그러나 새로운 방법에 대해서는 명칭 정책을 사용하는 것이 매우 유용할 것이다.
GitHub에 있는 Promise.any() 제안 라이브러리에서 opened issue를 찾았습니다. 당신의 생각을 공유하신 것을 환영합니다.

받아들이기를 거절하다
전반적으로 말하자면, 나는 새로운 방법에 도입된 비투매적 '삼키기' 거부라는 개념에 대해 결코 흥미를 느끼지 않는다.실제로 새로운 Promise API는 코드의 오류를 묵묵히 무시하는 방법을 제공합니다.

Promise.allSettled 영원히 거절하지 않는다.

Promise.any 모든 약속이 거절된 경우에만 거절한다.

현재 이를 수행할 수 있는 다른 핵심 JavaScript API는 없습니다.오류를 무시하는 유일한 방법은 try..catch / .catch() 의 빈 텍스트에 수동으로 포장하는 것입니다.그리고 왜 오류를 소홀히 하는지 여기에 논평을 쓰십시오. 그렇지 않으면 eslint will warn you.
나는 핵심 API가 모든 오류를 공개해야 한다고 생각한다.오류를 처리할지 말지는 개발자의 결정이다.다른 개발자들에게 그것은 명확해야 한다.부정확한 사용 거부로 인해 디버깅을 하는 데 얼마나 걸릴지 생각해 보세요!특히 제3자 코드를 처리할 때- 어떤 것들이 작용하지 않고 오류를 던지지 않았을 때.

결론
나는 일하는 날마다 약속을 한다.많은 다른 개발자들과 마찬가지다.나는 JavaScript의 비동기적인 특성을 좋아한다.명확하고 직관적인 API를 통해 작업을 더욱 빠르게 해결하고 생산성을 높일 수 있습니다.이것이 바로 Promise API가 매우 조심스럽게 다루고 변경되어야 한다고 생각하는 이유입니다.
읽어주셔서 감사합니다. 평론을 환영합니다.
이 게시물은 hackernoon.com에 가장 먼저 등장했다.