React: 非同期サーバーレンダリングをサポート（レンダリング前にデータを待機）

これがまだ存在しない主な理由（私は信じています）は、クライアント側では、レンダリングを延期するのではなく、基本的に常に何らかの負荷インジケーターを表示したいということです。 （これにより、コードが大幅に複雑になりますが、おそらくそれに対処できます。）

それなしでは解決するのが難しい2つのケースがあります：

• サーバー側では、レンダリングする前にデータをフェッチする場合、レンダリングされるコンポーネントの情報がないため、データの取得をコンポーネントに委任することはできません。
• クライアント側では、事前にレンダリングされたhtmlを受信した後にアプリケーションを初めてマウントするときに、サーバーで取得したデータから何らかのキャッシュがある場合でも、非同期メソッドを使用してそれらのデータを取得することをお勧めします。これにより、反応が妨げられます。 HTMLを再利用することから。

react-asyncは、ファイバーとキャッシュに関するこれらの問題を解決します。 それでうまくいきますが、私の見解では、これらはコアでしか解決できない問題を解決するための単なる「ハック」ソリューションです。

@fdecampredonは、 componentWillMountは非同期であり、すぐには何も返さない、と言っています。Reactは、何も表示されなくなるまで何をレンダリングするのでしょうか。 もしそうなら、まだデータがないのにレンダリングで何も返さないのはなぜですか？ （ええ、私はサーバーサイドを取得します）また、 componentWillMount発砲する前に小道具が変更された場合はどうなりますか？

個人的には、コンポーネントが実際に分離されたブラックボックスであり、ロードインジケーターも実装していない限り、 componentWillMount間に非同期要求をディスパッチするのは間違っているようです。 私が理解している限り、Reactコンポーネントを従来のOOPインスタンスと間違えないでください。 最良の場合、Reactコンポーネントは、小道具のデータを視覚化するためのツールです。インタラクティブである場合は、状態も表示される可能性があります。 これはビューであり、ビューとモデルではありません。

私の耳には、それは問題のように聞こえます。Reactコンポーネントは非同期リクエストをディスパッチするコンポーネントではなく、すべてのデータをフェッチし、そのデータの準備ができたら、 React.renderComponentを呼び出します。 クライアント側とサーバー側で同じソリューション。 また、非同期リクエストが失敗した場合に、選択した結果で中止することもできます。

私が何かを誤解した場合は、遠慮なく私を解雇してください。ただし、Reactコンポーネントは、単なるビューとして意図されている場合は、ビューおよびモデルとして扱っているようです。

@fdecampredonは、componentWillMountは非同期であり、すぐには何も返さない、と言っています

私はすべてのケースについて考えていなかったことを認めなければなりません^^。
この機能は、トップレベルコンポーネントを初めてマウントするときにのみ役立ちます。それ以外の場合は、ほとんどのキャストでローダーインジケーターを表示する必要があります。

個人的には、コンポーネントが実際に分離されたブラックボックスであり、ロードインジケーターも実装していない限り、componentWillMount中に非同期要求をディスパッチするのは間違っているようです。私が理解している限り、Reactコンポーネントを従来のOOPインスタンスと間違えないでください。最良の場合、Reactコンポーネントは、小道具のデータを視覚化するためのツールです。インタラクティブである場合は、状態も表示される可能性があります。これはビューであり、ビューとモデルではありません。

ある意味または他の方法では、 Fluxサンプルで行われるように、「トップレベル」コンポーネントがデータを取得できるようにする必要があり
このサンプルでは、​​todoのリストの取得は同期操作であるため、非常に単純です。同期操作が行われなかった場合、サーバーで事前レンダリングを行うと、データなしで初めてレンダリングされます（事前レンダリングが失われます）。サーバーからのマークアップ）。

1つのビュー階層によって1セットのデータが表示される単純なアプリケーションの場合でも、それほど問題はありません。データをプリロードしても、ストアの同期プロパティを維持できます。
ここで、アプリケーション全体で再利用する複数のモジュールで構成されるアプリケーションの場合、それらのモジュールを、異なるストアで「サブスクライブ」できる（データのフェッチを担当する）個別のアプリケーションとして処理できるようにしたいと思います。

おそらく私は物事を間違った方法で理解しているかもしれませんが、Webの周りのいくつかの議論/サンプルは、どこかに何かが欠けていると私に思わせます：

• いくつかのサンプルでは、 @ petehuntが同様のことを達成しようとしたように思われます。
• react-nested-routerはwillTransitionToで同様のメカニズムを促進し、いくつかの議論は私に適切な解決策を誰も持っていないように感じさせます。
• RRouterは、コンポーネントがレンダリング/マウントされるときにデータをプリフェッチするためのある種のメカニズムも提供します。
• そして最後に、前に言ったようにreact-asyncします。

@fdecampredon明確にするために、react-nested-routerのwillTransitionToの目的は、データをロードすることではありません。特に、そのメソッドからpromiseを返すと、新しいUIのレンダリングが実際にブロックされるためです。絶対に必要な場合を除いて。

@fdecampredon誰もがまだ物事を理解しようとしているので、誰も決定的な答えを持っていなくても私は驚かないでしょう。 しかし、Facebookの開発者はこれに何度か遭遇したに違いないと思います。

これに関する更新はありますか？ Reactの探索を始めたばかりで、すぐにこれに遭遇します。 多くの人が同形アプリを構築するための解決策としてReactを推奨していますが、これが解決されない限り、それは単に仕事を成し遂げることができないと思います。

私の耳には、問題のように聞こえますが、Reactコンポーネントは非同期リクエストをディスパッチするコンポーネントではなく、すべてのデータをフェッチし、そのデータの準備ができたら、React.renderComponentを呼び出します。 クライアント側とサーバー側で同じソリューション。 また、非同期リクエストが失敗した場合に、選択した結果で中止することもできます。

私が何かを誤解した場合は、遠慮なく私を解雇してください。ただし、Reactコンポーネントは、単なるビューとして意図されている場合は、ビューおよびモデルとして扱っているようです。

これが当てはまる場合、Reactはわずかに異なるテンプレートソリューション/ビューレイヤーにすぎません。 そして、そのような可能性があるので、それは残念です。 @fdecampredonが複数のモジュールで構成される複雑なアプリケーションについて言及しているとき、私は本当に理解しています。 Reactはこれに最適です。

このアプローチは、コンポーネントをビューおよびモデルとして扱うことを意味するとは思いません。 Fluxアーキテクチャを見ると、（ストアからの）データを表示するだけでなく、ユーザーの操作に基づいてアクションを呼び出す_controller-views_の時点でReactコンポーネントを考えています。 そして、アクションはストア（=モデル）を更新します。 私には、それは明らかなMVCアーキテクチャのように聞こえます。

問題は、ストアに入力する最初のアクションにあります。 クライアント側では、推奨されているようにcomponentDidMount()メソッドからアクションを呼び出すことができるのはかなり簡単です。 一方、サーバー側では、アクションが終了してストアにデータが入力されるまでレンダリングを遅らせる特別な場所と何らかのメカニズムが本当に必要です。

現時点では、唯一の方法はReact-async / Fibers + Fluxであるように思われます。 Fluxの良いところは、コンポーネントの状態をサーバーからクライアントに転送するために人工的なキャッシュを必要としないことです（元のreact-asyncの例で行われたように）。ストアを初期化してから、 htmlマークアップを持つクライアント（この例を参照）。

しかし、この解決策は確かに_hackish_です。

非同期であるcomponentWillMountである必要は必ずしもないと思います。 ライフサイクルイベントである必要があるかどうかさえわかりません。 本当の問題は、サーバー側では、すべてが文字列にレンダリングされるまで、コンポーネントツリーを分析する方法がないことです。

これを解決するための私の理想的な解決策は、コンポーネントツリーを構築するだけの「レンダリング」を許可することです。その後、ツリーをトラバースして、追加のデータが必要なコンポーネントを見つけ、非同期でより多くのデータをロードして「再レンダリング」できるようになります。 「そのコンポーネントのサブツリーを作成し、マークアップをフラッシュする準備ができたら、そのツリーを文字列に変換できるようにします。

これは、ブラウザーで実行できることを複製します。必要に応じて再レンダリングできる仮想DOMを用意します。 違いは、ブラウザーではDOMの更新が暗黙的に行われる可能性があることです。 サーバーでは、非同期データに基づいて仮想DOMの更新を実行できるように、文字列にレンダリングするタイミングを明示する必要があります。

これを解決するための私の理想的な解決策は、コンポーネントツリーを構築するだけの「レンダリング」を許可することです。その後、ツリーをトラバースして、追加のデータが必要なコンポーネントを見つけ、非同期でより多くのデータをロードして「再レンダリング」できるようになります。 「そのコンポーネントのサブツリーを作成し、マークアップをフラッシュする準備ができたら、そのツリーを文字列に変換できるようにします。 — @mridgway

うん、それはいいだろう。 現在、サーバー側でコンポーネントを2回レンダリングすることは、回避策として使用できます。

React内でサポートしたいものの例としてreact-nexusを参照したいと思います。 これは基本的にmountComponent動作を書き直したものですが、実際にDOMにマウントしたり、文字列を書き込んだりせずにコンポーネントツリーを構築する点が異なります。 これにより、コンポーネントツリーをトラバースし、ツリーの構築中に非同期メソッドを実行できます。 この実装の問題は、最初のツリーを破棄してから、とにかくReact.renderToString呼び出すことですが、その事前レンダリングツリーを取得してレンダリング/マウントすると便利です。

私はコア内でこれに取り組むつもりですが、いくつかのポインターが必要になります。 要件の1つは、非同期で問題が発生しないように、 ReactContextをグローバルに参照しないようにすることだと思います。 これで問題が発生する可能性のある他のグローバルもありますか？

@mridgway私が間違っていなければ、グローバルReactContextは互換性のあるものであり、0.14でなくなるでしょう。 しかし、私は間違っているかもしれません。

@gaearonええ、それは私がwithContextの非推奨から得た意味です。

：+1：このATMにreact-routerを使用します。 @mridgwayのアプローチは非常に合理的に聞こえます。

この問題に対する少し異なる見方は、バンドラー（webpackなど）によって生成されたコードチャンクの非同期ロードを処理する方法です。

このチケットで説明されているように（ https://github.com/rackt/react-router/issues/1402） 、非同期レンダリングのサポートに関する問題は、関連するチャンクが最初のチャンクにまだロードされていないため、最初のレンダリングがnullに見えることですレンダリングパス。結果として、DOMのルートに<noscript>し、チェックサムが失敗します。 その後すぐにすべてが適切に配置されますが、ローカルで作業する場合はUIがちらつき、フィールドで作業する場合は特に、ダウンロードするチャンクが適切なサイズ（たとえば、> 30KB）の場合は、ちらつきが発生します。

大きなアプリを複数のチャンクに分割する機能は私たちにとって重要であり、データフェッチの問題を解決しました（サーバーでレンダリングしてデータの依存関係をフェッチする前にトラバースできるreact-routerとネストされたルートを使用しました）これは最後のピースですフロントエンドのReactソリューションに完全に移行することを妨げるパズルの例です。

@anatomicこれはReactの責任ではありません。適切にチャンクし、必要なチャンクがすべて読み込まれるまでレンダリングを延期するのはあなたの仕事です。 言い換えると、コンポーネントの1つが外部ライブラリに依存している場合、それを使用する前に満足させるのは明らかに問題です。Reactは試してみても実行できなかったため、同じことが全面的に当てはまります。

<WaitFor for={MyAsyncLoadedCompSignal} until={...} then={() => <MyAsyncLoadedComp ... />} /> 、自分に合った代替戦略を自由に実装してください。 しかし、これらは本質的に意見が分かれており、Reactが提供すべき、あるいは提供する必要のあるものではないため、コミュニティに任せるのが最善です。

Reactコンポーネントの範囲外に非同期のものを保持することをお勧めします。次に例を示します。

import React from 'react';
import Layout from './components/Layout';
import NotFoundPage from './components/NotFoundPage';
import ErrorPage from './components/ErrorPage';

const routes = {

  '/': () => new Promise(resolve => {
    require(['./components/HomePage'], HomePage => { // Webpack's script loader
      resolve(<Layout><HomePage /></Layout>);
    });
  }),

  '/about': () => new Promise(resolve => {
    require(['./components/AboutPage'], AboutPage => { // Webpack's script loader
      resolve(<Layout><AboutPage /></Layout>);
    });
  })

};

const container = document.getElementById('app');

async function render() {
  try {
    const path = window.location.hash.substr(1) || '/';
    const route = routes[path];
    const component = route ? await route() : <NotFoundPage />;
    React.render(component, container);
  } catch (err) {
    React.render(<ErrorPage error={err} />, container);
  }
}

