Redux: アクションが耇数のレデュヌサヌに関連しおいる堎合のcombineReducerに関する懞念

䜜成日 2015幎08月21日  Â·  52コメント  Â·  ゜ヌス: reduxjs/redux

私はReact.jsずFluxで構築されたチャットアプリに取り組んでcombineReducer関数が奇劙に芋えたす。 䟋えば

messageStore 、 unreadStore 、 threadStoreずいう3぀のストアがありたす。 そしお、 NEW_MESSAGEず呌ばれるアクションがありたす。 3぀のストアすべおが新しいメッセヌゞで曎新されたす。 Reduxでは、ストアは次のようにcombineReducerず組み合わされたレデュヌサヌです。

message = (state=[], action) ->
  switch action.type
    when NEW_MESSAGE
      state # new state
unread = (state=[], action) ->
  switch action.type
    when NEW_MESSAGE
      state # new state
thread = (state=[], action) ->
  switch action.type
    when NEW_MESSAGE
      state # new state

combineReducer {message, unread, thread}

そのような堎合、レデュヌサヌを分割しおも私の生掻は楜にならないように思えたす。 ただし、immutable-jsで構築された巚倧なストアは、これに察するより良い゜リュヌションかもしれたせん。 お気に入り

initialState = Immutable.fromJS
  message: []
  unread: []
  thread: []

allStore = (store=initialState, action) ->
  switch action.type
    when NEW_MESSAGE
        initialState
        .updateIn ['message'], (messages) -> messages # updated
        .updateIn ['urnead'], (urneads) -> unreads # updated
        .updateIn ['thread'], (threads) -> threads # updated

最も参考になるコメント

このようなアクションの堎合、いく぀かのレデュヌサヌたたはアプリが成長した埌のファむルでそれを維持する必芁がありたす。 珟圚のコヌドベヌスでは、5぀のストアが同じアクションを凊理しおいるのをすでに芋おいたすが、維持するのは少し難しいです。

これが良いか悪いかはアプリによっお異なりたす。 私の経隓では、同じアクションを凊理する倚くのストアたたはReduxレデュヌサヌがあるず、責任が分担され、チヌムの他のメンバヌず衝突するこずなく機胜ブランチで䜜業できるため、実際には非垞に䟿利です。 私の経隓では、1぀の巚倧な突然倉異よりも、無関係の突然倉異を個別に維持する方が簡単です。

しかし、あなたは正しいです、これがあたりうたく機胜しない堎合がありたす。 それらはしばしば次善の状態モデルの症状であるず思いたす。 䟋えば、

堎合によっおは、あるレデュヌサヌが別のレデュヌサヌのデヌタに䟝存するこずがありたすメッセヌゞを未読からメッセヌゞに移動したり、メッセヌゞを新しいスレッドずしおメッセヌゞからスレッドに昇栌させたりするなど。

問題の症状です。 状態内で物をたくさん移動する必芁がある堎合は、状態の圢状をより正芏化する必芁があるかもしれたせん。 代わりの{ readMessages, unreadMessages }あなたが持぀こずができたす{ messagesById, threadsById, messageIdsByThreadIds } 。 メッセヌゞを読んだ いいでしょう、 state.messagesById[id].isRead切り替えたす。 スレッドのメッセヌゞを読みたいですか state.threadsById[threadId].messageIdsから、 messageIds.map(id => state.messagesById[id])たす。

デヌタが正芏化されおいる堎合、ある配列から別の配列にアむテムをコピヌする必芁はありたせん。 ほずんどの堎合、フラグを反転したり、IDを远加/削陀/関連付け/関連付け解陀したりしたす。

党おのコメント52件

この堎合、 combineReducersが圹に立たないず思う理由を詳しく説明しおいただけたすか 実際、デヌタベヌスのような状態の堎合、単䞀のレデュヌサヌ次に、遞択されたアむテムなど、UI状態甚の他のレデュヌサヌが必芁になるこずがよくありたす。

参照

https://github.com/rackt/redux/tree/master/examples/real-world/reducers
https://github.com/rackt/redux/blob/master/examples/async/reducers

むンスピレヌションのために。

あなたが指摘した最初の䟋は私の堎合ず䌌おおり、 requestTypeは䞡方のレデュヌサヌで凊理されたす。
https://github.com/rackt/redux/blob/master/examples/real-world/reducers/paginate.js#L28

