Redux: ディスカッションのリクエスト：Reduxの「ボイラープレート」、学習曲線、抽象化、意見

いくつかのアイデア：

• redux、react-redux、redux-thunkを含む公式のredux-presetパッケージはすでに相互に配線されています
• dispatch(actionType, payload)は、アクションクリエーターの必要性を減らすことができます
• 組み込みのジャンプステートスタイルのレデューサークリエーター（例： createReducer({[actionType]: (state, payload) => state}, initState)

私が知っているほとんどの人は、reduxを多用し、拡張性があまり良くないことに気付いたため、redux-thunkから離れてしまい、アクションクリエーターがやりすぎて、管理側に何か他のものを使用することになります。 -redux-observableやredux-sagaなどの効果。

特にreduxを使い始めたときは、その魅力を理解できますが、「ベストプラクティスの定型パッケージ」の一部としてバンドルすることが最善のアイデアかどうかはわかりません。

したがって、この部分は私にとってより重要です（これは問題を解決するためのアイデアではなく、少なくとも私にとって重要な制約です）：

Reduxは、「物事を行うための最も簡潔な方法」ではなく、データフローを明確で読みやすくすることを目的としています。

Reduxの優れている点は、フレームワークというよりもデザインパターンに近いことです。また、表示されるすべてのコード（ストアとreact-redux除く）は独自のものです。

Jumpstateを見ると（今まで知りませんでした）、Reduxで最初に見た抽象化レイヤーの1つで、見栄えがします。 でも素晴らしい！ しかし同時に、それはMobXのような他のフレームワークからほんの少し離れたところにあり、同じものをテーブルにもたらす複数のフレームワークを持つことはあまり役に立ちません。 したがって、Reduxが他のツールと異なる点に焦点を当てることは重要です。真空中でReduxをより良くする方法だけではありません（他のツールと同じ世界に住んでいるため）。

もう1つの重要な点は、Reduxをヒットしたときに初心者が抱える多くの課題は、Redux自体ではなく、JavaScriptであるということです。 Angularのような他の大きなフレームワークはJavaScript自体を抽象化します。 Reduxレデューサーを作成することは、バニラJavaScriptの「デザインパターン」を適用するだけです。これは、初心者にはなじみがないかもしれません。代わりに、ブラックボックスを使用したくなるでしょう。

最後に、多くの定型文の削減ライブラリは、コンポーネント、レデューサー、アクション作成者の間に1：1：1の関係を追加しようとします（おそらく3つすべてではありませんが、多くの場合2つです）。 、複数のレデューサーからの状態を使用する複数のコンポーネントなど。 これは私が職場やその他の場所で答える一番の質問の1つであり、非常に便利です。 したがって、その分野で役立つツールはこれを失うべきではありません（また、「スイッチは厄介です」は世界で最良の議論ではありません）。

したがって、IMO、CTAには、優れたバニラJavaScriptリソースをリンクするだけでなく、「はじめに」の概念に沿って「理由」をより多く文書化し、物事をシンプルに保つことが含まれます。 多くの新しい概念をまったく学ぶことなく、Reduxで巨大なアプリケーションを構築できます。 私自身は重複観察可能な男ですが、Thunkを問題なく使用している数十万行のコードアプリを見てきました（そして小さなアプリがサンクで難破するのを見ました）。 非常に少数の「コア」概念を紹介し、それらを大量の概念にどのように適用できるかを示すことは、非常に役立ちます。

「コストに関係なくすべての定型文を削減する必要がある」というのは、最近のソフトウェアエンジニアリングコミュニティ全体の問題です...これは取り組むのが難しいことです。

当初から、reduxに関する私の主な関心事は、コードの読み取りまたは書き込みのいずれかで、N個のファイル間をジャンプする必要があり、単一のUIパーツのb / cロジックが、アクション、アクションタイプ、およびいくつかのコードベース全体に散在していることでした。レデューサー。 UIのあらゆる場所から状態ツリーの任意の部分にアクセスでき、単一のアクション（reduxを使用する主な理由）に応じて状態のさまざまな部分を変更できるのが本当に好きですが、 1つのアクションに応じて状態が変化するほど、ロジックがぼやけます。 ユーザーがこれやあれをしたときに何が起こったのかを単純に読み書きすることはできません。 しかし、私が欲しいのは次のように説明することができます：

// meta code
dispatch(ACTION);

onAction = {
  ACTION: [
    // handler 1: hide spinner here,
    // handler 2: change status there,
    // handler 3: update entity
  ],
};

結局、私はredux-interactions + redux-treeを思いついたので、これまでのところかなり満足しています。

現在のプロジェクトでのアプローチ：

注：アプリケーションの要件によって大きく異なります:)リアルタイムのオブジェクト更新を追加すると、おそらくsagasまたはobservableがthunk / promiseよりもメリットがあります。

• redux-thunk
• ミドルウェアを約束する
• クライアントフェザーアプリのラッパーである「apiラッパー」、ペイロードがAPIを呼び出すことを約束するアクションクリエーターであるservice(name, method, ...opts) （つまり、promiseミドルウェアがそれを取得してx_FULFILLEDをディスパッチします） 、 x_PENDING 、およびx_REJECTED ）。 このためのアクションの名前を上書きすることもできます。

最初にcomponentDidMount()を使用してAPIを呼び出し、データをコンポーネントの状態で保存します。 ただし、これにはapiラッパーを使用します。つまり、アクションは引き続き送信され（リクエスト情報であるメタを含むロガーミドルウェアによってログに記録されます）、必要なすべてのコンポーネントにストアを使用するようにリファクタリングする必要があります。 toは、アクションをリッスンするレデューサーを追加します。 ローカル状態のみを使用することから始め、そのコンポーネントの状態に別のコンポーネントからアクセス/変更する必要がある場合は、reduxにリファクタリングします。 そうは言っても、reduxはすべてに紙の証跡を提供するので、どこでもreduxを使用することの魅力がわかります。 私たちの現在のチームとアプリケーションのタイムラインを考えると、それは私たちのATMにとって有益ではありません。

私はredux-sagaで少し遊んだことがありますが、最も複雑な非同期フローはログイン/ログアウトであり、これは機能します（そしてコードはそれほど複雑ではありません）ので、切り替える大きな理由はあまりありません（ただし、テストする価値があるかもしれません）理由-反復可能+モックはテストするのに良い方法です）。 redux-observableたとえば、イベントをうまくダブルクリックしたい場合など、observable自体がメリットを提供しない限り、当面のメリットはわかりません。

レデューサーを返す独自のファクトリ関数を持ち、カスタム機能の上に独自の高階レデューサーを置くことで、定型文から少し離れました（たとえば、コンテンツがページ付けされるがカスタムを持つことができるように、「paginator」の上にレデューサーを置く）アイテムを変更するアクション）。

私が行う必要があると思うのは、基本的なReactアプリから作成された巨大なチュートリアルであり、コンポーネント間の通信で発生する問題を示し、次にreduxを導入し、次に進み、

また、 gothinkster / react-redux-realworld-example-appで使用されるパターンについて私が思いついた

私が知っているほとんどの人は、reduxを多用しているので、拡張性があまり良くないことに気付いて、redux-thunkから離れてしまいます。

私はあなたが言っていることを理解していますが、ここに私の裏返しの懸念があります：JS開発者の巨大なグループがまだ_矢印関数_や他のベースラインES（6 | 2015）機能を使用していないという事例証拠がますます見られています、理解不足、脅迫などが原因です。Reduxを使い始めたい、Reduxが導入する_パターン_を学ぶことで利益を得ることができる人々に、最初に観測可能なものやジェネレーターを学ぶことを期待しているのは、多分質問が多すぎると思いますか？

Redux-thunkは、一般的な種類のReduxミドルウェアが脳を曲げるという意味でも少し複雑ですが、少なくとも関数/コールバックであり、JSを作成している場合は簡単に理解できます。 「best-practice-always-redux」ではなく「learn-redux」として提案されている場合でも、1回のダウンロードで利用できる関連ツールの完全なパッケージを用意するというアイデアが本当に気に入っています。 create-react-appがセットアップするすべてのことを学習するときに微調整が必​​要なのと同様に、これは独自の微調整を促進し、単純なredux-thunkセットアップを独自のフォームとしてsagasなどを使用するように変換する方法を示す可能性があります。 「排出」の..。

いくつかの考え。

私はあなたが言っていることを理解していますが、ここに私の裏返しの懸念があります：JS開発者の巨大なグループがまだ矢印関数や他のベースラインES（6 | 2015）機能を使用していないという事例証拠がますます見られています、理解不足、脅迫などが原因です。Reduxを使い始めたい、Reduxが導入するパターンを学ぶことで利益を得ることができる人々に、最初に観測可能なものやジェネレーターを学ぶことを期待しているのは、多分質問が多すぎると思いますか？

ビンゴ！ 私たちは多くの人々がJSに不慣れな環境にいます（または彼らはJSを「知っています」が、それは彼らの専門ではなく、彼らは深いところから始まります）。 特に、それらの人々が別のエコシステム（Java、Railsなど）の経験豊富なソフトウェアエンジニアである場合、彼らは知らない概念を学ぶ前に、知っている概念をすばやく適用しようとします。 しかし、機能的なUXデザインパターンに飛び込む前に、JSを深く理解するように人々を説得するための最良の方法はわかりません。

Reduxのドキュメントには、今何かを探していて、Reduxの上にライブラリ全体を採用したくないという読者のために、ボイラープレートの削減に関するセクションがあることに注意してください。

私たちはこの議論に少し注意を払う必要があり、これはおそらくすでに多くの自転車小屋に入れられていることを理解する必要があります。 Reduxチームは、おそらくここで提案されるであろう多くのことを聞き、検討し、拒否しました。 すでに議論されていることについてのみ戦う場合、この議論から何も出てこない可能性は十分にあります。

そうは言っても、フレームワークをすべての人（新規および経験者）がよりアクセスしやすいものにする方法について話すのは素晴らしい考えだと思います。

ボイラープレートを減らすことを提案するものはすべて、必要なときにいつでも抽象化の下のものに戻ることができるようなものでなければなりません。 抽象化の作成者が考えていなかった余分なものが1つ必要だったため、後でドロップして下位レベルのものに戻るために抽象化を採用するのは楽しいことではありません。

Reduxの学習曲線は急勾配になる可能性がありますが、概念を理解したら、
抽象化レイヤーはしばしば消えます

もしそうなら、Reduxのどの部分を改善することを提案しているのだろうか？ すぐに追加し直す必要がない部分を削除または抽象化しますか？

これは、約1年前に職場での講演のために作成したreact / reduxライフサイクル全体の図です。

これにはかなりの数の部分がありますが、Reduxがそれらのいずれかなしでうまく機能することは想像できません。 コンテナは時々煩わしいものですが、コンテナを削除すると、ビューロジックとデータレイアウトが深く結びつきます。 アクションを削除すると、基本的に再びMVCになり、そもそもReduxを使用する意味がなくなります。 その図の「ビュー」は、ストアにサブスクライブして反応コンポーネントをレンダリングする単なる関数としてモデル化できるため、すでにほとんど存在していません。

フレームワーク全体で削除すべき定型文はそれほど多くないと思います。 アクションクリエーター、レデューサー、コンテナーなど、フレームワークの個々の部分の定型文を参照している可能性があります。 その場合、上記の「ボイラープレートを減らす」ページのヒントは、すでにそれらのほとんどに対処しています。 それを「より良い」ものにするために、その上に何も必要ありません。 （注：物事を改善するために何かを追加することにオープンではないというわけではありません。まだそれを見ていないだけです。）

たぶん、これは定型文を減らす問題ではなく、Redux教育を改善する問題です。 フレームワークを初心者が理解するのが難しい場合は、Reduxドキュメントを改善して、よりアクセスしやすくする必要があるかもしれません。 おそらく、削減定型文のヒントのいくつかは、ドキュメントでより積極的に宣伝する必要があります。

必要なステップ数（ボイラープレート）を減らしても、必ずしも問題が解決するとは限りません。 私の投稿の最初から私のポイントを強調するために、人々がそれを使用する必要があるすべての方法を考えていなかったので、捨てられるような抽象化を書きたくありません。

これまでのところいくつかの良い議論。 Lemmeは、私が目にする一般的な「ボイラープレート」関連の苦情のいくつかの簡単な例を投げ出します。

• 「オブジェクトをすぐに返すためだけに「アクションクリエーター」関数を作成する必要があるのはなぜですか？」
• 「単純な新機能を追加するためだけに、非常に多くのファイルに触れる必要があります。また、定数と関数名について同じ名前を何度も繰り返します...」
• 「AJAX呼び出しを行うためだけにこれらの「ミドルウェア」が必要なのはなぜですか？」
• 「なぜすべてにswitchステートメントを使用する必要があるのですか？」
• 「なぜこのdispatchものが必要なのですか？なぜこれらの関数をすべてまとめて機能させる必要があるのですか？」

そして、これらのタイプのコメントのいくつかの特定の例：

• Reduxの実装は面倒です。
• 最小限のReduxセットアップ
• JumpstateREADMEおよびJumpstate + Redux + CRA-ディスパッチやアクションの作成者は必要ありません！

そして、これらの「ボイラープレート」の懸念に対するいくつかの回答をすぐに捨てるために、リストされている5つのカテゴリのうち、実際には「 dispatch 」のみが_必須_です。 残りの部分：

