React: 'isMounted' 지원 중단

나는 이것에 동의하지 않는다. 특히 ES6 약속은 componentWillUnmount 에서 안정적으로 취소될 수 없으므로 setState 또는 다른 작업 전에 구성 요소가 마운트되었는지 확인하는 유일한 방법을 제거하면 추적하기 어려운 비동기 버그가 많이 발생합니다.

@yaycmyk 따라서 라인:

우리는 여전히 프라미스(및 관련 사용 사례)에 대한 몇 가지 좋은 이야기를 파악해야 합니다.

특히 내가 나열한 배경 문제를 읽으십시오. https://github.com/facebook/react/issues/2787#issuecomment -68738793

댓글 잘 읽었습니다. 나는 단지 문제를 다루기 어렵다고 생각합니다.

왜 약속을 취소할 수 없습니까? 모든 출처/증명/예시?

2015년 11월 16일 월요일에 Evan Jacobs [email protected] 은 다음과 같이 썼습니다.

나는 이것에 동의하지 않는다. 특히 ES6 약속은 신뢰할 수 없습니다.
componentWillUnmount에서 취소되었으므로 확인하는 유일한 방법을 제거합니다.
구성 요소는 setState 또는 다른 작업이 열기 전에 마운트됩니다.
많은 비동기 버그를 추적하기 위한 방법입니다.

@nvartolomei ES6 Promise 사양을 살펴보세요.

이것은 당장에 일어나는 것이 아니라 장기적인 목표입니다. 그러나 우리는 계획과 논의를 한 곳에서 추적하고 모든 문제에 대한 의견을 공유하지 않기를 원합니다. 우리는 현재 취소할 수 없는 Promise의 문제를 알고 있습니다. 이것이 우리가 아직 이것을 하지 않은 주된 이유입니다.

@yaycmyk 매우 복잡한 문제를 과도하게 단순화하기 위해 ... 의견에 따르면 ... 마운트되지 않은 구성 요소에 대해 setState 를 피하기 위해 isMounted 를 사용하는 것은 실제로 setState 경고는 표시하려고 했습니다. 실제로는 문제를 숨길 뿐입니다. 또한 Promise의 결과로 setState 를 호출하는 것은 테스트에서 반드시 나타나지 않는 경쟁 조건을 유발할 수 있기 때문에 어쨌든 약간의 안티 패턴입니다. 따라서 우리는 그것을 없애고 React에서 promise를 사용하기 위한 "모범 사례" 권장 사항을 파악하고 싶습니다.

문제가 이해하기 어렵다는 데는 동의하지만, 이는 우리가 아직 파악하고 있고 아직 미리 준비된 답변이 없는 복잡한 문제이기 때문입니다.

Promise의 결과로 setState를 호출하는 것은 어쨌든 약간의 안티 패턴입니다. 테스트에서 반드시 나타나지 않을 경쟁 조건을 유발할 수 있기 때문입니다.

우리는 이에 동의하지 않을 수 있습니다. 콘텐츠를 비동기식으로 가져오는 경우가 있고 해결되면 해당 콘텐츠를 팝업하기 위해 전체 규모의 재렌더링을 거치고 싶지 않을 때가 있습니다. 전체 가상 렌더가 필요하지 않은 무한 테이블 뷰 구현에서 특히 사용합니다.

약속을 취소할 수 없을 수도 있지만 다음과 같이 마운트 해제 시 구성 요소를 역참조하도록 할 수 있습니다.

const SomeComponent = React.createClass({
    componentDidMount() {
        this.protect = protectFromUnmount();

        ajax(/* */).then(
            this.protect( // <-- barrier between the promise and the component
                response => {this.setState({thing: response.thing});}
            )
        );
    },
    componentWillUnmount() {
        this.protect.unmount();
    },
});

중요한 차이점은 this.protect.unmount() 가 componentWillUnmount 에서 호출될 때 모든 콜백이 역참조된다는 것입니다. 즉, 구성 요소가 역참조되고 프라미스가 완료되면 no-op을 호출합니다. 이것은 약속이 마운트되지 않은 구성 요소를 참조하는 것과 관련된 메모리 누수를 방지해야 합니다. ProtectFromUnmount 소스