レデュヌサヌを分割するず、2぀のレデュヌサヌが他のレデュヌサヌから分離されおいる堎合の保守が容易になりたす。 しかし、圌らが同じ行動をずっおいるずき、それは次のこずに぀ながりたす

  • このようなアクションの堎合、いく぀かのレデュヌサヌたたはアプリが成長した埌のファむルでそれを維持する必芁がありたす。 珟圚のコヌドベヌスでは、5぀のストアが同じアクションを凊理しおいるのをすでに芋おいたすが、維持するのは少し難しいです。
  • 堎合によっおは、あるレデュヌサヌが別のレデュヌサヌのデヌタに䟝存するこずがありたすたずえば、メッセヌゞをunreadからmessageに移動したり、メッセヌゞを新しいスレッドずしおmessageからthread昇栌させたりしたす。

これらの2぀の問題に察する適切な解決策は芋圓たりたせん。 実際、これら2぀の問題に぀いおは完党にはわかりたせんが、トレヌドオフのようなものです。

このようなアクションの堎合、いく぀かのレデュヌサヌたたはアプリが成長した埌のファむルでそれを維持する必芁がありたす。 珟圚のコヌドベヌスでは、5぀のストアが同じアクションを凊理しおいるのをすでに芋おいたすが、維持するのは少し難しいです。

これが良いか悪いかはアプリによっお異なりたす。 私の経隓では、同じアクションを凊理する倚くのストアたたはReduxレデュヌサヌがあるず、責任が分担され、チヌムの他のメンバヌず衝突するこずなく機胜ブランチで䜜業できるため、実際には非垞に䟿利です。 私の経隓では、1぀の巚倧な突然倉異よりも、無関係の突然倉異を個別に維持する方が簡単です。

しかし、あなたは正しいです、これがあたりうたく機胜しない堎合がありたす。 それらはしばしば次善の状態モデルの症状であるず思いたす。 䟋えば、

堎合によっおは、あるレデュヌサヌが別のレデュヌサヌのデヌタに䟝存するこずがありたすメッセヌゞを未読からメッセヌゞに移動したり、メッセヌゞを新しいスレッドずしおメッセヌゞからスレッドに昇栌させたりするなど。

問題の症状です。 状態内で物をたくさん移動する必芁がある堎合は、状態の圢状をより正芏化する必芁があるかもしれたせん。 代わりの{ readMessages, unreadMessages }あなたが持぀こずができたす{ messagesById, threadsById, messageIdsByThreadIds } 。 メッセヌゞを読んだ いいでしょう、 state.messagesById[id].isRead切り替えたす。 スレッドのメッセヌゞを読みたいですか state.threadsById[threadId].messageIdsから、 messageIds.map(id => state.messagesById[id])たす。

デヌタが正芏化されおいる堎合、ある配列から別の配列にアむテムをコピヌする必芁はありたせん。 ほずんどの堎合、フラグを反転したり、IDを远加/削陀/関連付け/関連付け解陀したりしたす。

それを詊しおみたいです。

reduxを詊すためのデモペヌゞを䜜成したした。 combineReducerは私にかなりの耇雑さをもたらしたず思いたす。 たた、リポゞトリ内のすべおの䟋でcombineReducerを䜿甚しおいたすが、デヌタを含むJavaScriptオブゞェクトではなく、単䞀の䞍倉デヌタオブゞェクトをモデルずしお䜿甚できる可胜性はありたすか

@jiyinyiyongあなたが話しおいる耇雑さは本圓にcombineReducers䜿甚しないでください。 それはただのヘルパヌです。 代わりにImmutableを䜿甚する同様のヘルパヌを確認し

私は䞻にImmutable.jsをサポヌトするために独自のcombineReducers()ヘルパヌを䜜成したしたが、ルヌトレデュヌサヌのように扱われる远加のレデュヌサヌが必芁になる堎合がありたす。
https://github.com/jokeyrhyme/wow-healer-bootcamp/blob/master/utils/combineReducers.js

最初の匕数は状態の圢状ず䞀臎し、最䞊䜍のサブ状態を、指定した䞀臎するサブレデュヌサヌに枡したす。 これは、公匏バヌゞョンずほが同じです。

ただし、0個以䞊の远加匕数を远加するこずはオプションであり、これらは他のルヌトレデュヌサヌず同様に扱われたす。 これらのレデュヌサヌは完党な状態に枡されたす。 これにより、掚奚されるサブリデュヌサヌパタヌンよりも倚くのアクセスを必芁ずする方法でアクションをディスパッチできたす。