• アクションクリエーターを使用する必要はありませんが、一貫性を保つための良い習慣です（私の投稿Idiomatic Redux：なぜアクションクリエーターを使用するのですか？ ）
• アクションクリエーター、アクション定数、およびリデューサー用に完全に別個のファイルを用意する必要はありません。 「アヒル」パターンは、それらすべてを1つのファイルにまとめるための一般的なアプローチです。 これには、複数のレデューサーに1つのアクションをリッスンさせる機能を「隠す」という欠点があります。 Reduxは最終的にファイル構造が何であるかを気にしません。
• コンポーネントのように、Reduxの外部で完全に非同期作業を行うことができます。 しかし、Danの説明によると、Reduxの非同期フローにミドルウェアが必要なのは
• レデューサーでswitchステートメントを使用する必要はありません。これらは、特定の変数の複数の値を処理するための最も「明白な」方法です。 ルックアップテーブル、if / elseステートメント、およびその他の必要なものはすべて問題ありません（ FAQによると：switchステートメントを使用する必要がありますか？ ）
• 何か便利なことを実現するには、実際にstore.dispatch()を呼び出す必要があります。これがReduxの基本的な設計上の決定です。 アクションクリエーターをバインドすると、それらを接続されていない子コンポーネントに渡し、関数が呼び出されるたびにディスパッチさせることができます。

したがって、全体として、これらの「ボイラープレート」の懸念から_必要な_ものはほとんどありません。 これは、ドキュメントの例と、コードの重複排除や関心の分離などの「優れたプログラミング手法」を組み合わせたものです。

@markeriksonが提起した質問は本当に公平だと思いますし、過去のある時点で自分自身にも質問したことがあります。

Reduxは、ある意味でデータモデリング用の「低レベル」ライブラリです。 このような低レベルのライブラリと同様に、ほとんどの場合を説明するために簡単に抽象化できる多くのことが公開されています。 @gaearonが元々そうしなかった理由は、彼がライブラリをできるだけ小さく柔軟に保ちたいと思ったからだと思います。 その決定のおかげで、Reduxコアにすべてを含める必要なしに、Redux上にさまざまなものを構築することができます。

たぶん、正しい道は、Reduxの上に優れたライブラリを開発して安定させることかもしれないと考える必要があります（Jumpstateのように？）。 私たちは人々にそれを教えることから始め、次に彼らが必要なときに直接Reduxを使用する簡単な道を彼らに与えます。

Reduxのコアコ​​ードベースにこれ以上必要なものはないと思います。また、永久に抽象化する必要のある部分は見当たりません。 （もしそうなら、私に知らせてください：smile :)私の意見では、Reduxコアに物を追加したり削除したりしても得られるものは多くありません。

誰もが使用できるほど安定していて柔軟性があるところまでライブラリを改善することは、おそらくより良い選択肢です。 あなたが言ったように、「ボイラープレート」の多くは実際には必要ないので、Redux自体を変更するのではなく、Reduxの上にあるライブラリでそれを取り除きましょう。

別のコミュニティで起こっているこの例は、Rustプログラミング言語です。 「mio」と呼ばれるRustプログラミング言語用のノンブロッキングIOライブラリがあります。 Reduxと同じように、小さくて低レベルであることに焦点を当てています。 問題は、それが本当に難しく、定型文でいっぱいになるため、ほとんど誰もそれを直接使用しないということです。 ほとんどの人は、mioに基づいて構築され、非常に使いtokioという別のライブラリを使用しています。 このように、mioからの配管が必要な人は誰でもそれを直接使用できますが、何かをすばやく作成したい人は誰でもtokioを使用できます。

同様のモデルを採用する必要があります。

@sunjayのコメントのいくつかを拡張するには：

＃775に最近コメントがあり、物事をうまく捉えていると思います。

Reduxは、十分な構造と十分な柔軟性のバランスを提供する汎用フレームワークです。 そのため、開発者がユースケースに合わせてカスタマイズされた状態管理を構築するためのプラットフォームを提供すると同時に、グラフィカルデバッガーやミドルウェアなどを再利用できます。

そうです、Reduxは多くの点で「単なるパターン」です。 コアライブラリは実際には機能が完全です-唯一の実際の半計画的な変更は、提案されたエンハンサーの再構築（＃1702、＃2214）のようなものであり、おそらくcombineReducersより柔軟にする（＃1768、＃1792など） ）。

Reduxが作成されてからほぼ2年が経過し、今では人々がReduxをどのように使用しているかについてかなり良い考えがあります。 一例として、 @ jimbollaは＃2214ですべての既知のストアエンハンサーのリストを収集し、それらがどのように機能し、何に使用されるかを分類しました。 私はまだReduxのシンプルさと柔軟性の大ファンですが、一般的な使用法を簡素化し、人々の問題を解決する、Reduxの上にまだ慣用的な抽象化がいくつか見られることを望んでいます。

もう1つの半関連トピックのセット、および私が明確に個人的に興味を持っているものは、「カプセル化されたロジック/コンポーネント」（ @slorberの「Elm / Reduxを使用したスケーラブルなフロントエンド」プレイグラウンドによる）と「プラグアンド

興味深い関連点として、 @ toranbはhttps://github.com/ember-redux/ember-reduxでReduxのEmberラッパーを作成する素晴らしい仕事をしました。 Emberの世界は「設定より規約」に「本当に」入っているので、 ember-reduxは、 redux-thunkなどを含む妥当なデフォルトのストア構成を設定します。 そのようなある種のアプローチが役立つかもしれません。

そうです、私はここでさまざまな考えを投げかけていますが、それらはさまざまな方法で関連しています。 全体として、Reduxの学習と使用の障壁を低くし、より高度なユースケースを全面的に有効にしたいと考えています。

Reduxは一般的なAPIであり、特殊なものではありません。 これにより、より詳細になり、より多くのケースがカバーされます。 その力は複雑なソフトウェアにありますが、新しいプロジェクトや単純なプロジェクトでは、これは必要の範囲を超えています。

ただし、一般的なAPIの上に特殊化を構築できます。 たとえば、私はhttps://github.com/acdlite/redux-actionsを使用して、一般的なケースの定型文を減らしてい

もう1つの問題は、信じられないほど複雑なアプリケーションの苦痛を経験したことがない新しい人々が、何が重要なのか疑問に思っていることです。 まあ、彼らにとって、彼らはおそらくその痛みを経験するまでreduxを使うべきではありませんが、Danのeggheadシリーズは彼らをこのポイントをかなり簡単に超えて蹴ることができます。

https://egghead.io/courses/getting-started-with-redux
https://egghead.io/series/building-react-applications-with-idiomatic-redux

参照：抽象化の範囲： https ：

前述のように、 redux-actionsは定型文を削除するのに非常に優れています。 .toString付加して方程式から定数を削除することは、私が好きな非常に優れたアイデアですが、 redux-actionsを使用するよりも自分でこのロジックを作成する方が好きです。

ディスパッチされたアクションストリームを監視するための組み込みメカニズム（ subscribeのコールバック引数？）が必要です（ミドルウェアで実行できることはわかっていますが、使用できないため、ユースケースがかなり制限されます）外部、つまりコンポーネントまたはconnect ）

私はしばしば他の人にreduxを教えます、そしてそれは以下の理由でかなり気が遠くなることがあります

• 多くの可動部分：ストア、状態、レデューサー、アクションクリエーター、アクション、非同期アクション、ミドルウェア、連結成分
• ライブラリ。 REST APIと通信する単純なアプリの場合、必要なもの：redux、react-redux、redux-thunk（またはその他）+テストする場合は追加のライブラリ
• コードを配置する必要のある場所の量（_可動部品_を参照）

reduxはそれ自体が完全に理にかなっている素晴らしいライブラリだと思います。また、正しく使用すると、優れた抽象化と非常にスケーラブルなものになると思います。 また、reduxはどのUIライブラリでも使用できることを理解していますが、ほとんどの場合、reactで使用されると思います。

一般的に、私は多くの欲求不満が多くの可動部分から来ると信じています。

これが私が持っていたいくつかの考えです。 これらはすべてreduxの上に構築できるため、そのままにしておくことができます。

• 組み込みの非同期アクションのサポートが追加されたreactreduxのようなライブラリを提供します。
• 多くの非同期アクションがRESTAPIと通信しているため、そのための慣用的なミドルウェアを提供します
• 接続を使用する代わりに、スマートコンポーネントを実際のコンポーネントとして記述します。 その後、 renderメソッドでダムコンポーネントをレンダリングできます
• _コンテナコンポーネント_、_スマートコンポーネント_、_ダムコンポーネント_、_アクションクリエーター_、および_リデューサー_のスケーラブルなファイルレイアウトを規定します。
• _redux-cli_を提供してコードを生成します（例： redux action loadUsers
• redux-sagaやredux-observableなどの非同期レイヤーで標準化し、ドキュメントに含めます（ほとんどのreduxの問題について相談できる場所が1つあると便利です）
• デフォルトでは、拡張言語機能（たとえば、デコレータ（@connect））またはTypeScriptを使用して、特にmapStateToPropsおよびmapDispatchToProps（mobxにはデコレータが必要であり、構文は単純です）の冗長性を減らします。

NS

同意しました。 redux-actionsは、定型文を削除するいくつかの単純な抽象化の良い例です。

これを聞いてみましょう：Create-React-Appにはreact-scriptsパッケージがあり、これにはBabelとWebpackの構成が事前に構築されており、実用的なデフォルトが多数組み込まれています。 対応するredux-scriptsパッケージはどのように見えるでしょうか？

redux-thunkに関する他の（否定的な）コメントのいくつかに同意します。 初心者にはお勧めしません（おそらくもうお勧めしません）：

1. 始めるのは魔法のようです。
2. それは実際にはそれほど多くのボイラープレートを奪うことはありません。 より複雑な非同期プロセスを考えると、小道具からdispatchを取得して渡す必要があることは、コードのごく一部にすぎないことがわかります。
3. その結果、アクションクリエーターをまとめて、より大きなワークフローに構成することはできません。
4. 最後のポイントは、reduxスタイルをライブラリよりもフレームワークにすることについてうまく説明できません。ライブラリを呼び出すのではなく、フレームワークを使用してコードを呼び出すことです。

React-Nativeアプリケーションでかなり頻繁に使用し、ほとんどの場合便利でしたが、アクションの作成者がvoid効果的に返すため、アクションを一緒に作成するのに問題がありました（「ログインに成功した後にプロファイルをロードする」と考えてください）。

「何かをする唯一の方法は、Reactイベントハンドラー/コールバックからすぐにdispatchすることだ」と人々に思わせる傾向があります。 また、 connectからreact-reduxを使用し、 mapDispatchToPropsに大きく依存していたため、イベントハンドラーが単なる関数であるmapDispatchToProps 。

（上記のアプリケーションの大部分は昨年の初めに作成されたものであり、Reduxのより大きなエコシステムで起こっていることに追いついていないため、古くなっている可能性があることに注意してください）。

@bodhi ：あまりにも多くの接線を外さずに、私はそれらの結論のいくつかに同意しません。 redux-thunkは11行の長さで、 「サンクとは何ですか？」のようないくつかの素晴らしい説明がありIdiomatic Reduxでのサンク（およびある程度のサガ）のさまざまなトレードオフのいくつかについて説明する投稿があり

私は、いくつかの架空の抽象化レイヤーで副作用を処理するための「祝福された」または「組み込みの」方法が必要になることに同意します。 Sagasとobservableはどちらも素晴らしいです、あなたがそれらの使い方を理解しているなら。 ここでの潜在的な目標は、Reduxを学び、使用するための簡単なパスを提供することであることを考えると、それらが適切かどうかはわかりません。

redux-thunkを使用することは、非同期で何かを行うだけでなく、現在の状態に依存する何かを行うことでもあることがわかりました。 非常にクリーンでシンプルなインターフェースであり、アクションクリエーターの使用を奨励します。

菩提：おそらく少し話題から外れていますが、ディスパッチはvoidを返さず、内部関数の結果を返すことを言及する価値があると考えただけです。 したがって、たとえば約束を返す場合、アクションを簡単に連鎖させることができます。 readmeの構成に関するセクションを参照してください。
https://github.com/gaearon/redux-thunk/blob/master/README.md

それ以外は、このオープンな議論をしてくれたコミュニティに感謝します。みんなの考えやアイデアを聞くのはとても興味深いことです。
これまでのところ、個人的にはサンクに固執していますが、「何が起こったのか」と「状態はどのように変化するのか」を明確に区別しようとしています。 私たちのコードには、その間違いを犯すインスタンスがかなりあります（レデューサーが何が起こったかに反応するのではなく、アクションを使用してレデューサーに何をすべきかを指示する）ので、どういうわけかそれを難し​​くしたライブラリを見るといいでしょうします（まだsagasで販売されていません）。

2017年3月19日で、夜11時48分で、菩提[email protected]は書きました：

redux-thunkに関する他の（否定的な）コメントのいくつかに同意します。 初心者にはお勧めしません（おそらくもうお勧めしません）：

始めるのは魔法のようです。
それは実際にはそれほど多くのボイラープレートを奪うことはありません。 より複雑な非同期プロセスを考えると、小道具からディスパッチを取得して渡す必要があることは、コードのごく一部にすぎないことがわかります。
その結果、アクションクリエーターをまとめて、より大きなワークフローに構成することはできません。
最後のポイントは、reduxスタイルをライブラリよりもフレームワークにすることについてうまく説明できません。ライブラリを呼び出すのではなく、フレームワークを使用してコードを呼び出すことです。
React-Nativeアプリケーションでかなり頻繁に使用し、ほとんどの場合便利でしたが、アクションの作成者が無効を効果的に返すため、アクションを一緒に作成するのに問題がありました（「ログインに成功した後にプロファイルをロードする」と考えてください）。次のアクションのシーケンスに使用するという約束などはありません）。

「何かをする唯一の方法は、Reactイベントハンドラー/コールバックからすぐにディスパッチすることだ」と人々に思わせる傾向があります。 また、react-reduxからの接続を使用し、mapDispatchToPropsに大きく依存していたため、イベントハンドラーが単なる関数である可能性があることを忘れがちでした。

（上記のアプリケーションの大部分は昨年の初めに作成されたものであり、Reduxのより大きなエコシステムで起こっていることに追いついていないため、古くなっている可能性があることに注意してください）。

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信するか、GitHubで表示するか、スレッドをミュートしてください。

