Reduxの力とは何ですか？

これは、記事「 Reduxの素晴らしいところ 」（ ジャスティンファルコーネ著）の翻訳です。

Reduxは、Reactコンポーネントの状態を使用して伝えるのが難しい複雑な状態の相互作用を巧みに処理します。 実際、これはオブジェクト指向プログラミングにも見られるメッセージングシステムですが、言語に直接組み込まれているのではなく、ライブラリとして実装されています。 OOPと同様に、Reduxは制御を呼び出し側から受信側に転送します。インターフェースは状態を直接制御しませんが、処理のためにメッセージを渡します。

この点で、Reduxのストレージはオブジェクトであり、レデューサーはメソッドハンドラーであり、アクションはメッセージです。 store.dispatch({ type:"foo", payload:"bar" })



をstore.send(:foo, "bar")



store.dispatch({ type:"foo", payload:"bar" })



、Rubyのstore.send(:foo, "bar")



store.dispatch({ type:"foo", payload:"bar" })



同等です。 ミドルウェアはアスペクト指向プログラミング（たとえばRailsのbefore_action



）とほぼ同じ方法で使用され、 before_action



の助けを借りて、react-reduxに依存性注入が実装されます。

このアプローチの利点は何ですか？

• 上記の制御の反転により、状態変更の実装が変更されるとすぐに、ユーザーインターフェイスを更新する必要がなくなります。 ロギング、取り消し、タイムトラベルデバッグなどの複雑な機能を追加するのは簡単です。 統合テストは、正しいアクションが送信されたかどうかを確認するためだけに削減され、残りについては単体テストで十分です。

  
  
  
  
  
  
  

• Reactのコンポーネントの状態は、ユーザー情報やアラートなど、多くのアプリケーションモジュールに影響を与えるエンドツーエンドの機能と連携するには遅すぎます。 Reduxには、このためだけに、ユーザーインターフェイスに依存しない状態ツリーがあります。 さらに、インターフェイスの外部で状態を処理する場合、localStorageまたはURLでのシリアル化が1か所で実行されるため、一貫性を維持しやすくなります。

  
  
  
  
  
  
  
• method_missing
  
  
  
  は、結合したり、同時に送信したり、 method_missing
  
  
  
  のスタイルで処理したりすることのできるアクションを自由に操作できます。

しかし、これらのケースはすべて特別です。 より単純なシナリオはどうですか？



ここで問題が発生します。

• アクションは状態間の複雑な遷移と見なすことができますが、基本的には1つの値のみを指定します。 Reduxで作成されたアプリケーションでは、これらの単純なアクションの多くが頻繁に蓄積されます。これは、セッター関数を手動で作成するJavaをclearlyとさせます。

  
  
  
  
  
  
  

• アプリケーション全体で同じ状態を使用できますが、ほとんどの場合、インターフェースの特定の部分を参照します。 コンポーネントからReduxリポジトリへの状態の転送は、適切なレベルの抽象化なしの単なるリダイレクトです。

  
  
  
  
  
  
  
• レデューサー関数は、最も複雑なメタプログラミングタスクに対処できますが、通常はそのタイプに応じたプリミティブなディスパッチアクションになります。 これは、パターンマッチングの簡潔で表現力のある構文が異なるElmやErlangのような言語では問題になりませんが、Javascriptでは面倒なスイッチコンストラクトを処理する必要があります。

ただし、主な問題は、単純なケースの定型文のこのような長い作業の後、一般的に複雑なケースではより良い解決策があることを忘れることです。 最終的に状態の巧妙な移行に直面して、あなたは単に新しい値を設定する多くの異なるアクションを送ります。 あるレデューサーから別のレデューサーにスイッチオプションをコピーアンドペーストし、どこからでも使用できる関数の形式で抽象化しません。

これらすべてを人的要因に帰するのは簡単です。ドキュメンテーションをマスターしなかった、または「マスターは愚かです-ナイフは愚かです」 -しかし、そのような問題はしばしば疑わしく見つかります。 それがほとんどのマスターのために愚かであるならば、ナイフに問題がありますか？

だから、通常のケースではReduxから離れて、特別なケースのためにそれを保存する方が良いでしょうか？

Reduxチームからそのようなアドバイスが与えられます。同僚にも同じことを言いますsetState