これを悪甚するのは明らかに良い考えではありたせんが、耇数のサブレデュヌサヌず耇数のルヌトレデュヌサヌがあるず䟿利な奇劙なケヌスを芋぀けたした。

おそらく、耇数のルヌトレデュヌサヌを远加する代わりに、䞭間のステップでは、远加の匕数を䜿甚しお、より広いアクセスただ合蚈アクセスより少ないを必芁ずするサブレデュヌサヌを定矩するこずができたす。 䟋えば

function a (state, action) { /* only sees within a */ return state; }
function b (state, action) { /* only sees within b */ return state; }
function c (state, action) { /* only sees within c */ return state; }

function ab (state, action) { /* partial state containing a and b */ return state; }
function bc (state, action) { /* partial state containing b and c */ return state; }

let rootReducer = combineReducers(
  { a, b, c },
  [ 'a', 'b', ab ],
  [ 'b', 'c', bc ]
);

郚分レデュヌサヌず远加のルヌトレデュヌサヌのPRを提出する䟡倀はありたすか これは恐ろしい考えですか、それずも他の十分な人々に圹立぀可胜性があるものですか

ハロゲンずニレがこれらの問題にどのように察凊しおいるかを知りたいず思いたす。 JavaScriptはいく぀かのプログラム図が混圚しおおり、さたざたな方法で私たちを導きたす。 FRPず単方向のデヌタフロヌのどちらが正しいのか混乱しおいたす。

これは私にずっおも混乱のポむントであるこずがわかりたした。 ここに私のナヌスケヌス/゜リュヌションを投皿するだけです。

3぀の異なるリ゜ヌスタむプクラむアント、プロゞェクト、ゞョブの配列を凊理する3぀のサブリデュヌサヌがありたす。 クラむアント REMOVE_CLIENT を削陀するず、関連するすべおのプロゞェクトずゞョブを削陀する必芁がありたす。 ゞョブはプロゞェクトを通じおクラむアントに関連付けられおいるため、ゞョブリデュヌサヌは、結合ロゞックを実行するためにプロゞェクトにアクセスできる必芁がありたす。 ゞョブリデュヌサヌは、削陀するクラむアントに属するすべおのプロゞェクトIDのリストを取埗しおから、䞀臎するゞョブをストアから削陀する必芁がありたす。

私は次のミドルりェアでこの問題を回避したした

export default store => next => action => {
  next({ ...action, getState: store.getState });
}

そのため、すべおのアクションがaction.getState()介しおルヌトストアにアクセスできたす。

@ rhys-vdwありがずうございたす 本圓に圹立぀ミドルりェア:)

@ rhys-vdwこれをありがずう–玠晎らしい解決策のようです。 ゚ッゞケヌス/参照敎合性をどのように凊理したすか。たずえば、゚ンティティが2぀たたはそれ以䞊の他の゚ンティティによっお共有されおいる堎合や、削陀䞭に存圚しないレコヌドを指しおいる堎合などです。 これに぀いおのあなたの考えを聞くこずに熱心です。
@gaearon Reduxには、正芏化された゚ンティティのこの皮の参照敎合性の問題を解決する方法が文曞化されおいたすか

特定の方法はありたせん。 スキヌマを定矩し、このスキヌマに基づいおレデュヌサヌを生成するこずで、これを自動化できるず思いたす。 そうすれば、物が削陀されたずきに「ゎミ」を集める方法を「知っおいる」でしょう。 ただし、これはすべお非垞に手䜜業で波打っおいお、実装䜜業が必芁です:-)。 個人的には、削陀が実際のクリヌンアップを正圓化するほど頻繁に行われるずは思いたせん。 私は通垞、モデルのstatusフィヌルドを反転し、削陀されたアむテムを遞択するずきに衚瀺されないようにしたす。 たたは、もちろん、䞀般的な操䜜でない堎合は、削陀時に曎新できたす。

@gaearon超高速返信に也杯。 ええ MongoのようなドキュメントベヌスのDBで参照を䜿甚する堎合、参照敎合性を凊理するのず同じ努力をしおいるず思いたす。 私は挂っ任意のごみ実䜓なしで玔粋な状態を持っおいるいずれかの䟡倀があるず思いたす。 特に州にCRUDオペレヌションがたくさんある堎合、これらのゎヌスト゚ントリがあなたを぀たずかせる可胜性があるかどうかはわかりたせん。

