Redux: Reduxの時代は過ぎ去りました

https://github.com/rackt/redux/issues/464

多くの人がReduxにかなり満足しています。 あなたは周りに尋ねるべきです—私はこの質問に答える資格がありません。 アプリがFacebookのように非常にデータ量が多い場合（複雑な関係を持つ多くのネストされたエンティティ）、GraphQLバックエンドに投資してRelayを学ぶことをお勧めします。 私はそれについて良いことを聞いただけです。

もちろん、Reduxはより明示的であり、宣言型データのフェッチを解決しません。 ReduxとGraphQLを

ReduxはRelayよりもはるかに低いレベルであり、プレーンなJSオブジェクトおよび関数が「過去」であるよりも「過去」ではありません。 リレーはフレームワークであり、サニティチェックを行わないReduxは10個の10ライナー関数であるため、スコープが異なることは驚くべきことではありません。 あなたに最適なものを選んで、私たちに知らせてください。

GraphQLの宣言型フェッチは、驚くべき一流です。 ただし、Relayにはまだ主にHoC APIがあり、それ自体は宣言型ではありません。 Relayがコンポーネントツリーから切り離されたより柔軟なAPIを提供する場合、適切なReduxバインディングを作成できますか？

2つの異なる問題を解決する2種類のシステムだと思います。
このチケットは、ハンマーの時間が経過したかどうかを尋ねる大工のようなものです。
私が主張するgraphqlベースのシステムは、多くのアプリにとって過剰に設計されたソリューションです。逆に、複雑なデータ構造を持つアプリは、reduxを使用して構築された場合、おそらく不十分に設計されています。

私が主張するgraphqlベースのシステムは、多くのアプリにとって過剰に設計されたソリューションです。逆に、複雑なデータ構造を持つアプリは、reduxを使用して構築された場合、おそらく不十分に設計されています。

それを置く良い方法; それは私もそれについてどう感じているかです。

@gaearonはreduxで良い仕事を続けます！ 最高のツールの1つです！ 私はそれを私の会社の5つの大きなアプリと2つの小さなアプリで使用していて、それを愛しています！

@gaearonはreduxで良い仕事を続けます！ 最高のツールの1つです！ 私はそれを私の会社の5つの大きなアプリと2つの小さなアプリで使用していて、それを愛しています！

：100：

私は彼らが同じではないと思います：

• リレー-サーバーからのデータフェッチ管理を解決するため
• redux-アプリケーションの状態管理を解決するため

多くの複雑なアプリケーションには、管理する必要のあるサーバーに関係のない状態が含まれています。 リレーを使用する場合は、最終的には自分自身もreduxが必要になると思います。 反対に、リレーは非常に素晴らしいブーストのように見えますが、サーバー関連のものだけです

質問は、リレーがフラックスに触発されたデザインパターンとどのように関連しているかです。 リレーはどこで終わりますか、いつReduxが必要ですか？ リレーフラックス2.0ですか？

Todoリレーの例：reduxは廃止されますか？

たぶん、GraphQLとの間で自分自身をマップする方法とタイミングをレデューサーに伝える方法はありますか？ 複雑ではないことを言うのではなく、それを理解するための最も簡単な方法は何ですか。

リレーとは何かについてもっと学ぶ必要があります。 確かなのは、数百行のコードではありません。

@oriSomethingあなたは完全に正しくありません。 リレーは多くの状態管理も解決します。

@gyzerok私はクライアント側のアプリケーションの状態を意味しました

@oriSomethingはい、クライアント側のアプリケーションの状態について話しています

@gyzerok私はそれを逃したに違いない。 これについてのリンクを教えていただけますか？

@oriSomethingリレーは暗黙的に管理するため、特別なリンクはありません。 たぶん、あなたはFBがリレーについて話しているのを見ることができます。 彼らは、Relayがキャッシュの問題をどのように解決するかについて話します。 クライアント側のアプリケーションキャッシュ=状態。 はっきりとした話を覚えていません、ごめんなさい。

@oriSomethingは、開発者が明示的な状態管理を行う必要がある唯一の場所です。

@gyzerokわかりました、その場合、リレーが行うサーバーに関連しない状態管理はありますか？ 私が理解している限り、そうではありませんか？

@oriSomething正しく理解

@oriSomethingはい、そうです=> https://facebook.github.io/relay/img/Guides-Containers-HOC-Relay.png
チェック： https ：

クライアントに十分なデータがない場合にのみ、Relayはサーバーに追加データの要求を送信します。

ReduxはRelayよりもはるかに低いレベルであり、プレーンなJSオブジェクトおよび関数が「過去」であるよりも「過去」ではありません。 リレーはフレームワークであり、サニティチェックを行わないReduxは10個の10ライナー関数であるため、スコープが異なることは驚くべきことではありません。

そこで、私は楽しみのためにslim-redux.jsを作成しました。コメント、開発者への警告、サニティチェックのないReduxのバージョンです。 これは、すべての重要なReduxテスト（サニティチェックテストを除く）に合格し、99行です：wink:。 これは、RelayとReduxが大きく異なるスコープを持つツールであるという私の主張を封印するはずです。

