Redux: EggheadのReduxスクリーンキャストシリーズ

：+1：

1. ローカルコンポーネントの状態とグローバル状態
2. 複数のレデューサーによって処理されるアクションと1対1のアクションとレデューサーの関係
3. 最初のアクションが終了した直後に2番目のアクションをトリガーする必要がある場合の、アクションチェーン（特に非同期のもの）の処理。
4. 不必要な再レンダリングを防ぐための最適化技術（バッチ処理、再選択など）。

：+1：

シリーズの最初の16エピソードを見たばかりですが、これらは、私が働いている会社の社内トレーニングに使用する可能性が高い優れたリソースだと思います。 ただし、状態ツリーにプレーンオブジェクトとディープフリーズのみを使用し、 immutable-jsのよう

これについてのあなたの考えを知ることは素晴らしいことです。

Immutableをミックスに投入すると、ReduxとImmutable APIを区別することを学ぶ必要がある初心者を混乱させたり、Immutableが必要であると想定したりする可能性があります。

Immutableをミックスに投入すると、ReduxとImmutable APIを区別することを学ぶ必要がある初心者を混乱させたり、Immutableが必要であると想定したりする可能性があります。

わかりました、理にかなっています。 この決定の背後にあるあなたの考えを知っておくのは良いことです:-)。

@smashercosmoが言ったこと：+1：

ユニットテスト。 TDD。

@catelandが言ったこと：+1：

私はあなたのスキルセットに非常に感銘を受けていると言わなければなりません。この方法で、豊富なドキュメントと簡潔なチュートリアルを備えた優れたjsライブラリを作成できます。

すべてのビデオを見た後、私はメールで送る特定のビデオについてたくさんのフィードバックを持っています。 結論は、これはReduxの紹介以上のものであるということです。 コードプラクティスやコンポーネントアーキテクチャなどをカバーします。 それは本当に素晴らしく、非常に教育的です。 ビデオは3つのグループに分けることができると思います。 基本的なRedux、舞台裏でのRedux、Reactを使用したRedux。

今後のビデオでは、特定の概念に反応することを少なくし、非同期アクションとテストについてもっと詳しく見ていきたいと思います。

非常によくやった、それを続けてください！ :)

ビデオ21では、TodoAppコンポーネントはクラスである必要はなく、関数である可能性があることに注意してください。 この実現に至った経緯を説明できれば素晴らしいと思います。これが機能コンポーネントとして適している理由と、これによってどのようなメリットが得られるのでしょうか。

これすごくいいね。

@smashercosmoのリストの項目3も知りたいです。

@wpannellが言ったこと！ ユニットテスト/ TDD！

また、高度なドキュメントでカバーされているトピックに関するビデオを見たいと思います。

ユニットテストに関して、具体的に何に興味がありますか？
レッスン5、11、12は、レデューサーの単体テストの方法を示しています。

...それは良い質問です。 モカテストの場合、プロセスは大きく変わりますか？

あまり。 しかし、それは一連の高度なレッスンにとって良いトピックだと思います。 ユニットテストレデューサー、アクションクリエーター、コンポーネントなど。

まず、素晴らしいビデオ。 すでにreduxを理解していますが、それはさわやかでした。
より高度なビデオを作成している場合は、非同期アクション/ミドルウェアをお勧めします。
ユニットテストが実際にカバレッジを必要とするとは思わないでください。 レデューサー関数を呼び出して、それらをアサートできますか？

ええ、モカテストでexpectラップする以外に、実際にはそれほど多くはないと思います。 ：いいぞ：

ありがたいことに、すべてがとてもシンプルです！

オブジェクトIDハッシュによる不変性（例： [post._id]: {...post} ）。

reduce関数に過度に依存して、APIエンティティの配列を取得し、それを使用してIDハッシュを生成していることに気付きました。 normalizrがこれの一部を処理することは知っていますが、ポイントAからBに移動するEggheadIOビデオに似たビデオが欲しいです。これは、Reduxベースのものだけではなく、非常に絡み合っています。