（接線を続けて申し訳ありませんが...）

ディスパッチはvoidを返さず、内部関数の結果を返すことに注意してください。

ええ、素晴らしい！ 問題を解決する別の方法を見つける前に、ドキュメントをあまり詳しく調べたことがないと思います。

Reduxを私にとって非常に簡単にした最も価値のあることの1つは、アクションをコマンドではなくイベントとして扱うことです。 これにより、アクションを設計する方法とアクションに何を入れるかを決定するための苦労が完全になくなります。

コンポーネントは、ユーザーの操作が状態にどのように影響するかを知る必要はありません。コンポーネントは、 「ボタンXがクリックされた」など、内部で何が起こったかを外部に伝えるだけです。 アクションをコマンドとして使用する場合、コンポーネントと状態の間に双方向のバインディングを効果的に導入します。

レデューサーはコンポーネントにバインドされておらず、コンポーネントの状態ではなくアプリケーションの状態を表し、状態がどのように変化するだけです。 アクションは「状態をどうするか」というステートメントではないため、複数のレデューサーで単一のアクションを処理することに認知的な障壁はありません。

これにより、複数のアクションを同期的にディスパッチするケースも排除されます。

複数の場所から単一のアクションをディスパッチするケースもなくなります。 アクションクリエーターをコンポーネントの近くに置くことができるため、アクションをディスパッチしたコンポーネントを簡単に追跡できます。

DevToolsのアクションログを見ると、アプリ内で何が起こったかの完全な履歴を確認でき、アクションの影響を受ける具体的な状態スライスを簡単に確認できます。 歴史は可能な限り短いままです。

このプルベースのアプローチにより、データフローは真に一方向になり、 redux-sagaやredux-observableなどの副作用管理ライブラリと自然にスタックします。

@aikoven私はこれに完全に同意しますが（過去にreduxとイベントソーシングを比較することは間違いなくたくさんの議論がありました）、よく見られるFETCH_USERようなもの（そして行う必要があります）。 それは「イベントのような」よりも「コマンドのような」ようです。

@blockaネットワークリクエストを引き起こすイベントは常にあります。 リクエスト自体はFETCH_USER_STARTEDおよびFETCH_USER_DONE / FETCH_USER_FAILEDアクションでラップできます。これにより、リクエストの結果は最終的に状態になります。

👍 redux-actions

ボイラープレートを減らすだけでなく、私が気に入っているのは、reduxの非常に自然な拡張のように感じることです。 jumpstateようなものについては、実装が少し遠ざかっていると感じます。今度は、1つではなく2つのことを学ぶ必要があります。

つまり、ボイラープレートを減らすために追加するプラグインは、APIの冗長性は低くなりますが、reduxでの作業と非常によく似ているはずです。

ボイラープレートの多くは、どのような環境でも使用できるボイラープレートと同じです。 重複に遭遇した場合、通常、カスタム抽象化を使用して解決します。 これらの抽象化は、多くの場合、現在のプロジェクト以外では役に立たず、「銀の弾丸」は存在できません。 プロジェクトごとに要件は異なります。

reduxでも同じです。 FETCH_X_STARTEDアクション、 fetchX()アクションクリエーター、およびそれを処理するためのレデューサーなどが必要であることに問題がない場合は、自由に独自の抽象化を作成してください。

ボイラープレートのreduxを非難することは、すべてのコードをコピーして貼り付け、ボイラープレートが多すぎることでjavascriptを非難するようなものです。

redux-thunkを使用することは、非同期で何かを行うだけでなく、現在の状態に依存する何かを行うことでもあることがわかりました。 非常にクリーンでシンプルなインターフェースであり、アクションクリエーターの使用を奨励します。

同期コードにredux-thunkを使用することは良い考えではなく、ドキュメントで言及する必要があります。
多くの関数を一緒に構成する場合、ディスパッチフローが順序に依存しないかどうかわからないため、推論とテストが困難になります。

純粋なアクションの作成者がいて、より複雑な状態の変更にはアクションのバッチ処理を使用する方が良いようです。 このようにして、テストする純粋関数のみがあります。

理解を深めるために、このブログ投稿をお勧めします： http ：

@Machiaweliczny記事をありがとう。 私への質問は、ビジネスロジックをどこに置くかについての質問だと思います（ https://medium.com/@jeffbski/where -do-i-put-my-business-logic-in-a-で説明されてい

@dfbaskin

Reduxはドメイン駆動型の開発ではないことに注意してください。 ここでの「ビジネスロジック」は非常にあいまいな懸念事項であり、「実装しようとしているロジックに最適な概念の関数シグネチャ」です。 あなたの「ビジネスロジック」は、あなたが必要とするものに応じて、セレクター、レデューサー、アクションクリエーター、そして「オーケストレーター」（これについてはまだより良い言葉がありますか？）に広がっています。

(state, action) => stateであるレデューサーは、一般的に「状態に依存するロジック」があるべき場所です。 そして確かに、Elmアーキテクチャのようなものでは、そのようなロジックはすべて「更新」関数（レデューサーと同等）にあります。

残念ながら、Reduxでは、レデューサーは同期​​ロジックしか処理できません。 したがって、状態に依存する非同期の「ビジネスロジック」は、ディスパッチを介してコンポーネントから取得する必要があります（コンポーネントにその情報がある場合、常にそうであるとは限りません）。または、選択したオーケストレーターの概念（サンク、サガ、エピック）を介して取得する必要があります。そのための状態にアクセスできます。

レデューサーの制限がなければ、その必要はありません。 人々がredux-sagaまたはredux-observableを使用すると、実際にそれがわかります。彼らのアクション/アクションの作成者は通常、ほとんど些細なものになり（ほとんどの場合、プラスマイナスいくつかの正規化またはフォーマット）、saga / epicはほとんど「代替レデューサー」です。 、その上で、アクションと状態にアクセスして「モノ」を返す別のモノがあり、その結果、実際のレデューサーの複雑さが軽減されます。 レデューサーとオーケストレーターは非常に密接に関連しています（時にはあまりにも密接であり、半分の時間で交換可能な2つのコンストラクトを持つことは素晴らしいことではありません...しかしそれは私たちが持っているものです、それを楽しむのも良いでしょう）

@Machiaweliczny ：その「Thoughtson Thunks」の投稿の著者として、「同期作業にサンクを使用しない」ことは、私が言おうとしていたことの正反対であると確信できます:)

より良い議論ですが、私たちはトピックから少し離れ始めています。 （あそこに見える自転車小屋ですか？:)）

元の質問に戻りましょう。

• 「ボイラープレートが少ない」という慣用的なReduxの使用法はどのようになりますか？ これらの苦情に対する解決策をどのように提供できますか？
• 学習と使用のプロセスを簡素化するが、実際にはReduxを隠すことなく（そしてうまくいけば「ベース」Reduxへの移行/学習パスを提供する）、どのような可能な抽象化を作成できますか？
• 何らかの方法で改善されたドキュメントでこれをどれだけ解決できるでしょうか？

これらに対処するためにどのような具体的な手順を実装できますか？

議論の余地のない、実行可能な、短期間のステップの領域では、私は言うでしょう：

1）ストアの構成を簡単にします（デフォルトの構成である可能性がありますか？これがまだ当てはまるかどうかはわかりませんが、Elmには「スターターアプリ」タイプと通常のアプリタイプがありました。スターターアプリが使用されましたシンプルなアプリや、人々が学習しているだけの90％のケースをカバーするトレーニング資料では、今日まで、署名のドキュメントを検索せずに、基本的なミドルウェア（devtools、thunks）でReduxストアを構成できないことを認めます。 Reduxのコアコ​​ンセプトを学ぶために、新規参入者がストアのミドルウェアを構成する方法を知る必要があると主張する人はあまりいないと思います。

2）これはすでに当てはまる可能性があります。上記の「スターターストア」を使用してReduxをcreate-react-appに追加するのはできるだけ簡単なので、新規参入者は2分でReduxアプリを稼働させることができます。

これは私たちを非常に遠くまで連れて行ってくれると思います。

編集：スターターアプリとは、アプリの定型文ではなく、構成できない「createStore」を意味しますが、ユーザーがインポートして実行できる適切なデフォルトがあります。 その後、彼らはそれを超えたときに「本物の」createStoreに移動することができます。

それはまさにそこにあるかなり素晴らしいコンセプトのように聞こえます。

2017年3月20日月曜日午前10:02フランソワワード[email protected]
書きました：

議論の余地のない、実行可能な、短期間のステップの領域では、私は言うでしょう：

1.1。

ストアの構成を簡単にします（おそらくデフォルトで）
構成？ これがまだ当てはまるかどうかはわかりませんが、エルムはかつて
「スターターアプリ」タイプと通常のアプリタイプ。 スターターアプリは
シンプルなアプリとトレーニング資料で、人々がいるときに90％のケースをカバーします
ただ学ぶだけです。 今日まで、Reduxストアを設定できないことを認めます
のドキュメントを検索せずに、基本的なミドルウェア（devtools、thunks）を使用する
署名。 新規参入者が必要だと主張する人はあまりいないと思います
Reduxコアを学習するためにストアのミドルウェアを構成する方法を知る
コンセプト。
2.2。

これはすでに当てはまるかもしれません、上記でReduxを追加することを確認してください
create-react-appへの「スターターストア」は可能な限り簡単なので、新参者
2分でReduxアプリを稼働させることができます。

これは私たちを非常に遠くまで連れて行ってくれると思います。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/reactjs/redux/issues/2295#issuecomment-287806663 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AFUmCQYkUwjkCugevDBWC8TOu0HhWJTnks5rnqMWgaJpZM4MhnVF
。

私たちのモジュールはcombineReducers利用するため、モジュール内の各状態スライスには専用のレデューサーがあります（このアプローチは、ドキュメントの「スライスレデューサー」とも呼ばれる「レデューサーの構造化」セクションで概説されていると思います）。 これにより、switchステートメントがはるかに小さいため、推論が容易になります。 また、コードベース全体に共通のレデューサーが出現することも可能になりました。 最も単純なレデューサーは、アクションタイプを除いてモジュール間で同一であったため、アクションタイプごとにこれらのレデューサーを作成するヘルパー関数（レデューサーファクトリ？）を使用することで、ボイラープレートを削減できました。

const { makeIndicator, makePayloadAssignor } from '../shared/reducers';

const searchModule = combineReducers({
  searching: makeIndicator(c.SEARCH),
  results: makePayloadAssignor(c.SEARCH_RESPONSE, [])
});

おそらく、このようなより一般的なスライスレデューサーを特定することは、ボイラープレートの懸念を軽減するための良い方法であり、レデューサーの基本的な構成要素として機能する可能性があります。

これは基本的なJavaScriptリファクタリングです。 前に言ったように... "javascript"には
コードに抽象化などを適用するまでは、「ボイラープレート」がたくさんあります。

Reduxは単なるjavascriptです。 それについて魔法は何もありません。

12:44時月、2017年3月20日には、マルクスクッツェー[email protected]
書きました：

私たちのモジュールはcombineReducersを利用して、
モジュールには専用のレデューサーがあります（このアプローチの概要を説明していると思います
ドキュメントの「構造化レデューサー」セクション、別名「スライス」
レデューサー」）。これにより、スイッチが原因で物事を推論しやすくなります。
ステートメントははるかに小さいです。 また、一般的なレデューサーが出現することを可能にしました
コードベース全体。 最も単純なレデューサーはモジュール間で同一でした
アクションタイプを除いて、ボイラープレートを次のように減らすことができました
これらのレデューサーを作成するヘルパー関数（レデューサーファクトリ？）を持っている
アクションタイプ別：

const {makeIndicator、makePayloadAssignor} from '../ shared / reducers';
const searchModule = CombineReducers（{
検索：makeIndicator（c.SEARCH）、
結果：makePayloadAssignor（c.SEARCH_RESPONSE、[]）
}）;

おそらく、このようなより一般的なスライスレデューサーを特定するのは良いことです
ボイラープレートの懸念を軽減する方法、
レデューサーの基本的な構成要素。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/reactjs/redux/issues/2295#issuecomment-287820595 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AACourLpL5--NJiRzrWmKFJ31cl5DXJrks5rnqzxgaJpZM4MhnVF
。

ボイラープレートレデューサーを開発するよりも、一般的なreduxパターンを説明する方が良いと言ったほとんどのコメント提供者に同意します。 チームメイトと私は1。5年前にreduxを使い始めましたが、最も単純なことについてほとんど混乱していました。reduxはほとんどがイベントソーシングであり、同じアクションを複数のレデューサーで処理できること、アクションにはIDだけでなくビジネスエンティティ全体を含めることができることです。 、レデューサーは単なる関数であり、作成、生成、分割など、好きなことを自由に行うことができます。よくある間違いを犯しました。アクションをリモートコマンドとして使用し、なぜ古典的なメソッド呼び出しを使用しないのか疑問に思いました。 巨大なミドルウェアを作成し、「ジェネレーターが複雑すぎる」ためにredux-sagaを回避し（redux-sagaは素晴らしいですが！）、巨大なスイッチで長いファイルを作成しました。 これはもちろん、平凡なプログラミングスキルのためですが、構造化情報が不足しているためでもあります。 今日、メンテナのおかげで、ドキュメンテーションははるかに良くなりました！

これは、ライブラリとしてのReduxに関する非常に貴重なトピックです。

これは基本的なJavaScriptリファクタリングです。 前に言ったように... "javascript"には
コードに抽象化などを適用するまでは、「ボイラープレート」がたくさんあります。
Reduxは単なるjavascriptです。 それについて魔法は何もありません。

パーフェクト、@ blocka！ このメッセージを広める必要があると思います。

Reduxは、その最小限のアプローチのために、人々にとって異常で定型的な感じがします。 最小限は、一般的な「フレームワーク」（最小限のコード、最小限の原則）に対して奇妙に感じます。