window.addEventListener('hashchange', () => render());
render();

Webpack Code Splitting 、 React.js Routing from Scratch and react-routing （近日公開）を参照してください。

@syranideこれからも作業を続けていきますが、上記のようにバイナリではないと思います。 ルーターはReact環境の外にあるのではなくコンポーネントであるため、react-routerを使用しているため、ミックスにいくつかの問題が発生する可能性があります。

<WaitFor ... />アプローチを実行した場合でも、最初のレンダリングで別のDOMが取得され、コンテンツのちらつきや消失が発生しますか？

私たちがやった場合アプローチ、確かに最初のレンダリングで別のDOMを取得しますが、それでもコンテンツのちらつき/消失が発生しますか？

ちらつきを望まない場合（一部の場合）、レンダリングする前に、依存するすべてのチャンクがロードされるのを待つだけです。webpackは、このすぐに使えるrequire.resolveます。

PS。 はい、react-routerやその他の使用しているものは確かに解決策を複雑にしますが、それでもReactの解決すべき問題ではありません。

ちらつきを望まない場合（一部の場合）、レンダリングする前に、依存するすべてのチャンクがロードされるのを待つだけです。webpackは、このすぐに使えるrequire.resolveを提供します。

私はそれを調べます、 require.resolve私の理解は、それがモジュールのIDの同期ルックアップであり、サーバーへのトリップを含まなかったということでしたか？ チャンクの読み込みを管理するためにrequire.ensureを使用しています。

コードをもう一度見ると、react-routerにサーバー上でレンダリングされていると思わせるが、標準のクライアント側のアプローチに従うことで、問題を回避できると思います。

const history = new BrowserHistory();

if (typeof history.setup === "function") {
    history.setup();
}

Router.run(routes, history.location, (err, initialState, transition) => {
    React.render(<Provider redux={redux}>{() => <Router key="ta-app" history={history} children={routes} />}</Provider>, document.getElementById('ta-app'));
});

それを調べます。require.resolveについての私の理解は、それがモジュールのIDの同期ルックアップであり、サーバーへのトリップを含まなかったということでしたか？ チャンクの読み込みを管理するためにrequire.ensureを使用しています。

申し訳ありませんが、はい、 require.ensureを意味しました。 コールバックは、すべての依存関係が満たされた場合にのみ実行されるため、render / setStateをその中に配置するだけです。

わかりました、それは私たちがそれをやっていた方法のようなものです、あなたの返事に感謝します。 これはreact-routerで対処する必要があるもののように感じるので、そこで議論を続けます-これがこの会話をするのに間違った場所であった場合は申し訳ありません！

require.ensureが進むべき道であることは間違いありません。私たちの最終的な問題は、現在アクセスしているルートにリンクする必要があるため、ルーターに直接接続されていることだと思います。 react-routerはコンポーネントベースであり、レンダリングツリーに関連付けられています。 上記の私のハックがなければ、すべてが非同期でロードされる前にツリーを表示する方法と戦うことになります（またはルーティングロジックを複製して、関連するチャンクをトップレベルでロードできるようにします）。

require.ensureが進むべき道であることは間違いありません。私たちの最終的な問題は、現在アクセスしているルートにリンクする必要があるため、ルーターに直接接続されていることだと思います。 react-routerはコンポーネントベースであり、レンダリングツリーに関連付けられています。 上記の私のハックがなければ、すべてが非同期でロードされる前にツリーを表示する方法と戦うことになります（またはルーティングロジックを複製して、関連するチャンクをトップレベルでロードできるようにします）。

