React: 【傘】サスペンスを放す

unstable_AsyncMode公開します（多分？）

これはすでに公開されていませんか？

unstable_を削除する

名前のないコード分割ライブラリのオープンソースを楽しみにし

[傘]とはどういう意味ですか？🤔☂️

つまり、これはいくつかのプロジェクト/パッケージ/ツールに影響を与える機能です。

@ghoullierなるほど、ありがとうございました！

ねえ@acdlite 、これに最適な準備をする方法についての質問です。 どんな種類のタイムラインも求めていない/期待していないが、疑問に思っている：

現在、これらの機能がReact 16に組み込まれ、16.3でリリースされた新しいContext APIのように、段階的に簡単に採用できることを期待していますか？

それとも、Reactをv17にプッシュし、採用するためにより多くの作業が必要になると思いますか？

私はあなたのリストにあるほとんどすべてのものと大幅に交差するロードマップに取り組んでおり、それに対処するための最善の方法を模索しているので、尋ねます。

また、最善の準備方法に関するヒントはありますか（今日書かれたコードに関して、Reactのこれらの改善と将来互換性を持たせたい）-ポリフィル/テクニックなど？

（これらの質問が他の場所で回答され、私がそれらを見逃した場合はお詫びします）

@JedWatsonの質問に別の質問を追加します。

• また、安定したリリースのタイムラインを取得する必要はありませんが、新しいプレリリースを取得することは可能/有用でしょうか？ （AFAIKの最新リリースは2月から16.4.0-alpha.0911da3です。）

ありがとう！ ❤️

IMO、彼らはそれが上陸する前のように以前のようにブログ投稿を提供するでしょう。

そして、重大な変更がないため、あまり準備する必要はないと思います（サスペンスを使用したreduxフェッチなど、現在のプラクティスとは異なる/競合しているように見える多くの機能がありますが、codemodまたは簡単なカプセル化がありますこれを行うには、fbに3W以上のコンポーネントがあります）。 また、 @ acdlite （ZEITのssrサスペンスについて）と@gaearon （アイスランドのクライアントサスペンスについて）の話を見ると、あまり心配する必要がなく、侵襲的ではないことがわかります。

ちなみに、レポで「傘」キーを検索するだけで、＃8830や＃12152などの詳細情報が見つかります。

AFAIKの最新リリースは2月の16.4.0-alpha.0911da3です。

IIRC、これは誤操作ですか？

@JedWatsonこのコメントは、アプリケーションが非同期セーフであることを保証するために開発者が何をしなければならないかを理解するのに役立ちました。

Facebookでサスペンスモジュールと新しいAPIの展開に取り組んでいます。 @acdliteが何か他のことに忙しい場合に

現在、これらの機能がReact 16に組み込まれ、16.3でリリースされた新しいContext APIのように、段階的に簡単に採用できることを期待していますか？

React 16と17のどちらが付属するかはわかりません。Reactチームによると、Facebookでの動作や、関連するAPIの準備状況によって、今年末までにリリースされる可能性があります。いいえ。 しかし、コードに関しては、Facebookでかなり長い間実験を行ってきたので、採用するのは簡単だと言って嬉しいです。 サスペンス機能は、既存のコードベースでも引き続き機能します。 ただし、追加の変更（非同期レンダリングなど）を使用すると、新機能によってもたらされるボーナスが増えます。

最善の準備方法に関するヒントはありますか（今日書かれたコードに関して、Reactのこれらの改善と将来互換性を持たせたい）-ポリフィル/テクニックなど？

移行はかなり段階的で進歩的だと思います。 @ NE-SmallTownが言ったように、私たちは重大な変更を導入したくありません。 コードベースが非常に大きいため、Facebookに展開するのも面倒です。 しかし、これまでのところ、展開はスムーズであり、追加の変更を行う必要はありません。

@JedWatson

現在、これらの機能がReact 16に組み込まれ、16.3でリリースされた新しいContext APIのように、段階的に簡単に採用できることを期待していますか？

徐々に。 常に段階的に:)そうでなければ、Facebookでこれを出荷する方法はありません。

これが私が期待していることです：

| | クライアント| サーバー側のレンダリング|
| ----------------- | ---------------------------- |- -------------------------------------------- |
| サスペンス| どこでも動作します* | 既存のサーバーレンダラーと同じ制約|
| 非同期レンダリング| <AsyncMode>を使用したオプトイン| 既存のサーバーレンダラーと同じ制約|

*同期モードでは、 delayMsは常に0です。 プレースホルダーはすぐに表示されます。

サスペンスは、既存のコンポーネントに変更を加えることなく機能します。 ある時点で<StrictMode>互換性が必要になるかもしれないと思っていましたが、内部テスト中に、厳密モードにアップグレードするための最良の方法の1つはサスペンスを使用することでした。 鶏が先か卵が先かというジレンマ。 そこで、strictモードの外でも機能させる方法を見つけました。

つまり、ユーザーは非同期レンダリングに移行する準備ができる前であっても、サスペンスへの移行を開始するという考え方です。 次に、サブツリーの準備ができたら、 <AsyncMode>ラップしてオプトインできます。

ただし、新しいアプリの場合、話は異なります。デフォルトで非同期になります。 非同期のみの新しいルートAPI（ ReactDOM.render代わり）を紹介します。

最初のリリース後、多くのサードパーティフレームワーク（Redux、Apollo、React Router ...）が非同期モードで正しく機能しない可能性がある厄介な期間があります。 それはしばらくの間採用を傷つけるかもしれません。 しかし、その考え方は、新機能が非常に魅力的であるため、ライブラリが適応するか、非同期互換の代替手段に取って代わられるのにそれほど時間はかからないということです。

また、最善の準備方法に関するヒントはありますか（今日書かれたコードに関して、Reactのこれらの改善と将来互換性を持たせたい）-ポリフィル/テクニックなど？

すべてを<StrictMode>ラップし、警告がないことを確認します。 リリースが近づくにつれて、より詳細な移行ガイドが提供されます。

