React: `isMounted`を廃止

私はこれに同意しません。 特にES6PromiseはcomponentWillUnmountで確実にキャンセルできないため、setStateまたは別のアクションの前にコンポーネントがマウントされているかどうかを確認する唯一の方法を削除すると、非同期バグを追跡するのが難しい多くの方法が開かれます。

@yaycmykしたがって、次の行になります。

約束（および関連するユースケース）に関するいくつかの良い話を理解する必要があります。

特に、私がリストした背景の問題を読んでください： https ：

コメントを読みました。 私は問題が手に負えないことに気づきました。

なぜ約束は確実に取り消されないのですか？ ソース/証明/例はありますか？

2015年11月16日月曜日、EvanJacobsの[email protected]は次のように書いています。

私はこれに同意しません。 ES6の約束は特に確実ではありません
componentWillUnmountでキャンセルされたため、次のことを確認する唯一の方法を削除します。
setStateまたは別のアクションが開く前にコンポーネントがマウントされます
非同期のバグを追跡するのが難しい多くの方法。

@ nvartolomeiES6の約束の仕様を見てください。

これは長期的な目標であり、すぐに起こっていることではありません。 ただし、計画とディスカッションを1か所で追跡し、これが発生したときにすべての問題のコメントにまたがって追跡するのではありません。 Promisesが現在キャンセルできないという問題を認識しています。これが、まだこれを行っていない主な理由です。

@yaycmyk非常に複雑な問題を過度に単純化するために...コメントは言っています...マウントされていないコンポーネントにsetStateを使用してisMountedを使用しても、 setStateという問題は実際には解決されませんsetStateを呼び出すことは、テストに必ずしも表示されない競合状態を引き起こす可能性があるため、とにかくアンチパターンのビットです。 したがって、私たちはそれを取り除き、Reactでpromiseを使用するための「ベストプラクティス」の推奨事項を理解したいと思います。

問題が少し不可解であることに同意しますが、それは主に、私たちがまだ理解している複雑な問題であり、まだ定型的な対応がないためです。

promiseの結果としてsetStateを呼び出すことは、テストに必ずしも表示されない競合状態を引き起こす可能性があるため、とにかくアンチパターンのビットです。

私たちはそれに同意しないことに同意することができます。 コンテンツが非同期でフェッチされており、解決されたコンテンツをポップするためにフルスケールの再レンダリングを実行する必要がない場合があります。 特に、完全な仮想再レンダリングが不要な無限テーブルビューの実装で使用します。

promiseをキャンセルできない場合がありますが、次のように、アンマウント時にコンポーネントを逆参照させることができます。

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で呼び出された場合、すべてのコールバックが逆参照されます。つまり、コンポーネントが逆参照され、promiseが完了すると、no-opが呼び出されます。 これにより、promiseがマウントされていないコンポーネントを参照することに関連するメモリリークを防ぐことができます。 secureFromUnmountのソース

この簡単な方法を使用して、任意の約束にキャンセルを追加できます

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;
  }
});

これはもちろん私の意見ですが、reactコンポーネント内でpromiseを使用して非同期データをロードすることは非常に一般的なシナリオであるため、独自の定型コードを作成するのではなく、reactでカバーする必要があります。

問題は、真のマウント状態を許可するには、reactが各コンポーネントでDOMマウントプロセスを終了するときにリスナーを追加する必要があることです（同じ、定義されている場合はcomponentDidMountをアタッチします）が、必要がないため、perfに影響しますどこでもそれを休むために。 componentDidMountは未定義であるため、コンポーネントはデフォルトでDOMマウントの準備ができていることをリッスンしません。

setStateに、目的の状態変化に解決される連鎖プロミスを渡すことができるとしたらどうでしょうか。 コンポーネントがアンマウントされ、保留中のプロミスがある場合、それらの最終的な結果は無視されます。

@istarkov素敵なパターン、それのように！ 少し変更されたAPIは次のとおりです。

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

// cancel it
cancel();

私はReactとドキュメントを読むのが初めてなので、これを捨てるだけです。Ajaxを介した初期データの.isMounted()を使用するため、WebサイトはWebサイトと一致しません。 上記の@istarkovのパターンを使用して、 componentWillUnmountの初期ロードをキャンセルする方法についての完全なヒントを見るのは素晴らしいことです。

@dtertman https://github.com/facebook/react/pull/5870で修正され、ドキュメントが厳選されたときにオンラインになります。

@jimfbありがとう、検索でそれをどのように逃したのかわかりません。