私はreact-routerに精通していませんが、それでもsetRoute(...) => require.ensure([], function() { require(...); setRoute(...); })場合であると想像していますが、これは実際には実用的ではないため、別のレベルの間接参照を導入します。 ルートのマップとそれぞれの非同期require.ensureローダー。 ヘルパーfunction asyncSetRoute(...) { loadRoute(route, function() { setRoute(...); }}を作成します。代わりに、 asyncSetRouteを呼び出すと、すべての準備が整うまでルーターの更新が延期されます。

擬似コードと一種のジェネリックですが、それは私にとって全体的なアプローチのようです。 たぶんreact-routerがこれを提供するはずですが、そうではないかもしれません...たぶんそれは外部ヘルパーとして理想的に提供されているのかもしれませんが、私にはわかりません。

したがって、何時間もの調査の結果、すべてを上から下にフィードしない限り、サーバー側のレンダリングが_不可能_であることを確認しました（？）。

考えられる短期的な解決策：
A.ストアを事前に入力し、サーバー側の読み込みを同期化する

B. 1つのデータオブジェクトを非同期でフェッチした後、すべてを1つのデータ入力として上からフィードします。

re： 'A'。 レンダリング構造がどのようになるかをすでに知っていない限り、これは機能しません。 さまざまなコレクション/モデル/ APIの依存関係を知るために、それをレンダリングする必要があります。 また、2つの異なるAPIを使用せずに、クライアントでフェッチを非同期にし、サーバーで同期させるにはどうすればよいですか？

re： 'B'。 基本的に上記と同じ問題です。 人々は、それぞれのルートに対応するために、依存関係のあるJSONをほとんど作成する必要がありませんか？

Reactがサポートするソリューションを待つ間、他に短期的なソリューションはありますか？ ユーザーランドフォークまたはプラグインはありますか？ https://www.npmjs.com/package/react-async ？

@NickStefan

問題がわかりません。 :-(

1. ストアがシングルトンではない場合は、FluxまたはFluxのようなコンテナー（Alt、Redux、Flummoxなど）を使用します。
2. promiseを返すルートハンドラーでfetchDataような静的メソッドを定義します。
3. サーバーで、ルートをコンポーネントに一致させ、コンポーネントからfetchDataを取得し、コンポーネントが完了するのを待ってからレンダリングします。 これにより、FluxまたはReduxストアインスタンスが事前に入力されます。 ストアインスタンスはシングルトンではないことに注意してください。特定のリクエストにバインドされているため、リクエストは分離されたままです。
4. Promiseの準備ができたら、事前に入力したストアインスタンスと同期してレンダリングします。

このアプローチを説明するReduxの優れたチュートリアルは次のとおりです： https ：//medium.com/@bananaoomarang/handcrafting -an-isomorphic-redux-application-with-love-40ada4468af4

@gaearonご迷惑をおかけし

これは良いフラックスの習慣ですが、それは潜在的に制限されていませんか？ ビューツリーの下部に、非常に異なるデータを必要とする小さなコンポーネントを追加した場合は、ルートでデータの依存関係を編集する必要があります。

私が求めているのは、深くネストされたコンポーネントが非同期データのニーズを定義する方法です。

ルートコンポーネントにニーズを追加する必要がある場合、ルートをその1つのサブコンポーネントのニーズに結合していませんか？

@NickStefanとreact-routing 、たとえば、非同期データのフェッチは次のようになります。

import Router from 'react-routing/lib/Router';
import http from './core/http';

const router = new Router(on => {
  on('/products', async () => <ProductList />);
  on('/products/:id', async (state) => {
    const data = await http.get(`/api/products/${state.params.id`);
    return data && <Product {...data} />;
  });
});

await router.dispatch('/products/123', component => React.render(component, document.body));

これらのソリューションは機能しますが、すべてのデータのプリフェッチがルーターにバインドされているためです。 これはほとんどの場合問題ではありませんが（URLはページに何を表示するか、したがってどのデータが必要かを定義します）、一般的には制限です。 すべてを単独で処理するスタンドアロンの再利用可能なコンポーネント（Twitterストリーム、コメント、カレンダーなど）を作成することはできず、コンポーネント階層に挿入するだけで済みます。 これを可能にする唯一の方法はreact-asyncですが、それはほとんどハックです。

Reactコンポーネントは、このように使用することを意図したものではなく、_controller_-viewsよりも多くのビューであると思います。 おそらく、完全に新しいライブラリがReactの基盤の上に出現する必要があります。

私の夢は、いつの日か、Wordpress、Drupal、ModxなどのReactを使用して完全なCMSを作成できるようになることです。 ただし、HTML / PHPスニペットの代わりに、ReactコンポーネントからWebサイトを構成します。

@NickStefan

あなたのリストから、サーバーのデータ依存性の解決策は、ルートコンポーネント（静的メソッド/リンクした記事）でのみデータのニーズを定義することであると私は正しいと思います。 データの依存関係がルートで定義されている場合は、ストアなどを事前に入力する方がはるかに簡単です。

ルートコンポーネントにニーズを追加する必要がある場合、ルートをその1つのサブコンポーネントのニーズに結合していませんか？

ルートではなく、ルートハンドラーレベルで。 アプリには多くのルートハンドラーが含まれている可能性があります。 さらに、 React Routerのようなライブラリは、ネストされたルートハンドラーをサポートし配列が含まれるため、それらをPromise.allできます。 これは意味がありますか？

「すべてのコンポーネントが依存関係を宣言できる」ほどきめ細かくはありませんが、ほとんどの場合、データフェッチをルートハンドラー（最上位およびネストされたハンドラー）に制限するだけで十分であることがわかりました。 以下に、 propsを介してデータを受け入れる純粋なコンポーネントがあるため、データがフェッチされていることを_認識_していません。 彼らがそれを要求できないことは理にかなっています。

「すべてのコンポーネントが依存関係を宣言できる」アプローチは、ある種の要求バッチ処理ソリューションがない限り、実用的ではありません。 <User>がAPI呼び出しが必要であると宣言し、100個の<User>のリストをレンダリングするとします。100個のリクエストを待ちますか？ この種のデータフェッチ要件の粒度は、リクエストバッチソリューションがある場合にのみ機能します。 それがあなたに合っているなら、リレーはまさにそれです。 ただし、そのための特別なバックエンドが必要になります。

@NickStefan現在、コンポーネントごとの非同期フェッチはサポートされていません。追加したいのですが。この問題は私たちの進捗状況を追跡しますが、誰も積極的に取り組んでおらず、大規模なリストラが必要になるため、しばらく時間がかかります。

@gaearon

「すべてのコンポーネントが依存関係を宣言できる」アプローチは、ある種の要求バッチ処理ソリューションがない限り、実用的ではありません。

これについてもう少し考えた後、私はあなたに同意します。 私が探していたものは実際には実用的ではありません。

私はもともとあなたの100人でさえ例は、チームの規律で問題ありません（つまり、100個すべてに対して1つの要求を行う<UsersContainer>を作成するだけです）。 しかし、それは単に慣習を持っているだけの「人にスケーラブル」ではありません。 ルートまたはルーターへのすべての依存関係を強制するのがおそらく最善です。 リレーのようなものでさえ、3つの異なるコンテナ（RelayContainer、RelayRootContainer、RelayRouterなど）を使用してルートで依存関係を宣言するように強制します。 これは、依存関係の宣言をツリーの上位に本質的に「持ち上げる」ことが唯一の方法であるという点を証明しています。

やあ！
これに関する更新はありますか？

+1

あなたが本当にこれについて考えるならば、あなたはこれをしたくないと私は主張します。 私は当初、Reactに非同期レンダリングを実行させたいと思っていました。 しかし、このスレッドの他の人たちは、そうでなければ私を納得させました。

リレーでも、基本的には、ルートコンテナ宣言、リレーコンテナなどを使用して、依存関係をツリーの上位に「引き上げる」必要があります。同期レンダリングがその方法です。

非同期レンダリングは悪夢になる可能性があります。 私は、リクエストアニメーションフレームで個々の更新を行うためにハッキングされたバックボーンを持つ会社のコードベースでの作業の経験から話します。

同意しました。 以前はこれが必要だと思っていましたが、実際には、ロードするデータをビューで指定するのは逆です。 ビューはアプリケーションの状態の関数であり、それ自体がリクエストの関数です（セッションがある場合はユーザーの状態の場合もあります）。 これがReactのすべてです。 コンポーネントがロードするデータを指定できるようにすることは、「一方向のデータフロー」の考え方であるIMOに反します。

ロードするデータをビューで指定するのは、実際には逆方向です。

これが本当かどうかは完全にはわかりません。 場合によっては、ロードするデータを知っているのはコンポーネントだけです。 たとえば、ユーザーがノードの大規模なグラフを参照できる拡張可能なツリービューがあるとします。どのデータをロードする必要があるかを事前に知ることは不可能です。 コンポーネントだけがそれを理解できます。

とにかく、ブリッジを介して通信するために非同期が必要なWebワーカー（＃3092）内でReactコードを実行するというアイデアを追求する場合、この議論ははるかに関連性が高くなる可能性があります。

大きなツリービューの例で、サーバー側ですでに開いているパスを使用してレンダリングできるようにしたい場合は、そのパスをURL構造に追加します。 このような複雑なコンポーネントがいくつかある場合は、それらの状態をGETパラメーターで表します。 このようにして、これらのコンポーネントはSSRのすべての利点を享受できます。つまり、クロール可能で、履歴を使用してナビゲートでき、ユーザーはコンポーネント内のノードへのリンクを共有できます。これで、サーバーが必要なデータを判断する方法もあります。応答をレンダリングするためにフェッチされます。

グラフをツリーと間違えて更新しましたが、それでも、そのグラフに対するユーザーのビューの状態はURL構造で表す必要があると感じています。 また、あなたが実際にReactに取り組んでいることに気づいていませんでした。 データレイヤーをビューと同形に統合するためのフレームワークに取り組んでいる場合、それは素晴らしいことです。 しかし、それはビューの領域を超えており、Reactがフルスタックコントローラーの役割を担うべきではないことに同意できると思います。

スレッド全体を読んでいないので、これがすでに議論されている場合は申し訳ありません。

本当に役立つことの1つは、コンポーネントを「開始/インスタンス化」してライフサイクルメソッドを起動するreact-dom/serverメソッドがあり、開発者がコンポーネントをhtml文字列にレンダリングする準備ができたときに決定できるようにすることです。 。 たとえば、開発者はsetTimeoutまたはより信頼性の高いものを使用して、非同期メソッドが完了するのを待つことができます。

これは、これを達成するために現在reduxで使用している「ハック」です。

  // start/instantiate component
  // fires componentWillMount methods which fetch async data
  ReactDOM.renderToString(rootEle)

  // all my async methods increment a `wait` counter 
  // and decrement it when they resolve
  const unsubscribe = store.subscribe(() => {
    const state = store.getState()
    // as a result, when there are no more pending promises, the wait counter is 0
    if (state.wait === 0) {
      unsubscribe()
      // all the data is now in our redux store
      // so we can render the element synchronously
      const html = ReactDOM.renderToString(rootEle)
      res.send(html)
    }
  })

このアプローチの問題は、2番目のReactDOM.renderToStringがすべてのcomponentWillMountメソッドを再度起動し、不要なデータフェッチが発生することです。

やあみんな！ これは現在取り組んでいるものですか？ この問題はますます重要になっていると思います。 私は最近、react reduxのconnectをdataConnectに拡張するライブラリを作成しました。このライブラリでは、コンテナデータの要件も指定できます。 これらのデータ要件は、ランタイムにバンドルされ、単一のリクエストでGraphQLを使用してクエリされます。 これは、構成可能性と分離を促進し、よりパフォーマンスの高いフェッチを保証するため、データ仕様の将来であると思います。 （リレーで見られるすべての概念）

上記の問題はサーバー側のレンダリングです。 最終的にどのデータ要件になるかを静的に分析できないため、現在、バンドルをDBからクエリするために一度レンダリングし、reduxストアを非表示にしてから、再レンダリングして最終的な文字列を取得する必要があります。 。 この問題は@olalondeの問題と似ています。

反応要素ツリーへのアクションと更新をトリガーし、オンデマンドでDOM文字列の結果を取得できるのは素晴らしいことです。 これが私がそれを描く方法です：

const virtualTree = ReactDOM.renderVirtual(rootEle);

// get the bundled query from redux store for example
const bundle = store.getState().bundle;

// Fetch the data according to the bundle
const data = fetchDataSomehow(bundle);

// hydrate store
store.dispatch({type: 'hydrate', data});
// components that should update should be marked on the virtual tree as 'dirty'

virtualTree.update(); // this would only update the components that needed update

const domString = virtualTree.renderToString(); // final result

他のオプションは、すべてのフックが存在し、didMountのように機能している状態で、クライアント側のように自由に更新できるようにすることです。 ただし、DOMを変更する代わりに、仮想DOM表現を変更し、オンデマンドで文字列にレンダリングします。

皆さんはどう思いますか？ 考慮すべきことがありますか、それとも完全に間違っていると思いますか？

こんにちは、みんな。 私はこの号を1年ほど購読しています。 当時、コンポーネントはモジュール性の主要な単位であったため、コンポーネント内からロードする必要のあるデータを指定できる必要があると考えていました。 この問題は私にとって非常に重要であり、Reactの次のバージョンで確実に解決されると思いました。

それ以来、REST / HATEOSの背後にある理想をより深く尊重するようになりました。これは、アプリケーションのシステム（ブラウザー、クローラー、アプリケーションサーバー、プロキシ、CDNなど）の指針となる原則が続いて。 この問題に関連しているため、_URLはアプリケーションの状態を真に表すものである必要があります_。 それだけで、リクエストを処理するために必要な情報を決定する必要があります。 ビューレイヤーのReactがこれを決定するべきではありません。 データに基づいて構築する必要があります。 ビューはデータの関数であり、データはURLの関数です。

これはいいアイデアだと聞き続けているので、過去にこれを捨てることをためらっていましたが、現実の世界は複雑すぎてこれを機能させることができません。 そして時々、私が一歩後退する例を聞いて、私があまりにも衒学者であるのか、それとも理想主義的であるのか疑問に思います。 しかし、これらの例を熟考すると、必然的に、URLでアプリケーションの状態を表す合理的な方法を見つけることができます。

• あなたの州には独立して変化するパラメータがありますか？ それらを個別のクエリパラメータとして表します。
• あなたの州（またはその一部）は大きすぎてURLに収まりませんか？ 名前を付けて、不変のデータストアに保存します。 名前/ IDで参照してください。
• あなたの状態は非常に速く変化しているので、すべてを永久に保存することはできませんか？ おめでとうございます。あなたは合法的なビッグデータを持っており、ストレージの春であり、それを使って賢いことを考え始めます。 または、恥ずかしがり屋で、UPDATEクエリを使用してデータを変更し、後ですべてのものを永久にキャッシュすることはできないことを受け入れることができます（*）。
• ユーザーごとに異なるビューがありますが、パーソナライズされたホームページなど、同じURLで提供されていますか？ ユーザーIDに基づいて、ユーザーのIDを含むURLに移動します。
• 古いURL構造を壊すオプションがない古いアプリケーションを構築していますか？ それは痛いです、私は同じ船に乗っています。 古いURL構造を適切に設計されたURL構造にリダイレクトし、セッションデータ（またはその他）をURLパスセグメントとパラメーターに変換します。
• アプリケーションのアーキテクチャをほとんどまたはまったく制御できませんか？ Reactが設計されたのはそうではなく、Reactが相互に互換性のあるWordpress / Magnolia / Umbracoアーキテクチャのようなものに収まるように壊されてほしくありません。

他の方法では得られなかった、そのすべての作業で何が得られますか？

• URLを共有することにより、あるユーザーが別のユーザーをアプリケーション内の同じ場所に移動させる機能。
• ブラウザが提供するすべてのツールを使用してアプリケーションをナビゲートする機能。 標準クライアントはその要素にあります。
• クライアントが簡単にたどることができる方法で複雑なページ付けを提供する機能：応答内のnextリンク。 FBグラフAPIはこの良い例です。
• GoogleAnalyticsでのユーザーのワークフローの詳細なグラフ。
• リクエストログだけからグラフを自分で作成するオプション。
• 混沌のスタールートからの脱出：すべてのリクエストをapp.get("*", theOneTrueClientonaserverEntryPoint)として照合する代わりに、サーバーアプリケーションフレームワークを意図したとおりに使用できます。 200 OK\n\n{status: "error"}代わりに、リクエストから正しいHTTPステータスコードを返すことができます。 スタールートは魅力的ですが、それは狂気につながります。

では、スターツールであるReactが操作を制御していないので、データを取得するにはどうすればよいでしょうか。 レンダリングするコンポーネントをどのように知ることができますか？

1. データアクセス関数にルーティングし、関連するリクエストパラメータのデータをフェッチします。 URL全体を解析し、完全なコンテキストオブジェクトができるまで繰り返します。
2. APIリクエストに応答するかのように、コンテキストを可能な限り最も単純な応答オブジェクトに変換します。 APIリクエストを処理していますか？ その後、完了して乾燥します。
3. その最小限の複雑さですが、おそらく大きなオブジェクトをトップレベルのコンポーネントに渡します。 ここからは、Reactコンポーネントの構成です。
4. 文字列にレンダリングし、応答します。 CDNはURLで識別され、すべての州にURLがあるため、これを永久にキャッシュできることをCDNに知らせてください（*上記のオプションを犠牲にしない限り）。 もちろん、CDNには無限のストレージはありませんが、優先されます。

私はここを荒らしするつもりはありませんが、この問題のリクエストのコアテーマは誤った方向に進んでおり、少なくともここで見た理由のために、Reactはそれに対応するために何も実装すべきではないと強く感じています昨年。 優れたアプリケーションアーキテクチャのいくつかの側面は明らかではなく、Webを正しく理解するのは特に困難です。 快適さのために優雅さを犠牲にするのではなく、インターネットとWebを構築した先祖の知恵から学び、尊重する必要があります。

それがReactを素晴らしいものにしているのです。それがビューです。 最高の眺め。 ビューのみ。 λ

@ d4goxnに同意しない必要があります。 私はReactをビューレイヤー以上のものにしようとはしていません。ルーティングは重要ですが、すべてのデータ要件を指定するには間違いなく十分ではありません。 コンポーネント/コンテナーレベルでデータ要件を指定することにより、Reactをビューレイヤー以上のものにすることはありません。 これにより、アプリの分離とワークフローが大幅に向上します。 これは、作業を単純化するだけでなく、大きなアプリケーションが必要になることでもあります。 アプリに30のルートがあり、それぞれにユーザープロファイルコンポーネントを追加したいとします。 それぞれにすべてのデータ要件が指定されている代替ルートに従って、そのデータ依存関係を追加するために30のルートを通過する必要があります。 そのコンポーネントのコンテナでデータニーズを指定する場合は、必要な場所にコンポーネントを追加するだけです。 プラグアンドプレイです。 これだけでなく、すべてのコンポーネントのデータ依存関係のクエリを最適化できます。 リレーはこれの良い例であり、それについての話は私よりもこれをはるかによく説明しています。

私は古い知恵をとても尊敬していますが、それが進化と新しい標準の作成の限界ではないはずです。少なくともそれは私が見ている方法です。

私の提案は、基本的にReactを変更しないことですが、dom / componentsツリーを変更する「仮想のみ」の方法、基本的にはサーバー側で「実行」できるReactを使用することです。これは、非常に簡単に実行できると思います（アクションをブロックするだけです）。 DOMを変更します）。 キャッシュを使用して、CDNを配置することもできます。 今日のサイトとアプリケーションのダイナミクスの成長に伴い、静的キャッシングは減少する傾向がありますが、それは別のトピックです😄

ビューがデータへの依存関係を指定している場合は、依存関係グラフを最適化し、それを最小限のクエリ数に変換する何らかの方法が必要になります。 ビューを作成する前にデータを準備することはできませんが、データを2つのフェーズに分割することはできます。これは、このスレッドでの計画を理解しています。 たとえば、それぞれが独自のクエリを持つ、適度に複雑なコンポーネントのコレクションを取り上げます。 おそらく、それらはすべて同じコンポーネントのインスタンスではなく、単一のクエリに折りたたむことができるパターンはありません。 これがGraphQLが取り組んでいることだと思います。 データストアごとにGQLサーバーを実装または統合する必要があります。 最適化されたGQLクエリのどの部分をどのデータストアで処理する必要があるかを分類することはかなり複雑に聞こえますが、私の提案にもその複雑さの一部があります。

この例では、すべて同じデータを必要とするルートが多数ある場合、そのデータソースの識別子をURLから除外する理由として実際にはわかりません。 スタックのルートのかなり近くに小さなデータフェッチミドルウェアモジュールをマウントします。これにより、そのユーザーオブジェクトがコンテキストにアタッチされ、エンドルートハンドラーに向かう途中で、コンテキストがより多くのミドルウェアに渡されます。 ルートReactコンポーネントは、コンテキストのその特定の部分を気にしないかもしれませんが、それを気にする可能性のある次のレベルの子供、または自分の子孫が気にする子供にそれを渡します。 これが不当に複雑または深い配線を導入する場合は、Fluxストアのようなものが必要になる可能性がありますが、それ自体が大きなトピックです。

分離と分離：私はそこにあなたの痛みを感じます。 私の提案では、2つの非常に異なるシステムがあり、データを保存と取得用に最適化されたフォームから、抽象的な単純さのために最適化されたフォームに変換します。 それから私の見解は、それがコンポーネント階層を下って渡されるので、それに適した形にそれを変換しています。 両方のシステムに追加する必要がある機能を追加しながら、これら2つのシステムを緩く結合しておくことは、私が難しいと言うことではありませんが、抵抗が最小のパスでもありません。 データストアのプログラミングと動的UIのプログラミングの間の精神的な切り替えは現実的です。 以前はバックエンドとフロントエンドの開発者が別々でしたが、HTTPはこれら2つのパラダイム間のインターフェースとして機能していました。 今、私はそれを1つのアプリケーションに内部化しようとしていますが、あなたはそれを委任しようとしています。

アプリケーション内の複雑さとアクティビティの増加により、サーバー上のはるかに大きなデータセットを参照する非常に小さなオブジェクトでクライアントの状態を表すことができなくなるとは思いません。 大規模なマルチプレイヤーの一人称シューティングゲームを考えてみましょう。多くのことが速く起こっており、クライアントからゲームのホスト/サーバーに必要な最小限の情報を送信したいと考えています。 あなたはそれをどれくらい小さくすることができますか？ すべての入力状態のマップ。 タイムスタンプ+不確実性の範囲、キーボード用の約110ビットフィールド、およびマウス/ジョイスティックとVRヘッドセットの向き用の数十バイト。 クライアントは予測、楽観的なレンダリング、物理化を行い、サーバーはクライアントの小さな状態と状態履歴から大量の情報を取得し、かなり大量のデータを返し、すべてのクライアントを修正および更新します（近くのすべてのエージェント、アセットプッシュに対してすべて同じパラメータ）が、クライアント要求のそのストリームは、2KBの要求に快適に収まる可能性があります。 そして、それはアプリケーションアーキテクチャにとって恩恵かもしれません。

私はあなたにRelayとGraphQLについて私を教育するように頼むつもりはありません。 APIが安定したバージョンに到達する前に、表面的に調べただけです（現在、ロックされていますか？）コンポーネントを使用して、データの依存関係を指定するGraphQLスキーマを選択し、実際のデータをフェッチする必要があると確信している場合は、それは良い計画です、そして多分それは私がそれらをもう一度見直す時です。 そのアーキテクチャについていくつか難しい質問がありますが、トピックから外れようとしています。

：ビール：

PS私はHTTPがMMOFPSの優れた通信プロトコルになることを示唆するつもりはありませんでした

@ d4goxn私はこれについてのあなたの躊躇と懐疑論を完全に理解しています。 GraphQLの使用を開始し、後でRelayの概念を導入するまで、これについて考えたことはありませんでした。 ぜひご覧になることをお勧めします。 また、複数のデータストアがある場合でも、新規または既存のサーバーにGraphQLを実装することは想像するほど難しくありません。 話題から外れたくないのですが、これは重要な議論です。

このレベルの抽象化が進むべき道だと私は信じています。 私はRelaxCMSでそれを使用してきましたが、ワークフローと分離は非常に便利です。 それだけでなく、要求されるデータは、UIが必要とするものよりも多くも少なくもありません。これは、各コンポーネントが必要とするデータを収集してマージすることによって自動的に作成されます。 チェックに興味がある場合、これはRelatehttp ： //relax.github.io/relate/how-it-works.htmlによって行われます。 これにより、アプリケーションのどこにでもコンポーネントを含めることができ、アプリケーションの独立したブロックとして機能することを確認できます。

まだ理解していないのは、サーバー側のレンダリングだけです。 reactのソースコードを調べた後、私が説明したようにすでに解決策があるかもしれないと思います。そうでなければ、reactチームの誰かがこれに同意すれば解決策に取り組むことができます。

@ d4goxn私もあえてあなたと議論します:)あなたの元の投稿には、ビューがデータの関数であり、データがURLの関数であるというステートメントが含まれて、画面に表示されるのはURLの関数であるという

私にとっての主な質問は、そのような関数をどのように構築するかです。

あなたが提案するアプローチは、古き良きサーバーサイドMVCアプリケーションと非常に似ているように感じます（たとえば、Spring MVCが良い例です）。 現在のURLは、_ビジネスロジックを実行する_対応するコントローラーメソッドをアクティブにします。 必要なすべてのデータをフェッチして、それらをビューに渡します。 これに関する私の問題は次のとおりです。生成されたWebページを見ると、それはコンポーネントのある種の階層です（必ずしもReactコンポーネントである必要はありません）。 あなたがしなければならないことは、URLから階層を作成または生成することです。 しかし、あなたはそれを二度しなければなりません！ まず、コントローラーで階層をデコードして、フェッチする必要のあるデータを知る必要があります。次に、ビューの階層をデコードして、実際のビューをレンダリングする必要があります。 あまり_DRY_アプローチではないと思います。

私はSpringMVCにあまり詳しくありませんが、Reactの使用方法と非常によく似た方法でこの問題に対処する別のMVCフレームワーク（Netteと呼ばれるPHPフレームワーク）を頻繁に使用します。 このフレームワークはコンポーネントもサポートします。 アイデアは、コンポーネント（フォームなど）ごとに、コンポーネントのインスタンス化、特に_必要なすべてのデータのロード_を担当するファクトリをコードで定義することです。 このようなコンポーネントは、ビューのどこにでも含めることができます。 したがって、HTMLコードを記述して_ビュー階層_を作成するときに、コンポーネントを挿入するだけで、基盤となるファクトリが必要な初期化を処理します。 コンポーネントは小さな独立したコントローラーのように動作し、独自のライフサイクルを持ち、依存関係を処理し、ビューからパラメーター化することもできるため、再利用性が向上します。

私はクライアント側でもReactでこのアプローチを使用してきましたが、非常に実行可能のようです。 Reactコンポーネントは最初から_controller-views_として示されていて、それが私がそれらを使用する方法です。 データフェッチを担当する_controller_コンポーネントがあり、次にビジュアルのみを気にする_view_コンポーネントがあります。 ページ全体は、両方のタイプのコンポーネントで構成されています。 それらはうまく分離されており、簡単に再利用できます。

私のアプリケーションは、必要がなかったので同形ではありません（または今日ではユニバーサルと呼ばれています）が、使用しているスタックはそれが可能である必要があります（そして、まだ実験的なリレーを除いて、このスタックはこの問題の最長パス）。 参考までに、次のようになります。

• コアツールはreact-routerです。 各URLで非同期データ要求をフックすることができ、クライアント側とサーバー側の両方で機能します。 正式に言えば、このアプローチには、前述の問題があります。 これらの_controller_コンポーネントは使用できません。 しかし、ここで重要なのはreact-routerの設計です。 これにより、_data-hierarchy_と_view / componenthierarchy_の両方を同じ場所で定義でき、実際のルート定義も階層化されます。 とても_Reactのように_感じます。
• 状態全体（データ）はreduxで処理されます。 他のすべての利点に加えて、状態全体を単一のオブジェクトに保持します。つまり、サーバー上にオブジェクトを作成してクライアントに送信するのは非常に簡単で自然です。 また、 connect()アプローチのおかげで、小道具を使用してトップレベルからすべてのデータを渡す必要はありません（私のアプリケーションの現在のサイズを考えると、それは絶対にクレイジーです）。
• もう1つのパズルのピースは、状態を可能な限り小さく保つことを可能にする再選択です。 また、デカップリング係数が大幅に増加します。

それはまだ完璧ではありませんが、私がこのスレッドに最初に出くわしたときに利用可能だったものからの重要な進歩です。 サンプルの実装はここにあります。

データフェッチがコンポーネントレベルであるときにサーバー側のレンダリングを実行する方法が必要な場合を除いて、私もほぼすべての同形動作を行っています。 今のところ哲学的な議論に追加することなく、私は長い間、componentDidMountで独自のデータをフェッチするコンポーネントでバニラリアクション（および自家製ルーティング）をうまく使用してきました。 コンポーネントとデータの依存関係を定義するために冗長な構造を維持するというアイデアは本当に嫌いです。これはコンポーネントツリーですでに定義されています。ここでは、完全なコンポーネントになるまで、非同期でフェッチされるデータを組み込む複数のレンダリングパスが必要になる可能性があります。ツリーが解決されました。

今のところ、私は、アイソモフィックな反応、imoにとってこれの重要性が高まっていることを2番目にしたかっただけです。 それまでの間、解決策を模索します。 ありがとう。

@decodeman興味がある場合は、

@ decodeman 、FWIWは、大規模な本番アプリで（あなたがこのredux-sagaの例に触発されていcomponentWillMountに移動する必要があります。 管理しやすくするために、一般的な読み込みシナリオを処理する高次のコンポーネントもあります（たとえば、prop xを確認し、nilの場合は読み込みます。

また、コンポーネント内にデータをロードし、ある種のレイジーレンダリングメソッドを使用できることも非常に重要だと思います。 おそらく、双方を満足させるために、asyncRenderToStringと呼ばれる新しいメソッドを作成し、 asyncOnLoadなどと呼ばれる新しい「ライフサイクル」イベントを追加します。 これは、asyncRenderメソッドを呼び出す場合にのみ呼び出されます。 サーバー側とクライアント側の間のコードの重複に関して、これは、一般的な読み込みコードを別のメソッドに移動し、そのメソッドをasyncOnLoadとcomponentMountから呼び出す開発者によって修正できます。 asyncOnLoadが実行されたかどうかの検出では、おそらく返されたPromiseを使用する必要があります（未定義が返される/メソッドが定義されていない場合は、該当するライフサイクルイベントを直接呼び出してからレンダリングする必要があります）。それ以外の場合は、Promiseが解決するまで待機します。

そのような解決策は、適切なサーバー側のレンダリングのために現時点で使用しなければならないすべてのハッキーな方法を解決すると思います。 たとえば、react router v4を使用してreactアプリケーションのサーバー側でのレンダリングを簡単に行えるようにします（同形アプリケーションを機能させる唯一の方法である集中ルート構成を使用しなくなりました）

これは、いわゆるストリームチェックアウト反応ストリームで解決されました。

2016年11月3日（木曜日）には、フロリアンKrauthan [email protected]
書きました：

また、内にデータをロードできることは非常に重要だと思います
コンポーネントとある種の怠惰なレンダリングメソッドがあります。 多分両方を作るために
サイドハッピーasyncRenderToStringと呼ばれる新しいメソッドを作成し、新しい
asyncOnLoadなどと呼ばれる「ライフサイクル」イベント。 この意志
asyncRenderメソッドを呼び出す場合にのみ呼び出されます。 コードに関して
サーバー側とクライアント側の間の重複これは開発者が修正できます
一般的な読み込みコードを別のメソッドに移動して、それを呼び出すだけです。
asyncOnLoadおよびcomponentMountからのメソッド。 asyncOnLoadが
おそらく、返されたPromiseを使用する必要があります（未定義の場合
返された/メソッドが定義されていない場合は、該当するものを直接呼び出す必要があります
ライフサイクルイベントとレンダリング）それ以外の場合は、約束まで待機します
解決します。

そのような解決策は、私たちが使用しなければならないすべてのハッキーな方法を解決すると思います
現時点では、適切なサーバー側のレンダリングが必要です。 たとえば許可を含む
react routerv4を使用したreactアプリケーションのサーバー側での簡単なレンダリング
（これは、現在の集中ルート設定を使用しなくなりました
同形アプリケーションを機能させる唯一の方法）

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/facebook/react/issues/1739#issuecomment -258198533、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ATnWLUIEJw4m1Y3A4oGDOBzP6_ajDcqIks5q6g4_gaJpZM4CHAWq
。

@ yamat124反応ストリームを検索すると、このプロジェクトのみが見つかります： https ：

少なくともドキュメントに基づくと、データをプリロードするためのライフサイクルイベントを設定して、Promiseが解決されるまでサブチャイルドの次のレンダリング呼び出しを遅らせる方法はありません。 それとも何か他のことについて話しているのですか？

https://github.com/makeomatic/redux-connectはどうですか？

繰り返しますが、それはすべて非常にハッキーな方法です。 コンポーネントツリーから独立したルーティングが必要です。 また、ルートに含まれる「メイン」コンポーネントは、ロードする必要のあるすべてのデータを認識している必要があります（99％の時間で機能しますが、常に機能するとは限りません）。 reactのコンポーネントレンダリングが遅れている場合、両方とも廃止されます。

私は同意します、これはおそらく私が今反応について最も嫌いなことです。 手動で実行できると言って、フレームワークがこの機能を持たないように防御しようとするのは嫌いです。もちろん、ソフトウェア開発に関連するすべてのものと同様に、フレームワークは可能ですが、そうする必要があるという意味ではありません。 この正確なこと自体が、フレームワーク自体の内部から解決されるべきものであることを指摘する必要があるかどうかに注意を払っているモジュールがたくさんあるという事実。

Next.jsには、サーバー側のレンダリングを行うためのasync getInitialPropsがありますが、残念ながら、親からルートまでずっと子のgetInitialPropsを呼び出す必要があります。 Apollo GraphQLクライアントでは、すべてのツリーをトラバースしてサーバー側のデータ要件を収集し、すべてを送り返すこともできます。 Next + Apolloの例： https ：

これらを組み合わせるための非同期Reactコンポーネントライフサイクルメソッドがあると便利です。

今週SSRについて学んだばかりですが、私が書いたものが理にかなっていることを願っています😄

/ cc @nkzawa @stubailo

ところでcomponentWill/DidMountはすでに非同期です、それは役に立ちますか？

https://twitter.com/Vjeux/status/772202716479139840

@sedubois Reactは、レンダリングする前にPromiseが解決するのを待ちますか？ そうでなければ、本当に助けにはなりません！

@olalondeそうです： https ：

const getMessage = async () => new Promise((resolve) => {
  setTimeout(() => {
    resolve('Got async message!');
  }, 3000);
});
class App extends Component {
  state = {
    message: 'Loading...',
  };
  async componentWillMount() {
    this.setState({ message: await getMessage() });
  }
  render() {
    return (... {this.state.message} ...);
  }
}

@seduboisあなたの例では、 componentWillMount注意してください

  async componentWillMount() {
    this.setState({ message: await getMessage() });
  }

undefinedとpromiseを返しますが、スクリーンショットは、ReactがLoading...テキストをレンダリングするため、promiseを待機しない（待機

編集：修正。

@sedubois @polytypic Promiseはまったく処理されないため、関数内でスローされたすべてのエラーが黙って無視される原因にもなります。

@ polytypic @ dantman 「約束がまったく処理されない」とはどういう意味かよくawait演算子が待機しています。 エラーをキャッチする必要があります。例を更新しました（Apolloと同様の読み込み/エラーシグネチャを使用）。

    try {
      this.setState({ message: await getMessage() });
    } catch(error) {
      this.setState({ error });
    }

そしてレンダリング：

{error ? error : loading ? 'Loading...' : message}

@sedubois関数をasyncすると、暗黙的にpromiseが返され、関数内のthrowは、スタックをスローするのではなく、暗黙的にそのpromiseの拒否になります。 これは、 componentWillMountが呼び出し元にpromiseを返していることを意味します。

Reactは戻り値に対して何もしないので、関数は誰かがそれを使って何かをしていることを期待してPromiseを返しますが、代わりに捨てられているだけです。

処理されないため、その約束の拒否はReactのコードによってキャッチされず、未処理のエラーはコンソールに表示されません。

そして、try..catchを実行しても、これから完全に保護することはできません。 setStateがキャッチからエラーをスローした場合、またはキャッチでタイプミスをした場合、そのエラーは黙って消え、何かが壊れていることに気付くことはありません。

@sedubois実際、非同期メソッドは常にJavaScript（まあ、将来のJavaScript）でpromiseを返すように見えます。 C＃でのasync-awaitの問題について考えると混乱しました。 _騒音についてお詫びします！_

それにもかかわらず、スクリーンショットは、Reactが約束が解決されるのを待たないことを明確に示しています。 componentWillMountを呼び出した直後にrenderを呼び出し、 Loading...テキストをレンダリングします。 次に、 setState呼び出した後、再びrender呼び出します。 Reactが約束の解決を待っていた場合、 Loading...テキストはまったくレンダリングされません。 代わりに、promiseが解決するまで待機し、 render呼び出すだけです。これは、この問題のすべての動作の一種です。サーバー側のレンダリング中に非同期IOを実行できるようにするためです。

@dantman @ polytypicthanks👍はい、応答を待ってエラーを適切に処理するには、React内で変更が必要であることを確認してください。 たぶん、コードのあちこちにawait追加すると、それが可能になります😄

個人的には、Webワーカーを使用してアプリケーションの状態を保存し、変更時に小道具を出力します（データストレージとReactコンポーネントからのフェッチを完全に切り離し、Reactをレンダラーとして扱い、一方向のフローの原則を維持します）。レンダリングするために期待される要件（特定のプロパティがtrueであるなど）を含むメッセージ。

そうすれば、最初のメッセージが中間の「読み込み中」の状態であっても、非同期コンポーネントメソッドを必要とせずに、静的なサーバー側のレンダリングには使用されません。

@seduboisメソッドの別のスタックである必要があります。 または重大な変更。 Reactの現在のレンダリングメソッドは同期されているため、promiseを返す別のサーバーレンダリングメソッドが必要になります。

@dantmanこれらの水域は私には深すぎるので、ここでは意見を述べたくありません（私の最初の目的は、Vjeuxの非同期コンポーネントWillMountハックを指摘することでした...）、しかし、うーん、Reactはタイプを見ることができませんライフサイクルメソッドによって返されるオブジェクト。それがpromiseの場合は、非同期で処理し、それ以外の場合は同期で処理します（現在のように、つまり下位互換性のある方法で）？

@fkrauthanが提案したものがundefinedと追加の非同期renderToStringAsync関数を返すことができるライフサイクルメソッドload 。 ただし、 loadは、クライアントとサーバーで常に呼び出す必要があります。 renderまたはrenderToStringを使用する場合、返されたpromiseは無視され、現在の動作と一致します。 renderToStringAsyncを使用し、 loadがpromiseを返す場合、レンダリングする前にpromiseを解決する必要があります。

Next.jsが好きではないのはなぜですか、コンストラクターの前に呼び出されるReact async getInitialPropsライフサイクル関数を追加しますか？ そのようなメソッドがない場合は、コンストラクターを直接呼び出します。

const props = await (Component.getInitialProps ? Component.getInitialProps(ctx) : {});
...
const app = createElement(App, {
  Component,
  props,
  ...
});

Next.jsは、そのgetInitialPropsがReactコンポーネントのライフサイクルにフックされていないため、最上位のコンポーネントでのみ呼び出すことができることを除いて、なんとか仕事をしているように見えます。 それで、アイデアはそこにあり、ただ一緒に結合することができますか？

@seduboisgetInitialPropsが正しい場所ではないと思います。 まず第一に、ES6を使用している人々は、その方法を持っていない/使用していません。 第二に、あなたはinitalProps（これは単なるデフォルトです）で作業したくないのですが、initalPropsと渡された小道具のマージの上で作業したいのです。 そのため、 componentWillMount前にディスパッチされる新しいライフサイクルイベントの提案。

@ Lenne231のアイデアは、他のライフサイクルイベントを中継して、その約束がすでに解決されている可能性があるため、いくつかの問題を引き起こす可能性があると思います。 同じライフサイクルイベントの2つの異なる動作があると、少し注意が必要になります。

そのため、サーバーとクライアントには、その新しいライフサイクルをまったく呼び出さない1つの同期レンダリングメソッドが必要です。 そして、そのライフサイクルを呼び出し、promiseが解決されるまで常に待機してから続行する非同期バージョン。 私の意見では、クライアントレンダリングでもライフサイクルが必要か、サーバーレンダリングだけでライフサイクルが必要かを判断できるため、最大の柔軟性が得られます。

ES6を使用している人は、その方法を持っていない/使用していません

@fkrauthan多分あなたはgetInitialStateを参照しますか？ ここで私は新しいもの、 getInitialProps （Next.jsで使用される名前）について話していました。

2番目のポイントについては、はい、 constructor前ではなく、 componentWillMount前に新しいライフサイクルメソッドを使用する方がよい場合があります。 先に述べたように、Reactのライフサイクルを微調整する余裕がないため、Nextではそうではないと思います。 したがって、なぜそれらのアイデアをReactに取り入れることが素晴らしいのでしょうか。

@seduboisそれでも。 たとえば、es7機能を使用して、クラス本体でstatic props = {};を定義します。 これにより、私の意見ではコードが読みやすくなり、es7が正式にリリースされるとすぐに、ますます多くの人がコードに切り替えるようになると確信しています。

注：ES7はすでに完成しており、新しい言語機能はべき乗演算子のみであるため、クラスプロパティは「ES7」機能ではありません。 あなたが参照しているのは、ステージ2クラスのプロパティの提案です。 それはまだ言語の一部ではなく、変更されたり、削除されたりする可能性があります。

データをフェッチするために反応する非同期関数の必要性はわかりません。代わりに、オンデマンドでrenderToStringを実行する仮想レンダラーに満足しています。 したがって、アクションを設定すると、文字列にレンダリングする前に仮想ツリーがそれに応じて更新されます。 これは、反応において優れたSSRを達成するために理想的だと思います。 データを取得する方法と場所は開発者に任されています。

私は前に述べましたが、良いAPIは次のようなものになります（私が以前に提案したもので少し更新されています）：

const virtualTree = ReactDOM.renderVirtual(rootEle);

// get the bundled query from redux store for example
const bundle = store.getState().bundle;

// Fetch the data according to the bundle
const data = await fetchDataSomehow(bundle);

// hydrate store (this will set updates on the virtual tree)
store.dispatch({type: 'hydrate', data});

// final result
const domString = virtualTree.renderToString();

これにより、Apolloなどの一部のGraphQLクライアントで発生している、ダブルrenderToStringを作成するように強制する問題を回避できます。 データの依存関係を最初にフェッチし、データが入力された状態で2番目にレンダリングします。 renderToStringは非常に高価なので、これは処理の無駄だと思います。

@ bruno12mota私はあなたの理解していますが、それをシミュレートしようとするライブラリの量（そしてあなたのソリューションではまだ何千ものライブラリがあります）は、おそらくそれがあなたがしなければならないものではなくコア機能であるべきだという兆候です上に構築します。 あなたのソリューションは、出力を取得するために、はるかに多くのレンダリング呼び出し（仮想ですが、レンダリング呼び出し）を必要とします。

@fkrauthanはい。ただし、仮想レンダリングは、文字列に対して2つのレンダリングを行うよりもはるかにパフォーマンスが高く、これが私の意見（SSRでのパフォーマンス）の主な問題であり、Reactの弱点です。 reactのrenderToStringを改善するためのいくつかの実験がありましたが、reactチームによるこの問題の実際の進歩はありません（ここで批判することはありません、彼らは素晴らしい仕事をしています）。

私は@ bruno12motaに同意します。この問題についてもしばらくの間検討してきましたが、これが最も簡単なアプローチです。 レンダリングをいつ「フラッシュ」するかを決定する自由は開発者にあります。

それはすべてをはるかに複雑にします。

1.）コードの観点から（コードを調べて、レンダリングを非同期にする方が、VDomを使用するだけで、ある時点でダンプできるレンダラーを作成するよりもはるかに簡単なはずです）
2.）ここで、アンマウントイベントも再検討する必要があります。 また、カスタムコードが必要以上に複雑になります。 たとえば、データをロードすると、データをロードする必要がある新しいコンポーネントがレンダリングされる可能性があります。 ここで突然、libは、どのコンポーネントがどの位置にすでにデータをロードしているか、どのコンポーネントに新しいデータのロードなどが含まれているかを把握する必要があります。

私は@ bruno12motaと一緒です。 VDomは間違いなくより「低レベル」のソリューションですが、React開発者にとっては実装が簡単であり、下位互換性の問題がなく、コミュニティがさまざまな高レベルのソリューションを試すことができます。

たとえば、1つの高レベルのソリューションは、非同期componentWillMountメソッドをラップし、すべての保留中のpromiseを待機し、すべてが解決されたときにVDom.renderToString()起動する「高レベルコンポーネント」である可能性があります。 私はアプリでSSRにこの種の戦略を使用していますが、VDomがないため、残念ながら現在多くのオーバーフェッチを行っています。

現在持っている機能を変えないのが一番いい方法だと思います。 これは、getInitialState、componentWillMount、またはrenderToStringの動作が異なるようにしないことを意味します。

代わりに、ここで説明する問題を解決するために新しい関数を追加する必要があります。 クライアントでのみ呼び出される関数があるのと同じように、サーバーでのみ呼び出される関数が存在する可能性があります。

「renderToStringAsync」関数をreact-dom / serverに追加できると思います。 通常のrenderToStringとの違いは、Promiseを返すことです。

実装側での唯一の違いは、非同期バージョンは、Componentインスタンスを作成するたびに、render（）を呼び出す前に、最初に「initialize（）」を呼び出して待機することです。 コンポーネントに「初期化」メソッドがない場合は、render（）をすぐに呼び出すことができます。

したがって、次の例のアプリ構造がある場合：

    ComponentB
    ComponentC
        ComponentD
        ComponentE

プロセスは次のようになります。

1) instanciate componentA
2) await componentA.initialize();
3) componentA.render()
4) do in parallel(
    instanciate componentB, await componentB.initialize(), componentB.render()
    instanciate componentC, await componentC.initialize(), componentC.render(), do in parallel(
        instanciate componentD, await componentD.initialize(), componentD.render()
        instanciate componentE, await componentE.initialize(), componentE.render()
    )
)
5) render to string