最初のリリース後、多くのサードパーティフレームワーク（Redux、Apollo、React Router ...）が非同期モードで正しく機能しない可能性がある厄介な期間があります。

アポロは厄介なことはしません-私たちは準備ができています！ 🕺😳

真面目な話ですが、私たちは：heart：すべてがReactなので、最初のリリースでこれらの変更に対応していることを確認することは、優先度が高いだけでなく、私たちが非常に興奮していることでもあります。 この@acdliteでのすばらしい作業に感謝します！

チャイムを鳴らして、ReduxチームがReact-Reduxの非同期互換性に取り組んでいると言います。

https://github.com/reduxjs/react-redux/issues/950で潜在的なロードマップをレイアウトしました。 TL; DR：

• React-Redux 5.1は、警告なしで<StrictMode>で動作することを願っています（現在のPR：https：//github.com/reduxjs/react-redux/pull/980）
• 6.0は、新しいコンテキストAPIを使用し、参照転送を追加し、場合によってはその他の変更を加えるための内部書き換えになりますが、現在のパブリックAPIをできるだけ多く維持するようにしてください（つまり、 <Provider>とconnect() ）。 それが非同期レンダリングでどれほどうまく機能するかを見て、前進するための最良の道を見つけます。 （私の以前の概念実証PRはhttps://github.com/reactjs/react-redux/pull/898にありますが、5.1の作業から学んだ他の教訓に基づいて、おそらくやり直します。）このリリースでは、新しいコンテキストと、おそらくマージされたばかりのまだリリースされていない「ライフサイクルメソッドからのコンテキストの読み取り」PRが必要なため、少なくともReact16.5が必要になります。
• その後、別のReact-Redux APIのアイデアを受け入れます（はい、はい、レンダリングの小道具や人が含まれる可能性があります）。

WIPにもっと注目していただければ幸いです。また、React Suspenseと非同期レンダリングでReduxをどのように使用しているかについて、ユースケースが適切にカバーされるように、フィードバックやディスカッションを提供していただければ幸いです。 また、Reactチームと、どのような制約を処理する必要があるかについてさらに話し合うことを望んでいます。すべての問題を解決するために必要な問題を確認できるサンプルアプリを入手できれば便利です。これは正しく機能します。

非同期レンダリングとサスペンスのリリースを楽しみにしています

@acdliteサスペンスと非同期レンダリングについても質問します。
私の質問は、それらが導入されて、その新しいバージョンのreactでアプリを書き始めると、それは、react APIと、reactでの人々のコーディング方法も変わることを意味しますか？ （サスペンスと非同期レンダリングの機能を使用する予定がない場合でも？）

サスペンスと非同期レンダリングを使用してreactコードを作成するのは難しいと思いますが（おそらくいくつかの新しいAPIまたはその他の制約のため）、それを必要としない人にとっては、なぜ新しい方法でreactを使用するように強制するのですか？ そして、彼らが今のように反応してコーディングすることを許可しませんか？

サスペンスでreactコードを書くのは難しいかもしれないと思います

私の話の後半を見る機会がありましたか？ 私はまったく逆だと思います—データフェッチにサスペンスを使用することは、他の何よりも（Redux、ローカル状態、または他のライブラリを含む）、はるかに難しいことではありません。

@gaearon私はしていません。 私は理論的にもっと話していました。 反応を知っている人々のセットがすでにあると想像してください。 人々が非同期レンダリングとサスペンスの機能を必要としないのなら、なぜ彼らに「新しい」反応を学ばせるのでしょうか？ 特に「新しい」反応を使用するのが難しい場合はどうでしょうか。 しかし：私は十分な情報を持っていないので、「トリッキー」な部分について間違って言うかもしれません-私は私の考えのいくつかを共有しているだけです:)。

ある意味で、アプリの10％にサスペンスと非同期レンダリングの機能が必要な場合、他の90％のケースでは、なぜ人々に「新しい」反応を学ばせるのでしょうか。 しかし、サスペンスと非同期レンダリングに関する情報をまだ多く収集していなかったため、間違っている可能性があります。

私のデモをまだ見ていないと、会話をするのは難しいと思います。

明確にするために： 「新しいReact」はありません。これらの機能は既存のパターンを壊しません🙂。 それらは相加的です。 これらの機能を使用するために、まったく異なる方法でコードを記述する必要もありません。ただし、一部の機能は、最新のライフサイクルメソッドを

これはあなたの懸念とは直接関係ありませんが、私はそれらが「使用するのが難しい」ということに同意しません。 サスペンスは、現在存在する他のどのロードメカニズムよりもはるかに簡単に使用できると思います。 それが私がとても興奮している理由です。 ただし、必要がなければ、新しい機能古いパターンは機能し続けます。

私は本当に私の話を見ることをお勧めします。 これらの機能が実際に動作しているのを見ると、これはもっと理にかなっていると確信しています。

@gaearon

古いパターンはすべて機能し続けます。

フィードバックをありがとうダン。 そうですね、そういう機能が必要ないのなら、機能が追加される前のやり方で書けるはずだと思います。

幸運を。

ちょっとダン（@gaearon）、私はつまらないことではありませんが、それを理解したいと思います。 あなたの上に言った：

ただし、必要がなければ、新しい機能を使用する必要はありません。 古いパターンは機能し続けます。

これは、「古い」Reactで行ったのと同じ方法で新しいReactでコーディングできることを示唆します。たとえば、ライフサイクルメソッドを同じ方法で使用できるなどです。

ただし、ここで、bvaughnは、getDerivedStateFromProps（またはcomponentWillReceiveProps）は、1回の更新で何度も呼び出される可能性があるため、その中のデータをフェッチしないソリューションであると述べています。

だから私の質問は、結局のところ、新しいReactを以前とまったく同じように使用することはできないようですよね？ 現在のreactcomponentWillReceivePropsのAFAIKは、1回の更新で何度も呼び出されないので、そうではありませんか？