JavaScript自体を書くのではなく、「framework-y」コードを書くことに慣れている人もいます。 開発者がフレームワークを使用する場合、組み込みの方法で物事を実行することが暗黙的に期待されます。 地獄のように悲しいが本当。

Reduxはこれまで以上に使い始めやすくなっていると思いますが、Reduxがすべてを行うことを期待しないように人々に明確にする必要があります。 @gaearonは常にこれを明確に言っていますが、残念ながら人々はすべてを行うフレームワークに慣れています。 なぜ彼らは「あまり役に立たない」何かを学ぶように動機づけられるべきなのでしょうか？ AngularはReduxよりもはるかに多くのことを行います。 なぜReduxなのか？ 答えはおそらくこの問題の私たち全員にとって明白です。 しかし、初心者には明らかですか？

私は昨日それについて短い記事を書きました： ReactやReduxのせいにしないでください。 もちろん、私はこれについて間違っている可能性があります。

高度なライブラリの上に抽象化レイヤーを配置する前例があります。 つい最近、TensorflowはコアAPIに加えて抽象化としてKerasを導入しました： http ：

TensorFlowを使用すると、TensorFlowを使用するほど賢くないように感じます。 一方、Kerasを使用すると、ニューラルネットワークが思ったよりも簡単だと感じます。 これは、TensorFlowのAPIが冗長で紛らわしいためであり、Kerasにはこれまでに経験した中で最も思慮深く設計された表現力豊かなAPIがあるためです。 TensorFlowとの最初の数回の苛立たしいやり取りの後、私は恥ずかしすぎてTensorFlowを公に批判することができませんでした。 それはとても不格好で不自然に感じました、しかし確かにこれは私の失敗でした。

これは、Reduxに登場するほとんどの最初のタイマーでも同様の経験だと思います。 TensorflowをRedux置き換え、 KerasをJumpstate置き換えます。 Reduxは非常に強力ですが、大多数のユーザーはおそらく利用可能なすべてのコントロールを必要としません。 おそらく、彼らはAngularから来ているか、ブートキャンプでReact + Reduxを教えられているか、さまざまなチュートリアルを見ています。 Reduxは、新しいユーザーのために呆然とする必要はありませんが、潜在的なユースケースの80％をカバーできる、より簡単な抽象化を提供するためのアンチパターンでもありません。

ええ、もしreduxがそれなりにうまくいっていたら、私たちはこの会話をすることはないでしょう。 reduxが有用であるか構造的に健全であるかに関係なく、人々は最初にそれを学んだときにまだ「悪い」と感じます。 これらの感情は有効です。

このスレッドでコメントしている人々はすべてreduxの専門家です-もちろん私たちはreduxに満足しています。 私たちはその哲学を内面化し、「ボイラープレート」を管理するための独自の抽象化を快適に行うことができます。 私たちは、このスレッドが提供しようとしている聴衆ではありません。 初めてreduxにアクセスするユーザー、おそらく関数型プログラミングに初めてアクセスするユーザーには、ある程度の共感が必要です。

例：reduxについてよく耳にする苦情です（アップスレッドについては言及されていないと思います）：reduxを使用するだけでは不十分であり、react-redux、redux-thunk、redux-actionsなどを使用する必要もあります。 。

reduxを使用するには、文字通り他のすべてのパッケージを使用する必要がありますか？ いいえ。
ほとんどのreduxユーザーはこれらの追加パッケージの一部またはすべてを使用することになりますか？ はい。

package.json内のパッケージの数は重要ですか？ いいえ、そうではありません。
package.jsonのパッケージの数は、人々の気持ちに影響しますか？ 絶対。

さて、redux自体はそのままにして、別のパッケージ（ create-redux-appなど）でそれらを組み立てる必要があると信じるのは公平だと思います。 しかし、私たちの手には本当に複雑な問題があり、ユーザーにRTFMを伝えるには十分ではありません。

reduxが有用であるか構造的に健全であるかに関係なく、人々は最初にそれを学んだときにまだ「悪い」と感じます。 これらの感情は有効です

絶対。 しかし、すべての人がそのように感じているわけではありません。 ある人はそうします。 問題がなかった人からは決して連絡がないことを覚えておいてください。 質問をしたり、stackoverflow / reactifluxを押したりした人だけが表示されます。 決してそうしない人の中には、助けが必要だがそれを求める方法がわからない人もいます...そして、うまくやっている人もいます、そしてあなたは彼らのためにそれを悪化させたくないです...そうでなければ彼らはそうします代わりにフォーラムに来る人であり、それは正味ゼロの利益になります。

Reduxは理由もなく人気を博しませんでした。 多くの人が、それはとても気持ちがいいと思い、他の人に勧めました:)

さて、redux自体はそのままにして、別のパッケージ（create-redux-appなど）でそれらを組み立てる必要があると信じるのは公平だと思います。

私はこのアイデアが好きでした。 既存のボイラープレートがすでにそれを解決していると主張することは可能ですが、Reactに入ろうとしたときに人々がツールに圧倒されていると不平を言っていた当時、Reactには多くのボイラープレートもありました。 create-react-appは、初心者がすでにReact _itself_に入る多くの手順を排除しているため、これらすべてに対する優れた回答でした。

しかし、それはまだ内部の定型文です。 ですから、私たちはまだ人々にエコシステムを購入するように勧め、Redux自体は設計上あまり効果がないことを明確にする必要があります。 ReactまたはReduxを使用したい場合、エコシステムから逃げることはできません。

しかし、Reduxコアにredux-thunkなどのパッケージを含めることがここに行く方法だとは思いません。

明確にするために、私が投げかけている種類のアイデアは、実際にコアに直接物事を含めることではありません。 それらは、別のパッケージやCLIツールなど、 create-react-app沿った、ある種の「ビルド済み構成」または「使いやすさの抽象化レイヤー」を仮想的に作成することを目的としています。

Jumpstate / Jumpsuitの作者としてチャイムを鳴らしたほうがいいと思います。

TL; DR：
Reduxは非常に低レベルであるため、習得や構成/統合が困難です。 コミュニティは、90％のユースケースを目的とした標準化された高レベルのredux apiの恩恵を受けて、学習曲線を緩和し、より単純なプロジェクトのソリューションとしても機能する可能性があります。 Jumpstateはこれを解決しようとしていますが、長期的な解決策ではありません。 このAPIがどのように見えるかについて、考えられるアイデア（実際のコードまたはメタコード）の提案を開始する必要があります。

Reduxは、門戸から学ぶのが非常に難しく、非同期ロジック、副作用、カスタムミドルウェアなどの新しい概念と統合するのも同じくらい難しいことがよくあります。私がこれを経験したのは1年ちょっと前のことです。反応エコシステムにとって非常に新しいものでした。

反応を学ぶのにほんの数日で、私はすぐにreduxを学ぶように勧められました。 この推奨事項は、同じことを行った（または行っていた）非常に経験豊富な開発者と初心者の開発者の両方からのものです。 これは、setStateを超えて拡張されたものすべての事実上のソリューションとして歓迎されていました（ただし、setStateゲートをこれに近づけないようにしましょう😉）。 reduxは素晴らしいので、これらすべてには正当な理由があります。

私は必然的に学習曲線にぶつかり、助けを求めるとすぐに、reduxのマーケティングと文書化されたアプローチが「Reduxは難しい、概念は低レベル、APIはロックされている、そしてあなたはただパワースルーする必要がある」というトーンを帯びていることに気づきましたそれ。"

だから、これは私が私のすべての仲間と一緒にしたことです。 それが私たちがするように教育されたものだったので、私たちはそれを通して力を与えました。 しかし、この旅に沿って、私はあえて抽象化レイヤーを非常に早い段階で作成し、reduxが提供しなければならなかった複雑さと高度な機能の一部を一時的かつ意図的に隠しました。

カスタムアクションクリエーターは必要なく、アクションとディスパッチャーをコンポーネントにマッピングすることを心配したくありませんでした。他の多くの場合と同様に、switchステートメントの代わりに冗長性の低いレデューサーレイアウトを選択しました。

それは素晴らしく機能しました。 実際、それは、学習曲線に同様に苦労していた残りの仲間や他の開発者のために、reduxを学習するプロセスを促進したほどです。

高度な「慣用的な」reduxを必要なときに使用できるように設計しましたが、90％のユースケース向けに設計しました。

決して、jumpstateがすべてのベースをカバーしていると言っているわけではありません。実際、jumpstateが「慣用的に」動作するために変更する必要のあるものがまだたくさんあります（カスタマイズ可能なアクションクリエーター、グローバルアクションインポートの削除...たくさんあります） 、しかしそれは間違いなく多くの人々が基本を学ぶのを助け、reduxが非常に単純なレベルでどのように機能するかを理解するための道を彼らに与えました。 Jumpstate slack orgで、jumpstateが誰かがreduxを学ぶのに役立ったというメッセージを常に受け​​取ります。

それらの人々が今日でもjumpstateを使用しているかどうかはそれほど重要ではありません（しかし、多くの人々が今日でもそれを本番環境で使用しています）。 重要なのは、彼らが経験したことと、reduxエコシステムでどれだけ早く生産的になることができたかでした。

この議論のために頭に浮かぶいくつかのより多くのアイデア：

• 単純化されたreduxがどのように見えるかのメタ例を提案し、それを突き刺してください！
• しばしば重複し、非常に意見が分かれるredux Middlewarsの要件について話し合い、標準を決定します。 非同期処理から始めることができます。 これは、reduxコミュニティの非常に多くの断片化を解決し、すべての人の努力がreduxの長期的な存続と使用法に違いをもたらすのに役立つ可能性があります。

何らかの方法で改善されたドキュメントでこれをどれだけ解決できるでしょうか？

多くの。 Reduxのドキュメントに関しては、AngularJSのドキュメントと同様に、不必要に冗長ですが、AngularJSとは異なり、「語るのではなく見せる」という原則に失敗するため、AngularJS1のドキュメントよりもかなり悪いと感じています。

Reduxのドキュメントは、コードの実際のデモンストレーションよりもコードスニペットを好みます。つまり、「ここに一連のコードがあります。接続方法については説明しませんが、機能することを信頼してください」という瞬間が多すぎます。 ブラウザ内でサンプルを実行する機能がないということは、ユーザーがローカルで行っていることが機能しているという自分の本能を信頼せざるを得ないことを意味します。 単純なTodoListアプリでさえ、Reduxの最良の「HelloWorld」の例とは言えないと思います。もっと単純にすることができます。

ダイアグラムは確かにここで役立ちます。 たとえば、私は@sunjayのものが好きです。 さらに良いかもしれないのは、Todoリストの例自体のために1つを設計することです-高レベルのビューからファイルがどのように接続されているかなど。 画像はほとんどの場合、長いテキストを伝えるのに適していて、ドキュメントの冗長性を減らすのに役立ちます。 これらの画像は、初心者が集中力を維持し、Redux全体をよりよく理解するのにも役立ちます。

私の2セント：コアを変更しないでください。 その輝きはそのシンプルさにあります。 この時点で、それに何かを追加すると、全体から離れてしまう可能性があります。

使いやすさとさらなる抽象化は、ユーザーランドで発生する可能性があります。 私はそれを使用するための公式または慣用的な方法も必要ではないと感じています。 それは予測可能な状態コンテナです、それだけです！

それは自立することができます、それは❤️になりましょう

とは言うものの、確かに、その上にさらに意見の分かれたライブラリを作成して、好きなようにパッケージ化します。 それは私もやっていますが、コアを変えないようにしましょう。

@HenrikJoreteg 、恐れることはありません！ ここで説明することでコアが変わることはないとほぼ確信しています。 コアは完全な機能であり、それ自体で立っています。 :)

多くの。 Reduxのドキュメントに関しては、AngularJSのドキュメントと同様に、不必要に冗長ですが、AngularJSとは異なり、「語るのではなく見せる」という原則に失敗するため、AngularJS1のドキュメントよりもかなり悪いと感じています。

これは非常に真実です。 Reduxが新しくなったときの1つは、ドキュメントがまばらだったということですが、基本はそこにありました。 「とてもシンプル」だったので、多くの人が採用しました。 しかし、オンラインリソースは現在、「私のお気に入りのミドルウェア」や「私のお気に入りの定型文の削減ツール」であることが多い「現実世界の手法」を示しようとしています。 人々は圧倒されます。

「少ないほど多い」については、言いたいことがあります。

@ Phoenixmatrix 、 @ Sylphony ：では、ドキュメントの刷新の可能性はどのようになりますか？

個人的には、「スターターストア」を持つという上記の提案と組み合わせるために、2つに分割します（2つの異なるサイト/ドキュメントではなく、2つの異なるセクション）。

キュートでシンプルな図面がたくさんある「Reduxアーキテクチャ」は、アクションとレデューサーを説明し、react-reduxとおそらくサンクを紹介し、「スターターストア」を使用してあらゆる種類の事前構成を制限し、それがいかに簡単であるかを示しますいくつかのajaxリクエストを実行し、画面上に何かをレンダリングするシンプルなアプリを作成することです。

他のすべては、より高度な概念を備えた「探索」セクションに入ることができます。 それでも、私はおそらくたくさんのものをはぎ取るでしょう。 今日、誰かが私に、アプリに複数のストアを含めることに関するセクションがあると指摘しました。 それは知っておくと良いことですが、その使用法は本当に進んでいます。 見ずにつまずく必要はないと思います。

より良いドキュメントは常に素晴らしいアイデアですが、それがここでの中心的な問題を解決するとは思いません。 抽象化ライブラリは、Redux APIの定型文と冗長性のために作成され、採用されています。 それらの同じライブラリは、明らかに何らかのレベルで必要とされているため、Reduxコミュニティを断片化しています。 エコシステムに積極的に貢献しようとしている同じ著者が「Reduxを理解していない」という理由で辞任され、公に解雇されるのは苛立たしいことです。 代わりに、コミュニティがReactコアの一部ではなく、ある程度「祝福された」単純な抽象化を作成できれば、誰もが勝ちます。 筋金入りのユーザーはReduxをそのまま使用し続け、他の人はより簡単で冗長性の低いAPIを使用して抽象化を使用できます。