ただし、 Reduxが正芏化された゚ンティティず埋め蟌たれた゚ンティティの䞡方をサポヌトしおいれば゚ヌスになるず思いたす。 そしお、目的に合った戊略を遞ぶこずができたす。 しかし、埋め蟌み゚ンティティの堎合、Reduxのドキュメントによるずアンチパタヌンであるnested reducersを䜿甚する必芁があるず思いたす。

レデュヌサヌでストアの残りの状態にアクセスするのは難しいこずがわかりたした。 ネストされたcombineReducersを䜿甚するのが非垞に難しい堎合がありたす。 .parent()や.root()など、州の残りの郚分にアクセスする方法があるず䟿利です。

レデュヌサヌ内の他のレデュヌサヌの状態にアクセスするこずは、ほずんどの堎合アンチパタヌンです。
通垞、次の方法で解決できたす。

  • そのロゞックをレデュヌサヌから削陀し、セレクタヌに移動したす。
  • アクションに远加情報を枡す。
  • ビュヌコヌドに2぀のアクションを実行させたす。

ありがずう 私はそれに同意したす。 ルヌト状態をレデュヌサヌに枡そうずした埌、より耇雑になったこずがわかりたした:-)

ええ、ルヌト状態を枡す際の問題は、レデュヌサヌが互いの状態圢状に結合されるようになり、状態構造のリファクタリングや倉曎が耇雑になるこずです。

さお、私は正芏化された状態を持぀こずの利点をはっきりず芋お、私の状態のredux郚分をDBのように扱いたす。

@gaearon 削陀のフラグを立おる゚ンティティたたは@ rhys-vdwのアプロヌチ参照を解決しお関連する参照を削陀するの方が優れおいるかどうかはただ考えおいたす。

アむデア/珟実䞖界の経隓はありたすか

reduxがelmに䌌おいお、状態が正芏化されおいない堎合は、レデュヌサヌを状態の圢状から切り離すこずが重芁です。 ただし、状態は正芏化されおいるため、レデュヌサヌはアプリの状態の他の郚分にアクセスする必芁があるようです。

レデュヌサヌはアクションに䟝存するため、レデュヌサヌはすでにアプリケヌションに掚移的に結合されおいたす。 別のreduxアプリケヌションでレデュヌサヌを簡単に再利甚するこずはできたせん。

状態アクセスをアクションにプッシュし、ミドルりェアを䜿甚するこずで問題を回避するこずは、リデュヌサヌがルヌト状態に盎接アクセスできるようにする、はるかに醜い圢匏の結合のように芋えたす。 これで、通垞はそれを必芁ずしないアクションも状態の圢状に結合され、レデュヌサヌよりも倚くのアクションがあり、倉曎する堎所が倚くなりたす。

状態をビュヌに枡しおアクションに倉換する方が、状態の圢状の倉化をより適切に分離できたすが、機胜が远加されるずきに远加の状態が必芁な堎合は、倚くのアクションを曎新する必芁がありたす。

レデュヌサヌがルヌト状態にアクセスできるようにするIMHOは、珟圚の回避策よりも党䜓的な結合が少なくなりたす。

@kurtharriger 䞀般的な掚奚パタヌンはドメむンごずにRedux状態を構造化するこずですが、 combineReducersを䜿甚しお各ドメむンを個別に管理するこずをお勧めしたす。 状態党䜓を特定のサブレデュヌサヌ関数に枡すなど、さたざたな方法で管理する独自のトップレベルレデュヌサヌを䜜成するこずは完党に可胜です。 最終的に、実際には_one _レデュヌサヌ関数しかなく、内郚でどのように分解するかは完党にあなた次第です。 combineReducersは、䞀般的なナヌスケヌスに圹立぀ナヌティリティです。

ビゞネスロゞックの分割に関するReduxFAQの回答にも、このトピックに関するいく぀かの良い議論がありたす。

はい、別のオプションは、1぀の巚倧な関数で単䞀のレデュヌサヌを䜿甚するか、組み蟌みの関数を䜿甚するのではなく、独自のcombineReducer関数を䜜成するこずです。
ルヌト状態匕数を远加するcombineReducersメ゜ッドが組み蟌たれおいるず䟿利ですが、この機胜を远加しようずしたPRは、アンチパタヌンずしおクロヌズされおいたす。 私は、IMHOが提案した代替案がはるかに党䜓的な結合をもたらすずいう点を䞻匵したかっただけであり、おそらくこれはアンチパタヌンず芋なされるべきではありたせん。 たた、ルヌト状態が远加の匕数ずしお远加された堎合、匷制的に䜿甚するのずは異なり、カップリングはオプトむンのたたです。

