図書館がすべてを行う方法を規定すべきだと考える罠に陥らないでください。JavaScriptでタイムアウトを使って何かを実行したい場合は、を使用する必要がありますsetTimeout。Reduxのアクションが異なる理由はありません。
Reduxの人はする非同期のものを処理するいくつかの代替方法を提供しますが、コードを繰り返しすぎていることに気付いた場合にのみそれらを使用してください。この問題がない限り、言語が提供するものを使用して、最も簡単な解決策を探してください。
非同期コードをインラインで書く
これは、最も簡単な方法です。そして、ここではReduxに固有のものはありません。
store.dispatch({ type: 'SHOW_NOTIFICATION', text: 'You logged in.' })
setTimeout(() => {
store.dispatch({ type: 'HIDE_NOTIFICATION' })
}, 5000)
同様に、接続されたコンポーネントの内部から：
this.props.dispatch({ type: 'SHOW_NOTIFICATION', text: 'You logged in.' })
setTimeout(() => {
this.props.dispatch({ type: 'HIDE_NOTIFICATION' })
}, 5000)
唯一の違いは、接続されたコンポーネントでは通常、ストア自体にはアクセスできないが、いずれかdispatch()または特定のアクション作成者が小道具として挿入されることです。しかし、これは私たちにとって何の違いもありません。
異なるコンポーネントから同じアクションをディスパッチするときにタイプミスをしたくない場合は、アクションオブジェクトをインラインでディスパッチするのではなく、アクションの作成者を抽出できます。
// actions.js
export function showNotification(text) {
return { type: 'SHOW_NOTIFICATION', text }
}
export function hideNotification() {
return { type: 'HIDE_NOTIFICATION' }
}
// component.js
import { showNotification, hideNotification } from '../actions'
this.props.dispatch(showNotification('You just logged in.'))
setTimeout(() => {
this.props.dispatch(hideNotification())
}, 5000)
または、以前に次のようにバインドしている場合connect()：
this.props.showNotification('You just logged in.')
setTimeout(() => {
this.props.hideNotification()
}, 5000)
これまでのところ、ミドルウェアやその他の高度な概念は使用していません。
非同期アクション作成者の抽出
上記のアプローチは単純なケースではうまく機能しますが、いくつかの問題があることに気付くでしょう：
- 通知を表示したい場所にこのロジックを複製する必要があります。
- 通知にはIDがないため、2つの通知を十分に速く表示すると、競合状態になります。最初のタイムアウトが終了すると、が送出され
HIDE_NOTIFICATION、タイムアウト後よりも早く2番目の通知が誤って非表示になります。
これらの問題を解決するには、タイムアウトロジックを集中化し、これら2つのアクションをディスパッチする関数を抽出する必要があります。次のようになります。
// actions.js
function showNotification(id, text) {
return { type: 'SHOW_NOTIFICATION', id, text }
}
function hideNotification(id) {
return { type: 'HIDE_NOTIFICATION', id }
}
let nextNotificationId = 0
export function showNotificationWithTimeout(dispatch, text) {
// Assigning IDs to notifications lets reducer ignore HIDE_NOTIFICATION
// for the notification that is not currently visible.
// Alternatively, we could store the timeout ID and call
// clearTimeout(), but we’d still want to do it in a single place.
const id = nextNotificationId++
dispatch(showNotification(id, text))
setTimeout(() => {
dispatch(hideNotification(id))
}, 5000)
}
コンポーネントは、showNotificationWithTimeoutこのロジックを複製したり、さまざまな通知で競合状態を発生させたりすることなく使用できるようになりました。
// component.js
showNotificationWithTimeout(this.props.dispatch, 'You just logged in.')
// otherComponent.js
showNotificationWithTimeout(this.props.dispatch, 'You just logged out.')
なぜ最初の引数としてshowNotificationWithTimeout()受け入れるのdispatchですか？ストアにアクションをディスパッチする必要があるためです。通常、コンポーネントはアクセス権を持っていますdispatchが、外部関数がディスパッチを制御できるようにしたいので、ディスパッチを制御できるようにする必要があります。
あるモジュールからシングルトンストアをエクスポートしdispatchた場合、代わりにそれを直接インポートすることができます。
// store.js
export default createStore(reducer)
// actions.js
import store from './store'
// ...
let nextNotificationId = 0
export function showNotificationWithTimeout(text) {
const id = nextNotificationId++
store.dispatch(showNotification(id, text))
setTimeout(() => {
store.dispatch(hideNotification(id))
}, 5000)
}
// component.js
showNotificationWithTimeout('You just logged in.')
// otherComponent.js
showNotificationWithTimeout('You just logged out.')
これは単純に見えますが、このアプローチはお勧めしません。私たちがそれを嫌う主な理由は、ストアをシングルトンにすることを強制するためです。これにより、サーバーレンダリングの実装が非常に困難になります。。サーバーでは、各リクエストに独自のストアを設定して、異なるユーザーが異なるプリロードデータを取得できるようにします。
シングルトンストアもテストを難しくします。特定のモジュールからエクスポートされた特定の実際のストアを参照するため、アクションクリエーターをテストするときにストアを模擬できなくなりました。外部から状態をリセットすることもできません。
したがって、技術的にはモジュールからシングルトンストアをエクスポートできますが、お勧めしません。アプリがサーバーレンダリングを追加しないことが確実でない限り、これを行わないでください。
以前のバージョンに戻す：
// actions.js
// ...
let nextNotificationId = 0
export function showNotificationWithTimeout(dispatch, text) {
const id = nextNotificationId++
dispatch(showNotification(id, text))
setTimeout(() => {
dispatch(hideNotification(id))
}, 5000)
}
// component.js
showNotificationWithTimeout(this.props.dispatch, 'You just logged in.')
// otherComponent.js
showNotificationWithTimeout(this.props.dispatch, 'You just logged out.')
これにより、ロジックの重複に関する問題が解決され、競合状態から解放されます。
サンクミドルウェア
単純なアプリの場合は、このアプローチで十分です。満足できればミドルウェアについて心配する必要はありません。
ただし、大規模なアプリでは、その周りに不便を感じる場合があります。
たとえば、私たちはdispatch周りを回らなければならないのは残念です。これにより、上記の方法で非同期にReduxアクションをディスパッチするコンポーネントは、それをさらに渡すことができるようにプロップとして受け入れる必要があるため、コンテナコンポーネントとプレゼンテーションコンポーネントを分離するのが難しくなりますdispatch。は実際にはアクションクリエーターではないconnect()ため、アクションクリエーターをバインドすることshowNotificationWithTimeout()はできません。Reduxアクションは返しません。
さらに、どの関数が同期アクションの作成者であり、どの関数showNotification()が非同期のヘルパーであるかを覚えておくのは面倒ですshowNotificationWithTimeout()。それらを異なる方法で使用し、それらを互いに間違えないように注意する必要があります。
これが、ヘルパー関数へのこの提供パターンを「正当化」dispatchし、Reduxが完全に異なる関数ではなく、通常のアクションクリエーターの特殊なケースとしてこのような非同期アクションクリエーターを「見る」ための方法を見つける動機でした。
私たちと一緒にいて、アプリの問題としても認識している場合は、Redux Thunkミドルウェアを使用することができます。
要点として、Redux Thunkは、実際に機能する特別な種類のアクションを認識するようReduxに教えています。
import { createStore, applyMiddleware } from 'redux'
import thunk from 'redux-thunk'
const store = createStore(
reducer,
applyMiddleware(thunk)
)
// It still recognizes plain object actions
store.dispatch({ type: 'INCREMENT' })
// But with thunk middleware, it also recognizes functions
store.dispatch(function (dispatch) {
// ... which themselves may dispatch many times
dispatch({ type: 'INCREMENT' })
dispatch({ type: 'INCREMENT' })
dispatch({ type: 'INCREMENT' })
setTimeout(() => {
// ... even asynchronously!
dispatch({ type: 'DECREMENT' })
}, 1000)
})
このミドルウェアが有効な場合、関数をディスパッチすると、Redux Thunkミドルウェアがそれdispatchを引数として提供します。また、そのようなアクションを「飲み込む」ので、リデューサーが奇妙な関数引数を受け取ることを心配する必要はありません。レデューサーは、直接送信されるか、先ほど説明した関数によって発行される、プレーンオブジェクトアクションのみを受け取ります。
これはあまり役に立たないように見えますか？この特定の状況ではありません。ただしshowNotificationWithTimeout()、通常のReduxアクション作成者として宣言できます。
// actions.js
function showNotification(id, text) {
return { type: 'SHOW_NOTIFICATION', id, text }
}
function hideNotification(id) {
return { type: 'HIDE_NOTIFICATION', id }
}
let nextNotificationId = 0
export function showNotificationWithTimeout(text) {
return function (dispatch) {
const id = nextNotificationId++
dispatch(showNotification(id, text))
setTimeout(() => {
dispatch(hideNotification(id))
}, 5000)
}
}
関数が前のセクションで記述したものとほとんど同じであることに注意してください。ただしdispatch、最初の引数として受け入れません。代わりに、最初の引数として受け入れる関数を返しdispatchます。
コンポーネントでどのように使用しますか？間違いなく、これを書くことができます：
// component.js
showNotificationWithTimeout('You just logged in.')(this.props.dispatch)
非同期アクションの作成者を呼び出して、必要なだけの内部関数を取得してから、dispatch渡しdispatchます。
ただし、これは元のバージョンよりもさらに厄介です！なぜ私たちはそのように行ったのですか？
前に言ったので。Redux Thunkミドルウェアが有効になっている場合、アクションオブジェクトではなく関数をディスパッチしようとすると、ミドルウェアはdispatch最初にメソッド自体を使用してその関数を呼び出します。
代わりにこれを行うことができます：
// component.js
this.props.dispatch(showNotificationWithTimeout('You just logged in.'))
最後に、非同期アクション（実際には一連のアクション）のディスパッチは、単一のアクションをコンポーネントに同期的にディスパッチすることと同じように見えます。コンポーネントが何かが同期的または非同期的に発生するかどうかを気にする必要がないため、これは良いことです。それを抽象化しました。
Reduxにそのような「特別な」アクションクリエーター（サンクアクションクリエーターと呼ぶ）を認識するように「教えた」ため、通常のアクションクリエーターを使用する場所ならどこでも使用できることに注意してください。たとえば、次のように使用できますconnect()。
// actions.js
function showNotification(id, text) {
return { type: 'SHOW_NOTIFICATION', id, text }
}
function hideNotification(id) {
return { type: 'HIDE_NOTIFICATION', id }
}
let nextNotificationId = 0
export function showNotificationWithTimeout(text) {
return function (dispatch) {
const id = nextNotificationId++
dispatch(showNotification(id, text))
setTimeout(() => {
dispatch(hideNotification(id))
}, 5000)
}
}
// component.js
import { connect } from 'react-redux'
// ...
this.props.showNotificationWithTimeout('You just logged in.')
// ...
export default connect(
mapStateToProps,
{ showNotificationWithTimeout }
)(MyComponent)
サンクの状態の読み取り
通常、レデューサーには、次の状態を決定するためのビジネスロジックが含まれています。ただし、レデューサーはアクションがディスパッチされた後でのみ起動します。サンクアクションクリエーターに副作用（APIの呼び出しなど）があり、ある条件下でそれを防ぎたい場合はどうしますか？
サンクミドルウェアを使用せずに、コンポーネント内でこのチェックを行うだけです。
// component.js
if (this.props.areNotificationsEnabled) {
showNotificationWithTimeout(this.props.dispatch, 'You just logged in.')
}
ただし、アクション作成者を抽出する目的は、この反復的なロジックを多くのコンポーネントに集中させることでした。さいわい、Redux Thunkを使用すると、Reduxストアの現在の状態を読み取ることができます。に加えてdispatch、getStateサンクアクションの作成者から返す関数の2番目の引数としても渡されます。これにより、サンクはストアの現在の状態を読み取ることができます。
let nextNotificationId = 0
export function showNotificationWithTimeout(text) {
return function (dispatch, getState) {
// Unlike in a regular action creator, we can exit early in a thunk
// Redux doesn’t care about its return value (or lack of it)
if (!getState().areNotificationsEnabled) {
return
}
const id = nextNotificationId++
dispatch(showNotification(id, text))
setTimeout(() => {
dispatch(hideNotification(id))
}, 5000)
}
}
このパターンを乱用しないでください。キャッシュされたデータが利用可能な場合にAPI呼び出しを回避するのに適していますが、ビジネスロジックを構築するための適切な基盤ではありません。を使用getState()して条件付きで異なるアクションをディスパッチする場合は、代わりにビジネスロジックをリデューサーに配置することを検討してください。
次のステップ
サンクがどのように機能するかについて基本的な直感を得たので、サンクを使用するRedux 非同期の例を確認してください。
サンクがプロミスを返す例はたくさんあります。これは必須ではありませんが、非常に便利です。Reduxは、サンクから何を返すかは関係ありませんが、からの戻り値を提供しますdispatch()。これが、サンクからPromiseを返し、を呼び出すことでPromiseが完了するのを待つことができる理由ですdispatch(someThunkReturningPromise()).then(...)。
複雑なサンクアクションクリエーターをいくつかの小さなサンクアクションクリエーターに分割することもできます。dispatchあなたは再帰的にパターンを適用することができるようにサンクによって提供される方法は、自体サンク受け入れることができます。繰り返しになりますが、これに加えて非同期制御フローを実装できるため、これはPromiseで最適に機能します。
アプリによっては、非同期制御フローの要件が複雑すぎて、サンクで表現できない場合があります。たとえば、失敗したリクエストの再試行、トークンを使用した再認証フロー、または段階的なオンボーディングは、この方法で記述した場合、冗長すぎてエラーが発生しやすくなります。この場合、Redux SagaやRedux Loopなどのより高度な非同期制御フローソリューションを検討する必要があります。それらを評価し、ニーズに関連する例を比較して、最も好きなものを選びます。
最後に、本当に必要なものがない場合は（サンクを含む）何も使用しないでください。要件によっては、ソリューションが次のように単純に見える場合があることに注意してください
store.dispatch({ type: 'SHOW_NOTIFICATION', text: 'You logged in.' })
setTimeout(() => {
store.dispatch({ type: 'HIDE_NOTIFICATION' })
}, 5000)
なぜこれをしているのかわからない限り、汗をかいてはいけません。
redux-sagaサンクより良いものが欲しいなら、私の答えをチェックすることを忘れないでください。答えが遅いので、表示される前に長い間スクロールする必要があります。これがショートカットです：stackoverflow.com/a/38574266/82609