@derekperkinsどうすれば「祝福された」図書館について合意に

私はすべてこのようなことを望んでいますが、一部の人だけが使用する別のライブラリを作成して、エコシステムをさらに断片化しないようにするにはどうすればよいですか。

関連するxkcd： https ：

ええ、reduxのコアとreact-reduxは、コンセンサスにできるだけ近いものです。 そのレベルでさえ大多数の人々が異なるニーズを持っているので、redux-thunkとredux-actionsでさえかなり境界線です。

Reduxでボイラープレートを減らすことは、「私は必要ありませんだから私はそれを抽象化します。 しかし、初心者でも「その部分」は劇的に異なります。

ちなみに、私たちはたくさん（数十）のreduxアプリを使用しており、アプリごとに要件が異なるため、共通の定型的な削減スタックを構築するのは困難です。 アプリが1つしかない場合や、同じ要件を持つアプリがいくつかある場合は簡単です。 小さなものでもかなり異なります。

ここでの考え方は、すべての人のすべての問題を解決するツールキットをまとめることではありません。 例としてCRAを使用します。BabelとWebpackおよびESLintを構成する方法はたくさんあります。 CRAが行うことは、ユーザー側の手間をかけずにすべてを機能させるための単一の意見のある方法を提供することであり、学習者にとって物事をより良くするためのいくつかの設定を意図的に選択します。 次に、ユーザーが必要に応じて構成を制御できるようにします。

また、すべてのユースケースを解決しようとするわけではありません。 CRAは、高度なコード分割、複数のエントリポイント、SSRなどに取り組むことはありません。 CRA docs _do_は、より多くの構成可能性を提供し、特定のユースケースでより適切に機能する可能性のある他のツールとオプションを示しています。

それはそれを置くための素晴らしい方法です。 早く立ち上がって実行するための何か
reduxとこの架空の設定レイヤーをインストールするだけですか？ それか
素晴らしいでしょう。

私が持っていたもう1つのアイデアは、開発モードで設定できるフラグです。
ユーザーの漸進的な学習機会を監視し、公開します。 の
このようにして、抽象化レイヤーはインタラクティブな教育ツールとして機能します。
16:14マーク・エリクソンの月、2017年3月20日には[email protected]
書きました：

ここでの考え方は、すべての問題を解決するツールキットをまとめることではありません
すべての人のために。 例としてCRAを使用する：構成する方法はたくさんあります
BabelとWebpackとESLint。 CRAが行うことは、単一の意見を提供することです
ユーザー側の手間をかけずにすべてを機能させる方法、そしてそれ
物事をより良くするためのいくつかの設定を意図的に選びます
学習者。 これは、ユーザーが場合は、設定の制御を取ることができます彼らはしたいです。

また、すべてのユースケースを解決しようとするわけではありません。 CRAはしようとしません
高度なコード分割、複数のエントリポイント、SSR、または次のようなものに取り組む
それ。 CRAのドキュメントは、提供される可能性のある他のツールやオプションを示しています。
より多くの構成可能性があり、特定のユースケースでより適切に機能します。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/reactjs/redux/issues/2295#issuecomment-287914805 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AFUmCactFzsw7etmGGP8MFK6kfNaOzTJks5rnvorgaJpZM4MhnVF
。

@sunjayクリックしなくてもxkcdリンクが何であるかを知っていました。 :)

@markeriksonに同意します。 これは、すべての人のすべてのエッジケースを処理する試みではありません。 これは、「これは物事を機能させるための良い方法です」と言っている、コアRedux開発者からの意見の表明です。 必要に応じてオーバーライドできる正常なデフォルトがありますが、デフォルトは開発者の80％で機能することを賭けます。

それはコアReduxに書かれているかもしれませんし、書かれていないかもしれません。 学習曲線を加速する以上のことを行うJumpstateのようなものの場所はまだあると思います。

Reduxの学習曲線は急勾配になる可能性がありますが、概念を理解すると、抽象化レイヤーの必要性がなくなることがよくあります。

それはある程度真実だと思いますが、必ずしも抽象化レイヤーを排除したいという意味ではありません。 私は過去にCを記述し、メモリ割り当てを理解していましたが、ガベージコレクションが処理されるGoで記述したほうがずっと好きです。 以前のTensorflowの例によると、低レベルのAPIに書き込む方がパフォーマンスが高くなりますが、Pythonkeras抽象化の使いやすさについても多くのことが言われています。 同様に、ReduxとJumpstate（またはこの問題からの抽象化）の場合、定型文を書くのが必ずしも難しいわけではありません。生のReduxのすべての柔軟性を必要としないほとんどのユースケースでは面倒です。

それが私次第だったら、私はこれを見たいです：

• バニラReduxよりも入力が簡単なFlow / TypeScriptフレンドリーなサブセット。
• 定数をそれほど強調しません（文字列リテラルの使用をより安全にします）。
• Reactまたは他のビューライブラリからの独立性を維持しながら、既存のバインディングをより簡単に使用できるようにします（たとえば、 mapStateToProps実装を提供します）。
• Reduxの原則を維持する（シリアル化可能なアクション、タイムトラベル、ホットリロードが機能するはずです。アクションログは理にかなっているはずです）。
• 箱から出してすぐに、より簡単な方法でコード分割をサポートします。
• レデューサーとセレクターのコロケーションを奨励し、一緒に書くのが面倒にならないようにします（書き込みと作成が簡単なレデューサーとセレクターのバンドルを考えてください）。
• アクションクリエーターをレデューサーと同じ場所に配置する代わりに、アクションクリエーターを完全に排除し、アクションからレデューサーへの多対多のマッピングを自然にします（ほとんどのライブラリのように遠ざけるのではありません）。
• 賢明なパフォーマンスのデフォルトを作成することで、ユーザーがそのコードを記述しなくても、一般的なユースケースで再選択によるメモ化が「正しく機能」します。
• インデックス作成、正規化、コレクション、および楽観的な更新のための組み込みヘルパーが含まれています。
• テスト可能な非同期フローのサポートが組み込まれています。

もちろん、コアに加えて、公式のReduxのものとしてブランド化することは問題ありません。
また、私はこれを書きません。 でも君ならできる。

私にとって、数ヶ月前にreduxを学んだとき、私はドキュメントを読みましたが、よく理解していません。そのため、2日間かけてsrcコードを読み、その後、 apiに関するすべての説明を読みます。ドキュメントが明確になります。

そして、「状態設計」、「リデューサー部門」、「ミドルウェア設計」、「非同期ソリューション」……章も、来月のプロジェクト開発で明らかになります。

したがって、srcコードを読むことは、 reduxを学ぶための最も適切なステップだと思います。その後、 reduxの環境をよりスムーズに理解し、探索することができます。

デフォルトでは非同期サポート。

redux-thunk, redux-sagaなどの別のプラグインを使用する必要がないことを意味します。

デフォルトの非同期サポート

そうです、それは人々がより良いものを探す前にそれを0.5秒間見るだけです。 コンポーネント内でAPIを呼び出してから、コールバック/プロミスの解決でディスパッチを呼び出すことを妨げるものは何もありません。 人々がすぐにそれを外部化したいと思っているだけです（私も含めて）。 ただし、ミドルウェアがなくても非同期を問題なく実行できます。

@gaearonのコメントは、スイープがどれだけ広いかを強調しているという点で完璧です。 私は彼が提案するRedux2.0の精度と優雅さ、そしてパワーを完全に愛し、感謝していますが、それらの改善のほとんどは私には関係ありません！

私は実際にそれが魅力的だと思います。

私自身のRedux抽象化ライブラリはほぼ完全に反対です。 単一レデューサーアクション、アトミックレデューサー関数をアクションコードとセレクターにバンドルすること、オブジェクトキーを優先して文字列を完全に削除することには、計り知れない価値があります。 それは私自身の90％の解決策であり、他の何よりも態度がCRAに似ています。

興味深い点は、私たちが解決しようとしている問題は何かということです。 多くの問題があり、いくつかの異なるソリューションスペースが利用可能です。 ダンが説明した方法でRedux2.0を構築した場合、その上に独自の抽象化ライブラリを再構築します。

Reduxの@jbellseyグレートは、グローバルにアプリにアクションと状態を提供することである-しかし、定義された範囲内-あなたはReduxの店の無限のインスタンスを持つことができますが、それらを組み合わせることができます。 基本的に、これはライブラリに役立ちます。 図書館が内部でreduxについて話しているのを見たら、あなたは恩恵を受けること

どのような問題を解決しようとしていますか？

アプリのグローバル状態。 R eliable a E sthetics D elivered U nified e X tensible：heart：

誰もグローバルを望んでいません。 しかし、誰もが1つ必要です：tm：

どうぞ、今のようにreduxをシンプルにしてください。 パターンです。 クックブックは常に100前後で発生します：

@markeriksonこれらの考えを整理するために、ドキュメント/スプレッドシートを開始することをお勧めしますか？ すでにいくつかの素晴らしいアイデアがあり、48時間しか経っていません🎉

私にとっては、サンクやサガの使用はお勧めしません。 代わりに、JavaScriptで依存性注入の手法を学びます。

Reduxをプレーンデータベースとして扱うと、簡単になります。

• Reduxに初期状態と、アクション（イベント）がアプリケーションの状態にどのように影響するかを伝えます。 （データベーススキーマやストアドプロシージャのように。）
• 次に、Reduxはそれを管理し、リスナーに通知し、状態を検査およびデバッグする方法を提供します。

私にとって、Reduxは私にとってすべてです（データベースがHTTP呼び出しを行うことは期待していません）。 I / Oや非同期のものについては、Reduxの外部で実行します。 これにより、Reduxストアを予測可能に保つことができます。 型署名は常にstore.dispatch(actionObject)です。 ディスパッチ関数やアクション内の隠された意味はありません（たとえば、アクションをディスパッチしてもAPI呼び出しは行われません）。

@tannerlinsley ：ええ、それのために行きます。

この議論を始める私には一つの欠点は：私はすでに、私はおよその作業と書き込みに必要なもののトンを持っています。 その多くは自主的なものですが、調査したいRedux関連のトピックのいくつかに取り組む十分な時間がないことを意味します。ましてや、主要なドキュメントの刷新や新しいツールキットの構築などに取り組むことはできません。スクラッチ。

私は絶対にこれらの可能な努力に参加したいのですが、他の人が参加して一緒に働く必要があります。 （すべてのOSSメンテナの有名な最後の言葉... :)）

Reduxをプレーンデータベースとして扱うと簡単になります

これが私がお勧めするものです！

• ストアを正規化してください
• ビューなどのデータを準備できます。 専用のレデューサーでこれを行います—そうすればreselectは必要ありません。 検討。
• アクションは別のアクションをトリガーするべきではありません—これは簡単に見える可能性があります。 しかし、 componentDidMountフックがあると難しいです。 これを解決する方法がわかりません。 これを階層内で上にシフトすることは必ずしも簡単ではありません

FWIW、私はD3.js （Reactなし）でReduxを使用していて、非常にうまくいっています。 このいくつかの例は、 d3-componentにリストされてい

React Reduxバインディングについて私が最も見逃しているのは、 connectです。 @gaearonの上記の概要/ビジョンから私が最も興味を持っているのは、「 mapStateToProps実装を提供すること」です。

ビューなどのデータを準備できます。 専用のレデューサーでこれを行います—その後、再選択する必要はありません。 検討。

ええ、これはTwitterがストアで行うことのようなものです、少なくとも私はそう思います-データマップへの通常のIDを含むentitiesブランチ、つまり基本的にメインフィードであるtimelineビューがありますエンティティブランチへのID参照を保持しているが、すでに事前計算されているものを確認してください。

非常に動的なリストを再選択することは...パフォーマンスが高すぎないため、これからのリファクターで私が目指していることです;）唯一の欠点は、データが重複してしまうことと、ビューの更新と削除を操作することです。あなたはしばしば約2か所（またはそれ以上）を覚えておく必要があるので、長期的にはかなり面倒です。

@stefensuhat自分でReduxを実装しようとしたとき、Promiseループを使用して非同期アクションを可能にしました。 https://github.com/iddan/deluxで確認でき

@gaearonはあなたのリストに完全に同意します！ 私が働いている組織では、リストの90％に続いて（また、アヒルの原則に従って）、reduxボイラープレートに取り組んでいます。 現時点では初期リリースであり、公開可能ではありません。

私は間違いなくこの良いアイデアに貢献したいと思います！

@markerikson @tannerlinsley

これらのアイデアを整理することに関しては、スプレッドシートを作成した後、開発を追跡するために適切なリポジトリにGithubの問題を作成することをお勧めします。 次に、これらの問題のリストをここにコメントする必要があります。

これは、特に何かがreduxで出荷されることを保証するものではありませんが、その特定のものに興味のある人々に、議論をフォローし、それを実現するために協力する機会を与えます。

これらの提案を実現する責任は、それぞれの新しい機能やアプローチに関心のある私たち全員にあります。 マークは議論を始めましたが、彼がすべてを実行することを誰も期待していないと確信しています。 :)

ええ、 @ gaearonのリストは理想的ですが、すでに述べたように、それはたくさんのことです。 真っ直ぐにそれに取り組むことを試みる誰もが忘却へのバイクシェディングに直面するでしょう。 関係なく発生することを望んでいますが、上に完全なレイヤーを構築するのではなく、一度に小さなピースを攻撃する必要があると思います（ここでも、事前構成されたスターターストアの例をプッシュします;））