この結合を明瀺的にする必芁がありたす。 手動で行うず明瀺的であり、文字通りN行のコヌドです。Nはレデュヌサヌの数です。 CombineReducersを䜿甚せず、その芪レデュヌサヌを手動で蚘述しおください。

私はredux / reactに䞍慣れですが、謙虚にこれを尋ねたすお互いの状態にアクセスする構成されたレデュヌサヌが状態圢状の異なる領域間の結合を远加するためにアンチパタヌンである堎合、この結合はすでにmapStateToPropsで行われおいるず䞻匵したすのconnect。その関数はルヌト状態を提䟛し、コンポヌネントはどこからでもどこからでもプルしお小道具を取埗するためです。

状態サブツリヌをカプセル化する堎合、コンポヌネントは、それらのサブツリヌを非衚瀺にするアクセサヌを介しお状態にアクセスする必芁がありたす。これにより、これらのスコヌプの内郚の状態圢状をリファクタリングせずに管理できたす。

reduxを孊ぶに぀れお、アプリの長期的な問題であるず私が想像しおいるこずに苊劎しおいたす。これは、アプリ党䜓の状態の圢状が、レデュヌサヌではなくmapStateToPropsによっお緊密に結合されおいるこずです。たずえば、コメントサむドバヌを知る必芁がありたす。 authナヌザヌの名前たずえば、コメントリデュヌサヌずauthレデュヌサヌによっおそれぞれ瞮小されたす。mapStateToPropsでも、この皮のカプセル化を行うアクセサヌメ゜ッドですべおの状態アクセスをラップするこずを詊みおいたすが、間違っおいるように感じたす。朚。

@jwhiting これは、「セレクタヌ関数」を䜿甚しお、特にmapStateToPropsで、状態から必芁なデヌタを抜出するいく぀かの目的の1぀です。 state.some.nested.fieldがどこにあるかを実際に知る必芁がある堎所が最小限になるように、圢状の状態を非衚瀺にするこずができたす。 ただご芧になっおいない堎合は、 Computing DerivedDataセクションをご芧ください。

ええ。 たた、デヌタ量が少ない堎合は再遞択を䜿甚する必芁はありたせんが、手曞きのセレクタヌを䜿甚したす。 このアプロヌチのshopping-cart䟋を確認しおください。

@markerikson @gaearonそれは理に

すべおのコヌドを単䞀のレデュヌサヌに保持するこずは、
懞念。 レデュヌサヌがルヌトによっお呌び出される堎合は、手動で呌び出すこずができたす
私があなたの提案だず思うように、ルヌト状態を明瀺的に枡したすが、
芪レデュヌサヌ階局には、それをリッピングする必芁があるcombineReducersが含たれおいたす
アりト。 だから、あなたがそれをリッピングする必芁がないように、それをもっず可胜にしたせんか
埌で出かけるか、ほずんどの人がそうするようにサンクに頌りたすか
827 PMゞョシュ・ホワむティングの土曜、2016幎4月16日には[email protected]
曞きたした

@markerikson https://github.com/markerikson @gaearon
https://github.com/gaearonそれは理にかなっおい
ありがずうございたした。 それ以倖の堎合は、mapStateToPropsでセレクタヌを䜿甚したす
コンポヌネントの䞻な関心事たたはおそらくすべおの州のアクセスはシヌルドしたす
異質な状態の圢状の倉化からのコンポヌネント。 方法を芋぀けたい
ただし、私のプロゞェクトで状態のカプセル化をより厳密に実斜するために、
コヌドの芏埋だけがそれを守るものではなく、歓迎したす
そこに提案。

—
あなたが蚀及されたのであなたはこれを受け取っおいたす。
このメヌルに盎接返信するか、GitHubで衚瀺しおください
https://github.com/reactjs/redux/issues/601#issuecomment -210940305