が完全に制御できなくなるまで、それを取り上げないでください。 しかし、Reduxを使用する理由はいつでも見つかるので、私自身も自分のルールには従いません。 set_$foo



ような多くのアクションがあり、値が割り当てられるたびに、URLが更新されるか、他の中間値がリセットされます。 状態とユーザーインターフェイスの間に明確で明確な対応があるかもしれませんが、ログインするか、アクションをキャンセルする必要があります。

実際、私はReduxで正しく書く方法、特にそれを教える方法を知りません。 私が取り組んだ各アプリケーションには、このようなReduxのアンチパターンがたくさんあります。より良い解決策が見つからないか、同僚に何かを変えるように説得できませんでした。 Reduxの専門家が平凡なコードを書いていると言えば、新人については何と言えますか。 Reduxを一列に並べて使用するという一般的なアプローチのバランスをとろうとしているだけです。

この場合の対処方法

幸いなことに、Reduxは、Jumpstart（ https://github.com/jumpsuit/jumpstate ）などの単純なものを操作するためのサードパーティライブラリを含めるのに十分な柔軟性を備えています 。 説明させてください：Reduxは低レベルのタスクに使用できないとは思いません。 それらの作業がサードパーティのライブラリに与えられた場合、これは理解を複雑にし、自明の法則によれば、些細なことに時間が無駄になります。各ユーザーは最終的には独自のフレームワークを部分的に構築する必要があるためです。

好きな人もいます。

そして私は彼らの中にいます！ しかし、これはすべての人に当てはまるわけではありません。 私はReduxの大ファンであり、ほぼすべてのプロジェクトで使用していますが、新しいwebpack構成も試してみたいです。 私は典型的なユーザーの例ではありません。 Reduxに基づいて独自の抽象化を作成すると、新しい機会が得られますが、半年前にドキュメントを残さずに終了したシニアエンジニアが書いた抽象化は何をもたらしますか？

Reduxが解決する複雑な問題に出くわす可能性はありません。特に、上級の同僚がそのようなタスクに関与しているチームのジュニアである場合はそうです。 次に、Reduxがすべてが3回書き換えられるような奇妙なライブラリであると想像します。 Reduxは、深く理解することなく、機械的に機能するのに十分なほど単純ですが、これにはほとんど喜びと利益がありません。

だから私は以前に尋ねた質問に戻ります：ほとんどがツールを誤って使用する場合、それは全体の問題ですか？ 高品質のツールは有用で耐久性があるだけでなく、それを使って作業するのも快適です。 正しく使用するのが最も便利です。 このようなツールは、仕事のためだけでなく、人のためにも作られています。 楽器の品質は、それを使用するマスターに関する作成者の注意を反映しています。

そして、私たちはどのようにマスターを気にしますか？ ツールの利便性に取り組むのではなく、すべてが間違っていると主張するのはなぜですか？

関数型プログラミングにも同様の現象があります。これは、私が「モナドの教訓」と呼ぶものです。モナドがどのように機能するかを説明するのは簡単ですが、その利点を伝えるのは驚くほど困難です。

投稿の途中でモナドを説明することに真剣ですか？

モナドはHaskellで一般的な抽象化であり、リストの操作やエラー、状態、時間、I / Oの処理など、さまざまな計算に使用されます。 do-notationの形式の構文糖は、命令コードに似た形式でモナドの操作のシーケンスを表すことができます。これは、非同期コードを同期のように見えるJavaScriptのジェネレーターにほぼ似ています。

最初の問題は、アプリケーションの観点からモナドを記述することは完全に正しいとは限らないことです。 修道士は、副作用と逐次計算を扱うためにHaskellに登場しましたが、抽象的な意味では、それらはそれとは何の関係もありません：彼らは単に2つの関数の相互作用に関する一連のルールであり、特別な意味はありません。 結合性は、算術演算、集合の演算、リストの結合、およびヌル伝播にも同様に適用できますが、それらとは独立して存在します。

2番目の問題は冗長性です。これは、少なくとも、命令型アプローチと比較したモナドの視覚的な複雑さを意味します。 Maybe



ような明確に定義されたオプション型は、落とし穴をnull



として見つけるよりも安全ですが、それらのコードは長くて扱いにくいです。 Either