@raquelxmoss

ビデオ21では、TodoAppコンポーネントはクラスである必要はなく、関数である可能性があることに注意してください。 この実現に至った経緯を説明できれば素晴らしいと思います。これが機能コンポーネントとして適している理由と、これによってどのようなメリットが得られるのでしょうか。

それは実際、私の側でのずさんなレッスン計画でした。 最初から機能的なコンポーネントにすることができたのは手遅れになるまで気づきませんでした。 クラスよりも関数を使用する利点は単純さであるため、できる限りいつでもこれを実行してください。 基本的に、 componentDidMountやstateのようなライフサイクルフックが必要ない場合は、機能コンポーネントを使用します。

これらのコードを実際のディレクトリ構造に分割して役立つようにする方法についてのレッスンを見つけます。 すべてが揃っている限り、おそらく機能することはわかっていますが、フォルダーの命名規則（コンポーネント/コンテナー/ストア/レデューサーなど）、どの種類のファイルがどのフォルダーに入るのかなどをお勧めします。

高度なレデューサー構成もお願いします。

複雑なコンポーネントの再利用（レデューサーまたは複数のレデューサー、一連のアクション、アクションクリエーター、サーバー側APIへのアクセス、redux形式などのいくつかのReactコンポーネントで構成されていますが、より現実的なアプリ固有です）。 これには、モジュラーディレクトリ構造の編成も含まれます。

全部見て、とても良かった！ ES6 / 7構文（ Object.assignような）の使用、React 0.14関数コンポーネント、および不変のものの回避に感謝します。

おそらく、推奨されるコードアーキテクチャを説明するビデオです。

そして、ES6 / 7構文を使用するようにドキュメントを更新しますか？ （PRはその方向に歓迎されますか？）

単体テスト、APIミドルウェアの作成、ReduxでのOAuth /ある種のユーザー認証の実行、reduxでのImmutableの使用（セットアップ方法、ベストプラクティスなど）

このシリーズは、Redux、単一原子状態、および関連する哲学の優れた入門書として役立ちます。 私はあなたが認知的過負荷を誘発することを避けながら、コア原則に焦点を合わせるという素晴らしい仕事をしたと思いました。 作業した環境も簡単に複製できるため、実践的な部分がさらに親しみやすくなります。

@gaearonサンプル動画の構造化アクションは、最初から標準の{ type: string, payload: Object }なりたいと思いますか？ ペイロードがアクションオブジェクト自体に配置されるカウンターリストの例について話しています。 { type: string, index: number } 。 これは私にはアンチパターンのように見えます。

サンプル動画の構造化アクションを、最初から標準の{type：string、payload：Object}にしたいと思いますか？ ペイロードがアクションオブジェクト自体に配置されるカウンターリストの例について話しています。 {タイプ：文字列、インデックス：数値}。 これは私にはアンチパターンのように見えます。

それは決してアンチパターンではありません。 これは通常のアクションオブジェクトです。 FSAは問題ありませんが、それは_コンベンション_です。 Redux自体には、この規則に依存したり、この規則から利益を得たりするものはないため、強制したくありません。

人々 source 、元のFluxドキュメントのpayload 、 sourceについてあらゆる種類の魔法のことを考えていました。 彼らは、なぜそれらが存在するのかを理解せず、それらが必要かどうかを注意深く評価することなく、盲目的にこれらのものをコピーしました。 その後、彼らはFluxが複雑で冗長であることに不満を漏らしましたが、実際には多くの場合、冗長な（ただし必須ではない）部分を自分でコピーしました。