そうは言っても、誰かがそのリスト全体を攻撃しようとする場合は、Reduxの外部、さらにはReactの外部に存在する他のツールやフレームワークも念頭に置いてください。 React / Reduxには、バニラフラックス、MobX、VueJS、およびそのエコシステム、Angularに比べて興味深い一連の利点があります。 コミュニティが何をするにしても、おそらくこれらの利点のいくつか（ @gaearonのリストの一部です）に焦点を合わせ続け、上に構築されたレイヤーが完全に冗長にならないようにする必要があります。 タイムトラベルのデバッグ、ミドルウェアエコシステムなど、他の場所でも利用できます。

私が作っている例：自動生成されたレデューサーを自動的に更新する関数を作成できるモジュールを作成したくなるかもしれません。 しかし、一度それを行うと、MobXを複製したので、それを行うのはあまり役に立ちません。

@Phoenixmatrixはい、つまりreduxにはデフォルトのミドルウェアがあるので、外部のミドルウェアを使用する必要はありません。 😄

Reduxの現在の実装に問題はありません。 ボイラープレートは存在しますが、型システムがあれば大した問題ではありません。

私にとっての大きな問題の1つは、数年前よりもはるかに複雑なフロントエンドアプリケーションを構築していることを人々が理解していないように見えることです。 大規模なチームで、より大きく、より複雑なアプリケーションを構築している場合、難易度が大幅に増加し、新しいパターンが出現するのは普通のことですが、人々はその難しさを拒否します。

物事を単純化したり、定型文を減らしたりするべきではないと言っているのではありませんが、トレードオフを理解して全体像を見ずに、Reduxを使い始めて定型文について不平を言うべきではありません。

Reduxが作成されたとき、多くの人（私を含む）がそれを構築しようとしましたが、 @ gaearonは最高の実装を取得し、ツール/デモで非常に優れた作業を行いました。 それ（そしてフラックス）は、タイムトラベルだけでなく、多くの人にとって新しいものではなく、すぐに自然に感じるというコンセプトのために、最初は多くの注目を集めました。

人々はReduxを新しい光沢のあるおもちゃと見なしています（実際にはそれほど簡単ではないようです）。 しかし、Reduxには、誰かがこれらの概念をエレガントな方法でフロントエンドに移植したという事実を除いて、本当に新しいものはありません。 Reduxとそのエコシステムのパターンは、分散システム、イベントソースのバックエンドアプリケーション、ドメイン駆動設計ですでに使用されており、これらのバックグラウンドを持つ人々はReduxを非常に簡単に理解できます。

残念ながら、人々は、関係するより一般的なパターンについて何も知らずに、手順をスキップしてReduxを使用したいと考えています。 個人的には、Reduxで本格的なものを構築したい人には、分散システムのバックグラウンドを最小限にすることをお勧めします。 それは奇妙に思えるかもしれませんが、そのような背景を持つことは、現在、そして今後数年間であなたに非常に深刻な利点を与えることができると思います。

フロントエンドアプリケーションを構築するときに、正確に何を構築しますか？

• 分散システムのメンバーを構築します
• そのメンバーは、より一般的なシステムのデータのサブセットのみを保持します
• そのメンバーの容量は非常に限られています（ストレージ、帯域幅、ネットワークの安定性など）。

ですから、私たちは非常に複雑なものを構築しようとしています。 データベース開発者よりも処理が難しい制約がありますが、長年にわたってこれらの問題について真剣に考えていた人々の以前の知識を再利用せずに、箱から出してすぐに簡単にできるようにしたいと考えています。 DB内の状態をどのように構成するかについて、人々はすでに考えていたと思いませんか？ それを照会する方法は？

今日、アプリケーションを出荷して、現在の知識を間違えるのではなく、私たちが構築しているものがもはや単純ではなく、追加の知識が必要であることを理解し、認めるべきだと言っているのではありません。 Reduxはこの知識を習得するための良い方法かもしれません。最初は実用的な方法で使用できますが、今後数年間でフロントエンドの開発がどれほど不快になるかを過小評価しないでください。

残念ながら、人々は、関係するより一般的なパターンについて何も知らずに、手順をスキップしてReduxを使用したいと考えています。

良くも悪くも、Reduxは本質的にReactの状態管理の戦いに勝ちました。 それに伴い、エコシステムを形成する能力が生まれます。 何かが機能することだけを望んでいる開発者は常に存在し、それだけが必要な単純なアプリケーションはたくさんあります。 人々は他の抽象化レイヤーを使い続けるか、単純なライブラリを介して正しい一般的なパターンを紹介することができます。

個人的には、Reduxで本格的なものを構築したい人には、分散システムのバックグラウンドを最小限にすることをお勧めします。 それは奇妙に思えるかもしれませんが、そのような背景を持つことは、現在、そして今後数年間であなたに非常に深刻な利点を与えることができると思います。

これが問題の核心です。 Reduxはそのままで、それを理解している人に最適です。 しかし、それを単純化することは必ずしも悪いことではありません。 アセンブリコードを理解することは通常、より良いコードを書くのに役立ちますが、ほとんどの人はもはやアセンブリコードを書いていません。 それはほとんどの人が始めるところではありません。

周りにもっと良いコメントがたくさんあります。 ここにはたくさんのアイデアがあり、さらに探求することができ、また探求する必要があります。

実用的な可能性のあるアイデアを思いつくことができるかどうか見てみましょう。 まず、小さなベースラインの概念を捨てることから始めます。

redux-starterなどと呼ばれる新しいパッケージを作成します。 そのパッケージは、 redux-actions 、 redux-thunk 、 redux-logger 、そしておそらくプロミスベースのミドルウェアに依存する可能性があります。 これは、シグネチャfunction createReduxStore({reducers, middleware}) {}持つ関数を提供します（以前の@Phoenixmatrixのコメントに基づく）。 ミドルウェアを受け入れることすら気にしないでしょうか？

createReduxStore()関数は、 applyMiddlewareの処理、ルートリデューサーのホットリロードの設定、およびReduxDevTools拡張機能の構成を処理します。 ミドルウェアが提供されていない場合、デフォルトで含まれているミドルウェアが構成されます。 これは、 ember-reduxのストアサービスセットアップコードまたは「ProjectMini-Mek」サンプルアプリのいる可能性があります。

これにより、少なくとも開始に必要なセットアップの量が最小限に抑えられ、便利な機能の適度なセットが提供されます。

ええ、私はそれが好きです（まあ、新しいユーザーのためのリダックスアクションと約束ベースのミドルウェアは好きではありませんが、私はあなたにそのバイクシェディングを楽しんでもらいましょう）。 ミドルウェアをわざわざ受け入れるのではなく、createStarterStore（reducer）だけです。

たぶんcombineReducerを置き換えることさえできるので、あなたは簡単に行うことができます：

const store = createStarterStore({
   foo,
   bar,
   baz
});

ここで、foo barbazはレデューサーです。

ドラット。 ユーザーがルートレデューサーファイルへのパスを渡すことを許可したとしても、 module.hot.accept()一方または両方が存在するため、「ルートレデューサーのHMRを設定するライブラリ関数」はおそらく機能しないことに気づきました。 require(path)再インポートステップでは、変数ではなくビルド時に静的に分析可能なパスが必要です。 （私は...私は間違っている可能性があると思います。）ああ、まあ。

しかし、ええ、 createStarterStore()はルートレデューサーまたはスライスオブジェクトのいずれかを受け入れることができます。

個人的には、Reduxで本格的なものを構築したい人には、分散システムのバックグラウンドを最小限にすることをお勧めします。 それは奇妙に思えるかもしれませんが、そのような背景を持つことは、現在、そして今後数年間であなたに非常に深刻な利点を与えることができると思います。

@slorber私はその部分であなたに同意します。

残念ながら、人々は、関係するより一般的なパターンについて何も知らずに、手順をスキップしてReduxを使用したいと考えています。

しかし、実際にはこれではありません。 Reduxに含まれるパターンを知っている人もいます。そのため、Reduxを使用することにしました。 単純な（または少なくとも単純な）ものを使用したいということは、必ずしもユーザーがより難しい実装を使用できないことを意味するわけではありません。 時間と労力を節約するだけです。

私が働いている場所では、Reduxを1年間使用していて、同じコードをコピーして貼り付けて（少し変更するだけで）ストアに新しいリソースを追加していることに気づきました。そのため、ある時点で私たちは感じました。この冗長なボイラープレートを抽象化するために、Reduxの上にレイヤーを実装する必要があります。
私の意見では、このアイデアはReduxの使用を単純化するだけでなく、最も一般的なパーツのボイラープレートを減らすことでもあります（同じように、 react-reduxはReactと一緒にReduxを使用するときにボイラープレートを減らします）。

非常に興味深い議論。 初期の頃からのreduxユーザーとしての私の2セント：

当初、私が覚えているように、reduxは、アプリを構築するためのフレームワークというよりも、プロトコルまたは一連の合理的な規則と見なされていました。 この緊縮財政は、reduxが新しい人々に圧倒され、独自の抽象化を行わずにスケーリングするのが面倒な理由の一部です。 しかし、2015年に状態管理の混乱を切り抜けた単純な方法も、それが始まった理由です。ミニマリズムにより、Apolloのような驚くべきフレームワークが、さまざまなプロジェクト（特に開発ツール）で行われた作業に便乗し、使い慣れた方法を提供できるようになりました。必要に応じて、状態管理で「より低いレベルにドロップ」します。

「低レベル」のライブラリreduxが大成功を収めていることは明らかだと思います。また、アプリを構築するための機能豊富なフレームワークとしては、まだ十分ではありません。 注意すべきことの1つは、reduxが進化しても、Apolloのようなプロジェクトの業界標準の「プロトコル」としての役割を壊さないということです。

この目的のために、おそらく現在のreduxはredux-coreようなパッケージになる可能性があり、 redux自体が抽象化のレベルを上げて、アプリを構築するための推奨される方法を提供します。 もちろん、redux-coreを使用したこのredux （Apollo、またはsagasを使用したものなど）のより高いレベルの代替手段はいくつもあります...

明確化と強調のために物事を言い換える：

このスレッドからの作業には、既存のReduxライブラリへの大きな変更は含まれません:)ドキュメントの刷新は完全に可能であり、いくつかの小さな調整があるかもしれませんが、既存のreduxパッケージはそのままです。

今説明したredux-starterパッケージ、またはダンが概説した「フレームワーク」-yアプローチのようなものは、 redux依存する新しいパッケージになります。

@markeriksonが提案したようなパッケージを作成することに投票します。 コードベースができたら、API、コードスニペット、およびより詳細なアイデアを検討し始めることができます。 そうすれば、特定の機能に関する問題を作成する場所ができます。

Deluxをスターターとして使用できます（jk）

@tannerlinsleyのJumpstateのヘビーユーザー（そして現在はメンテナーの1人）として、私はこれに非常に興奮しています。 Jumpstateを使用する私の理由は、 @ gaearonの元の投稿で非常に簡潔に概説されています。 そうは言っても、それは完全な解決策ではありません（意図されたものではありませんでした）。 今朝、これに加えて追加できるいくつかのことを考えていたところ、このスレッドを発見し、皆さんがすでに考えていることに気づきました。

長く曲がりくねった言い方：すごいですね、私は参加しています、私がどれだけ貢献できるかわかりません（私は試してみます）が、あなたには確かにチアリーダーがいます。

私はJumpstateを使用してReduxを数回教えてきましたが、学習曲線が大幅に短縮されたと自信を持って言えます。 ReduxはHTTPのように、Jumpstateはフェッチのように思います。 私はReduxが大好きで、（ばかげて）複雑なことをいくつか書いていますが、90％のケースでほとんどのことを教えるのに十分すぎることも知っています。

あなたがそれについて考えるとき、これはあるべき素晴らしい場所です。 フロントエンド開発とJavaScript全般に関する主な不満の1つは、「標準ライブラリの欠如」です。 これは非常に新しいもの（TM）であり、ブラウザーで完全なアプリケーションを開発できるようになっています。 標準ライブラリを必要と

Re：学習曲線、意見、抽象化：

Ajaxは、サンク、サガ、叙事詩の使い方を学んでいるかどうかに関係なく、新しい学習者が行き詰まる領域のようです。 それほど問題がないように思われる領域の1つは、アクションの作成です。これらは単なる古いJavascriptオブジェクトであり、Flux StandardActions仕様によって提供される明確さが追加されています。 この考え方から、私は次の質問にたどり着きました。

例えば

function fetchPosts(page) {
  return {
    type: 'FETCH_POSTS_REQUEST',
    // Ajax request setup
    ajax: {
      url: `/api/posts`,
      method: 'GET',
      data: { page },

      // Optional ajax meta attributes
      meta: {
        // Amount of time to debounce the execution of the request
        debounce: 400,
        // Amount of times to retry the request on failure
        retry: 2,
        // Amount of time before timing out
        timeout: 10000,  
        // The action type that cancels the request
        cancelType: 'CANCEL_FETCH_POSTS',
        // Strategy when multiple FETCH_POSTS_REQUESTs are in flight
        resolve: 'LATEST'
      }
    }
  };  
}

ajaxアクションはミドルウェアによって処理されます（ミドルウェアはアクションのajaxキーに反応します）。

私はこのアプローチが悪い考えである理由を考えようとしてきましたが、まだ取引のブレーカーについては考えていません。
私の見積もりの​​いくつかの利点：

• 平均的なアプリケーションで必要な非同期アクションの量が劇的に減少します（ajax関連の非同期アクションがなくなるため）
• プレーンな古いJavaScriptオブジェクトのみを扱っているため、理解しやすいです。
• 宣言型であり、実装の詳細は重要ではありません
• さまざまな実装が破損することなくスワッピングイン/スワッピングされる可能性があります
• それは慣用的なReduxです（アクションログはまだ意味があり、シリアル化可能など）

関心の分離の議論を呼びかける人もいますが、それは私たちのajaxリクエストアクションがすでに行っていることの自然な延長であると私は主張します。 現在、彼らはかなり明確なコンテキスト'FETCH_POSTS_REQUEST'でアクションを設定していますが、コンテキストが少なすぎてajaxリクエストの実装を抽象化できません。 選択肢はほとんどありませんが、ajaxリクエストを別の場所で手動で実行します。