@kurtharriger レデュヌサヌロゞックの最埌のビットをすべお1぀の関数に保持するこずは悪い考えであり、䜜業を䜕らかの方法でサブ関数に委任する必芁があるこずに同意したす。 ただし、それを行う方法に぀いおは誰もが異なるアむデアを持ち、独自のアプリケヌションに察する異なるニヌズがありたす。 Reduxは、䞀般的なナヌスケヌスの組み蟌みナヌティリティずしおcombineReducersを提䟛するだけです。 珟圚存圚するナヌティリティを䜿甚したくない堎合は、䜿甚する必芁はありたせん。すべおを手動で䜜成する堎合でも、独自のcombineReducersのバリ゚ヌションを䜜成する堎合でも、レデュヌサヌを独自の方法で構成するこずは倧歓迎です。

パタヌンず関心の分離に぀いお話しおいるので、私は実際に関連する䜕かに遭遇しおいたすが、代わりにアクションがありたす。

぀たり、あちこちで芋かけるajax shouldFetchパタヌンは、状態の圢ず密接に結び぀いおいるようです。 たずえば、ここでは。 その䟋では、レデュヌサヌを再利甚しおも、状態のルヌトに゚ンティティオブゞェクトがない堎合はどうなりたすか その堎合、そのアクションは倱敗したす。 ここでの掚奚事項は䜕ですか ケヌス固有のアクションを远加する必芁がありたすか たたはセレクタヌを受け入れるアクション

@shadowiiアクションクリ゚ヌタヌにセレクタヌをむンポヌトさせるこずは私には問題ないようです。 セレクタヌずレデュヌサヌを同じ堎所に配眮しお、状態の圢状に関する知識がそれらのファむルにロヌカラむズされるようにしたす。

異なるレデュヌサヌが同じアクションタむプを凊理するこずの問題は䜕ですか
たずえば、 accountずauthレデュヌサヌがある堎合、どちらもLOGIN_SUCCESSアクションタむプペむロヌドに認蚌トヌクンずアカりントデヌタを含むを凊理したす。 1぀は、管理する状態のスラむスのみを曎新したす。 アクションが州のさたざたな郚分に圱響を䞎えるずきに、このアプロヌチを䜕床も䜿甚しおいるこずに気づきたした。

異なるレデュヌサヌが同じアクションタむプを凊理するこずの問題は䜕ですか

問題はありたせん、それは非垞に䞀般的で䟿利なパタヌンです。 実際、それは_reason_アクションが存圚するこずです。アクションがレデュヌサヌ11にマップされおいる堎合、アクションを持぀こずにはほずんど意味がありたせん。

@ rhys-vdw投皿したミドルりェアを䜿っおみたした。

customMiddleare.js

const customMiddleware =  store => next => action => {
  next({ ...action, getState: store.getState });
};

そしお私の店の䜜成で私は持っおいたす

import customMiddleware from './customMiddleware';

var store = createStore(
        rootReducer,
        initialState,
        applyMiddleware(
            reduxPromise,
            thunkMiddleware,
            loggerMiddleware,
            customMiddleware
        )
    );
return store;

次の゚ラヌが発生したす

applyMiddleware.jsee1549 Uncaught TypeErrorミドルりェアは関数ではありたせん 
匿名関数@ applyMiddleware.jsee1549
匿名関数@ applyMiddleware.jsee1548
createStore @ createStore.jsfe4c65
configureStore @ configureStore.js ffde45
匿名関数@ index.jsxfdd725
匿名関数@ bundle.js1639
webpack_require @ bundle.js556
fn @ bundle.js87無名関数@ bundle.js588
webpack_require @ bundle.js556
匿名関数@ bundle.js579
匿名関数@ bundle.js582

@ mars76 䜕かを正しくむンポヌトしおいない可胜性がありたす。 それが本圓にcustomMiddleware.js内容党䜓である堎合は、_anything_を゚クスポヌトしおいたせん。 䞀般に、4぀のミドルりェアをapplyMiddlewareに枡したすが、おそらくそのうちの1぀は有効な参照ではありたせん。 戻っお、それらをすべお削陀し、䞀床に1぀ず぀再床远加し、どれが無効であるかを確認しお、その理由を理解したす。 むンポヌトステヌトメントず゚クスポヌトステヌトメントを確認したり、初期化の方法を再確認したりしたす。

こんにちは、

ありがずう@markerikson

構文を次のように倉換したしたが、今は問題ありたせん。

customMiddleware.js

export function customMiddleware(store) { return function (next) { return function (action) { next(Object.assign({}, action, { getState: store.getState })); }; }; } console.log(customMiddleware);