これらのレッスンでは、Reduxの重要な部分のみを教えます。 定数を導入しないことに注意してください。なぜなら、人々は定数に集中しすぎて、それらが実際には重要ではないことを見逃しているからです。 文字列にいくつかのタイプミスをした後は、最初からチュートリアルビデオに定数を入れた場合よりも、定数の利点を理解する可能性が高くなります。 FSAのような他の慣習についても同じことが言えると思います。便利だと思うなら、ぜひ使ってください。しかし、レッスンで要求されない場合は、説教しません。

@gaearon OK、

@sompylasar

例は、ビデオチュートリアルよりも規則を表示する方が良いと思います。 例としては、「これらの原則に基づいてコードを構築する方法は次のとおりです」という意見があり、ビデオはそれらの原則自体に関するものです。 これが、さまざまな例でさまざまな規則が表示される理由です。プロジェクトを開始する前に、ほとんどの人はさまざまな例を調べて、さまざまな方法を試してみます。

また、FSAに従わないことについて構造化されていないものはまったくありません。 { type: 'STUFF', id: 1 }は本質的に{ type: 'STUFF', payload: { id: 1 } }より悪くはありません。 それは単に好みと（時には）ツールの慣習の問題です。 アクションオブジェクトをpayload少なくしておけば、操作が難しくなることはありません。

すぐにeggheadでリリースされるいくつかのreduxユニットテストレッスンがあります😄

ダンが最初にクラックするために、Reduxのレッスンをしばらく延期しました。 完全に待つ価値があり、それからいくつか。

「慣用的なReduxでアプリケーションを構築する」は素晴らしい上級コースになります👍

@joelhooks両方とも素晴らしいですね！

jsbinを使用する代わりに、webpackとホットリロードを使用してプロジェクトをセットアップしてください。 これを現実の世界に持ち込んでください。 私はそれがreduxに固有のものではないことを知っていますが、それはうまくいくと思います、そしてあなたはこれを教えるのにふさわしい人です:)

@kevinrenskersはビデオシリーズではありませんが、何かを分析したい場合は、参照できる非常に優れた定型文の例がいくつかあります。

Danの例とWebpack構成のプロジェクト構造を要求した人。

https://github.com/urbanvikingr/todoをチェックして

ビデオのDanのコードに合わせて、ReactドキュメントでReduxを更新することを約束しました。 それは次の2週間以内に完了するでしょう-私のホリデープロジェクト：）-お楽しみに。

Egghead.ioビデオへの私のウィッシュリスト：
ジャスミンによるアクション/レデューサーテスト
ミドルウェアの詳細（サンク/プロミス）

スクリーンキャストは、Reduxの非常に便利な紹介です。 私が聞きたいのは、ルーティングとサーバー側のレンダリングを行うためのReduxの方法です

@grigioルーティングに関するこのディスカッションhttps://github.com/rackt/redux/issues/1145に興味があるかもしれません

@urbanvikingrありがとう、購読しました。 投票は終了したようですが、私は＃1168に投票したでしょう

レッスンは実はかなり良いですが、「店」と言うと「雑用」のように聞こえるのは気が散ります。

ここの誰もがそれに気づき、気を取られています。 彼らはそれを持ち出すにはあまりにも政治的に正しい。 そうそう、他の誰もそうしない場合に備えて、私は_あの_男になることに決めました:)

やがて英語が上手になります。 今のところ、これは私ができる最善のことです;-)

@gaearonあなたはReduxを説明するのにとても良い仕事をしました。 あなたとあなたのオープンソースの成果への称賛。

素晴らしいレッスンセット。 私は特に、「ソースを読む」方法で各コアRedux関数を最初から再実装する方法が好きでした。 チュートリアルとすべてのドキュメントがRedux向けであることに感銘を受けた他の誰かを出向させます。 これまでのところ、誰かが2年間のフロントエンドの進歩に追いついているので、概念は私の心を包み込むのが難しいですが、ドキュメントはそうするのに驚くほど役に立ちました。 それを続けてください、そして感謝します！

（また、 @ jugimasterに耳をわけではありません。）

@ianstormtaylor
ちなみに、それはアクセントではありません:)