@ giorgi-m：はい、ライフサイクルメソッドは変更されていますが、要点は、サスペンス自体がオプトイン機能であるということです。 既存のすべてのReactレンダリングメソッドとReactのレンダリング動作はそのまま機能します。 ただし、アプリの一部に<AsyncMode>タグを追加してオプトインすると、非同期データのニーズを示すためにSuspenseのアプローチを使用し始め、それを利用できるようになります。 それをコードベースに追加しないと、それは起こりません。

@ giorgi-m componentDidUpdate componentWillReceivePropsまたはgetDerivedStateFromProps代わりにcomponentDidUpdateを使用する必要があります。

@markeriksonつまり、ここでbvaughnが言ったことは、 <AsyncMode/>有効にしていない場合、1回の更新で_getDerivedStateFromProps_を何度も呼び出すことができるということですが、必ずしもそうとは限りません。
（そのような質問をして申し訳ありませんが、時々私にポップアップし、すべてをカバーするリソースが見つかりませんでした）。

ps。 bvaughnはまた、リンクされたスレッドでそれのオプション性について言及していなかったので、それは私の疑いを引き起こしました。

非同期更新をキューに入れるためのメソッド（たとえば、レンダラー固有のunstable_deferredUpdates()ではなくクラスコンポーネントのdeferSetState() unstable_deferredUpdates() ）をコアチェックリストに追加する必要がありますか？

私の理解では、非同期modeファイバーの更新は非同期になります。つまり、理論的にはdeferSetState()は不要です。 ただし、 unstable-async/suspenseデモでは、同期更新と非同期更新が混在しているため、 asyncモード（「ユニバーサル」コンポーネントの場合）でこれをどのように実行できるかわかりません。

タイムスライス傘のチェックリストに載っています。

コンポーネントタイプとしてpromiseをサポート

これに関連して、あなたが持っているとき：

const PromiseType = new Promise(() => {})
class A extends Component {
    componentDidMount() {}
    componentDidUpdate() {}
    render() {
        return <div><PromiseType></PromiseType></div>
    }
}

componentDidMountとcomponentDidUpdateライフサイクルがいつ呼び出されるかについてのヒューリスティックはありますか。

1. すべての子供が解決されたとき（約束を含む）、これは、約束が決して解決されない場合、子供が呼び出されないことを意味しますか？
2. すべての即時ホストの子がレンダリングされたら？

@thysultan ： componentDidMountとcomponentDidUpdateは、UIツリーが完全にレンダリングされてDOMに適用されたときに、コミットフェーズで呼び出されます。

したがって、サスペンスについての私の理解に基づくと、答えは、 Aインスタンスが実際にマウントされることは決してないということだと思います。 PromiseType _did_が解決されたが、その子孫の1つも解決されない約束を待とうとした場合、再びマウントされることはありません。 したがって、これらの例ではcDMとcDUは実行されません。

（ここで私の仮定が間違っている場合は、誰かが私を修正してください:)）

ええ、 componentDidMountまたはcomponentDidUpdateは、ツリー全体が解決された後にのみ実行されるコミットフェーズでのみ実行されます。 このツリーには、明示的に配置したプレースホルダーが含まれている場合があります（十分に待機した後も、その中の何かが中断するかどうかによって異なります）。ただし、プレースホルダーなしで子を明示的にレンダリングすると、最終的には「準備ができていない」状況。

私はこれで遊ぶことができることを本当に楽しみにしています（あなたがまだワールドワイドウェブにこれの実用的なバージョンを置いていないことを理解するためだけにたくさんのソースコードを閲覧しました）。

これをリリースするために私たちにできることはありますか？ ：D

プレイしたい場合は、マスターからコンパイルできます。 fixtures/unstable-async/suspense手順を参照してください

@gaearonこれは現在の状態のクライアント側のみであると私は正しいですか（サーバー側のレンダリングをサポートするためにさらに多くの作業を行う必要があります）？

編集、答えを見つけました：ユニバーサルアプリのSSRでサスペンスを使用することを熱心に探している他の人のために。 私はこれが今のところクライアント側であることを私たちに知らせるダンによるhttps://www.youtube.com/watch?v=z-6JC0_cOnsも示してい

実際、SSRのケースに関連する作業を間もなく開始します。

ローエンドのモバイルデバイスで実行されている非同期Reactアプリでこのシナリオを想像してみてください。

1. すべてのCPUを使用した外部広告の読み込みがあります（😓）
2. ユーザーがリンクをクリックすると、ルーターが新しいレンダリングをトリガーします
3. Reactは非同期モードであるため、Chrome / SafariがCPUの使用を許可するまで待機しますが、広告はさらに3秒間読み込まれ続けます
4. ユーザーはアプリが機能していないと考えています

この問題は、サスペンスで説明したのと同じ<Placeholder>テクニックを使用して回避できます。たとえば、1秒後にスピナーが表示されます。

このシナリオは考慮されていますか？ <Placeholder>は遅い非同期レンダリングで機能しますか？

@luisherranzこれを防ぐには2つのメカニズムがあります。

1. Reactには、すべての更新に関連付けられた期限があります。 クリックやこのような他のインタラクションからの更新は、より長い期限を明示的に選択しない限り、約150ミリ秒以内にフラッシュされるはずです（たとえば、必須ではない更新の場合）。 そのため、何かがスレッドを占有している場合、Reactは同期的にフラッシュを強制します。

2. Reactは、実際にはrequestIdleCallback使用しなくなりました。これは、実際、ブラウザーがそれをスケジュールするのに十分積極的ではないためです。 正確なスケジューリングアプローチも時間の経過とともに変化する可能性がありますが、これは間違いなく私たちが気にかけていることです。

ダンの素早い回答に感謝します。

1. Reactには、すべての更新に関連付けられた期限があります

素晴らしい。 テストできるAPIはすでに用意されていますか？

1. Reactは実際にはrequestIdleCallbackを使用しなくなりました。これは、実際にブラウザーがそれをスケジュールするのに十分積極的ではないためです。

それは私たちも実験したことです。 TwitterやYouTubeからの外部広告や埋め込みがある混雑したアプリでは、 requestIdleCallbackが呼び出されてレンダリングが完了するまで、数秒かかる場合があります。 だから👍それに。