ただし、アクションクリ゚ヌタヌ自䜓レデュヌサヌではないでストアにアクセスしようずしおいたす。 非同期呌び出しを行う必芁があり、さたざたなレデュヌサヌによっお管理されおいるストアの状態のさたざたな郚分を枡す必芁がありたす。

これが私がしおいるこずです。 これが正しいアプロヌチかどうかわからない。

デヌタを䜿甚しおアクションをディスパッチし、レデュヌサヌ内で状態党䜓にアクセスできるようになりたした。必芁な郚分を抜出しおオブゞェクトを䜜成し、このデヌタを䜿甚しお別のアクションをディスパッチしたす。これは、アクションクリ゚ヌタヌで利甚できたす。そのデヌタを䜿甚しおAsyn呌び出しを行っおいたす。

私の最倧の懞念は、レデュヌサヌがアクションクリ゚ヌタヌメ゜ッドを呌び出しおいるこずです。

コメントに感謝したす。

ありがずう

@ mars76 繰り返しになりたすが、Reducer内からディスパッチしようずしないでください。

アクションクリ゚ヌタヌ内のストアにアクセスするには、 redux-thunkミドルりェアを䜿甚できたす。 たた、レデュヌサヌ間でのデヌタ共有に関するFAQの質問や、䞀般的なサンクの䜿甚䟋をいく぀か

どうもありがずう@markerikson。

私の悪い。redux-thunkのgetStateに぀いお気づかなかった。 それは私の仕事をはるかに簡単にし、私のレデュヌサヌを玔粋なたたにしたす。

@gaearonは、アクションクリ゚ヌタヌにセレクタヌをむンポヌトさ蚀ったずき、セレクタヌぞのハンドオフのために状態党䜓がアクションクリ゚ヌタヌに枡されるこずを念頭に眮いおいたしたか、それずも䜕かが足りたせんか

@tacomanator 

ほずんどの堎合、アクションクリ゚ヌタヌでセレクタヌを䜿甚しおいる堎合は、サンク内でセレクタヌを䜿甚しおいたす。 サンクはgetStateにアクセスできるため、状態ツリヌ党䜓にアクセスできたす。

import {someSelector} from "./selectors";

function someThunk(someParameter) {
    return (dispatch, getState) => {
        const specificData = someSelector(getState(), someParameter);

        dispatch({type : "SOME_ACTION", payload : specificData});    
    }
}

@markeriksonありがずう、それは理にかなっおいたす。 参考たでに、私が尋ねおいる理由は、レデュヌサヌにディスパッチするのではなく、セレクタヌによっお掟生したデヌタを怜蚌ビゞネスロゞックに䜿甚するこずですが、それは私に思考の糧を䞎えおくれたす。

レデュヌサヌを1぀にたずめるために䜿甚した簡単なハックは

const reducers = [ reducerA, reducerB, ..., reducerZ ];

let reducer = ( state = initialState, action ) => {
    return reducers.reduce( ( state, reducerFn ) => (
        reducerFn( state, action )
    ), state );
};

ここで、 reducerAからreducerZは、個々のレデュヌサヌ関数です。

@brianpkelley https://github.com/acdlite/reduce-reducersです。

@markeriksonああ、初めおreact / redux / etcを䜿甚しお、この問題を調べおいるずきにこのスレッドを芋぀けたした。 笑の半分くらいで最埌たでスキップしたした

ええ、確かに。

参考たでに、 FAQを読むこずをお勧めしたすレデュヌサヌの構造化」セクション。 たた、私の「Practical Redux」チュヌトリアルシリヌズには、いく぀かの高床なレデュヌサヌテクニックを瀺す投皿がいく぀かありたすパヌト7ずパヌト8を参照。

redux-logicを䜿甚するずきの私の2セントは、 transform関数のルヌト状態からのアクションを拡匵するこずです。

䟋

const formInitLogic = createLogic({
  type: 'FORM_INIT',
  transform({ getState, action }, next) {
    const state = getState();
    next({
      ...action,
      payload: {
        ...action.payload,
        property1: state.branch1.someProperty > 5,
        property2: state.branch1.anotherProperty + state.branch2.yetAnotherProperty,
      },
    });
  },
});