したがって、基本的には、新しいオプションの関数「initialize」を使用する新しい関数「renderToStringAsync」が必要です。 それほど難しいことではないでしょう。

@VanCodingは、私がしばらく考えていたのと同じ考えを持っています。 クライアントのcomponentDidMountでinitializeを自動的に呼び出すこともできるかどうか疑問に思っていましたか？

したがって、サーバーでは次のようになります。

initialize()
render()

そして、クライアントでは次のようになります。

render() // without data (unless available synchronously)
componentDidMount()
initialize()
render() // with data

私はreact-routerv4を使用したreactserverレンダリングと、GraphQLを使用したreact-apolloの実用的な実装を持っています。

これは、 server-side-rendering-code-splitting-and-hot-reloading-with-react-routerに触発されました。

基本的に、サーバーレンダリングは同期コンポーネントを使用し、クライアントレンダリングは非同期コンポーネントを使用するため、webpackはモジュールjavascriptを非同期でロードおよび実行します。

ちなみに、サーバーのレンダリングはNashorn Script Engine（JVM）で実装されています。

• https://github.com/shendepu/moqui-react-ssr
• https://github.com/shendepu/moqui-react-ssr-demo
• https://github.com/shendepu/react-ssr-starter-kit （ブランチアポロ）

クライアントレンダリングコード
https://github.com/shendepu/react-ssr-starter-kit/blob/apollo/src/main.js#L63 -L82