ところで、私たちにとって、あなたの最初の答えに関連する別のユースケースがあります：私たちは2つのオフセットを持つレイジーロードを使用しようとしています。 1つ目は非同期レンダリングをトリガーし、2つ目は非同期が終了していない場合に同期レンダリングをトリガーします。 このようなもの：

1. ユーザーが下にスクロールすると、重い要素から1200pxになります。たとえば、ブログの次の投稿です。
2. 最初のoffetは、次の投稿の非同期レンダリングをトリガーします。
3. ユーザーは下にスクロールし続け、次の投稿の600pxになります。
4. 2番目のオフセットトリガー：非同期投稿が終了した場合（componentDidMountが呼び出された場合）は何も起こりませんが、終了しなかった場合は、投稿全体の同期レンダリングがトリガーされます。

したがって、時間の代わりに、2番目のトリガーでフラッシュを制御したいと思います。 それは意味がありますか？ それは可能でしょうか？

テストできるAPIはすでに用意されていますか？

マスターを意味するかどうかはわかりませんが（非同期モードはnpmリリースでは公式には利用できません）、有効期限はすべての更新に自動的に割り当てられます。 クリックなどのイベントの場合、本番モードでは約150ミリ秒です。 特別な不安定なAPIが必要な場合は、延期された（より長い）更新を選択できますが、設定することはできません。

したがって、時間の代わりに、2番目のトリガーでフラッシュを制御したいと思います。 それは意味がありますか？ それは可能でしょうか？

ええ、それは可能です。 私はここでこのようなメカニズムを説明しました： https ：//github.com/oliviertassinari/react-swipeable-views/issues/453#issuecomment-417939459。

マスターを意味するのかどうかはわかりません（非同期モードはnpmリリースでは公式には利用できません）

はい、 <unstable_AsyncMode> 、 flushSync 、 unstable_deferredUpdatesのnpmパッケージを使用しています。

npmにこれらの変更を加えて、アルファ/ベータバージョンのリリースを開始してください。 🙏

ええ、それは可能です。 私はここでこのようなメカニズムを説明しました：oliviertassinari / react-swipeable-views＃453（コメント）。

素晴らしい。 unstable_deferredUpdatesを使用した現在の実装よりもはるかに優れています:)

<div hidden>使用を開始するのが待ちきれません。 あなたたちは素晴らしい仕事をしています。

@luisherranz注意してください、それらのものは不安定です。 バグがあるか、かなり非効率的である可能性があります（たとえば、重要な最適化（「再開」）はまだ実装されていません）。 新しいscheduleモジュール（ schedule.unstable_scheduleWork ）を優先して、 unstable_deferredUpdatesも削除します。

はい、アプリのごく一部にのみ使用し、集中的にテストしていますが、これまでのところ非常に優れています:)

オフトピックになる可能性があります：
requestIdleCallbackは1秒間に20回しか呼び出されません-6x2コアのLinuxマシン上のChromeは、UI作業にはあまり役立ちません。
requestAnimationFrameはより頻繁に呼び出されますが、名前が示すタスクに固有です。

このため、 requestIdleCallback使用を停止しました。

requestIdleCallback代わりに何を使用していますか？

@TejasQ https://github.com/facebook/react/tree/master/packages/scheduler

もちろん。 愚かな私。 スケジューラモジュールがrequestIdleCallback代わりに内部でどのブラウザAPIを使用するのか疑問に思いました。 もっとはっきりと質問を提示すべきだった。 😅

わあ、見つけた。
https://github.com/facebook/react/blob/eeb817785c771362416fd87ea7d2a1a32dde9842/packages/scheduler/src/Scheduler.js#L212 -L222

それは次のレベルのクールです。

こんにちは、

サスペンスを理解しようとしているときに、 Suspendコンポーネントを使用しているときにアプリのどの部分が実際に「一時停止」されているのかわからないことに気づきました😳😱。

次の例では、 Titleがすぐに表示され、 Spinner 1000ミリ秒後に、 UserData 〜2000ミリ秒後に表示されると予想します（そのコンポーネントのデータの「ロード」には2000ミリ秒かかるため）。
しかし、私が見ているのは、 Titleが1000ms後にSpinnerと一緒に最初に表示されることです。

// longRunningOperation returns a promise that resolves after 2000ms
const UserResource = createResource(longRunningOperation);

function UserData() {
  const userData = UserResource.read(cache, "Lorem Ipsum");
  return <p>User Data: {userData}</p>;
}

function Spinner() {
  return <h1>Fallback Loading Spinner</h1>;
}

function Title() {
  return <h1>Hello World</h1>;
}

function App() {
  return (
    <React.Fragment>
      <Title />
      <Suspense maxDuration={1000} fallback={<Spinner />}>
        <UserData />
      </Suspense>
    </React.Fragment>
  );
}

unstable_createRoot(document.getElementById("mount")).render(<App />);

（React 16.6.0-alpha.8af6728を使用する完全な例はここcodesandboxにあります）

Titleすぐに表示して、アプリケーションの他の部分だけを「一時停止」する方法はありますか？ それとも、おそらくサスペンスを完全に誤解しましたか？ （この種の質問をするより良い方法があれば、私に知らせてください）

ありがとう！

こんにちは@nilshartmann！ 素晴らしい質問です！

タイトルをすぐに表示して、アプリケーションの他の部分だけを「一時停止」する方法はありますか？

私が正しく理解している場合は、この例のようにTitleをDOMにフラッシュする前に、Reactに明示的に_待機しない_ように指示して、 Titleすぐに表示し、他の部分のみを「一時停止」する必要があります。すぐにレンダリングされると予想される部分を<Suspense maxDuration={0}>ラップすることにより、アプリケーションの一部を作成します。

これは、基礎となる低レベルのスケジューラメカニズムが原因であると思いますか？ 私もこれをもっとよく理解したいのですが、それで今のところあなたの問題は解決するはずです。

実際にそこで何が起こっているのか聞いて興奮しています。

（この種の質問をするより良い方法があれば、私に知らせてください）