私も「気にしない」のですが、気が散っていたのは確かです！

でもその一方で、6つの外国語を勉強している私は、常に正しく言語を話すことを心がけており、そのために、誰かが私の間違いを指摘してくれたことに個人的に感謝しています。

ねえ@gaearon 、

絶対にあなたのコースを愛していました。 よくやった！ とても助かりました。

最近のEggheadコースに3つのReduxテストビデオレッスンを追加しました。
https://egghead.io/series/react-testing-cookbook

私の望みは、彼らがあなたがしたすべての素晴らしい仕事を補完することです！

しっかりしたコース！

Reduxの知識だけでなく、現代の実践の知識全体を向上させます！ そのような良いことを続けてください：+1 ：： tada：

ねえ、ちょうどビデオのコードへのリンク/参照がないことに気づきました。 おそらく明白であり、おそらく、十分に単純なユーザーはビデオをコピーすることができます。 しかし、私は多くの人々がビデオの正確なコードでリポジトリから利益を得ることができると思います-なぜですか？

すべてのレッスンのコードスニペットは、Eggheadサブスクライバーが利用できます。 :-)
ビデオは無料ですが、プラットフォームはお金を稼ぐ必要があるため、より多くのコースに投資したり、インストラクターに機器を送ったり、ビデオをホストしたり、Webサイトを改善したりできます。

つまり、コースにほぼ一致するexamples/todosフォルダーがあります。

...かっこいい、私はそれを逃していますか？ リンクを探しています..。

@gaearonはお詫びします、ちょうどビデオを再訪しました。 コードはすぐそこにあります：）...ビデオを見たり、メンバーシップを購入したり、他の人を見たり...実際にログインしたreduxビデオに戻っただけです。乾杯。

ちなみに、筆記録が不正確だと不満を言う人もいました。
それらを修正するためにPRを送信してください： https ：

@gaearon reduxを使用することにしましたが、eggheadでreduxvidsを見つけました。 ビデオは私がreduxを学び始めるのを本当に助けました。 今後、より多くの実例を見ることができれば素晴らしいと思います。

したがって、今後のreduxビデオトレーニングについての私の提案は、高度な構成、リファクタリングの詳細、そして間違いなく再選択の使用方法です。 いつリファクタリングするかについて直感があるようです。 したがって、関数型プログラミングはreduxと密接に関連しているため、リファクタリングのタイミングと、1つのことをうまく実行する関数を特定する方法についていくつかのヒントを得ることが非常に役立ちます。

私が構築しているアプリには、いくつかの大きなデータコレクションがあり、それらをテーブルに配置して、データの並べ替えやページ付けなどを行う必要があります。 セレクターをいつ使用するか、作成アクションをいつ使用するかを決めるのに苦労しています。 現在、USERS_SORT_TABLEアクションとSORT_TABLEアクションがあります。これは、ユーザーにテーブルからの状態の「継承」を保存させるためです。 これを行ったのは、todoストアでSORT_TABLEアクションをユーザーストアで並べ替えたくないためです。

私の解決策がDRYではないことは知っていますが、正しく行う方法がわかりません。 現状では、テーブルにデータを入力するすべてのストアに対して「SOMETHING」_SORT_TABLEアクションを作成する必要があります。これは間違っていると思いますが、正しい方法がわかりません。 もう1つの副作用は、アクションの名前の前に別のストアを分離する必要があるため、アクション名が大きくなっていることです。 これは正しくありえません。

次にいくつかのサンプルコードを示します。

/* actions.js */
// ...
export const USER_MOVE_COLUMN = 'USER_MOVE_COLUMN'

export function userMoveColumn (columnIndex, moveToIndex) {
  return {
    type: USER_MOVE_COLUMN,
    columnIndex,
    moveToIndex
  }
}

export const DATA_TABLE_MOVE_COLUMN = 'DATA_TABLE_MOVE_COLUMN'
// ...