私はそれがコヌド構造に぀いおだず思いたす
「サブステヌトアクションに盎接アクセスしないでください」
倚くのプロゞェクトでreduxを䜿甚した埌、最良のコヌド構造は、すべおのサブ状態を完党に分離されたコンポヌネントずしお凊理するこずであるこずがわかりたした。これらのコンポヌネントのすべおに独自のフォルダヌずロゞックがあり、このアむデアを実装するには、次のファむル構造を䜿甚したす。

  • reduxルヌト

    • reducers.js exportは、すべおの状態のレデュヌサヌを結合したす

    • middleware.jsはすべおのミドルりェアにapplyMiddlewareを゚クスポヌトしたす

    • configureStore.js createStore usingreducers.js、middleware.js

    • 状態フォルダからアクションをディスパッチするactions.js゚クスポヌトアクション<==これ

    • state1

    • initial.jsこのファむルには初期状態が含たれおいたすレコヌドを䜜成するために䞍倉を䜿甚したす

    • action-types.jsこのファむルにはアクションタむプが含たれおいたす私はdachoをキヌミラヌずしお䜿甚しおいたす

    • アクション.jsこのファむルには状態アクションが含たれおいたす

    • reducer.jsこのファむルには状態レデュヌサヌが含たれおいたす

    • state2

    • initial.js

    • action-types.js

      ...。

どうしお 
1-すべおのアプリケヌションには2皮類のアクションがありたす。

  • 状態アクションredux / state1 /アクション.jsこれらのアクションは状態を倉曎するだけの責任がありたす。これらのアクションを盎接起動するべきではありたせん。垞にアプリアクションを䜿甚しおください

    • アプリアクションredux / actions.jsこれらのアクションは、いく぀かのアプリロゞックを実行する責任があり、状態アクションを起動できたす

2-さらにこの構造を䜿甚するず、フォルダをコピヌしお貌り付け、名前を倉曎するだけで新しい状態を䜜成できたす;

2぀のレデュヌサヌが同じプロパティを倉曎する必芁がある堎合はどうですか

異なるファむルに分割したいレデュヌサヌがあり、「゚ラヌ」ず呌ばれるプロパティがあるずしたしょう。これは、䜕らかの理由でhttpリク゚ストが倱敗したずきに倉曎したす。

ある時点でレデュヌサヌが倧きくなったので、いく぀かのレデュヌサヌに分割するこずにしたしたが、それらすべおでその「゚ラヌ」プロパティを倉曎する必芁がありたす。

じゃあ䜕

@ Wassap1242぀のレデュヌサヌが同じ状態を管理するこずはできたせん。 2぀のアクションで同じプロパティを倉曎する必芁があるずいうこずですか

詳现がなければ、サンクを䜿甚しお「゚ラヌの蚭定」アクションをディスパッチするこずをお勧めしたす。

@ rhys-vdwかなり長いレデュヌサヌを分割しようずしお少し立ち埀生しおいたす。
そしお、あなたの提案に関しお、それは副䜜甚がないずいう芏則ず矛盟したせんか

@ Wassap124 、@ rhys-vdw明確にするために、 combineReducersのみを䜿甚しおいる堎合、2぀のレデュヌサヌが同じ状態を管理するこずはできたせん。 ただし、独自のナヌスケヌスに合わせお他のレデュヌサヌロゞックを䜜成するこずもできたす。https//redux.js.org/recipes/structuringreducers/beyondcombinereducersを参照しお

クむック゜ヌスケむビングを行う堎合...

combineReducersは、次のような関数シグネチャを返したす。

return function combination(state = {}, action) {

https://github.com/reduxjs/redux/blob/master/src/combineReducers.js#L145を参照しお

実際のレデュヌサヌオブゞェクトを参照するクロヌゞャを䜜成した埌。

したがっお、ストレヌゞから状態をハむドレむトしおリロヌドする必芁がある堎合にアクションをグロヌバルに凊理するために、そのような単玔なものを远加できたす。

const globalReducerHandler = () => {
  return (state = {}, action) => {
    if (action.type === 'DO_GLOBAL_THING') {
      return globallyModifyState(state)
    }
    return reducers(state, action)
  }
}

これはアンチパタヌンである堎合ずそうでない堎合がありたすが、実甚䞻矩は垞により重芁です。

別のレデュヌサヌからレデュヌサヌを呌び出す代わりにglobalReducerHandlerは呌び出すレデュヌサヌずは関係がないためアンチパタヌンです、 reduceReducers䜿甚したす。これは基本的にレデュヌサヌの堎合はcomposeですたあ、文字通り(Action ->)モナドの構成。

このペヌゞは圹に立ちたしたか
0 / 5 - 0 評䟡