あるかわかりません。 😄それは私には非常に明白に思えます。 質問してくれてありがとう！

@TejasQ私のブラウザでは、サンプルをロードすると、フォールバックスピナーがすぐにレンダリングされます。 1000ms後にロードするべきではありませんか？

@TejasQはあなたの答えに感謝します、しかし@karlhorkyは正しいです：今スピナーはすぐに現れます。

うわぁ！ 私は逃しました。 私は試した。 😅それをもう一度見て、あなたに戻ってきましょう。 私は何かを逃したに違いない。 🤷‍♂️

〜更新：私はここでそれを理解しようとしています。誰かがリアルタイムで一緒にそれを行うことに興味があれば、私たちは協力することができます。〜

2番目の更新： @ philipp-spiessと私はそれを見ました、そして私は本当に困惑しています。 私はまだそれを理解していません。 現時点では、これが実際にはunstable_とアルファ機能であるため、バグなのか、それとも単に表示されていないものなのかはわかりません。

どちらの場合でも、コアチームは役立つ回答を得るか、質問を使用してReactをさらに優れた/より親しみやすいものにすることができると思います。

彼らが何を言わなければならないか見てみましょう。 😄これを指摘してくれてありがとう、@ nilshartmann！

これはReactv16.6の一部としてリリースされましたか？ ブログ投稿には、Suspenseを使用したサンプルコードが示されています。

import React, {lazy, Suspense} from 'react';
const OtherComponent = lazy(() => import('./OtherComponent'));

function MyComponent() (
  <Suspense fallback={<div>Loading...</div>}>
    <OtherComponent />
  </Suspense>
);

これはReactv16.6の一部としてリリースされましたか？

遅延読み込みのユースケースのみ、および同期モードのみ。 並行モードは引き続きWIPです。

@nilshartmann

次の例では、Titleがすぐに表示され、Spinnerが1000ミリ秒後に、UserDataが約2000ミリ秒後に表示されると予想します（そのコンポーネントのデータの「ロード」には2000ミリ秒かかるため）。

maxDuration機能について少し混乱していると思います。 これは新しいメンタルモデルですが、これを文書化する時間はまだありません。 そのため、並行モードが安定したリリースになるまで、しばらく混乱し続けるでしょう。

フックの提案を発表しておめでとうございます。 チームと何かを共有したいと思います。 少し前に、Suspenseに似た機能を持つReactAsyncというコンポーネントをリリースしました。 基本的に、Promiseの解決を処理し、isLoading、startedAt、reloadやcancelなどのメソッドをすべて宣言型APIで提供します（ useAsyncフックが進行中です）。

今、私の主な関心事は、これがサスペンスとどのように統合されるかです。 ほとんどの場合、私はおそらくReactAsyncのSuspenseAPIを使用して、Suspenseのスケジューリング機能を無料で提供しながら、使い慣れたシンプルなReact AsyncAPIをユーザーに提供できます。 私が見てきたことについては、React Async APIは、より抽象的なSuspense APIと比較して、より賢明で親しみやすいものだと心から思っています。 基本的に、React Asyncは、ユースケースのわずかに小さいサブセットで機能するより具体的なAPIを提供しようとします。

ReactCacheライブラリを知って驚いた。 React Asyncの場合、私は意図的にキャッシュメカニズムを含めませんでしたが、バニラプロミスを処理することを選択しました。 その上にキャッシュを追加するのはかなり簡単です。

最後に、カスタムフックからサスペンス機能にアクセスすることを懸念しています。 サスペンスはいくつかの組み込みコンポーネントに大きく依存しているようで、フックからこれらを使用することは不可能です（私は思いますか？）。 サスペンスフックはありますか？ または、2つを統合する他の方法はありますか？

こんにちは。 Suspense / Lazyでコードをテストするにはどうすればよいですか？
現在、renderer.create（...）toTree（）がスローします
「toTree（）は、tag = 13のノードを処理する方法をまだ知りません」

Suspenseの小道具maxDurationが、同期モードと同時モードの両方ではなく、 Concurrent Modeでのみ使用される理由。 誰かが説明するのを手伝ってもらえますか？

（現時点では） Concurrent Modeがこのツリーを保留にしてから、強制的にコミットするまでの期間を意味します。これは、タイムスライスの期限を効果的に制御し、同期モードではタイムスライスは存在しません。 ツリーをコミットする前に待機すると、必然的にコミットが行われます...同期ではありません。

私はデータフェッチ用の内部アプリケーションでSuspenseを使用してきましたが、データフェッチ用にまだ使用されていない理由にすぐに気付きました。

ただし、最終的には、データのフェッチに使用することを目的としています。 おそらくキャッシュプロバイダーを除いてAPIが大幅に変更される可能性は低いと思われる場合、データをフェッチした後にデータを変更する必要がある場合、Suspenseはどのように機能するのでしょうか。

例として、これは私のアプリケーションからの本当にひどいフックです。

function useComponentList(id) {
  const incomingComponents = useSuspenseFetch(
    React.useCallback(() => getComponentAPI().listComponents(id), [id])
  )

  const map = React.useMemo(
    () =>
      Map(
        (incomingComponents || []).map(component => [component.id, component])
      ),
    [incomingComponents]
  )

  return useCacheValue(map)
}

このフック：

1. 指定されたエンドポイントから指定されたコールバックを使用してデータをフェッチします
2. そのデータをImmutableJSマップに変換します-これは潜在的にコストがかかるため、操作をメモします。
3. useCacheValueでラップされたマップを返します。これは、特に厄介なビットです。

useCacheValueは次のようになります。

export default function useCacheValue(value) {
  const [state, setState] = React.useState(value)
  React.useEffect(() => {
    setState(value)
  }, [value])

  return [state, setState]
}

value変更（データが再フェッチされたことを示します）に応答するフックであるという考えで、ユーザーはその状態の反応アプリ表現を変更できます。 ある意味で、それは非常に悪いキャッシュのように機能します（そのため名前が付けられています）。