サーバーレンダリングコード
https://github.com/shendepu/react-ssr-starter-kit/blob/apollo/src/main.js#L128 -L155

ルート内の同期コンポーネントまたは非同期コンポーネントを区別するための重要な場所が1つあります。
ルート内の同期されたコンポーネント
https://github.com/shendepu/react-ssr-starter-kit/blob/apollo/src/routes/Counter/Route.js#L10

RouteAsyncの非同期コンポーネント
https://github.com/shendepu/react-ssr-starter-kit/blob/apollo/src/routes/Counter/RouteAsync.js#L7 -L23

注：ファイル名はRoute.jsまたはRouteAsync.jsである必要があります。 コードは常にRouteAsync.jsをインポートする必要があります。 サーバーレンダリング用に構築されている場合、WebpackはRoute.jsに置き換えます。
https://github.com/shendepu/react-ssr-starter-kit/blob/apollo/build/webpack.config.js#L72 -L80

したがって、ビルドdistとdist_ssr 2つのバージョンがあり、 distはクライアント用で、 dist_ssrはベンダーとアプリの2つのチャンクしかないサーバー用です。 。 ストアの状態がエクスポートされ、index.htmlの<script>に__INITIAL_STATE__として埋め込まれます。 ビルドの2つのバージョンがある理由は、 ReactDomServer.renderToString()がまだ非同期コンポーネントをサポートしていないためです。

