Reduxサンクは、非同期のアクション/リクエストを管理するための信頼できる方法であると読みました。他のアクションによるアクションのディスパッチについてはあまり何もありません。
同期アクションをディスパッチするのはどうですか?サンクアプローチのパフォーマンスの問題はわかりませんが、内部で関数を定義せずに、他のアクションクリエーター内でアクションをディスパッチできますか?
このニーズにはreduxサンクを使用する必要はないようです。
通知の表示と非表示は ineded がサンクの良い使用例のようです。
Davidの答え は、何かに応じていくつかの更新を行う「デフォルト」の方法を説明します。異なる減速機から処理します。ほとんどの場合、これはあなたがやりたいことです。
時々(通知のように)不都合な場合があります。 この質問に対する私の答え で、1つまたは複数のアクションをディスパッチする方法を選択する方法を説明します。
複数のアクションをディスパッチすることを決定した場合doは、コンポーネントから順番に実行するか、Reduxサンクを使用します。 Redux Thunkが不思議に思える場合は、使用する前に 実際の意味を理解してください を実行する必要があります。コードの編成という点でのみメリットがあります。実際には、dispatch()
を2回連続で実行するのと同じです。
とはいえ、Reduxサンクのディスパッチでは、複数のアクションは次のようになります。
function increment() {
return { type: 'INCREMENT' }
}
function incrementTwice() {
return dispatch => {
dispatch(increment())
dispatch(increment())
}
}
store.dispatch(increment())
incrementTwice()(store.dispatch) // doesn’t require redux-thunk but looks ugly
store.dispatch(incrementTwice()) // requires redux-thunk but looks Nice
Reduxサンクを使用しても、パフォーマンスの問題は発生しません。これは、dispatch
を引き渡すことができる関数を呼び出す良い方法であり、必要に応じて何度でも実行できます。
変更を1対1で表明するアクションを考えるのは間違いです。実際、それらは多対多です。すべてのアクションはすべてのリデューサーで呼び出されることに注意してください。
たとえば、1つのアクションで複数の状態変更がトリガーされる場合があります。
function firstReducer(state, action) {
switch (action.type) {
case ACTION_X:
// handle action x
}
}
function secondReducer(state, action) {
switch (action.type) {
case ACTION_X:
// handle action x
}
}
function thirdReducer(state, action) {
switch (action.type) {
case ACTION_X:
// handle action x
}
}
逆に、2つの異なるアクションから同じ状態変化が生じる場合があります。
function firstReducer(state, action) {
switch (action.type) {
case ACTION_X:
case ACTION_Y:
// handle action x and y in the same manner
}
}
2つのアクションを同じ方法で処理するのは奇妙に思えるかもしれませんが、これは単一のレデューサーのコンテキストでのみです。他の減速機は、それらを異なる方法で自由に処理できます。
function secondReducer(state, action) {
switch (action.type) {
case ACTION_X:
// handle action x
case ACTION_Y:
// handle action y
}
}
function thirdReducer(state, action) {
switch (action.type) {
case ACTION_X:
// handle action x
default:
// ignore action y
}
}
この多対多の関係では、アクション階層を作成する必要はありません。複数の同期アクションを実行するアクション作成者がいる場合、コードはより複雑になり、推論するのが難しくなります。