このパターンが現在の状態のReduxでどのように機能するかを確認するのに苦労しています。 私ではないプログラマーによって書かれたとき、そしてサスペンスがデータフェッチの「準備ができている」とき、これがどのように見えるかについての発見はありましたか？ 現状では、これは命令型フェッチフラグを使用してReduxを単独で使用するよりもはるかに面倒です。

Reduxが独自のフックを持っていると、これはおそらくはるかに簡単になります。これは、Reduxが公開されることを意図していないコンテキストでHOCを使用することが主な難しさであるためですが、それでも公式の内容を確認したいと思います。答えは:)

サスペンスは、外部キャッシュ（状態によって駆動されるフックではない）で機能することを目的としています。 単純なユースケースで機能するこのようなキャッシュのリファレンス実装を提供します。 リレーは独自のキャッシュメカニズムを実装します。 他のツール（Apolloなど）も、互換性のある独自のキャッシュを実装できるようになり、これら2つの実装に触発される可能性があります。

答えが必要な質問は、突然変異/無効化だけではありません。 また、スピナーを表示するタイミング、吊り下げられたツリーの外側にある「インラインインジケーター」などの一般的なパターン、読み込み状態の調整（トップダウンの順序でロックを解除する必要があるもの、またはそのまま入ってくる必要があるもの）についても考慮する必要があります。準備完了）、リストのストリーミングレンダリング、これが部分的な水分補給にどのように影響するかなど。 私たちはこれらのことに取り組んでいますが、それらのいずれにも「公式の推奨事項」はまだありません。 ある場合は、更新を発表するブログからわかります。

ちなみに、データフェッチのサスペンスは、人々が慣れているものとは十分に異なるメンタルモデルです。 Reduxのような非常に制約のないメカニズムと統合した場合、必ずしもそれほど強力になると期待するのは公平ではないと思います。 しかし、私たちは見るでしょう。 今は何も言えません。

@gaearon 「私たちはこれらのことに取り組んでいます」と言うとき、私が購読できる問題はありますか、それともこれらの議論は非公開で行われていますか？

ありがとう、 @ gaearon :)

@ntuckerいつものように、進行中のアクティビティをPRとして見ることができます。 たとえば、次のようにhttps://github.com/facebook/react/pull/14717 、 https://github.com/facebook/react/pull/14884 、 https://github.com/facebook/react/pull/15061 、 https://github.com/facebook/react/pull/15151 、 https://github.com/facebook/react/pull/15272 、 https://github.com/facebook/react/pull/15358 、 HTTPS ：//github.com/facebook/react/pull/15367など。 各PRに説明的な情報を入れようとしていますが、テストによる動作の変化を確認できます。 実験のドキュメントバーは、いくつかの理由で低くなっています。

実際に機能することを確信した後、選択したモデルに関するより完全な説明を投稿します。 すべての実験を詳細に説明することは、私たちにとってもコミュニティにとっても生産的ではないと思います。 私たちの最初の実験のほとんどは失敗し、それらのすべてを文書化して説明すると、私たちの作業が遅くなります。

さらに悪いことに、これにより、人々が、元々設計された方法では機能しないことに後で気付く何かの周りにメンタルモデルを構築する結果になることがよくあります。 （削除したばかりのmaxDurationで発生しているように。）したがって、時間と時間の両方を有効に活用できるようになるまで、中途半端なアイデアの共有を控えたいと思います。 これは、過去にReactを開発した方法とも一致しています。 何かが本当に準備ができたら（メンタルモデルの理論的な記述であっても）、それを文書化して説明することにすべての注意を向けます。

ちなみに、データフェッチのサスペンスは、人々が慣れているものとは十分に異なるメンタルモデルです。 Reduxのような非常に制約のないメカニズムと統合した場合、必ずしもそれほど強力になると期待するのは公平ではないと思います。 しかし、私たちは見るでしょう。 今は何も言えません。

@gaearon 、幸いなことに、サスペンスのメンタルモデルは私自身のメンタルモデルと完全に一致しています。 パズルのその部分が所定の位置に収まることに非常に興奮しています。 頑張ってくれてありがとう！

昨年11月に発表されたロードマップ（https://reactjs.org/blog/2018/11/27/react-16-roadmap.html）は、サスペンスの「同時」バージョンが2019年第2四半期に予定されていることを示しています。 2019年第3四半期。Q3ではない、またはQ3などに関して入手できるアップデートはありますか？

これは私が見つけた最新のロードマップアップデートでした： https ：//reactjs.org/blog/2019/08/08/react-v16.9.0.html#an -update-to-the-roadmap

10月に実験的なリリースを提供しました： https ：

サスペンスは私を殺している

@gaearon本番環境で使用されているとのことですが。 しかし、私は本番環境で「実験的な」コードを使用することに非常に消極的です。 ロードマップ、ステータス、進捗状況、タイミングなどについて明確ではありません。これはアルファ、ベータ、RCの品質ですか？ この「実験的」という言葉は、私には「これに触れないでください」という意味です。

私たちは皆、このコードに基づいてビジネスを行っています。私たちは皆、皆さんと同じように圧倒されていると確信しています。 少し明快に、ブログ、SOMETHINGは本当に役に立ちます。 まるで「Facebookで制作中なので、完成です」と感じます。

@mschipperheyn

これは複数年にわたるプロジェクトです。 正直な答えは、2年前に始めたときに思っていたよりもはるかに多くの仕事を生み出したということです。

しかし、幸いなことに、現在は本番環境で頻繁に使用している

今日のさまざまなワークストリームの大まかな状態は次のとおりです。

• <Suspense>とコード分割のためのAPI lazy 。 （React 16.6で出荷）
  
  
  
  • ご存知かもしれませんが、これはすでに使用できます。
  
  