two-versions-buildアプローチの唯一の問題は、開発モードで警告が発生することです。
React attempted to reuse markup in a container but the checksum was invalid. This generally means that you are using server rendering and the markup generated on the server was not what the client was expecting. React injected new markup to compensate which works but you have lost many of the benefits of server rendering. Instead, figure out why the markup being generated is different on the client or server:

ただし、クライアントとサーバーのバージョンの違いはRoute.jsとRouteAsync.jsのみであるため、警告は無視できます。警告は本番モードでは表示されません。

サーバー側でコンポーネントをレンダリングする前に非同期データをフェッチする場合：

• Rest API：コンポーネントの使用に静的loadDataを追加しました

const { matchedRoutes, params } = matchRoutesToLocation(rootRoute.routes, 
                                                        location, [], {}, rootRoute.pattern)
matchedRoutes.filter(route => route.component.loadData).map(route =>
              route.component.loadData(store, params))

loadDataをプローブして実行します。 matchesRoutesは、親がインデックス0からの一致したルートの配列です。 loadDataは、順番に実行することも、並行して実行することもできます。

• GraphQLクエリ：単に使用getDataFromTreeからreact-apollo/serverすべてGraphQLクエリを実行します。

ところで、Nashorn Script Engineを使用すると、パフォーマンスを最適化する機会が1つあります。ベンダーには、一度実行されて再利用されるライブラリコードとポリフィルが含まれているため、後のリクエストでは、アプリチャンクのみが実行されます。 ライブラリはベンダーチャンクに移動されるため、アプリにはsrcに小さいjavascriptコードのみが含まれているため、毎回ベンダーチャンクを評価する場合に比べてパフォーマンスが向上します。 （すべてのJavaScriptは一度コンパイルされてキャッシュされ、リクエストごとに実行されます。）

アプリのチャンクにはsrcコードしか含まれていないと嘘をつきました。 また、 babel-runtimeと、 babel-runtimeによって参照される複製されたcore-js/libraryれています。 babel-runtimeは、index.jsまたはメインエントリがないため、ベンダーチャンクに移動できません。そのため、webpackはそれをモジュールとして認識できませんでした。 しかし、コードサイズは小さいです。

@VanCodingの例をさらに詳しくhttps ：

たぶん、初期化は適切な名前ではありません-名前は、サーバー上でのみ、またはこの関数が返されるまでレンダリングが遅延する環境でのみ使用されることを意図していることを明確にする必要があります-別名、クライアントではありません。 アイデア： getStaticProps 、 getServerProps 、 getInitialProps 、 getAsyncProps .. ..

また、そのようなrenderToStringAsyncメソッドの開発に技術的またはその他の障害があるかどうかをコアチームから聞くのもよいでしょう。

@nmaroええと、関数は何も返さないはずなので、「get」で始まらない名前がいいと思いますが、それを除けば、これが最善の方法だと思います。 私はそれが最終的にどのように呼ばれるかを気にしません。

さらに、約40行のコードで、この概念実証を行いました。 実稼働での使用を目的としたものではありませんが、さまざまなコンポーネントを使用したテストは成功しました。

したがって、Reactチームがそれでもこれを望まない場合は、サードパーティのライブラリでそれを行うのはそれほど難しくありません。

または、renderToStringにオプションを追加することもできます。
renderToString(Component, {async: true})

@nmaroこれにより、関数の戻り型が提供されたオプションに依存するようになりますが、これは良い習慣とは見なされません。 関数は常に同じタイプの結果を返す必要があると思います。

@VanCodingコードをサードパーティのライブラリとして使用する方法の例はありますか？

@VanCodingかっこいい！ しかし正直なところ、それをreactの内部レンダリングアルゴリズムに統合するのは難しいと思います。 https://github.com/facebook/react/blob/master/src/renderers/dom/stack/server/ReactServerRendering.jsをチェックして、reactの内部で迷子になります... IMO私たちは本当に誰かからの意見が必要です芯。

@seduboisは、通常のrenderToString関数を使用するのと同じように関数を使用できます。 ただし、文字列を直接返すのではなく、文字列に解決されるPromiseを返します。

したがって、それを使用すると、次のようになります。

var react = require("react");
var renderAsync = require("react-render-async");
var MyComponent = require("./MyComponent");

renderAsync(react.createElement(MyComponent,{some:"props"}).then(function(html){
    console.log(html);
});

理論的には、通常のrenderToStringと同じ方法で既存のreactコンポーネントをレンダリングできるはずです。 唯一の違いは、非同期コンポーネントもサポートされていることです。

@nmaroその通りです。 それは役に立ちます。

これのステータスは何ですか？

@firasdib私たちはまだいくつかの反応

+1

Googleのインデックス作成の問題にはSSRが必要であり、以下に説明するすべての手荷物は私たちが対処するためのものであるため、この問題はReactが一般的なライブラリとして成功するために非常に重要です。

JavaScriptが約束を待つ適切な方法を提供していれば、非同期レンダリング全体は必要ないと思います。 次に、天気を示すパラメーターを渡すか、データの読み込みを同期（SSRの場合）または非同期（実際のWebブラウザーの場合）にするかどうかを指定できます。 データ読み込みロジックは、Reactコンポーネントのコンストラクターでpromiseを開始し、componentWillMountで待機することができます。

しかし、私が理解しているように、React開発者はcomponentWillMountの有用性に疑問を示しており、コンストラクターにすべての作業を行わせることを推奨しています。 どちらの方法でも機能します。

一部の人々は、コンポーネントを純粋なビューにすることで問題に対処できると主張しています。 それらは部分的に正しいです。 残念ながら、これは、レンダリングツリーが完了するまでロードするデータがわからない最も一般的なケースでは機能しません。

問題の核心は、レンダリング関数がDOMTreeに追加するコンポーネントを選択するロジックを持つことができるということです。 これが、Reactを非常に強力にし、サーバー側のレンダリングに非常に適している理由です。

IMOの真の解決策は、発行されたすべてのデータ読み込みの約束をreactに登録できるようにすることです。 すべてのデータの読み込みが完全なreactを約束すると、レンダリング結果でコールバックされます。 これにはいくつかの意味があります。

• DOMtreeは数回レンダリングされます。 これは、不安定なデータ読み込み状態から安定した「読み込み済み」状態に「落ち着く」ライブシステムのようなものです。
• バギーシステムでは、システムが安定した「ロード済み」状態に到達しないリスクがあります。 それに対処するには、タイムアウトを導入する必要があります。

その結果、高速ではないプロセスでサーバー側のライブラリをはるかに「計算集約的に」使用することになります。

したがって、私はまだ物事を成し遂げることを支持して一般的なケースを妥協する回避策を考えています:)

それまでの間、非同期データ読み込み環境でSSRを解決する必要があります。

1. データ読み込み呼び出しは、リクエストURLから派生する必要があります（react-routerが例です）。 すべてのデータ読み込みpromiseを1つのpromiseリストに収集します。
2. Promise.all（）を使用します。これは、それ自体がPromiseです。 このpromiseが完了すると、ロードされたデータをサーバーレンダリング関数に渡します。

このモデルは、特定の設計アーキテクチャに関連付けられていません。 フラックス/ reduxはわずかにメリットがあるようですが、アプリケーションでreduxモデルを放棄したため、わかりません。

このモデルの問題は、上記の項目1です。 単純なアプリケーションは、すべてのデータ読み込み呼び出しを認識しています。 独立した「モジュール」を備えた複雑なアプリケーションでは、このモデルには、元のReactコンポーネントツリーのある種のレプリケーション、さらにはレンダリングロジックが必要です。

render（）関数ですでに記述されているロジックを繰り返さずに、複雑なプロジェクトでSSRを機能させる方法がわかりません。 フラックスは解決策かもしれませんが、確かに私はそれを経験していません。

項目1の実装はあいまいです。 react-routerの例では、ルーターとして、そのルートに属する最上位のコンポーネントを返す必要があります。 これらのコンポーネントをインスタンス化できると思います。

app.use(function(req, res, next) {
    match({ routes, location: req.url }, (error, redirectLocation, renderProps: any) => {
    if (error) {
        res.status(500).send(error.message)
    } else if (redirectLocation) {
        res.redirect(302, redirectLocation.pathname + redirectLocation.search)
    } else if (renderProps) {
        // You can also check renderProps.components or renderProps.routes for
        // your "not found" component or route respectively, and send a 404 as
        // below, if you're using a catch-all route.
        console.log("renderProps", renderProps)
        for (let eachComp of renderProps.components) {
            // create an instance of component
            // ask component to load its data
            // store data loading promise in a collection
            console.log("eachComp: ", eachComp)
        }
        res.status(200).send(renderToString(<RouterContext {...renderProps} />))
        } else {
        res.status(404).send('Not found')
        }
    })
});

したがって、トップレベルのコンポーネントはもはや「純粋な」コンポーネントではありません。 これらのコンポーネントは、データの読み込みをトリガーする機能により、トップレベルのコントローラーの役割を果たします。 フラックスモデルはそれを改善しません。 ルートをデータ読み込み機能の関連付けに移動して、別のモジュールに移動するだけです。

残念ながら、トップコントローラーの子にこの方法でデータをロードし続けると、reactレンダリングの目的で作成されたオブジェクトグラフが複製されます。 物事を単純に保つために（可能であれば）、すべてのデータの読み込みを最上位のコントローラーレベルに配置する必要があります。

それが私が見ているものです。

これらのSSRの影響に気付いたとしたら、Googleのインデックス可能なアプリケーションに対するReactの有用性について2度考えたことでしょう。 おそらくfluxは解決策ですが、fluxを使用すると、単純なReactアプリケーションよりもアプリケーション全体が複雑になります。 私はそこに行ったことがある。 単純なデータ読み込み機能の代わりに、複数のファイルにわたってロジックを追跡する必要があります。 理論的なレベルでは、プロジェクトを実行するまでは本当に良さそうに見えました。 新しい人は始めるのに苦労しました。 コードベースからreduxを引き出した後は、そのような問題はありません。 私はそれがすべてのUIデザインの複雑さへの答えだと思いました:)

今週のReactConfから、React Fiber（React 16）がリリースされた後、彼らは次の作業を計画しています（React 17の場合と思われます）。