@istarkovは、これが意図的なものかどうかはmakeCancelableは処理しません。 元のpromiseが拒否された場合、ハンドラーは呼び出されません。

元の約束のエラーを処理したい場合があるため、これは理想的ではないようです。

これが、元の約束の拒否を処理する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/is Mounted-antipattern.html

投稿を更新したいですか、それとも投稿の作成者にメッセージを送信する必要がありますか？

@vpontisありがとう、修正します！ （https://github.com/facebook/react/pull/6152）

ねえ@jimfb 、インターネットであなたに

makeCancelable関数の別のバグ修正：最近のノードバージョンでUnhandledPromiseRejectionWarningが発生する可能性があります（特に、新しいバージョンのノードでテストを実行する場合）。 ノード6.6.0での変更の1つは、未処理のpromise拒否がすべて警告になることです。 @vpontisの既存のコードには、同じ基本約束で別々のthenとcatch呼び出しがありました。 事実上、これにより_two_promiseが作成されます。1つは成功のみを処理し、もう1つはエラーのみを処理します。 つまり、エラーが発生した場合、最初のPromiseはノードによって未処理のPromise拒否と見なされます。

修正は非常に簡単です。2つの呼び出しをチェーンするだけで、成功ハンドラーとエラーハンドラーの両方で1つの約束ができます。 修正されたコードは次のとおりです。

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()が何らかの理由で解決されたpromiseで同期的にスローされた場合、両方のハンドラーが呼び出されます。

解決策は、 .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を使用すると、ハングしている非同期コールバックのクリーンアップを非常に簡単に回避できます。

1つのコールバックは大したことではありません。 ただし、そのコールバックは、オブジェクトと中間のコールバック、Promise、およびサブスクリプションに依存します。 多くのコンポーネントがこれを行うと、すぐにメモリの問題が発生します

makeCancellableは、コンポーネントへの参照を保持する関数への参照を保持することになる別のPromiseを作成するだけです。 makeCancellableソリューションは、ブールプロパティisMountedをpromiseに移動するだけです。

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の遅延オブジェクトでそれを行う方法です。 私はPromiseAPIにあまり詳しくないので、どのように表示されるかわかりません。 また、cancel（）が呼び出され、遅延が解決されていない場合、これは遅延を拒否しません。 おそらく、これがどのように機能するかについて、人々は異なる意見を持っています。

したがって、チェーンは次のようになります。

AJAXリクエスト->クロージャ-> CancellableDeferredInstance-> JQuery Deferred-> Component

キャンセル後は次のようになります。

AJAXリクエスト->クロージャ-> CancellableDeferredInstance /オブジェクト参照がnullになりました/ JQuery延期->コンポーネント

そのため、AJAXリクエストは、コンポーネントがGCdになるのを妨げなくなりました[延期への参照を誤って保持することによって、どこかで実装を台無しにしていないと仮定します。 イェーイクロージャー....]

こんにちは@benmmurphy 、私はJSガベージコンパイルにあまり精通しておらず、Reactでは動作が異なる可能性がありますが、理解は異なります。

makeCancellable使用すると、Reactコンポーネントをマウント解除時にガベージコレクションできます。 説明します。

makeCancellableは、コンポーネントへの参照を保持する関数への参照を保持することになる別のPromiseを作成するだけです。 makeCancellableソリューションは、ブールプロパティisMountedをpromiseに移動するだけです。

makeCancellable ：

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

makeCancellable ：

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

makeCancellableがなくても、 thisへの参照があるため、コンポーネントがマウント解除されたときにガベージコレクションを行うことはできません。 ただし、他のケースでは、コンポーネントがマウント解除されるとすぐにキャンセル可能なPromiseの失敗ハンドラーが呼び出されるため、参照がぶら下がることはありません。

@vpontis

問題を説明するnodejsコードがいくつかあります。 Fooコンポーネントは、非同期コールバックresolveがnullに設定された場合にのみGCされます。 たとえば、解決に30秒かかるajaxリクエストを実行してから、コンポーネントがアンマウントされたとします。 その後、コンポーネントは30秒間GCdされません。 これは、isMount（）の廃止で解決しようとしている問題の1つです。

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

編集：

あなたの前で話してすみませんが、初めて投稿を読んだとき、あなたが何をしようとしているのか理解できませんでしたが、今は理解していると思います。 エラーコールバックにコンポーネントへの参照が含まれていない（またはコンポーネントへの参照に従わない）ため、コンポーネントはPromiseによって参照されているとは見なされないということです。 これは実際には真実です。 さて、最初の部分は本当です。 ただし、この推論には問題があります。

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されていることをテストすることを確認してください。 私はまだ私のテストをしていません、そして私がいくつかのばかげたエラーをしたのでそれがうまくいかなくても私を驚かせません：/