頭に浮かぶもう1つのことは、いくつかのドキュメントで見た非同期アクションチェーンです。 このようにリクエストをチェーンする必要がなかったので、このチェーンがどれほど広く使用されているかはわかりませんが、ここで提案している範囲外になると思います（おそらくそうではありません）この説明で述べた90％のユースケースには該当しません）。

結論として、このような抽象化は、一般的なReduxアプリケーションを作成するために必要な学習曲線とコードの量を容易にするのに役立つ可能性が非常に高いようです。 誰かがこのアプローチについて何か考えを持っていますか？あなたが考えることができる取引ブレーカーはありますか？ @markerikson @gaearon

先行技術： redux-axios-middleware

このスレッドではたくさんのことが起こっています。

Reduxの複雑さについての議論について。 個人的には、Reduxが複雑で冗長であると不満を言う人には同意しません。 これは、Flux＆Elmアーキテクチャに基づく低レベルのライブラリを使用する場合のトレードオフです。 Reduxのホームページには、必要ないかもしれない

Reduxはそのまま見つけられます。 幸運なことに、コアチームはそれが機能が完全であり、変更する気がないことを認識しています。 その上に構築された抽象化は素晴らしく、それぞれに独自のユースケースがあります。 これは、適切に設計された低レベルのライブラリに期待するものです。

問題はRedux自体ではなく、それを学ぶための進歩的ですぐに使える方法がないことにあります。 一部の人が言及したように、React自体にも同じ問題があり、 create-react-appが解決策でした。

そのための素晴らしいリソース（つまり、ダンのエッグヘッドシリーズ）があるので、おそらくそれは問題ではありません。 おそらく、学習曲線なしで複雑な問題を解決するライブラリを使用したい人が問題です。

とにかく、これはこのスレッドの目的ではありません。

@markerikson私は個人的にこのredux-starter開発を手伝うつもりです。

_もっとかっこいい名前が欲しいけど_：stuck_out_tongue：

多くのアクションを生成するために必要な定型文は、reduxで私が目にする唯一の欠点です。

非常に低レベルですが、それは素晴らしいことだと思います。 これが、たとえばMobXよりもReduxスタイルのパラダイムを好む理由の1つですが、その有用性は理解しており、MobXを使用します。 しかし、Reduxを理解した今、それを実行できれば幸いです。 Redux（または一般的にはReduxパターン）であるため、データは特に「舞台裏」には行きません。 一般に、コードが処理されている場所はどこでも、コードを記述し、そうでない場合は理解できます（時間をかけて学習した場合は、後で詳しく説明します）。

問題は、私が最初にReduxについて学んだとき、理解することはたくさんありましたが、それも単純でした。 何かが難しいことも単純なこともあります。 しかし、そのため、「このコンセプトはとても論理的です！自分でできると思います！」と思いました。 そのため、最初のプロジェクトでは、Reduxパッケージを使用する代わりに、独自の小さなReduxストアを作成しました。

そうすることで、Reduxの概念を理解するのに役立つだけでなく、Javascript自体の理解を深めることができました。 （これは、これまで関数型プログラミングの概念についてほとんど何も知らなかった人の観点からのものであるため、マイレージは異なる場合があります。）Reduxの概念は、そのシンプルさという点で非常に優れていますが、信じられないほど強力です。

Reduxはとても人気があるので、うーん、「流行語らしさ」は、Javascriptでの機能の素晴らしさから初心者の気をそらす可能性があるということだと思います。 ですから、彼らの考え方は「ReactやReduxなどを手に入れました。今度は素晴らしいプログラマーになり、素晴らしいアプリを作ります！」かもしれません。 それは悪いことではありません。 しかし、彼らは、ツールが機能する理由を理解せずに、光沢のある新しいツールを使用して開発プロセスを促進したいだけに集中する可能性があります。

概念が理解されると、Redux（またはReduxのようなパターン）にあらゆる種類のことを実行させることが非常に簡単になります。 Angularのような他の（まだ素晴らしい）ツールよりもReactが好きなのと同じ理由で、私はそれが好きです。 _それはただのJavascriptです。_これがJavascriptの仕組みです！
必要な定型文をいくつかのパラダイムによって減らすことができれば、それは素晴らしいことですが、unlimitedddpowaaaaaaに支払うのは小さな代償だと思います。

IMOのこのすべての「冗長性はトレードオフです」は単なるマゾヒズムです。 冗長性は、それはあなたがすべてでReduxのを使用するように作る犠牲だ、何のサービスではありません。 私はReduxやjavascriptを非難しているのではなく、これが本質的な複雑さではないことを指摘したいだけです。 Elmは、Reduxが達成するすべてのことをより少ない行とより単純なコードで管理します。

そこで、ボイラープレートを機械的に書き出します。 Jumpstateなどは作業を楽にしますが、実行時に実行できることには制限があり、typescript / flowではjumpstateはあまり役に立ちません。 しかし、codegenはタフであり、すでに過負荷になっているビルドシステムにもう1つ追加したいとは思わないでしょう。

慣用的なReduxに翻訳されたElmコードのようなものがあれば...それでも私の鼓動する心であり続けてください。

ここに私の考えのいくつかがあります、私が前のコメントを繰り返さないことを望みます：

アクションクリエーターはアクションタイプとして使用できます

actions.js

export function increase() {}

reducer.js

import { increase } from './actions.js';
export default handleActions({
    [increase]: (state) => state + 1
}, 0);

関数には一意の参照があるため、それらをアクションの識別子として扱うことができます。 FSA互換ではありませんが、多くのコードを節約し、間違いを防ぎます。

アクションは非同期でディスパッチできます

async function a() {

}
async function b() {
}
store.dispatch(a());
store.dispatch(b()); // b() will be dispatched after a() resolves

そうすれば、アクションクリエーターは非同期関数でありながら、次々にディスパッチできます。 多くの状況で見られるように、人々はミドルウェアベースのソリューションを使用する必要がなく、ボイラープレートコードを大幅に節約できます。
このコンセプトは、デラックスのプロミスファクトリーによって実装されています

redux ===ボイラープレート

https://github.com/Emilios1995/redux-create-module

しかし、この機能はあなたの命を完全に救うことができると思います。

このスレッドで進行中の2つの異なるアイデアのセットを区別する価値はあります。

• 「フルサービス」のreduxベースのフレームワーク
• reduxコアの追加機能

私は@markeriksonに同意し、reduxコア自体がフレームワークになるべきではなく、redux-thunkとreact-reduxを別々のパッケージに保持したい理由を理解しています。 ただし、reduxコアには新しい「ヘルパー関数」の余地と前例の両方があると思います。

ReduxのAPI表面積はかなり小さいです： createStore 、 applyMiddleware 、 combineReducers 、 bindActionCreators 、およびcompose 。 しかし、これらのほとんどは便利な関数です。 Reduxが機能するために厳密に必要なのはcreateStoreだけです。 なぜこれらのいずれかがコアに属しているのですか？

• applyMiddlewareは、エンハンサーを格納するための簡略化されたインターフェイスを作成します。 しかし、もっと重要なことは、 applyMiddlewareは、reduxストアにエフェクトを追加する標準的な方法としてミドルウェア_interface_をサポートしていることです。 applyMiddlewareは比較的シンプルなインターフェースを備えており、ユーザーが一度に多くのミドルウェアを実行できるため、ミドルウェアエコシステムが可能になります。

• combineReducersは、便利な形式のレデューサー構成を提供します。 レデューサーを作成する唯一の方法ではありませんが、確かに、より便利なパターンの1つです。 しかし、reduxコアに存在するということは、それが一般的であるだけでなく、_ユビキタス_であることを意味します。 私が遭遇した重要なReduxアプリはすべて、 combineReducersを使用してルートレデューサーを作成します。 これの裏側は、 combineReducersがReduxに付属する唯一のレデューサー構成の形式であるため、多くのユーザーが、それが存在する唯一のレデューサー構成の形式であると信じているように見えることです。

• bindActionCreatorsは、アクションのディスパッチに関する定型文の一部を削減します。 しかし逆に、 bindActionCreatorsは、ボイラープレートに対するReduxの評判の一部にも間接的に責任があります。 これは、 bindActionCreators存在するだけで、アクションクリエーターの使用が促進されるためです。 これは、アクションクリエーター（ bindActionCreatorsによって「承認」されている）とセレクター（文書化されているが同等のコア機能がない）の普及率を比較すると特に顕著です。 react-reduxを使用する多くのコードベースを見てきました。 mapStateToPropsは常に「特注」セレクターですが、 mapDispatchToPropsは常に事前に作成されたアクションクリエーターのオブジェクトマップです。

これらのどれもReduxの機能に不可欠ではありませんが、それらのすべてはその使いやすさに不可欠です。 これらの関数はいずれもReduxの固有の柔軟性を制限するものではありませんが、一般的なパターンを呼び出し可能な関数に具体化することで、選択が難しくなりません。 そして、これらのヘルパー関数のそれぞれがさらに疑問を投げかけます。

• ミドルウェアがストアエンハンサーの簡略化である場合、広く役立つ可能性のある他の簡略化はありますか？
• 単に文書化するのではなく、他にどのような形式のレデューサー構成を実装できますか？ レデューサーオブジェクト？ 依存するレデューサー？ 線形構成？
• 再選択を統合することで、人々は以前にはなかったセレクターを作成および作成することができますか？ これは正味のプラスになるでしょうか？

これらすべての答えが否定的であったとしても、私たちは自分たち自身と地域社会に彼らの前提を考慮することさえ拒否することによって不利益をもたらすと思います。

@modernserf ：まず、コメントと、Reduxに関する最近の考えに感謝します。 それらはすべて_非常に_価値があり、有益であり、おそらくこのスレッドの他の人のために読む必要があるはずです。 だから、私はそれらをここにリンクします：

• メインの投稿： Reduxの何がそんなに素晴らしいのですか？
• 投稿につながったTwitterスレッドの保存バージョン： https ：//storify.com/acemarke/redux-pros-cons-and-limitations
• その後のいくつかの追加の考え： https ：

関係する歴史があるので、それらを持ち出す必要があるのは非常に興味深いです（私は私の投稿The Tao of Redux、パート1-実装と意図のために多くの時間を費やしました。特に、 redux-thunkはもともとはReduxにreact-reduxも後で分離されました。

あなたはそれらのユーティリティが確かに特定の使用パターンを成文化しているということは正しいです。 とはいえ、これらのユーティリティが含まれているのは、スライスリデューサーの構成、非同期動作やその他の集中型動作のためのミドルウェアのパイプライン、コンポーネントからアクションをディスパッチするプロセスを簡素化するためのバインドされたアクションクリエーター（特に関数の受け渡し）などの使用パターンを体系化したためです。子コンポーネントへ）。 同様に、Reselectはコアにはありませんが、 Danは明示的にその作成を奨励​​しました。

そうです、誰もがそれらを「書くことができた」のですが、それらを組み込むことによって、私たちは人々にそれらの特定のツールを特定の方法で使用するように促しました。 間違いなくそれに同意します。

最後の3つの質問ごとに：

• ミドルウェアは「ストアエンハンサーの単純化」であると_推測_できますが、それが正当であるとは思いません。 むしろ、それは非常に特殊な目的のためのストアエンハンサーです。 他のストアエンハンサー関連の作業に関する限り：Danは、Reduxコアの主要な部分の1つを変更したいのは、エンハンサーの初期化方法に関連していると述べています。 ＃2214で@acdliteの＃1706でバージョン、および@jimbollaのバージョン：非常に長い時間のために開いて座っているの変化ストアエンハンサーの実装には、2つの「競合」のPRは実際にあります。 ジムがすべての既知のストアエンハンサーのリストをまとめ
• レデューサーの構成と構造には、他にもたくさんのパターンがあります。 「依存」レデューサーに関しては、それがはるかにニッチなユースケースであり、かなりアプリ固有であるように思われるため、正確に何ができるかわかりません。 関連するメモとして、ダンは長い間、 combineReducers何らかの3番目の引数を追加することを提案したPRをすべて閉じていましたが（そしてそれらの_lot_がありました）、最終的に＃1768を先に進めることを許可しましたその間。 そのPRも行き詰まっています。
• セレクターの最も一般的な使用例は、状態のビットを直接抽出し、それらを名前付きの小道具として渡すことのようです。 また、React-ReduxにmapStateオブジェクト短縮構文をcreateStructuredSelectorでも同じことができるにもかかわらず、多くのリクエストがありました。

その「TaoofRedux」の投稿で文書化したように、述べられた目標は、ReduxコアAPIを可能な限り最小限に抑え、その上にエコシステムをは特定のプラグインを「祝福」する意図についてコメントしました。

gaearonがかつて言ったように（私はどこにいるのか思い出せません...おそらくSlack）私たちはFluxライブラリのKoaのようになることを目指しています。 最終的に、コミュニティがより成熟したら、おそらくreduxjs GitHub組織の下で、「祝福された」プラグインと拡張機能のコレクションを維持する計画です。

以前のアップスレッドでは、ある種の「簡単なReduxセットアップ」抽象化ライブラリなどを提案していました。 そのようなもの、または少なくとも「祝福された」アドオンのリストは、あなたが考えている線に沿って十分でしょうか？ （そして、実際には、このスレッドの最初のコメントでもそうしました。）そうでない場合、追加の提案やアイデアはありますか？

最終的に、コミュニティがより成熟したら、おそらくreduxjs GitHub組織の下で、「祝福された」プラグインと拡張機能のコレクションを維持する計画です。

これも私が行うことですが、おそらくさらに一歩進めます。プロジェクトをモノレポに再構築します。現在のreduxパッケージは@redux/core 、祝福されます。 reselectやredux-actionなどのライブラリはリポジトリと名前空間に取り込まれ、 reduxパッケージ自体は、これらすべてのパッケージを単一の名前空間に再エクスポートするだけです。