이 간단한 방법은 모든 약속에 취소를 추가하는 데 사용할 수 있습니다.

const makeCancelable = (promise) => {
  let hasCanceled_ = false;

  const wrappedPromise = new Promise((resolve, reject) => {
    promise.then((val) =>
      hasCanceled_ ? reject({isCanceled: true}) : resolve(val)
    );
    promise.catch((error) =>
      hasCanceled_ ? reject({isCanceled: true}) : reject(error)
    );
  });

  return {
    promise: wrappedPromise,
    cancel() {
      hasCanceled_ = true;
    },
  };
};

편집: 정확성/완전성을 위해 업데이트되었습니다.

사용하는 방법

const somePromise = new Promise(r => setTimeout(r, 1000));

const cancelable = makeCancelable(somePromise);

cancelable
  .promise
  .then(() => console.log('resolved'))
  .catch(({isCanceled, ...error}) => console.log('isCanceled', isCanceled));

// Cancel promise
cancelable.cancel();

ES6 약속을 취소할 수 있도록 지원하는 방법을 나열하는 것은 요점이 아닙니다. 그 의도는 사양 주변에서 작동하려고 하기 보다는 사양과 함께 작동하는 솔루션을 제공하는 것이어야 합니다.

나는 동의한다. 프라미스 결과를 받았을 때 컴포넌트가 여전히 마운트되어 있는지 단순히 확인하는 대신 모든 종류의 마법에 의존하여 결과를 설정해야 하는 컴포넌트에서 프라미스를 "언바인드"할 수 있어야 합니다. 설계되었습니다.
나에게 그것은 간단한 테스트가 이것을 처리하는 가장 쉬운 방법인 솔루션을 과도하게 엔지니어링하는 것처럼 느껴집니다.

다음과 같은 방법으로 간단한 검사를 계속할 수 있습니다.

React.createClass(function() {
  componentDidMount: function() {
    this._isMounted = true;

    ajax(/* */).then(this.handleResponse);
  }

  handleResponse: function(response) {
    if (!this._isMounted) return; // Protection

    /* */
  }

  componentWillUnmount: function() {
    this._isMounted = false;
  }
});

이것은 물론 내 의견이지만 반응 구성 요소 내부에 약속이 있는 비동기 데이터 로드는 우리 고유의 상용구 코드를 작성하는 대신 반응으로 다루어야 하는 일반적인 시나리오인 것 같습니다.

문제는 실제 마운트 상태를 따르기 위해 반응이 각 구성 요소(정의된 경우 componentDidMount를 연결하는 것과 동일)에서 DOM 마운트 프로세스를 완료할 때 리스너를 추가해야 하지만 필요하지 않기 때문에 성능에 영향을 미칩니다. 여기저기 놔두는 것. componentDidMount가 정의되지 않았으므로 구성 요소는 기본적으로 DOM 마운트 준비를 수신하지 않습니다.

setState 가 원하는 상태 변경으로 해결되는 연결된 약속을 전달할 수 있다면 어떻게 될까요? 구성 요소가 마운트 해제되면 보류 중인 약속이 있으면 최종 결과가 무시됩니다.

@istarkov 멋진 패턴, 좋아요! 다음은 약간 변경된 API입니다.

// create a new promise
const [response, cancel] = await cancelable(fetch('/api/data'));

// cancel it
cancel();

나는 React에 익숙하지 않고 문서를 읽고 있기 때문에 이것을 던지기 위해 : Load Initial Data via Ajax 팁은 .isMounted() 를 사용하므로 웹 사이트가 웹 사이트와 동의하지 않습니다. 위의 @istarkov 패턴을 사용하여 componentWillUnmount 에서 초기 로드를 취소하는 방법에 대한 완전한 팁을 보는 것이 좋습니다.

@dtertman https://github.com/facebook/react/pull/5870 에서 수정되었으며 문서가 선택되면 온라인 상태가 됩니다.

@jimfb 감사합니다. 검색에서 어떻게 놓쳤는지 잘 모르겠습니다.