/* reducers.js */
// ...
export default function user (state=userInitialState, action) {
  switch (action.type) {
    // ...
    case USER_MOVE_COLUMN:
      return dataTable(state, assign(
        action,
        {type: DATA_TABLE_MOVE_COLUMN}
      ))
    // ...
    default:
      return state
  }
}
// ...
export default function dataTable (
  state=dataTableInitialState,
  action,
  key='dataTable')
{
  switch (action.type) {
    // ...
    case DATA_TABLE_MOVE_COLUMN:
      return {
        ...state,
        [key]: {
          ...state[key],
          columns: move(
            state[key].columns, action.columnIndex, action.moveToIndex
          )
        }
      }
    // ...
    default:
      return state
  }
}

したがって、テーブルと「モデル」ストアの間にあるべきではない依存関係を作成したことがわかります（モデルストアは、オブジェクトの配列のコレクションキーを使用する必要があります）。 また、dataTableは、「親」レデューサーの状態を操作しますが、操作するべきではありません。 そこでセレクターを使う必要があると思いましたが、これを書いている時点では、UIに表示されるものを変更するためだけに大きなストアを複製しないように努めていました。

そのため、現在、これらの問題のいくつかを解決するための再選択と、他のいくつかの問題を解決するためのリファクタリング手法を学ぶのに苦労しています。 最初のReduxコースは私を危険にさらすのに十分でした。 今、私はそれを正しく行う方法を学びたいと思います。 :)

それがお役に立てば幸いです。冗長すぎないでください。 明確で正直なフィードバックを提供しようとしています。

私を助けてくれるかもしれないどんな親切な人にとっても、私はすでにダンの別のコメントから/examples/real-world/reducersを見つけました、そして私は現在私が上で概説した問題のいくつかを作り直しています。 私が解決策を見つけたら、助けようとして時間を無駄にしたくありませんでした。

警告をありがとう:)

redux-devtoolsを私のプロジェクトに統合することは私にとって大きな苦痛でした..私はそこに何があり、それをどのように/いつ使用するかを説明するeggheadシリーズを高く評価していました（そして今でもそうします）。 いつ何を使うべきかを説明しているPRを読みましたが、hmr、transform 3、redux hotreloaderはreacthotreloaderなどとは違うものがたくさんあるので混乱しました。

上で概説した問題のいくつかに苦労している他の人のために、Reduxの定型文と名前空間アクションのすべてではないにしてもほとんどを削除できるプロジェクトを作成しました。 ここでそれを参照して

@granteagonこのカップルはアクションクリエーターに

アクション/リデューサーの作成に加えてラッパーまたは抽象化を作成するほとんどの人は、それらが常に直接結合されると想定する傾向があることに注意しました。 確かに、私のアプリでは、これまでのところ、私のアクションの_ほとんど_には、対応する処理ロジックのチャンクが1つだけありますが、ツリーの複数の部分を更新する必要がある場所は確かにいくつかあります。

@ gaearon @ markeriksonそれはアクションクリエーターにレデューサーを結合します。ただし、90％の確率で、それは問題ないか、望ましいことです。残りの10％の時間は、まだ手作業でコーディングされたアプローチを使用できます。私はあなたが言ったことを考え、将来の発展のためにそれを検討します。

@granteagon @gaearon

reduxrに似たローカル抽象化を使用したので、ここに追加の結合はないと主張します。アクションとレデューサーの間で1：1のマッピングを強制するものはありません。同じアクションをリッスンする2つの異なるスライスに2つのレデューサーを含めることができます。

const counterReducersA = {
  // this counter increments by 1 each time
  increment: (state, action) => state + 1
}

const counterReducersB = {
  // this counter increments by 2 each time
  increment: (state, action) => state + 2
}

const counterA = reduxr(counterReducersA, 0);
const counterB = reduxr(counterReducersB, 0);

const rootReducer = combineReducers({
  counterA: counterA.reducer,
  counterB: counterB.reducer
});