タイプを使用したエラー処理は、例外をどこにでもスローできるコードよりも理解しやすいように見えますが、同意するように、例外を含むコードは、 Either



で値を定数で返すよりも簡潔です。 状態、入力/出力などの副作用については、命令型言語ではまったく些細なことです。 関数型プログラミングのファン（私を含む）は、関数型言語の副作用を扱うのは非常に簡単だと主張するでしょうが、どんな種類のプログラミングも簡単だと納得できる人はいないでしょう。

これらの例を広く見てみると、その利点は本当に顕著です。モナドの法則に従うだけでなく、同じ法則です。 1つのケースで機能する一連の操作が、他のケースで機能する場合があります。 リストのペアをペアのリストに変えることは、条件でPromise



オブジェクトのペアを組み合わせて、結果を含むタプルを返すものと同じです。

なぜこれすべてなのか？

実際、Reduxにも同じ問題があります。彼が複雑だからではなく、単純だからといって、トレーニングするのは難しいです。 理解はむしろ知識ではなく、基本原理を信頼することです。そのおかげで、帰納によって休息することができます。

この理解は共有するのが簡単ではありません。なぜなら、基本原則は平凡な公理に(prevState, action) => nextState



する（「副作用を回避する」）か、意味がほとんどなくなるほど抽象的であるためです（ (prevState, action) => nextState



）。 特定の例は役に立たない：Reduxの冗長性を示すだけで、その表現力は示さない。

悟りに達した私たちの多くは、私たちがどのように彼に来たかをすぐに忘れてしまいます。 私たちの「啓発」は、繰り返される間違いや誤りの結果であることをもはや覚えていません。

そして、あなたは何を提案しますか？

私たちに問題があることを認識してほしい。 Reduxはシンプルですが、簡単ではありません。 これは開発者による合理的な決定ですが、同時に妥協です。 使いやすさを優先してメカニズムの単純さを部分的に犠牲にするツールは、多くの人々にとって有用です。 しかし、コミュニティは、ある種の妥協が行われたことを認識していません。

私の意見では、ReactとReduxを比較するのは興味深いです。ReactはReduxよりもはるかに複雑で、APIははるかに広く、奇妙なことに、学習と使用が簡単です。 React APIで本当に必要なのは、 React.createElement



およびReactDOM.render



であり、状態、コンポーネントのライフサイクル、さらにはDOMイベントさえも異なる方法で処理できます。 これらすべての機能をReactに含めると、難しくなりましたが、改善されました。

「原子状態」は抽象的な概念であり、実際に利益をもたらすのは、それを理解した後です。 一方、Reactでは、どのように動作するのか理解していなくても、 setState



コンポーネントsetState



がアトミック状態を制御します。 このような解決策は理想的ではありません。一般的に状態を放棄するか、変更ごとに必ず更新する方が効率的です。 このメソッドは、非同期に呼び出すと不快な驚きをもたらす可能性がありますが、それでもsetStateは理論的な概念ではなく、作業メソッドとしてのReactにとってはるかに便利です。

Redux開発チームとそのユーザーコミュニティはどちらもAPI拡張に積極的に反対していますが、現在行われているように、多数の小さなライブラリをまとめることは、初心者にとっても厄介な作業であり、退屈な作業です。 Reduxが単純なケースの組み込みサポートのレベルまで成長できない場合、このニッチを占める「救世主」フレームワークが必要になります。 ジャンプスーツは良い候補になる可能性があります。多対多の関係の性質を維持しながら、特定の機能の形でアクションと条件のアイデアを具体化します。 しかし、救い主の選択は救いの事実ほど重要ではありません。

皮肉なことに、Reduxの意味は「開発者エクスペリエンス」です。ダンは、Elmのようなタイムトラベルデバッガーを学習および再生するようReduxを設計しました。 しかし、アイデアが独自の形を取り、実際にReactエコシステムのオブジェクト指向環境に変わったため、「DX」の利便性が背景に消え、構成の柔軟性が失われました。 これによりReduxエコシステムが繁栄しましたが、アクティブなサポートを備えた便利なフレームワークが必要な場合はどこでも、ギャップは空です。 Reduxコミュニティはそれを満たす準備ができていますか？

オルガ・イサコワ訳