• 並行モードAPI、例： createRootおよびuseTransition 。 （ experimentalリリースで利用可能）
  
  
  
  • Fluxのようなライブラリの互換性ソリューション。 （進行中@ bvaughn 、https：//github.com/reactjs/rfcs/pull/147）
  
  
  • 優先モデルをより賢明なモデルに変更します。 （進行中@ acdlite 、https：//github.com/facebook/react/pull/18612）
  
  
  • 最後の保留中の遷移のみを終了させます。 （進行中@acdlite）
  
  
  • オフスクリーンAPI（進行中@lunaruan）
  
  
  • サスペンスのコンテンツを非表示/表示するときの火の効果
  
  
  • オフスクリーンのコンテンツを非表示/表示するときの火の効果
  
  
  • 必要に応じてポータルの子を表示および非表示にする
  
  
  • スケジューリングのための進行中の標準化作業に合わせる（開始されていない）
  
  
  • 既知の主要なバグを修正します（進行中の@gaearonおよび@acdlite）
  
  
  • イベントのセマンティクスを変更します。 （進行中@sebmarkbage @trueadm）
  
  
  • ドキュメントではなくルートに委任して、より段階的な採用を可能にします（進行中、@ trueadm）
  
  
  • キャプチャフェーズで離散イベントをフラッシュします。
  
  
  • 命令型コードでよりうまくプレイするには、デフォルトの優先度をeventから取得することを検討してください。
  
  
  • 他のAPIセマンティクスとデフォルトを完成させます。 （開始されていません）
  
  
  • タイピングとドキュメントを更新します。
  
  
• データフェッチのためのサスペンス
  
  
  
  • コンポーネントのシグナリングの低レベルのサポートは、レンダリングする準備ができていません（技術的には、安定したReactでも利用できますが、このAPIは安定しているとは見なされません）。
  
  
  • サーバーレンダラーはサスペンスフォールバックを即座にフラッシュします（実験的なリリースで利用可能）
  
  
  • GraphQLユースケースのソリューション（リレーフック、出荷済み）。
  
  
  • GraphQL以外のユースケースのソリューション（ Next.jsと共同で@sebmarkbageを進行中）。
  
  
  • データ駆動型の依存関係のためのバンドラー統合。 （進行中）
  
  
  • コンテキストを含むブロックAPIをファイナライズします。
  
  
  • 一般的なキャッシングソリューション。 （開始されていません）
  
  
  • ある種のルーター統合。
  
  

まるで「Facebookで制作中なので、完成です」と感じます。

私はそれがこのようにどのように見えるかを見ることができますが、この読書は少し意気消沈します。 :-)私たちは過去数ヶ月間、これにノンストップで取り組んできました。技術的な側面の多くは、完成しているか、ほぼ完成に近づいています。 残りの作品のほとんどは2つのカテゴリに分類されます。

• 安定したリリースでそれらをセメントで固定する前に、初期設計で発見した欠陥を修正します。 現在持っているものをリリースする場合は、数か月以内に大幅な変更を行う必要があります。 それは紛らわしいだけでしょう。

• エコシステムの互換性と適切なデフォルト。 ライブラリや既存のアプローチでは機能しないため、今日誰も使用できないものをリリースしても役に立ちません。 したがって、作業の大部分（たとえば、 useMutableSourceを介したFluxのようなライブラリとの互換性、より優れたイベントセマンティクスの選択、推奨されるキャッシュ戦略の出荷）は、リリースしたものを実際に使用できるように

「今日は使えますか」…技術的には、今日は全部使えます。 します。 具体的には、リレーフックとコンカレントモードを使用します。 まだ重要な計画された変更と既知の問題があるため、現在の状態は、広く採用される準備ができていると見なす基準を満たしていません。 もちろん、バグやAPIをすぐに変更してもかまわない場合は、私たちと同じように@experimentalリリースを使用できます。

Facebookが私たちの「成し遂げられた」という点でここで特別な立場にあるとは言えません。 まったく逆に、私たちは完了していません。しかし、内部的には、解約を許容し、移動中の列車の上に構築することをいとわないのは、それが私たちが構築しているものがしっかりしていることを知る方法だからです。 この重いドッグフーディングがなければ、6か月で発見した欠陥は、発見して再設計するのに数年かかるでしょう。

要約すると、やるべきことはまだたくさんあります。

@gaearonこのアップデートをありがとう！ そして、私の口調が間違っていた場合はお詫び申し上げます。 何ヶ月もTwitterを精査して何も見つからなかったので、少しイライラしたことを認めます。 この側面Server renderer immediately flushes Suspense fallbacks (available in experimental releases)は、実装のためにApolloGraphqlを使用してこれをテストする際に時間を割り当てることができるもののように見えます。

そうです、図書館の作者や好奇心旺盛な人々が遊び始める準備ができているはずです。 不足している部分は主に「幸せな道」を提供することに関するものですが、配管のほとんどはそこにあるはずです。

サーバーレンダラーはサスペンスフォールバックを即座にフラッシュします（実験的なリリースで利用可能）

これについてどこで読むことができますか？ 並行モードAPIリファレンス（実験的）を期待していましたが、運がありませんでした。

誰かがNext.js、リレーフック、並行モードを一緒に（SSRで）ステッチするデモを持っているなら、それは素晴らしいでしょう。 そうでなければ、十分なドキュメントを見つけることができれば、運試しをするかもしれません。

@CrocoDillon

SSRに関する追加のドキュメントはありませんが、これは主に、新しいデフォルトの動作であるためです。

コンポーネントがサーバー上で一時停止するときよりも実験的なリリースがある場合は、代わりに最も近いSuspenseフォールバックをフラッシュします。 次に、クライアントでcreateRoot(node, { hydrate: true }).render(<App />)ます。

これにより、すべての新しいハイドレーション機能がすでに有効になっていることに注意してください。 したがって、たとえば、サスペンス境界はサーバーで生成されたフォールバックHTMLに「アタッチ」されてから、クライアントレンダリングを試みます。

また、アプリ全体が読み込まれる前に水分補給を開始できることにも注意してください。 <App>が読み込まれると、水分補給できます。 以下のコンポーネントがコードの準備ができていないときに中断する限り（レイジーと同様）。 この場合、ReactはサーバーのHTMLコンテンツを保持しますが、サスペンス境界をそれに「アタッチ」します。 子コンポーネントがロードされると、水和が継続されます。 水和した部分はインタラクティブになり、イベントを再生します。