@istarkov 는 이것이 의도적인 것인지 확실하지 않지만 원래 약속이 실패하면 makeCancelable 가 처리되지 않습니다. 원래 약속이 거부되면 처리기가 호출되지 않습니다.

원래 약속에 대한 오류를 계속 처리하기를 원할 수 있기 때문에 이것은 이상적이지 않은 것 같습니다.

다음은 원래 약속에서 거부를 처리하는 makeCancelable 대한 제 제안입니다.

const makeCancelable = (promise) => {
  let hasCanceled_ = false;

  const wrappedPromise = new Promise((resolve, reject) => {
    promise.then((val) =>
      hasCanceled_ ? reject({isCanceled: true}) : resolve(val)
    );
    promise.catch((error) =>
      hasCanceled_ ? reject({isCanceled: true}) : reject(error)
    );
  });

  return {
    promise: wrappedPromise,
    cancel() {
      hasCanceled_ = true;
    },
  };
};

취소 가능한 약속을 만드는 것이 좋은 생각인지 확신할 수 없지만 약속을 취소할 수 있도록 만들려면 기본 동작을 유지해야 합니다. :)

@vpontis : +1:

@istarkov 귀하의 원래 게시물은 여기에서 참조됩니다: https://facebook.github.io/react/blog/2015/12/16/ismounted-antipattern.html

게시물을 업데이트하고 싶습니까 아니면 게시물 작성자에게 메시지를 보내야 합니까?

@vpontis 감사합니다, 수정하겠습니다! (https://github.com/facebook/react/pull/6152)

안녕하세요 @jimfb , 인터넷에서 당신을

makeCancelable 함수의 또 다른 버그 수정: 최근 노드 버전에서 UnhandledPromiseRejectionWarning 가 발생할 수 있습니다(특히 새 버전의 노드로 테스트를 실행할 때). 노드 6.6.0 의 변경 사항 중 하나는 처리되지 않은 모든 약속이 거부되면 경고가 발생한다는 것입니다. @vpontis 의 기존 코드에는 동일한 기본 약속에 대해 별도의 then 및 catch 호출이 있었습니다. 효과적으로, 이것은 성공만 처리하는 약속과 오류만 처리하는 약속을 _2_ 생성합니다. 즉, 오류가 있는 경우 첫 번째 약속이 노드에서 처리되지 않은 약속 거부로 간주됩니다.

수정은 매우 쉽습니다. 성공 및 오류 핸들러 모두에 대해 하나의 약속을 하도록 두 호출을 연결하기만 하면 됩니다. 다음은 고정 코드입니다.

const makeCancelable = (promise) => {
  let hasCanceled_ = false;

  const wrappedPromise = new Promise((resolve, reject) => {
    promise
      .then((val) =>
        hasCanceled_ ? reject({isCanceled: true}) : resolve(val)
      )
      .catch((error) =>
        hasCanceled_ ? reject({isCanceled: true}) : reject(error)
      );
  });

  return {
    promise: wrappedPromise,
    cancel() {
      hasCanceled_ = true;
    },
  };
};

@alangpierce 정답 에 매우 가깝지만 정확하지는 않습니다. resolve() 또는 reject() 가 해결된 프라미스에 대해 어떤 이유로든 동기적으로 throw하면 두 핸들러가 모두 호출됩니다.

해결책은 .then(onFulfilled, onRejected) 패턴을 사용하는 것입니다.

const makeCancelable = (promise) => {
  let hasCanceled_ = false;

  const wrappedPromise = new Promise((resolve, reject) => {
    promise.then(
      (val) => hasCanceled_ ? reject({isCanceled: true}) : resolve(val),
      (error) => hasCanceled_ ? reject({isCanceled: true}) : reject(error)
    );
  });

  return {
    promise: wrappedPromise,
    cancel() {
      hasCanceled_ = true;
    },
  };
};

이 makeCancelable 솔루션은 isMounted()가 더 이상 사용되지 않는 이유에 대해 포인트 3을 볼 때 isMounted() 호출과 효과적으로 동일하지 않습니까?

구성 요소가 완전히 마운트 해제되면 setState를 호출합니다.
이것은 비동기 콜백이 제대로 정리되지 않는다는 강력한 표시입니다. 불행히도, 주류 JS API를 사용하면 매달린 비동기 콜백을 정리하는 것을 매우 쉽게 피할 수 있습니다.

하나의 콜백은 큰 문제가 아닙니다. 그러나 해당 콜백은 객체 및 중간 콜백, 약속 및 구독에 계속 걸립니다. 많은 구성 요소가 이 작업을 수행하면 메모리 문제가 빠르게 발생합니다.

makeCancellable은 구성 요소에 대한 참조를 보유하는 함수에 대한 참조를 보유하게 되는 또 다른 약속을 생성합니다. makeCancellable 솔루션은 부울 속성 isMounted를 약속으로 옮기는 것입니다.

GC 문제를 해결하려면 cancel()이 호출될 때 null을 제거해야 합니다. 그렇지 않으면 여전히 비동기 프로세스에서 구성 요소로의 참조 체인이 있습니다.

class CancellableDeferred {
  constructor(request) {
    this.deferred = $.Deferred();

    request.then((data) => {
      if (this.deferred != null) {
        this.deferred.resolve(data);
      }
    });

    request.fail((data) => {
      if (this.deferred != null) {
        this.deferred.reject(data);
      }
    });
  }

  cancel() {
    this.deferred = null;
  } 

  promise() {
    return this.deferred.promise();
  }
}

-> jQuery 지연 객체로 수행하는 방법입니다. Promise API에 대해 잘 알지 못해서 어떻게 보일지 모르겠습니다. 또한 이는 cancel()이 호출되고 deferred가 해결되지 않은 경우 deferred를 거부하지 않습니다. 아마도 사람들은 이것이 어떻게 작동해야 하는지에 대해 다른 의견을 가지고 있습니다.

그래서 체인은 다음과 같습니다.

AJAX 요청 -> 폐쇄 -> CancellableDeferredInstance -> JQuery 지연 -> 구성 요소

그런 다음 취소 후 다음과 같이 보입니다.

AJAX 요청 -> 폐쇄 -> CancellableDeferredInstance /객체 참조가 이제 null/ JQuery 지연 -> 구성 요소

따라서 AJAX 요청은 더 이상 구성 요소가 GCd가 되는 것을 방지하지 않습니다. 야 폐쇄....]