@IwanKaramazow私は十分に明確ではなかったと思います、私が言おうとしているのは、すべてのデータがサーバーに関するものではなく、管理するサーバーに関係のないデータがあり、本当にリレーとは思わないこのデータを管理できる場合でも、「ツール」に移動します

@oriSomething例を挙げていただけますか？

@mattappersonに完全に同意し

私は、例えば、クライアント側のフォームの状態について協議を@oriSomething考える@IwanKaramazow

GraphQLのため、Redux =>リレーから移動しました。 私のアプリケーションのほとんどすべてのリソースは階層的でした。 それらは当然、ネストされたエンティティであることが理にかなっています。 これらのモデルのキャッシュをReduxに保持することは素晴らしいことでした。 私は自分のデータを正しく見ていて、素晴らしいredux-devtoolsですばやく繰り返すことができました。

しかし、GraphQLがなければ、リモートリソースをreduxツリーにマッピングするために数回のラウンドトリップを行う必要がありました。

1. / resource1-list
2. / resource2-list？resource1 =
3. / resource3-list？resource2 =

明らかに、これはRESTの問題であり、Reduxの問題ではありません。 以前にいくつかのRedux-GraphQLバインディングを見ていたら、おそらくそれらを使用していたでしょう。 私のアプリケーションでは、Relayの採用はほとんど変わりませんでした。 代わりの@connect私が使用していますRelay.createContainer 。 どちらの製品も、APIが異なるアーキテクチャの同じビジョンを持っています。 私はこれについて簡単な投稿を書きました。

私は現在reduxとrelay / graphqlの両方を使用しており、relayはデータのフェッチに優れていますが、常にreduxを使用していることがわかります。 私は現在2つの理由でreduxを使用していますが、将来さらに多くの理由を見つけることができます

1）データベースに存在しないコンポーネント間で共有する必要があるその他の状態
2）フォームの準備。 実際には、アプリケーションの一部に、送信ボタンのあるツールバーコンポーネントと、すべての入力フィールドを保持するパネルコンポーネントがあります。 フォームに入力すると、reduxに保存されている「フォームレデューサー」に入力をデバウンスして、送信する前にツールバーがデータにアクセスできるようにします。

また、reduxdevtoolsは素晴らしいです。

男ああ男。 私は今日Relayを読んでいますが、コードが読みやすく、理解しにくいことを認めなければなりません。 Reduxの例をいくつか見て、コードを読むだけでコアコンセプトを理解することができました。

チュートリアルやTodoの例は、エレガントではないようです。 ReactとFLUXはシンプルであることに誇りを持っていると思います。 現時点では、Relayからそのような感覚は得られていません。

リレーはReactと密接に関係しており、ほとんどのアプリの複雑さが比較的過剰であることを考えると、私は最近Falcorにもっと熱心になっています。 実際、promiseベースのインターフェースのため、Reduxでほとんどの非同期動作を行う方法に非常にうまく適合します。 また、Reactから切り離されているため、アプリのどこでも簡単に使用できます。 また、サーバー側のレンダリングはまだ完全には焼き付けられていません。これは私にとって初心者ではありません。

また、「RelayLite」に似たreact-resolverも気に入ってい

@timdorrすべての状態をFalcorに保存しようとしましたか？ たとえば、レデューサーにFalcorオブジェクトを使用させる。

未だに。 私はまだ実験モードにあり、プロジェクトで揚げる大きな魚を持っているので、まだ十分な注意を払っていません。

私はFalcorで遊んだことがあるので、それを強くお勧めします。 実際、私は現在、ReduxアプリとFalcorバックエンドの統合に取り組んでいます。 Relayのクエリ集約は提供されませんが、クライアントライブラリに非常に高度なキャッシュレイヤーがあり、オーバーフェッチを防ぎます。 それで十分かもしれないと思いますが、時間が経てばわかります。

@gaearon宣言型データフェッチを使用して

主な違いは、Relay＆GraphQLではデータフェッチがより宣言的であるように思えます（ElmはURLを指定するように求めますが、戻ってくるデータを並べ替えるのはあなた次第です）。その他はすべてElmでより宣言的です。 。

実際、ElmエコシステムはRelay / GraphQLの移植の恩恵を受けることができるようです。

クエリの集計に関しては、 Model.batchメソッドがあります。 間隔（ミリ秒単位）またはスケジューラーのいずれかが必要ですが、スケジューラーに関するドキュメントはあまりありません。

私に聞いても構わないのなら、ReduxとFalcorをどのように統合していますか？ 私のすべての試みは私を苛立たせました。

また、Falcorのreduxの例を見たいと思います。 私はすべてのFalorドキュメントを読み、relay / graphqlよりもはるかに簡単であることに同意します。 それほど強力ではありませんが。

ReduxとRelayの関係、およびそれらを一緒に使用することが理にかなっているのかどうか疑問に思っている人は、 https ： ください。