store.dispatch(counterA.action.increment());  // increments both counters

もちろん、同じものという名前の「レデューサー」関数が複数ある場合（つまり、同じアクションに応答する場合）、暗黙的に両方がアクションペイロードが特定の形になることを「期待」する必要があります---これは完全に類似していますバニラリダックスに2つのレデューサーがあり、どちらも同じtype定数を処理するため、どちらも同じアクション形状を期待する必要があります。

おそらく、 @ gaearon 、カップリングの意味を誤解しましたか？

サンクの実装を示す前に、ミドルウェアなしで非同期フローを示すことが役立つと思います。

やや関連性がありますが、ドキュメントはめちゃくちゃ役に立ちましたが、非同期フローページのこのステートメントは、後から考えると本当に私を軌道に乗せませんでした。「ミドルウェアがなければ、Reduxストアは同期データフローのみをサポートします。」

@battaile ：それは本当だからです:)ミドルウェアがなければ、非同期は完全にReduxの外で発生する必要があります（したがって、ReactコンポーネントなどのUIレイヤーで発生する可能性があります）。 store.dispatchを呼び出すときはいつでも、アクションはレデューサー関数に直接進み、Goを渡さず、$ 200を収集せず、AJAX呼び出しの途中で停止しません。

ストアエンハンサーを使用すると、 dispatchなどの関数を独自のバージョンでラップできるため、 applyMiddlewareは、実際のストアのdispatch関数に到達する前に、「ミドルウェアパイプライン」の抽象化を提供します。 。 これは基本的に、標準のReduxフローの_内部_で、飛び出して必要な非同期処理を実行できる抜け穴を提供します。

したがって、ミドルウェアがなくても、完全に非同期の処理を実行できます...実際にReduxに関連するものとはまったく別の方法ですべてを実行する必要があります。

それは本当だからです:)

私はそれが間違っているとは言いませんでした、私はそれが私を軌道から外したと言いました:)

私は次のようなことをしたかったのですが、それは私ができなかったことを意味しているように見えました：

const mapDispatchToProps = (dispatch) => ({
  onclick(searchTerm) {
    dispatch(actions.requestOrders(searchTerm));

    return fetch('http://localhost:49984/Order/Search?search=' + searchTerm)
      .then(response => response.json()).then(response => {
        dispatch(actions.receiveOrders(searchTerm, response));
      })
      .catch((err) => {
        dispatch(actions.receiveOrdersError('An error occurred during search: ' + err.message));
      });
  },
});

これは簡単に醜くなる可能性があることはわかっていますが、概念的には見ると便利だと思います。 または、少なくとも私の場合はそうでした。

「ミドルウェアがなければ、Reduxストアは同期データフローのみをサポートする」ことに同意します。 誤解を招くです。

技術的には、「内部」と「外部」を区別したい場合は、この記述は正しいかもしれませんが、非同期を実行する唯一の方法はミドルウェアを追加することであると人々に信じ込ませる場合は、言い換えたり、詳しく説明したりできます。それ。

ええ、違いは、非同期動作が技術的にはdispatch 「内部」ではなく、コンポーネントレベルで発生していることです。 マイナーな違いですが、有効な違いです。

私は、この声明が技術的に正しくないと実際に主張している人はいないと思います。

@markerikson内側と外側の区別が重要な具体的な例があるかどうか、興味がありますか？

1つの例として、チェーン内のミドルウェアが非同期ミドルウェアでディスパッチされたサンク（またはpromiseなど）を認識できるようにする場合があります。 ミドルウェアが何をするかはわかりませんが、そのようなものが必要になるのは現実的だと思います。

うーん...具体的に「具体的な」例についてはよくわかりません。 全体として、「outside」と「insie」の違いは、最初にdispatchを呼び出す前に発生するのか、それとも後に発生するのかという問題です。 それが「外側」で「前」の場合、React、Angular、またはその他のものであるかどうかにかかわらず、すべての非同期性とロジックはビューレイヤーにより密接に関連しています。 「内部」と「後」の場合、非同期性とロジックはストアレベルにあり、ビューレイヤーに関連付けられていません。