@benmmurphy 안녕하세요. 저는 JS 가비지 컴파일에 익숙하지 않고 React에서는 다르게 작동할 수 있지만 이해가 다릅니다.

makeCancellable 사용하면 React 구성 요소가 마운트 해제될 때 가비지 수집이 가능합니다. 설명하겠습니다.

makeCancellable은 구성 요소에 대한 참조를 보유하는 함수에 대한 참조를 보유하게 되는 또 다른 약속을 생성합니다. makeCancellable 솔루션은 부울 속성 isMounted를 약속으로 옮기는 것입니다.

makeCancellable :

handleError() {
  if (this.isMounted()) {
    console.log('ERROR')
  }
}

makeCancellable :

promise.then(...).fail((reason) => {
  if (reason.isCancelled) return;
  console.log('ERROR');
})

makeCancellable 없으면 여전히 this 대한 참조가 있으므로 구성 요소가 마운트 해제될 때 가비지 수집될 수 없습니다. 그러나 다른 경우에는 구성 요소가 마운트 해제되자마자 취소 가능한 프라미스의 실패 핸들러가 호출되므로 더 이상 참조가 필요하지 않습니다.

@vpontis

문제를 설명하는 몇 가지 nodejs 코드가 있습니다. Foo 구성 요소는 비동기 콜백 resolve 이 null로 설정된 경우에만 GC됩니다. 예를 들어 해결하는 데 30초가 걸리는 Ajax 요청을 실행하면 구성 요소가 마운트 해제됩니다. 그런 다음 구성 요소는 30초 동안 GCd가 아닙니다. 이것은 isMount()를 더 이상 사용하지 않음으로써 해결하려는 문제 중 하나입니다.

