React ベースの SPA をサーバー側でレンダリングしたいと思います (最近はそうではありません)。したがって、React をreact-router、redux 、およびisomorphic starterkitのようなビルド レイヤーと組み合わせたいと考えています。
すべてを結合するhapi Universal reduxがありますが、フローを整理する方法に苦労しています。私のデータは、REST API の複数のエンドポイントから来ています。コンポーネントが異なればデータのニーズも異なり、クライアントにジャスト イン タイムでデータをロードする必要があります。サーバーでは、特定のルート (コンポーネントのセット) のすべてのデータを取得し、必要なコンポーネントを文字列にレンダリングする必要があります。
私の最初のアプローチでは、redux のミドルウェアを使用して非同期アクションを作成しました。これは、データをロードし、promise を返し、SOME_DATA_ARRIVED
promise が解決されたときにアクションをトリガーします。次に、レデューサーがストアを更新し、コンポーネントが再レンダリングされます。すべて問題ありません。原則として、これは機能します。しかし、ルーティングが始まると、流れがぎこちなくなることに気付きました。
多数のデータ レコードを一覧表示する一部のコンポーネントには、レコードをフィルター処理するための複数のリンクがあります。フィルタリングされたすべてのデータ セットは、 のような独自の URL を介して利用できる必要があります/filter-by/:filter
。そのため、さまざまなコンポーネントを使用<Link to={...}>
して、クリック時に URL を変更し、ルーターをトリガーします。ルーターは、現在の URL によって表される状態に従ってストアを更新する必要があります。これにより、関連するコンポーネントが再レンダリングされます。
それを達成するのは容易ではありません。最初にアクションをトリガーしようとcomponentWillUpdate
しました。これにより、データが非同期に読み込まれ、ストアにデータが入力され、コンポーネントの再レンダリング サイクルがもう 1 回発生しました。ただし、これはサーバーでは機能しません。3 つのライフサイクル メソッドしかサポートされていないためです。
だから私はこれを整理する正しい方法を探しています。ユーザーの観点からアプリの状態を変更するアプリとのユーザー インタラクションは、URL を更新する必要があります。IMOこれにより、ルーターは何らかの方法で必要なデータをロードし、ストアを更新し、調整プロセスを開始する必要があります。
だからinteraction -> URL change -> data fetching -> store update -> re-render
。
initial state
要求された URL からロードするデータを決定し、その状態をstore
生成して reduxの生成に渡すことができるため、このアプローチはサーバーでも機能するはずです。しかし、私はそれを適切に行う方法を見つけていません。したがって、私には次のような疑問が生じます。
- まだ理解していない/知らないことがあるため、私のアプローチは間違っていますか?
- redux の REST API からロードされたデータを保持するのは正しい
store
ですか? state
コンポーネントをredux に保持し、store
他のコンポーネントを自分で管理するのは少し厄介ではありstate
ませんか?- 持っているという考えは
interaction -> URL change -> data fetching -> store update -> re-render
単に間違っていますか?
私はあらゆる種類の提案を受け付けています。