その_sortof_は、reduxコアを変更しないという制約を満たしています。 また、拡張バージョンは、コアの厳密なスーパーセットであるため、コアとの下位互換性があります。 新しい機能は純粋にオプトインであり、プライベート状態への特別なアクセスはありません。 「肥大化」に関する限り、これらの各ライブラリはそもそも小さく、ツリーを振るのが簡単になるように記述されています。

また、mapStateのオブジェクト短縮構文を追加するためのReact-ReduxへのオープンPRもあり、ReselectのcreateStructuredSelectorでも同じことができるにもかかわらず、多くのリクエストがありました。

これはあなたに何かを教えてくれるはずだと思います。

私が提案しているモノレポ構造は、基本的にLodashが使用する構造です。 さて、Lodashはモデル化するのに興味深いライブラリです。その膨大な数の関数のコレクションであり、その多くは自分で実装するのは簡単です。 lodashのほぼすべての関数は、「レシピ」としてより柔軟になる可能性があります。 groupByは、結局のところ実際には_pattern_です。 あなたがそれをどのデータ構造で使用しているのか、誰に言いますか？

また、すべてのlodash関数は、独自の_アラカルト_ライブラリでも利用できます。 import groupBy from "group-by"超えるimport { groupBy } from "lodash"は_機能的な_メリットはありません。 必要なものだけをインストールできるのに、なぜツリーシェイクに対処する必要があるのですか？

しかし、Lodashの使用経験は、レシピやナノライブラリーの使用とは根本的に異なります。 配列を使って何かをしているときに、自分自身を繰り返しているような気がする場合は、おそらくそれを行うためのLodash関数があることを知っています。 レシピを検索する必要はなく、何もインストールする必要はありません。ファイルに別のインポート行を追加する必要さえない可能性があります。 それはほんのわずかな摩擦を取り除くだけですが、私たちの日々はこのような瞬間で満たされ、それは合計されます。

別の観点から、私が自分の2セントを追加してもかまわないことを願っています。

CQRS 、イベントソーシング、そして最終的にはドメイン駆動設計の考え方は、 FluxとReduxを生み出したより大きな祖先です。 これらの影響が時々引用されますが、 Reduxとその子孫ツールは、当時人気のあったFluxとFluxの実装からAPI用語のほとんどを取り入れました。 これは問題ありませんが、既存のエクスポージャー開発者がそれらのアイデアに対して持っていた可能性のある利益を得る機会を逃していると思います。

違いの2つの例を挙げます。私が見たほとんどのイベントソーシングの議論では、 Reduxアクションはイベントと呼ばれReduxActionCreatorsはコマンドと呼ばれます。 この用語にも無料で付属している明確さとセマンティクスがいくつか追加されていると思います。 イベントは、ログに記録可能でシリアル化可能なデータです。 イベントは、過去形で何が起こったかを説明します。 イベントを再生できます。 イベントを記録コマンドには命令法があります。 コマンドはイベントをトリガーし

アーキテクチャパターンとしてのイベントソーシングは、今後10年間で人気が高まると思います。また、APIとディスカッションをより広範なコミュニティとより緊密に連携させることで、 Reduxは使いやすさ、明快さ、使いやすさを向上させることができると思います。

この議論はすでに打ちのめされていると思います： https ：

ああ、気づかなかった、ありがとう！ ：+1：

当時、取れる措置がなかったため、＃351は閉鎖されたようです。 APIの決定と使用する言語を再検討している時期にいる場合、私には、このアイデアを再検討するのに適切な時期のように思えます。

もっと具体的にすることができます。

イベントソーシングのイディオムに触発されたAPIがどのように見えるかについての私の考えは次のとおりです。

コンセプト

• 観察可能なイベントストリーム
• イベントストリームには、サポートされているイベントの適切に入力されたセットがあります
• コマンドはイベントストリームにディスパッチします
• 1つ以上のクライアントがイベントストリームを消費します

API

import { createEventStream, createProjection } from 'redux';

// Initialize the event stream separately from the store.  This becomes the one
// true source of truth for your application.
const eventStream = createEventStream({
  // Commands are the only thing that we want to couple to the eventStream.  The 
  // set of events which may end up in an eventStream should be easy to predict.
  //
  // A definition like this supports static analysis inference well for 
  // consumers that can leverage it.
  increment: () => ({ type: 'INCREMENT' }),
  decrement: () => ({ type: 'DECREMENT' }),
});

// Multiple stores with disjoint or overlapping data can be used to consume the 
// same event stream.
const store = createProjection(eventStream, reducer, init);
const adminStore = createProjection(eventStream, adminReducer, init);

// We don't need a jargon term ("Middleware"), or a dedicated hook to handle 
// async anymore.  We just register more subscribers to the eventStream.
eventStream.subscribe(myCustomMiddleWare);
eventStream.subscribe(sendEventsToAnalytics);
eventStream.subscribe(logEventsForPlayback);

// Calls to commands can be wrapped with React Providers or container components 
// in the same way that Redux currently does.  They can also be called directly.
eventStream.increment();

@ajhyndman ：提案と議論に感謝しますが、自転車小屋は完全に塗装され、馬は納屋から逃げました（比喩を完全に混ぜ合わせるため）。 Danは、CQRS / ESの用語ではなくFluxの用語を使用することを選択しました。また、コアAPIやReduxの概念に使用される用語を変更する予定はありません。

（また、これを実証する統計はありませんが、現時点では、少なくともJSコミュニティ内では、CQRS / ESの用語よりもReduxの「アクション」と「アクションクリエーター」の使用に精通している人が多いと思います。 ）

この会話は以前にもあったような印象を受けており、再開したくないという強い思いがあります。 😄ここではあまり強く押しません。 （より良いタッチポイントがあれば、この会話を他の場所で読んだり、続けたりすることに興味があります。）

もちろん、塹壕の要因があることも正しいです。APIの表面全体と用語を変更すると、現時点ではコストがかかります。

イベントソーシングとReduxのコミュニティがお互いから学ぶ機会があると私はまだ主張します。

• 学習と使用のプロセスを簡素化するが、実際にはReduxを隠すことなく（そしてうまくいけば「ベース」Reduxへの移行/学習パスを提供する）、どのような可能な抽象化を作成できますか？

用語を借りたり、APIを変更したりしなくても、私たちが見つけることができる勝利があると思います。 たとえば、ストアを「currentStateが追加専用リスト（またはストリーム）の「純粋関数」（派生または縮小）である状態コンテナー」と説明することで、 Reduxを紹介することに成功しました。アクションの」。

さらに将来を見据えると、reduxのようなサーバーインフラストラクチャを実装して抽象化することは完全に可能だと思います（ Apache Samza 、およびLinkedInのエンジニアリングチームの他の作業の一部を参照）。 それを目指しているのであれば、クライアントとサーバーの状態管理にも同様の抽象化を使用できるはずです。 それを達成できるのなら、同形で永続的なReduxストアを

JavaScriptコミュニティとインフラストラクチャコミュニティが一緒になり、またはそれらの間で簡単にマッピングできる概念は、これらの機会がより早く明らかになり、より表現力豊かな抽象化になると私は期待しています。

私はこれらのアイデアのいくつかに少し興奮していると思います！ ダンプという言葉をお許しください。

補足：上記で提案したサーフェスを実装するRedux用のイベントストリームのようなラッパーAPIを作成することは可能のようです！

https://github.com/ajhyndman/redux-event-stream

@ajhyndmanラッパーはあなたのアイデアをそこに持っていく正しい方法だと思います👍

あなたが言及したsamzaとLinkedInのエンジニアリング作業に関連して、他の人が素晴らしい話を読んだり見たりしていない場合は、Apache Samzaでデータベースを裏返しにして、いつかそうする時間を見つけてください！ ある時点で、ダンがreadmeやツイートでそれについて言及しているのを見たと思います。この話は、データベースと状態管理の見方を永遠に変え、reduxの非常に密接な考えのいとこです。

そのビデオは素晴らしいです！ これは、実際にはreduxリポジトリのREADMEのThanksリストの2番目の項目でもあります。

こんにちは、みなさん！

このスレッドの存在に気付かずに、 @ markeriksonの元の質問に直接答え、 @ gaearonのリストからほとんどのものを削除するライブラリを開発しました。

ライブラリはKeaと呼ばれます：

これは、redux、redux-saga、およびreselectを抽象化したものです。 それらを接続する接着剤を除いて、Keaは新しいものを作成するふりをせず、必要に応じてraw reduxアクションクリエーターとレデューサー、raw redux-saga sagas、rawreselectセレクターを公開します。 それは新しい概念を発明するものではありません。

Keaは、さまざまな操作モードをサポートしています。スタンドアロンで使用したり、Reactコンポーネントに接続したり、Reactコンポーネントの上にインラインで接続したり、セレクターへの入力がReactコンポーネントの小道具に依存するReactコンポーネントに動的に接続したりできます。

私は個人的に2つの大きなアプリケーションでそれを使用しています。1つはプライベートレッスン用のマーケットプレイスで、もう1つは巨大なフリート追跡ソフトウェアです。 さらに、それを使って独自のアプリを作成した人もいます。 それは私たちにとってとても便利だったので、私はそれをきれいにし、ドキュメントを書くのにかなりの時間を費やしました。

私にとって、このライブラリは、redux自体のコアに忠実でありながら、常にボイラープレートを大幅に削減してきました。

とにかく、十分な話、ここにいくつかのコードがあります。 これは、私が「インラインケア」と呼んでいるものの例です。ここでは、ロジックがコンポーネントに直接接続されています。 このモードは、始めたばかりの場合や、ReactのsetStateの代わりとして最適です。

import React, { Component } from 'react'
import PropTypes from 'prop-types'
import { kea } from 'kea'

@kea({
  actions: () => ({
    increment: (amount) => ({ amount }),
    decrement: (amount) => ({ amount })
  }),

  reducers: ({ actions }) => ({
    counter: [0, PropTypes.number, {
      [actions.increment]: (state, payload) => state + payload.amount,
      [actions.decrement]: (state, payload) => state - payload.amount
    }]
  }),

  selectors: ({ selectors }) => ({
    doubleCounter: [
      () => [selectors.counter],
      (counter) => counter * 2,
      PropTypes.number
    ]
  })
})
export default class Counter extends Component {
  render () {
    const { counter, doubleCounter } = this.props
    const { increment, decrement } = this.actions

    return (
      <div className='kea-counter'>
        Count: {counter}<br />
        Doublecount: {doubleCounter}<br />
        <button onClick={() => increment(1)}>Increment</button>
        <button onClick={() => decrement(1)}>Decrement</button>
      </div>
    )
  }
}

アプリが成長し、より多くの場所でincrementおよびdecrementアクションまたはcounterプロップにアクセスする必要がある場合は、次のようにコードを分割できます。

// counter-logic.js
import PropTypes from 'prop-types'
import { kea } from 'kea'

export default kea({
  actions: () => ({
    increment: (amount) => ({ amount }),
    decrement: (amount) => ({ amount })
  }),

  reducers: ({ actions }) => ({
    counter: [0, PropTypes.number, {
      [actions.increment]: (state, payload) => state + payload.amount,
      [actions.decrement]: (state, payload) => state - payload.amount
    }]
  }),

  selectors: ({ selectors }) => ({
    doubleCounter: [
      () => [selectors.counter],
      (counter) => counter * 2,
      PropTypes.number
    ]
  })
})

// index.js
import React, { Component } from 'react'
import { connect } from 'kea'

import counterLogic from './counter-logic'

@connect({
  actions: [
    counterLogic, [
      'increment',
      'decrement'
    ]
  ],
  props: [
    counterLogic, [
      'counter',
      'doubleCounter'
    ]
  ]
})
export default class Counter extends Component {
  render () {
    const { counter, doubleCounter } = this.props
    const { increment, decrement } = this.actions

    return (
      <div className='kea-counter'>
        Count: {counter}<br />
        Doublecount: {doubleCounter}<br />
        <button onClick={() => increment(1)}>Increment</button>
        <button onClick={() => decrement(1)}>Decrement</button>
      </div>
    )
  }
}

試してみて、ドキュメントを読んで

Keaに対するフィードバックは、これまで圧倒的に肯定的であり、問題から引用し

お時間を割いて、ここまで読んでいただきありがとうございます！ :)

いい感じ！ 'increment' 、魔法の文字列はあまり好きではありません

この議論は別の場所で前進しましたか？ Keaは、一般的に受け入れられている最も正しい結果ですか？

@lucfranken ：いいえ、議論は

Reduxのより高いレベルの抽象化を探しているなら、Keaはおそらく良いオプションです。 ストアのセットアッププロセスを簡素化する「Reduxスターターパック」を探している場合は、いくつかを見回す必要があるかもしれません。 私はそのようなものを実際に見たことがあることを知っていますが、現在そのような公式のライブラリはありません。

ここのリングに私の帽子を投げます。 これが私がこの問題に対処する方法です： https ：

個人的には、ボイラープレートの大幅な簡素化と削減だと思います。

それは私が最近構築するすべてのものを構築してきた方法です。

それが役立つと思います：
https://github.com/anish000kumar/redux-box

ねえ、私の会社では、ネットワーク層を管理し、Reduxから多くの定型文を削除するライブラリをオープンソース化しました。 成功していることが証明されていますが、自分で試してみてください： https ：

これがreduxボイラープレートを減らすための私のアプローチです

https://github.com/zhDmitry/restate

非常に遅れたスレッドのネクロとして、しばらく前に、「ボイラープレート」が人々にとって何を意味するのかについて、Twitterでフィードバックを求めました。

https://twitter.com/acemarke/status/969040835508604929

ネクロスレッドの復活！

このスレッドの最初のコメントを編集したところ、ここで説明したアイデアはRedux-Starter-Kitパッケージに変換されました。 それを試してみて、Reduxの使用を簡素化するのにどれだけ役立つか見てください！