npm install promise
npm install weak

node --expose-gc gc.js
first gc Foo {}
after first gc Foo {}
after resolve = null Foo {}
foo gc'd
after second gc {}

https://gist.github.com/benmmurphy/aaf35a44a6e8a1fbae1764ebed9917b6

편집하다:

과거 이야기를 해서 미안하지만 처음 게시물을 읽었을 때는 당신이 말하려는 요점을 이해하지 못했는데 지금은 알 것 같아요. 당신이 말하려는 것은 오류 콜백이 구성 요소에 대한 참조를 포함하지 않기 때문에(또는 구성 요소에 대한 참조를 따르지 않기 때문에) 구성 요소가 약속에 의해 참조되는 것으로 간주되지 않는다는 것입니다. 이것은 사실입니다. 글쎄, 첫 번째 부분은 사실입니다. 그러나 이러한 추론에는 다음과 같은 문제가 있습니다.

1) 예제의 오류 처리기에 구성 요소에 대한 참조가 없더라도 then() 콜백은 일반적으로 사용합니다. 예를 들어 then 핸들은 일반적으로 this.setState(...) 합니다.
2) 예제의 오류 처리기에 대부분의 오류 처리기가 구성 요소에 대한 참조가 없더라도. 예를 들어 그들은 다음과 같이 할 것입니다:

promise.then(...).fail((reason) => {
  if (reason.isCancelled) return;
  console.log('ERROR');

  this.setState({error: true});
})

3) 코드가 then() 콜백을 따르지 않고 isCancelled 변수를 확인한 후 함수를 종료한다는 것을 알고 있지만 GC는 이를 알지 못합니다.

다른 사람이 내 예제나 이에 기반한 것을 사용하기 전에 실제로 GC가 올바르게 수행되는지 테스트해야 합니다. 나는 아직 내 것을 테스트하지 않았으며 어리석은 오류를 범했기 때문에 작동하지 않으면 놀라지 않을 것입니다./

약속 API 측면에서 이것은 GC 측면에서 nodejs에서 저에게 효과적입니다. 하지만 _resolve , _reject 매개변수를 클로저 근처에 두지 않는 것이 좋습니다. 이것이 JS 사양에 따라 작동하는지 또는 작동하는지 확실하지 않기 때문입니다. 노드가 일부 최적화를 수행하고 있기 때문입니다. 구현이 보이는 모든 변수를 캡처하거나 클로저에서 참조되는 변수만 캡처할 수 있습니까? JS를 실제로 이해하는 사람이 차임벨을 들고 설명할 수 있을지 모르겠습니다. :)

var makeCancelable = (promise) => {
  let resolve;
  let reject;

  const wrappedPromise = new Promise((_resolve, _reject) => {
    resolve = _resolve;
    reject = _reject;

    promise.then((val) => {
       if (resolve != null) resolve(val)
    });
    promise.catch((error) => {
       if (reject != null) reject(error)
    });
  });

  return {
    promise: wrappedPromise,
    cancel() {
      resolve = null;
      reject = null;
    },
  };
};

isMounted 함수가 16.0에서 제거됩니까?

@istarkov 코드로 약간의 개선을 위한 제안:

const makeCancelable = (promise) => {
    let hasCanceled_ = false
    promise.then((val) =>
        hasCanceled_ ? reject({isCanceled: true}) : resolve(val)
    )
    .catch((error) =>
        hasCanceled_ ? reject({isCanceled: true}) : reject(error)
    )

    return {
        promise,
        cancel() {
            hasCanceled_ = true
        }
    }
}

새로운 약속이 불필요할 뿐입니다.

새로운 약속이 불필요할 뿐입니다.

@BnayaZil resolve 및 reject 함수를 호출하고 있지만 어디에서 왔는지 명확하지 않습니다. Promise.resolve 및 Promise.reject 를 의미했습니까? 이 경우에도 여전히 새로운 Promise를 반환할 것입니다.