非同期Reactライフサイクルメソッドが来る可能性があることを意味しますか？

さて、ファイバーは主に高速/スムーズな再レンダリングに関するものではありませんか？ サーバーでは1回だけレンダリングするため、これらの変更がサーバー側のレンダリングに影響を与えるかどうかはわかりません。

@VanCodingは、少し不明瞭だった上記のメッセージを更新しました。 私はファイバーがなくなった後の彼らの計画を意味しました。

私のようにここに着陸する人々のために、私は、役立つかもしれないreactを使用してカスタム実装を作成することになりました。

https://github.com/siddharthkp/reaqt

キーは、サーバー上でのみ実行されるasyncComponentWillMountです。 ここで説明する問題を回避するために、すべてのコンポーネントではなく、エントリポイントコンポーネントでのみ使用できます。

@siddharthkpコンポーネントが何を解決しようとしているのか、実際にはわかりませんか？ トップレベルのApplicationReactコンポーネントに対してasyncComponentWillMountのみをサポートしている場合、なぜライブラリを使用する必要があるのですか？ その約束を外で解決してから、renderを呼び出すことができますか？ それとも私は何かを逃しましたか？

@fkrauthan

その約束を外で解決してから、renderを呼び出すことができますか？

そうです、まさにそれが行われていることです。

魅力は、1つのコマンドで非同期ssr（+コード分割+ hmr）を取得できることです。 ssrは簡単ではないので、多くの人がssrを実装していないのを目にしました。それが動機でした。

トップレベルのApplicationReactコンポーネントのasyncComponentWillMountのみをサポートします

1. 1つのアプリケーションコンポーネントである必要はありません。 各ページ/画面/エントリポイントのデータを取得できます。 （ここで複数のエントリポイントを宣伝し

2. このパターンは意図的なものであり、ツリー内のすべてのコンポーネントが独自のデータを必要とする場合、パフォーマンスの悪いパターンを助長する可能性があります。 トップレベルのコンポーネントでデータを取得し、小道具として子に渡すと、データが抑制されます。

@siddharthkpリポジトリはNext.js（React Conf BTWでも発表されました）よりもどのように改善されていますか？

https://github.com/zeit/next.js

とにかく、サードパーティのライブラリに関する議論はIMHOのトピックから外れています。私たちが興味を持っているのは、React自体のサポートです。

サードパーティライブラリに関する議論はIMHOのトピックから外れており、私たちが関心を持っているのはReact自体のサポートです。

同意します。 reaqtの問題で特定の質問について話し合うことができ

これのユースケースは、react-nativeおよびreact-native-vector-iconsを使用することです。 コンポーネントの小道具は、約束から受け取ったデータによって決定されるようにしたい

const AsyncUser = props => fetchUser()
  .then(data => (
     <User {...data} />
   ))

サポートされている場合、これにより多くの複雑なコードが理解しやすくなり、新しい非同期パターンが開かれる可能性があると思います。

同じ問題があります。ssrを実行して、予測プロップだけでなく、componentWillMountのアクションによってフェッチされたコンテンツも検索します。プロップが準備されるのを待ってから、プロップを文字列にレンダリングするにはどうすればよいですか。

誰かがこれが便利だと思ったら、 react-frontloadというライブラリを作成しました。これを使用すると、promise-returning関数をコンポーネントにバインドして、サーバーとクライアントの両方のレンダリングでコンポーネントがレンダリングされるときに実行できます。

この関数はサーバーレンダリングで「同期的に」実行されますが（実際にはそうではありません;-)、最終コンポーネントのレンダリングは解決されるまでブロックされます）、クライアントレンダリングでは通常どおり非同期に実行され、ページがサーバーレンダリング。 コンポーネントごとに、実行時をよりきめ細かく制御するために指定できるオプションもあります。

これはデータの読み込みに非常に役立ちます-私が解決するために書いたユースケースのほとんどです。 やってみて！ 😄

https://github.com/davnicwil/react-frontload

<AsyncComponent 
  delayRendering={LoadingComponent}
> 
   {/*return a promise that returns a component here*/}
</AsyncComponent>

データがあることがわかっているので、上記のアプローチで行う必要のないすべての条件付きレンダリングについて考えてみてください。

これに参加します。 Reactに欠けているのはまだ重要な機能だと思います。 また、サードパーティのライブラリがこの主題をカバーしている場合でも、これは内部から直接行われる必要があることに同意します。

私は実装を思いついたhttps://github.com/timurtu/react-render-async

非常に優れた非同期コンポーネントインターフェイス、@ timurtu。

...みなさん、このスレッドに直接関係するさまざまなことがあるので、ここでチャイムを鳴らしたいと思っていました。このスレッドを長い間追跡してきました。

• 1つは、SSRを考慮すると、ルートレベルのデータフェッチが最も理にかなっていると思います。理由は次のとおりです。
  Redux-First Routerデータフェッチ：非同期ミドルウェアの80％のユースケースを解決
• Reduxを使用したサーバーレンダリングは今ではばかげたシンプルです。これまでに見たことのないように行う方法について、 Redux-Firstルーターを使用したステップバイステップガイドをサーバー-Pro / wRedux-Firstルーターのように10ステップでレンダリングする
• 最後に、コード分割を正しく行うには、両方（つまり、SSR +分割の両方）も実行する必要があります。 両方を同時に行うことは大きな問題であり、少数の人が成功裏に達成し、今までコミュニティを支援するための一般的なパッケージを持っていなかったことがわかりました。 React Universal Component + babel-plugin-universal-import + webpack-flush-chunks （およびextract-css-chunks-webpack-plugin ）は、この問題を実際に解決するパッケージのファミリーです。 そして初めて。 基本的に、サーバー上でコンポーネントを同期的にレンダリングできますが、さらに重要なことに、クライアント上での最初の同期レンダリングのために、レンダリングされた正確なチャンクをクライアントに転送します。 webpackプラグインを介してcssチャンクスタイルシートを取得することもできます。 これは、 @ timurtuが共有したものや、 main.js読み込み、解析、評価、レンダリング、そして最後に数秒後に動的インポートを要求する必要がある多くのそのようなコンポーネントとは異なります。 これらは、スタイルなしコンテンツのフラッシュ（FOUC）を解決するためのソリューションですが、サーバーにレンダリングされた正確なチャンクをページに埋め込むことはできません。 ユニバーサル（私のパッケージファミリーの名前）を使用すると、従来のWebアプリのように動作する同期的な方法で、インタラクティブ（TTI）短縮できます。 あなたはこの記事でそれについてもっと学ぶことができます： React Universal Component 2.0＆babel-plugin-universal-import

ルートレベルとコンポーネントレベルの長所/短所については触れていませんが、最初のリンクは主にそれに焦点を当てています。 基本的に、データを（並列ではなく）順番にフェッチする必要があるネストされたコンポーネントがある場合、コンポーネントレベルはSSRに悪影響を及ぼします。 また、ルートごとに1つのフェッチしか正しく実行できない場合は、 componentDidMountで行うのではなく、データの依存関係をルートエンティティにアタッチしてコントラクトを形式化することをお勧めします。 上記の他の多くの人がこれと同じ結論に達しました。 Redux-First Routerは、Reduxを非常に快適に操作できるようにする一種の「契約」に沿って、これを非常にうまく形式化しています。

Redux-First Routerは、多くの古いパラダイムを再び新しくしますが、驚くべきことに、Reduxエコシステムに欠けている部分としてぴったりと適合します。 Reduxのワークフローにネイティブなルーターが必要な場合は、Redux-FirstRouterを試してみてください。 それは比較的新しく、私はオープンソースの初心者ですが、それは私が基本的に1年間取り組んできたものであり、それが出てから2か月で大きな牽引力を得ました。 人々はそれを愛しています。 ぜひチェックしてみてください:)。

また、React Routerよりもはるかに優れたReduxのソリューションであり、残念ながら優れたRedux-LittleRouterが見逃していた方法でビジョンを正しく実現する方法を説明するローンチ記事もあります。
プレリリース：Redux-First Router —Redux-Little-Routerを超えた一歩

RLRとRFRの主な違いは、RFRが常にLOCATION_CHANGEDだけでなく、ルートごとに異なるアクションタイプ（つまり、URLの変更）をディスパッチすることです。 これにより、他のアクションと同様に、URLの変更をレデューサーの一意のタイプとして切り替えることができます。 小さく見えるかもしれませんが、大きな違いがあります。 そのため、 <Route />コンポーネントは必要ありません。これは、Reduxランドでは不要です。 ルートthunksでのデータフェッチからReact Native、React Navigation、コード分割、プリフェッチなど、 Redux-FirstRouterがサポートする機能の膨大なリストもあります。

人々の考えを聞きたいです。

@faceyspaceyありがとうございます。非同期データに基づいて小道具を設定する場合など、私が抱えていた問題に対処していると思います。たとえば、 react-native-vector-iconsはアイコンを約束として返すことができます。 これは間違いなく別の見方ですが、非同期コンポーネントを状態に結び付けるcomponentWillMountまたはredux X_GET_START 、 X_GET_END 、およびX_GET_ERRORアクションボイラープレートを削減します。コンポーネントをレンダリングするために本当にそのリクエストを1回だけ行いたい場合。 データのポーリングなどを行っている場合は、ステートフルでreduxを使用する方がおそらく理にかなっています

@faceyspaceyルートレベルについてあなたが言っていることはわかりますが、必要なデータのフェッチのみに依存し、周囲の他のすべてを同期的にレンダリングする小さなコンポーネントを使用する方がよいのではないでしょうか。

より良い？ どこ？ React Nativeについて？ Facebookのような大規模な組織のReactNativeアプリでは？

たぶんReactNativeで。 私の見解にSSRがある場合、議論はありません。 繰り返しますが、フェッチを実行できる1つのコンポーネントに制限しない限り、リクエストごとに複数のフェッチがないと、やりたいことは不可能です。 その時点で、ルートエンティティとの契約を形式化することをお勧めします。

React NativeとSPAについては、確かに。 しかし、データデップが組み込まれているコンポーネントをテストするのは面倒です。 Apolloにはここにいくつかのものがありますが、最後に、データペアのコンポーネントテストを本当に正しく、つまりシームレスにするために、長いToDoリストがあることを確認しました。 セットアップとモックが簡単なストアが1つあるセットアップが好きです。 すべてのテストでそれを行う方法を再利用できます。 次に、そこからコンポーネントをテストするのは、スナップショットを取得する単純な同期レンダリングです。 コンポーネントにデータディップを追加すると、Reactのテストは直感的ではなくなります。 しかし、人々はそれを行い、それを自動化します。 標準が少なくなり、カスタムアドホックコードに近づきました。 移入する必要のある非同期コンポーネントごとに異なる戦略を立てるよりも、非常に明白な方法で非同期に移入できるストアを用意する方が生産性が高くなります。

SSRがなく、テスト戦略がシームレスで邪魔にならない場合は、コンポーネントレベルに反対しません。 あなたがメガコープであるなら、それは理にかなっています。なぜなら、すべての開発者がトップルートレベルに触れる必要がなく、他の人のためにそれを壊す可能性があるからです。 そのため、FBはRelayとGraphQLを使用してこのルートを開拓しました。 問題の事実は、世界で100社だけが本当にこの船に乗っているようなものです。 ですから、私はコロケーションをほとんどの人/アプリ/企業にとって現実よりも誇大宣伝だと考えています。 ルートレベルのコツをつかみ、Redux-First Routerのように非常にうまく機能するパッケージを入手すると、メンバーがルートレベルに触れることを許可されているチームのアプローチを開発するのがはるかに簡単になり

https://www.codesandbox.io

基本的に、それがどのように行われるかを理解したら、私はあなたの意見を聞きたいです。 これはSPAであることに注意してください。 したがって、SSRの例については、デモリポジトリまたは定型文を確認する必要があります。 しかし、これは良いスタートです。

最も簡単な方法は、非同期レンダリングメソッドをサポートすることだと思います（レンダリングはpromiseを返します）。 これにより、ルートコンポーネントが子コンポーネントのレンダリングを待機できるようになり、もちろんレンダリングの結果が約束されます。 私はここでpreactにこのようなものを実装しましたhttps://github.com/3axap4eHko/preact-async-example

@faceyspacey上記の詳細な回答ありがとうございます。 私はRedux-FirstRouterのアイデアが本当に好きです。それは間違いなく私のすべての問題を解決し、以前よりもはるかに透明でクリーンなものになります。

本当にありがとう！