要点は、Relayが最終的に複数のソース（バックエンド、ローカルエフェメラルデータなど）からのデータを処理するため、使用している可能性のある他のFlux実装を置き換えることです。

https://github.com/facebook/relay/issues/168#issuecomment -135169255：

リレーはFluxパターンの実装であることに注意してください（Fluxはそれ自体を置き換えることができますか？;-)。

OpenGovではReduxとRelayの両方を多用しています。 確かに、Relayに移行してから、 reducers/フォルダーははるかに小さくなりました。 ただし、Reduxは、アプリケーションレベルのローカル状態管理に依然として非常に役立つことがわかりました。 おそらくいつの日か、リレーはその地域でもそれに取って代わるでしょう。 しかし、 @ josephsavonaが一度言ったように、「Reduxアーキテクチャ」は本当にただ...関数です:)いつかライブラリからReduxに移行したとしても、不変の状態更新、リアクティブデータフロー、レデューサーを使い続けるでしょう。近い将来の機能など。 これはReduxIMOの貴重な部分であり、必ずしもこのリポジトリに存在する100行未満のライブラリではありません。 （もちろん、コミュニティもそうです。）

アプリがFacebookのように非常にデータ量が多い場合（複雑な関係を持つ多くのネストされたエンティティ）、GraphQLバックエンドに投資してRelayを学ぶことをお勧めします。

同意しましたが、GraphQL + Relayは、適度なサイズのアプリ、特にゼロから開始する新しいプロジェクトにとっても優れた投資であると私は主張します。

https://github.com/gyzerok/adrenalineについてどう思い

リレーを使用していないため、正確には適合しませんが、Meteorコミュニティからのこの意見のあるフルスタックアプローチについてどう思いますか？ https://github.com/mattkrick/meatier

GraphQL / RelayやDatomic / Om.Nextのような深いアーキテクチャだけがオブジェクト/リレーショナルインピーダンスの問題を解決できます...これが私の考えです-フィードバックをいただければ幸いです。

GraphQL / Relay：Reduxの終わり？

このトピック（Relay / Redux、GraphQL、および複雑さの軽減）に興味を持っている人はたくさんいるようです。私は、アプリの状態に対するReduxアプローチで非常にうまく機能するシンプルで機能的なGraphQLクライアントの設計に取り組んでいます。

この一連の設計原則について人々がどう思うか興味があります： https ：

ここに私の2セントを追加するだけです：Reduxに終わりはないと思います。 シンプルで美しく、多くの場合十分です。 JSエコシステムは非常に高速で、維持するのが困難です。Reduxは、何らかの形でReactと同様に、しばらくの間信頼できるマイルストーンです。 ワークフローを毎月進化させることはできません（少なくとも、私はできません）。現在、Reduxは本当に良い選択肢だと思います。 多くのプロジェクトでは、リレー（および一般的なデータフェッチ）は必要ありません…

@gaearonこの投稿をしてから数か月が経ちましたが、ReactカンファレンスでReduxについて講演しました。 Relay /と比較して、ReduxとのGraphQL統合、またはおそらく3つすべての組み合わせに関して、現在どこにいると思いますか？

@likeabbas GraphQLとReduxの統合をお探しの場合は、Apolloクライアントをお試しください： http ：//docs.apollostack.com/apollo-client/index.html

まだRelayと100％の機能同等性はありませんが、近づいています。

@likeabbasから質問をエコーする@gaearon：「どこで私たちが再来とGraphQL統合の面で今リレー/、または3つすべてのおそらく組み合わせと比較されていると思いますか？」

いくつかの簡単な考え。 Reduxは、十分な構造と十分な柔軟性のバランスを提供する汎用フレームワークです。 そのため、開発者がユースケースに合わせてカスタマイズされた状態管理を構築するためのプラットフォームを提供すると同時に、グラフィカルデバッガーやミドルウェアなどを再利用できます。 そのユースケースはなくなる可能性が低いように思われるので、「Reduxの時代は過ぎ去った」というよりも、おそらくもっと興味深い質問があります。GraphQLクライアントを構築している場合、Redux上に構築することは理にかなっていますか？

正解が1つあるかどうかは明らかではないと私は答えます。 Reduxでの構築は統合（共有ツール、共有データ）の恩恵を受ける可能性がありますが、カスタムアプローチの構築はより多くの作業ですが、よりドメイン固有のツールを可能にし、パフォーマンスを向上させる可能性があります。 ソフトウェア開発の多くのものと同様に、それはユースケースに依存します！

@josephsavona ：それはReduxの_素晴らしい_要約です！ どこかのドキュメントのためにそれを盗む必要があるかもしれません:)

ええ、このスレッドのタイトルは最適ではなく、質問はちょっと疲れ果てているようです。 おそらく、議論を別の場所に移す時が来たのでしょう。

>.> lock the issue

これを閉じます。 とにかく解決策があるかどうかわからない。 Reduxは何人かの人々のために働きます、そしてそれは私にとって十分です。

おっと、間違ったボタン。 申し訳ありません😄