며칠 전에 fetch() 요청을 중단할 수 있는 새 API가 DOM 사양에 추가되었습니다. 이 API는 아직 어떤 브라우저에서도 구현되지 않았지만 "abortcontroller-polyfill"인 NPM에서 사용할 수 있는 폴리필을 만들었습니다. 폴리필은 본질적으로 @istarkov가 게시한 코드와 동일한 작업을 수행 하지만 구현되면 코드 변경 없이 실제 브라우저 API로 전환할 수 있습니다.

세부 정보:
https://mo.github.io/2017/07/24/abort-fetch-abortcontroller-polyfill.html

React.createClass 는 더 이상 React 16에 존재하지 않고 새로운 create-react-class 패키지에는 isMounted 대한 명확한 사용 중단 메시지가 포함되어 있으므로 이를 종료하겠습니다.

나는 @istarkov의 솔루션을 효율적으로 사용하는 것과 동일하다는 것을 @benmmurphy에 동의 isMounted() 가 쓰레기 수집 문제가 해결되지 않기 때문에.

@benmmurphy 의 솔루션은 더 가깝지만 잘못된 변수를

핵심은 핸들러를 역참조하는 클로저를 통해 함수를 전달하는 것입니다.

const makeCancelable = promise => {
  let cancel = () => {};

  const wrappedPromise = new Promise((resolve, reject) => {
    cancel = () => {
      resolve = null;
      reject = null;
    };

    promise.then(
      val => {
        if (resolve) resolve(val);
      },
      error => {
        if (reject) reject(error);
      }
    );
  });

  wrappedPromise.cancel = cancel;
  return wrappedPromise;
};

이 솔루션이 이전 솔루션이 아닌 가비지 수집을 허용하는 이유에 대한 추가 설명은 여기 에서 찾을 수

나는 이것을 npm 패키지로 쓰레기통으로 바꿨습니다 . 유스 케이스 IS 반응하기 때문에, 나는이 구성 요소가 마운트 해제 얻을 때 트랙의 약속과이를 취소하는 HOC 성분으로, trashable-반응 .

편집 : 내 나쁜, 방금 @hjylewis thrashable 을 보았고 약속도 취소합니다. 여전히 아래 패턴은 IMO가 약간 개선된 것입니다.

이러한 솔루션 중 어느 것도 약속을 취소하지 않으며 영원히 보류 중인 약속을 흡수하여 연장 없이 취소할 수 있습니다.

function makeCancelable(promise) {
  let active = true;
  return {
    cancel() {active = false},
    promise: promise.then(
      value => active ? value : new Promise(()=>{}),
      reason => active ? reason : new Promise(()=>{})
    )
  }
}

// used as above:

const {promise, cancel} = makeCancelable(Promise.resolve("Hey!"))

promise.then((v) => console.log(v)) // never logs
cancel()

여기에서 살다

GC와 관련하여 수정해야 할 미묘함이 있을 수 있고 커피가 아직 시작되지 않았지만 그 패턴은 반환된 약속이 실제로 취소되고 누출되지 않도록 만들 수 있습니다(과거에 구현했습니다).

@pygy 답변 감사합니다!

불행히도 귀하의 솔루션은 여전히 ​​가비지 컬렉션을 허용하지 않습니다. 본질적으로 조건부를 사용하는 @istarkov 의 솔루션을 다시 작성

이 구현을 휴지통에 놓고 테스트를 실행하여 쉽게 테스트할 수 있습니다(가비지 수집 테스트 실패).

또한 구현에서 오류를 제대로 처리하지 못합니다.

2018년입니다. 위에서 언급한 것보다 더 나은 접근 방식이 있습니까?

예, 반응 네이티브의 두 배 크기의 문서가 있지만 매우 전문적인 일부 탐색 프레임워크를 사용할 수 있습니다.

약속 "취소"에 대한 이러한 스니펫은 그다지 좋은 IMHO가 아닙니다. 취소된 약속은 원래 약속이 해결될 때까지 해결되지 않습니다. 따라서 isMounted 트릭을 사용할 때까지 메모리 정리가 발생하지 않습니다.