@raRaRaあなたがそれを気に入ってくれてうれしいです！ ...最大の課題の1つは、これまでルートレベルのデータフェッチの適切な抽象化が行われていなかったことです。 React React v3にはコールバックがあり、v4には優れたパターンがあります（特にreact-router-configパッケージの場合）が、v4では自明ではなく、ファーストクラスではありません。 それは後付けです。 ただし、さらに重要なのは、Reduxには存在しないことです。 したがって、reduxユーザーが完全な「ルートレベル」の抽象化を利用できるようになったのは、これが初めてです。

RFRでは、「ルートレベル」と「コンポーネントレベル」の重要性が再考されると思います。 RelayやApolloのようなものは、コンポーネントへのデータ依存関係のペアリングに関して多くの誇大宣伝を生み出しましたが、これら2を使用していない場合、ライフサイクルハンドラーで何かを行うことによって、ある時点で傷ついた世界に陥る可能性があります。 。

とはいえ、最終的にRFRはApolloとルートレベルで統合される予定です。 前述のまれな例外を除いて、コンポーネントレベルで物事を行うことによるメリットはほとんどありません。 少なくとも80％の時間（そしておそらくアプリでは100％）、ルートに基づいて必要なすべてのデータを決定できます。 それが不可能な場合は、「ビューレイヤー」でデータを取得しているため、URLによってすべてが解釈されるように再考される可能性があります。 そのため、Apolloのようなツールを使用しても、問題のあるアンチパターンに取り組み始めます。これにより、「状態」をビューレイヤー以外の場所に配置しないことで、最終的には痛みを引き起こす可能性があります。 つまり、これらのデータフェッチを実行するために必要な状態です。 多くの場合、データのフェッチに使用される正確なパラメーターを調整する必要があります。 したがって、データをフェッチする直前に、状態と小道具を取得し、2を変換してパラメータを取得します。 これは、現在ビューレイヤーに存在し、その再レンダリングメカニズム（つまり、ライフサイクルハンドラーが呼び出されるとき）の対象となるものです。 ある時点または別の時点でのすべてのアプリは、受信/変更された無関係の小道具に応じて、データがフェッチされるべきときにフェッチされない、またはフェッチされないという結果になります。 また、すべてのアプリで、変更された無関係の小道具を防ぐために追加のコードを作成する必要があります。 つまり、データのフェッチに使用されるパラメータに影響を与えない小道具。

React Native + Apolloの場合、SSRがないため、サーバーで順次データフェッチが発生する可能性があるため、問題は少なくなります。 ただし、画面が非常に小さい場合、コンポーネントレベルのデータフェッチが本当に必要ですか。 あなたは一般的に、それぞれの「シーン」がそのデータに関して何を必要としているかを知っています。 これは、100万個のグラフ、複数のテーブルなどを備えたデスクトップWebパネルダッシュボードのようなものではありません。その1つのユースケースは、コンポーネントレベルが意味をなし始める最大の主要な場所です。 ただし、そこでも、これらすべてのウィジェットのすべての要件を1つの場所で指定し、Apolloを介してそれらをフェッチできます。 まだ十分に考えていませんが、基本的な考え方は、GraphQLデータ要件をルートにアタッチしてから、他のReduxデータと同じようにコンポーネントでデータに接続することです。 つまり、より具体的には、react-reduxのconnectとApolloの同等のものの両方を排除するという考え方です。 1つだけ欲しいのですが、もっとフラットにしたいのです。 Apolloを使用するには、コンポーネントに本当に必要なものにアクセスするために、より深くネストされたデータを破棄する必要があります。 ビジョンは、通常のReduxと同じように見える1つの方法に加えて、ルートレベルでのgraphql仕様です。

私はほとんど調べていないので、それについて話すのは少し時期尚早ですが、ルートレベルがアプリの正しいアプローチである場合、Apollo + GraphQLも例外ではありません。

最後に、すべてのデータ依存性と非同期作業がコンポーネントから分離されている場合、テストは非常に簡単です。 関心の分離は、データフェッチについて心配することなくコンポーネントをテストできる場合、生産性を大幅に向上させます。 もちろん、テストでは、事前に非同期フェッチを実行してストアにデータを入力する必要がありますが、コンポーネントから分離しておくと、すべてのテストで事前に使用するいくつかのsetupヘルパー関数の下でそのような作業を簡単に形式化できます。コンポーネントがどのようにレンダリングされるかをテストする前に、ストアにデータを入力します:)

@faceyspacey私は完全に同意します。 しかし、私はApolloもGraphQLも試したことがないことを認めなければなりません。私はそれらを確実にチェックして、それらが私のユースケースにどのように適合するかを確認します。

私はMVCパターンを使用してWebアプリケーションを作成することに非常に慣れています。ここでは、基本的にすべてのデータとコントローラーへの依存関係を取得します。 次に、データをビューまたはビジネスロジックに挿入します。 あなたが言ったように、それはビューがデータフェッチと結合されていないのでテストをはるかに簡単にします。

ビュー部分がデータをフェッチしてビジネスロジックを実行しているMVCアプリケーションを見たことがありますが、それはひどいものです。 一部のビュー/コンポーネントに隠されており、テストが困難/不可能になるため、どちらのデータがフェッチされるかわかりません。

私にとって、Redux-First Routerは、MVCのコントローラー部分とルートに非常によく似ています。 これはとても理にかなっています:)

ありがとう。

結局のところ、新しいスタックは次のとおりです。

M：リダックス
V：反応する
C： Redux-最初のルーター（まもなく「Rudy」に名前が変更されます）

React（特にRedux）が登場したとき、私たちは皆、MVCの古代の知恵を捨てたいと思っていたようでした。まるで、以前のアプリケーションを開発する際の苦痛を完全に取り除くことができたかのようでした。 しかし、最終的には、それをサポートするためのツールがまだ構築されていないだけだと思います。 結局のところ、リアクティブなクライアントファーストのアプリケーションであっても、MVCの恩恵を大いに受けています。

新しいクライアントファーストスタックと従来のサーバーサイドMVCでは動作が少し異なる場合がありますが、基本的には同じ3つの関心の分離です。

3つの相互作用/動作の違いについては、基本的に、これまでコントローラーは初期段階でモデルを取得し、それらを使用してビューをレンダリングしていました。 そして今では、コントローラー（RFR）がすぐにビューをレンダリングし（「UIモデル」、つまりRedux状態で選択）、コントローラーがドメインモデル（これもRedux状態で保存されている）を見つけたら、ビューをもう一度

こんにちはみんな、このリンクを見てください。 これがデータサーバー側のレンダリング例ですhttps://github.com/bananaoomarang/isomorphic-redux

@ harut55555 idkそれは私だけかもしれませんが、これはgetリクエストとpostリクエストを行うための多くのコードのようです

何か変更はありますか？ リリースされた16の反応とほとんどのソリューションが機能しない

現在のアプローチは、reduxobservableやreduxthunkなどのツールでreduxを使用することだと思います

私の使用例

<App>
    <Page>
        <AsyncModule hre="different.com/Button.react.js" /> downloaded from external url on server or client
    </Page>
</App>

問題は、アプリをレンダリングする前に、どのようなコンポーネントを使用するかわからないことです。

好奇心旺盛なコンポーネントではなく、データ/コンテンツをダウンロードしてみませんか？

いつ？ 動的ページがあり、コンポーネントはそうである場合とそうでない場合があります

条件付きレンダリングが必要なようですhttps://reactjs.org/docs/conditional-rendering.html

ルーティングの問題だと思います。reactはページをレンダリングするだけで、レンダリングデータを管理および要求するべきではありません。

Apolloの@graphqlを使用すると、データの読み込みが非常に簡単になり、React-Router v4コンポーネントベースのAPIを使用すると、シンプルなコンポーザブルルーティングが可能になります。 どちらもReduxのアプリケーション状態に直交しています。

データのフェッチを待機するシングルパスストリーミングレンダリングを実行するには、 render()がpromiseを返すことができる必要があります（クライアントでは、今と同じように、サーバーでのみpromiseを返します）。

次に、 @graphqlは、データがロードされた後、render（）のpromiseを返すことができます。 残りはすべて単純なReactです。

数ヶ月前、私はJSConfアイスランドで、Reactの今後の非同期レンダリング機能について説明しました（第2部を参照）： https ：//reactjs.org/blog/2018/03/01/sneak-peek-beyond-react

@acdliteは、同じ概念を適用して、Reactコンポーネントでサーバー上のデータを非同期的に待機し、準備ができたらマークアップを段階的にフラッシュする方法について説明しました： https ：

これらの講演をお楽しみください。 1年かそこらでこの問題を終わらせ、これに対する公式の戦略を立てることができるかもしれないと思います。

リングを覚えています。 私たちは結婚して未来を一緒に計画しています。 今これを終わらせて、私に会いに来てください。 働く時間はいつも愛

ReactDOMServer.renderToStaticMarkupを使用してツリーをウォークし、非同期の依存関係に到達する場所にブックマークを配置し（通常、APIからデータをロード）、ツリー全体が解決されるまで、これらの依存関係が解決されるまでツリーをウォークし続けることができます。次に、最後のReactDOMServer.renderToStringを実行して、実際にHTMLにレンダリングします。これは、すべての依存関係が解決されたため、同期されます。

私はreact-baconjs ： render-to-html.jsでこのアプローチを採用し@gaearonのコメントに触発されました。

@ steve-taylorええ、これは機能します。 これは、 react-frontloadで使用する回避策でもあります。これは、Reactアプリで機能する、これに対するより汎用的なソリューションです。

基本的に、同期レンダリングロジックを2回実行し、最初のレンダリングでヒットしたすべてのデータ読み込みの約束が解決されるのを待ってから2番目のレンダリングを実行することで、非同期レンダリングを偽造しているだけです。

明らかに少し無駄がありますが、十分に機能します（最初のレンダリングの出力は単なる約束ではなく、実際のHTMLでもあります）。 真の非同期サーバーレンダリングがReactに組み込まれると、驚くべきことになります。

@davnicwilいい仕事！ 特定の非同期SSRソリューションを一般化することを考えました。 react-frontloadは無制限の非同期深度を処理しますか？ あなたが「二度」と言ったので尋ねる。

@ steve-テイラー乾杯！ はい、深さでツリー内のコンポーネントの深さを意味する場合、それは無制限です。 これにより、コンポーネント自体で（高階コンポーネントを使用して）データ読み込み関数を宣言し、最初のレンダリングでそれが発生すると、実行されてPromiseが収集されます。

動作しないのは、データを非同期でロードする子コンポーネントがさらにあり、それが理にかなっている場合は、結果に応じて動的にレンダリングされる場合です。 これは、この種のネストが発生しないようにアプリを構成する必要があることを意味します。実際には、これは大きな制限ではありません。 実際、多くの点で、ネストされた非同期ロジックはシリアルリクエストを意味し、待機時間が長くなるのに対し、フラット化はパラレルリクエストを意味するため、UXに関しては優れています。

とはいえ、ネストの問題（実際には、この非同期サーバーのレンダリングの問題全体）は、近い将来、Reactに登場するSuspenseのもので解決される可能性があります。 🤞

参考までに、これに取り組み始めました。

https://reactjs.org/blog/2018/11/27/react-16-roadmap.html#suspense -for-server-rendering

素晴らしい@gaearon！

@davnicwil react-baconjsは無制限の深さをサポートします。

@gaearonこれにより、create-subscriptionでオブザーバブルをサポートできるようになり、オブザーバブルの

この機能が欲しいのは2つの理由からです。 まず、私のアプリでは、状態はWebワーカーに保存されます。 したがって、コンポーネントに必要なその状態のビットを取得することは非同期操作ですが、5ミリ秒ほどかかり、データを待っている間にReactが何かをレンダリングすることは意味がありません。 次に、現在、オブザーバブルをコンポーネントに変換する普遍的な方法はありません。オブザーバブルが最初の値を同期的に出力する場合は、サブスクライブしてその値を取得し、サブスクライブを解除してから、再度サブスクライブして変更をリッスンします（これがリプレイです）。 create-observableドキュメントの件名の例）。 また、最初の値を非同期で出力する場合は、最初にnullをレンダリングし、変更をリッスンします。

@ steve-taylor react-frontloadは、 1.0.7リリースで、無制限の深さのコンポーネントネストもサポートするようになりました。

このライブラリがこのスレッドにたどり着く一部の人々に役立つことを願っています-クライアント/サーバーレンダリングで動作する非同期データ読み込みソリューションを探している場合は、最小限の統合作業でそれをチェックする必要があります。

アプリがReactHooksでビルドされたときにこの問題が発生し、それを解決するためにパッケージreact-use-apiを作成しました。これは、APIデータをフェッチしてSSRをサポートするカスタムフックです。 パッケージが困っている人に役立つことを願っています。

ただし、まだ公式の解決策を待つことを楽しみにしています。react-frontloadが言うように、現在レンダリングが開始されると非同期データの読み込みが行われるのを待つ組み込みの方法はありません。