これは実際、今日のRedditのディスカッションで私が言おうとしていたポイントの多くです： https ：

「どのようなアクションをディスパッチし、いつディスパッチするのか」という質問。 はビジネスロジックの中核部分であり、残りの半分は「これらのアクションに応じて状態を更新するにはどうすればよいですか？」です。 アクション管理がサンクやサガなどで行われている場合、そのコードがReactコンポーネント、Angularコントローラー、jQueryクリックハンドラー、Vueコンポーネントインスタンスなどによって開始されたかどうかは実際には関係ありません。 コアロジックはUIレイヤーの外側にあり、UIレイヤーは、ストアから必要なデータを取得して表示し、ユーザー入力をアプリロジック関数呼び出しに変換する役割を果たします。

つまり、その意味では、「内部」と「外部」の問題は重要だと思います。これは、ロジックがアプリレベルとUIレベルのどちらで動作しているかを概念的に区別するためです。

@markeriksonこの質問の行に私と一緒にいてくれてありがとう。 議論の余地があると思われるかもしれませんが、これは「アプリレベル」と「UIレベル」の違いであるという考えを少し押し戻したいと思います。

注：便宜上、 thunkを使用して、実際にredux-thunkまたはredux-promiseであるかどうかにかかわらず、非同期へのアブリトラリーミドルウェアアプローチを表します。

UIレイヤーは、ユーザーの操作をハンドラーに接続するだけです。 誰かがボタンをクリックすると、UIは_some_ハンドラーを呼び出すように設定されます。 多くの場合、コンポーネントはこれらのハンドラーを小道具として受け取ります。たとえば、バインドされたアクションの作成者です。 UIは、ハンドラーを呼び出したときに何が起こるかを認識していません---それを呼び出すだけです。

「ハンドラー」が関数をディスパッチするか（ミドルウェアによって処理される）、非同期呼び出しを実行してプレーンアクションをディスパッチするかどうかはUIレイヤーに違いはありません--- UIは完全に不可知論的です（または少なくとも不可知論者になることができます）

サンクを使用しているかどうかに関係なく、「アプリ」の大部分はこれらの「ハンドラー」にあります。 典型的なreact / reduxアプリでは、これらの「ハンドラー」は多くの場合、ある種のアクションクリエーターです。 すべての非同期のものをサンクとして記述し、それらをディスパッチすることができます。 または、すべての非同期のものを、引数としてdispatchを受け入れる関数として記述することもできます。 コンポーネントの観点からは、 someHandler(dispatch)またはdispatch(someHandler())いずれかです。または、バインドされたアクションクリエーターが上から受け継がれる場合は、どちらの場合もsomeHandler()になります。 この違いをUIレイヤーから完全に隠すバージョンのbindActionCreatorsを作成できます。

redux-thunkを使用してアクションクリエーターで作成されたreact / reduxアプリケーションを提供していただければ、UIレイヤーを_基本的に_変更せずに、redux-thunkを完全に交換し、非ミドルウェアアプローチを使用できます。 （注： getStateをどこに/どのように注入するかについては詳しく説明していませんが、ここではそれが小さな詳細であると_信じています_）。

そのため、「内部」と「外部」の区別が「アプリレベル」または「UIレベル」であることを理解するのに苦労しています。

私は議論に感謝します、そして私は私が否定的に出くわさないことを望みます。

このコースは素晴らしいです。 これを締めくくると、人々はコースのコミュニティノートリポジトリにコメントを送ることができます： //github.com/tayiorbeii/egghead.io_redux_course_notes

また、ダンが一緒に置いた次のシリーズもぜひチェックしてください！ https://egghead.io/courses/building-react-applications-with-idiomatic-redux