적절한 취소 가능한 프라미스 래퍼는 두 번째 프라미스와 Promise.race를 사용해야 합니다. 즉 Promise.race([originalPromise, cancelationPromise])

@benmmurphy 의 솔루션은 더 가깝지만 잘못된 변수를

내 솔루션이 작동한다고 생각하지만 자바 스크립트 런타임이 확실히 알기 위해 제공하는 약속에 대해 충분히 알지 못합니다. 테스트 하네스의 노드에서 솔루션을 실행하면 값을 올바르게 GC합니다. 내 솔루션은 해결/거부 기능을 더 높은 범위에 할당한 다음 취소가 호출될 때 이러한 값을 무효화했습니다. 그러나 함수는 하위 범위에서 계속 사용할 수 있었지만 참조되지는 않았습니다. 현대 자바 스크립트 엔진은 참조되지 않는 한 클로저에서 변수를 캡처하지 않는다고 생각합니다. 나는 이것이 사람들이 다음과 같은 일을 했기 때문에 실수로 DOM 누수를 만드는 큰 문제였다고 생각합니다. var element = findDOM(); element.addEventListener('클릭', function() {}); 및 요소는 클로저에서 사용되지 않았더라도 클로저에서 참조됩니다.

@hjylewis @benmmurphy 왜 핸들러를 역참조해야 합니까 ?? 핸들러가 실행된 후에는 가비지 컬렉션이 발생합니다. 맞나요??

약속 "취소"에 대한 이러한 스니펫은 그다지 좋은 IMHO가 아닙니다. 취소된 약속은 원래 약속이 해결될 때까지 해결되지 않습니다. 따라서 isMounted 트릭을 사용할 때까지 메모리 정리가 발생하지 않습니다.

적절한 취소 가능한 프라미스 래퍼는 두 번째 프라미스와 Promise.race를 사용해야 합니다. 즉 Promise.race([originalPromise, cancelationPromise])

@hjylewis 와 광산은 실제로 작동합니까? 노드가 약한 상태에서 확인할 수 있습니다. 그러나 그것들을 다시 보면 나는 그들 중 어느 쪽도 특이한 작성된 약속 코드가 아니라는 데 동의합니다. 약속 사용자로서 거부된 상태에서 해결될 '취소된' 약속을 예상할 수 있으며 둘 다 이를 수행하지 않습니다. 그러나 구성 요소의 경우 거부 처리기를 무시하기 위해 추가 코드를 작성할 필요가 없기 때문에 사용하기 더 쉬운 솔루션일 수 있습니다.

나는 특이한 거부 가능한 약속이 Promise.race([])를 사용하여 취소 가능한 약속을 만들 것이라고 생각합니다. Promise가 해결되면 보류 중인 콜백이 삭제되어 그 시점에서 브라우저 네트워크에서 구성 요소로의 참조 체인이 없기 때문에 작동합니다. 왜냐하면 Race Promise와 구성 요소 사이에 더 이상 참조가 없기 때문입니다.

취소 가능한 약속과 함께 Promise.all() 사용하고 브라우저 콘솔에서 잡히지 않는 오류를 피할 수 있는지 궁금합니다... 첫 번째 취소 오류만 잡을 수 있기 때문에 다른 것들은 잡히지 않은 채로 남아 있습니다.

2018년입니다. 위에서 언급한 것보다 더 나은 접근 방식이 있습니까?

프라미스 실행을 취소하는 더 나은 방법, 즉 setTimeout, API 호출 등. 2019년입니다 😭 😞

TC39에서 진행 중인 Promise 취소 스레드가 있습니다. (제 생각에는) 여기에 관련이 있습니다(아마도 .. 확실하지 않음).
https://github.com/tc39/proposal-cancellation/issues/24

프라미스 실행을 취소하는 더 나은 방법, 즉 setTimeout, API 호출 등. 2019년입니다 😭 😞

우리는 다음과 같은 것을 찾고 있습니까?

const promise = new Promise(r => setTimeout(r, 1000))
  .then(() => console.log('resolved'))
  .catch(()=> console.log('error'))
  .canceled(() => console.log('canceled'));

// Cancel promise
promise.cancel();