おそらく@devknollに次の統合の試み/例を尋ねることができます。 彼はおそらくいくつか持っています。

Next.jsで同時モードを有効にするには、 react@experimentalとreact-dom@experimentalをインストールし、以下をnext.config.js追加します。

// next.config.js
module.exports = {
  experimental: {
    reactMode: 'concurrent'
  }
}

これに関するNext.jsのディスカッションは次のとおりです： https ：

サーバーレンダリングでサスペンスを待つことは可能ですか（たとえば、静的サイト生成などの場合）？ コールバックの使用が適切なデフォルトであることに同意します。オーバーライド可能かどうか疑問に思っていますか？

また、アプリ全体が読み込まれる前に水分補給を開始できることにも注意してください。 いつロードされた、あなたは水和することができます。 以下のコンポーネントがコードの準備ができていないときに中断する限り（レイジーと同様）。 この場合、ReactはサーバーのHTMLコンテンツを保持しますが、サスペンス境界をそれに「アタッチ」します。 子コンポーネントがロードされると、水和が継続されます。 水和した部分はインタラクティブになり、イベントを再生します。

@gaearonは、サーバー上でコンポーネントを通常どおりレンダリングできるが、クライアント上ではReact.lazyを使用できるという意味ですか？ サーバーから完全なマークアップを返すことを許可しますが、クライアントでのコンポーネントコードの解析とレンダリングを遅らせます。 サーバーでレンダリングされたマークアップは、ここでサスペンスのフォールバックとして機能しますか？

@robrichard私は実際にReact.lazy実際に試したことはありませんが（FBでは別のラッパーを使用し、Nextにも独自のバージョンがあります）、これがどのように機能するかを期待しています。 確認する価値があります:-)特定の制限があります。たとえば、小道具を更新して上記のメモのベイルアウトがない場合、またはその上のコンテキストを更新した場合は、何をすべきかわからないため、それを削除してフォールバックを表示する必要があります。それと。

@gaearon現在の状態の部分的な水分

unstable_createRoot APIを使用している限り、これはすべての@experimentalリリースで長い間使用されてきました。

これがデモです： https ： index.js

@gaearon 「データ駆動型の依存関係」の意味を詳しく説明して

@gaearon 「データ駆動型の依存関係」の意味を詳しく説明して

はい、もちろん。 上記のリストが簡潔であることをお詫びする必要があります。非常に凝縮されており、これらの多くは重要な個別のサブプロジェクトです（そのため、時間がかかっています）。

あなたの特定の質問に答える前に、一歩下がって、より広い文脈を与えましょう。 より広い文脈では、本当に優れたデータフェッチソリューションを構築する

「公式」Reactに入るには非常に高い基準があります。 「Reacty」であるためには、通常のReactコンポーネントと同様に構成する必要があります。 これは、何千ものコンポーネントに拡張できるとは思わないソリューションを誠実に推奨できないことを意味します。 また、パフォーマンスを維持するために複雑で最適化された方法でコードを記述しなければならないソリューションをお勧めすることはできません。 FBでは、リレーチームから多くの教訓を学びました。 誰もがGraphQLを使用できるわけではない、またはリレーを使用したいと思うわけではありません（それ自体はあまり人気がなく、チームは外部での採用のために最適化していません）。 ただし、一般的なReactのデータフェッチソリューションに、Relayから得た苦労して得た教訓が組み込まれており、パフォーマンスとコロケーションのどちらかを選択する必要がないことを確認したいと思います。

これは大きなアプリだけではないことを強調したいと思います。 この問題は大きなアプリで最も顕著ですが、npmから多数のコンポーネントをインポートする小さなアプリも、これらの非効率性のサブセットに悩まされています。 クライアント側のコードを大量に出荷してウォーターフォールにロードするなど。 または、事前にロードしすぎます。 また、小さなアプリが永遠に小さなアプリであり続けるわけではありません。 Reactコンポーネントモデルがアプリの複雑さに関係なく同じように機能するように、あらゆるサイズのアプリに最適なソリューションが必要です。

さて、あなたの特定の質問に対処するために。 リレーには、「データ駆動型の依存関係」と呼ばれる機能があります。 それについて考える1つの方法は、動的なimport進化です。 動的なimportは必ずしも効率的ではありません。 条件が真の場合にのみコードをロードする場合（たとえば、「ユーザーがログインしています」または「ユーザーに未読メッセージがありますか」）、唯一のオプションはそれを遅延トリガーすることです。 ただし、これは、何かが使用されている場合にのみ、フェッチを「開始」していることを意味します（ React.lazy ）。 それは実際には手遅れです。 たとえば、複数のレベルのコード分割コンポーネント（またはデータを待機しているコンポーネント）がある場合、最も内側のコンポーネントは、その上のコンポーネントがロードされた後にのみロードを開始します。 これは非効率的であり、ネットワークの「ウォーターフォール」です。 リレー「データ駆動型依存関係」を使用すると、クエリの一部としてフェッチするモジュールを指定できます。 つまり、「何らかの条件が真の場合、このコードチャンクをデータ応答に含めます」。 これにより、必要になるすべてのコード分割チャンクをできるだけ早くロードできます。 コロケーションをパフォーマンスと交換する必要はありません。 これは大したことではないように思えるかもしれませんが、製品コードの文字通りの秒数を削減しました。

繰り返しになりますが、RelayをReactに入れているわけではなく、人々にGraphQLの使用を強制したくありません。 しかし、概念的には、機能自体は汎用であり、優れたオープンソースソリューションを使用すると、現在よりもはるかに多くのコード分割を実行できます（したがって、出荷されるクライアントJSコードが大幅に少なくなります）。その汎用機能は呼び出されません。 「データ駆動型の依存関係」—これは私が参照したリレー名です。 この機能は、GraphQLを必要としないより大きな推奨ソリューションの一部になります。 これは単一の箇条書きのポイントを説明するのに多くのことだったので、私はリストでその名前でそれを参照しました。

これがそれを明らかにすることを願っています。