promise 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はまだどのブラウザにも実装されていませんが、NPMで利用できるポリフィル「abortcontroller-polyfill」を作成しました。 ポリフィルは、 @ istarkovによって投稿されたコードと基本的に同じことを行いますが、

詳細はこちら：
https://mo.github.io/2017/07/24/abort-fetch-abortcontroller-polyfill.html

React.createClassはReact 16に存在しなくなり、新しいcreate-react-classパッケージにはisMounted明確な非推奨メッセージが含まれているため、これを終了します。

私は@istarkovのソリューションを効果的に使用するのと同じであることを@benmmurphyに同意isMounted() 、それがガベージコレクションの問題を解決していないので。

@benmmurphyのソリューションはより近いですが、間違った変数をnullにするため、promiseハンドラーは逆参照されません。

重要なのは、ハンドラーを逆参照するクロージャーを介して関数を渡すことです。

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パッケージに変換しました。 そして、ユースケースはreactであるため、 promiseを追跡し、コンポーネントがマウント解除されたときにそれらをキャンセルするHOCコンポーネントを作成しました。

編集：私の悪い、私はちょうど@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年ですが、上記のアプローチよりもさらに優れたアプローチはありますか？

はい、React Nativeの2倍のサイズのドキュメントがありますが、非常に専門的なナビゲーションフレームワークを使用できます。

約束を「キャンセル」するためのこれらのスニペットは、それほど素晴らしい私見ではありません。 キャンセルされたプロミスは、元のプロミスが解決するまで解決されません。 したがって、メモリのクリーンアップは、isMountedトリックを使用した場合に発生するまで発生しません。

適切なキャンセル可能なpromiseラッパーは、2番目のpromiseとPromise.raceを使用する必要があります。 つまり、 Promise.race([originalPromise, cancelationPromise])

@benmmurphyのソリューションはより近いですが、間違った変数をnullにするため、promiseハンドラーは逆参照されません。

私のソリューションは機能すると思いますが、javascriptランタイムが確実に知ることを約束するものについては十分にわかりません。 テストハーネスのノードの下でソリューションを実行すると、値が正しくGCされます。 私のソリューションでは、解決/拒否関数をより高いスコープに割り当て、cancelが呼び出されたときにこれらの値を無効にしました。 ただし、関数は引き続き下位スコープで使用可能でしたが、参照されていませんでした。 最近のJavaScriptエンジンは、参照されていない限り、クロージャ内の変数をキャプチャしないと思います。 これは、人々が次のようなことをしたために誤ってDOMリークを作成するという大きな問題だったと思います。varelement= findDOM（）; element.addEventListener（ 'click'、function（）{}）; クロージャーで使用されていなくても、要素はクロージャーで参照されます。

@hjylewis @benmmurphyなぜハンドラーを逆参照する必要があるのですか？ ハンドラーが実行された後、ガベージコレクションはどうにか起こりますよね??

約束を「キャンセル」するためのこれらのスニペットは、それほど素晴らしい私見ではありません。 キャンセルされたプロミスは、元のプロミスが解決するまで解決されません。 したがって、メモリのクリーンアップは、isMountedトリックを使用した場合に発生するまで発生しません。

適切なキャンセル可能なpromiseラッパーは、2番目のpromiseとPromise.raceを使用する必要があります。 つまり、 Promise.race([originalPromise, cancelationPromise])

@hjylewisと私のものは実際に動作しますか？ノードweakで検証できます。 しかし、それらをもう一度見ると、どちらも特異な書面による約束コードではないことに同意します。 promiseユーザーとして、「キャンセルされた」promiseが拒否された状態で解決されることを期待する可能性がありますが、どちらもこれを行いません。 ただし、コンポーネントの場合、これは、拒否ハンドラーを無視するために余分なコードを記述する必要がないため、より使いやすいソリューションです。

特異体質の拒否可能なpromiseは、Promise.race（[]）を使用してキャンセル可能なpromiseを構築すると思います。 これは、Promiseが解決されると保留中のコールバックが削除されるため、その時点で、レースPromiseとコンポーネントの間に参照がなくなるため、ブラウザーネットワークからコンポーネントへの参照チェーンがなくなるために機能します。

これらのキャンセル可能な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();