0

タイマーを使用するReduxでライブラリを構築しています。イベントをディスパッチし、タイマー オブジェクトSTART_TIMERも呼び出す必要があるアクション クリエーターがあります。startコードは次のようになります。

// thunk action creator
const startTimer = () => (dispatch, getState) => {
  
  if (!getState().timer.isRunning)
    externalTimerObject.start()

  dispatch({
    type: 'START_TIMER'
  })
  
}

私が解決しようとしている2つの問題があります：

  1. アクションをデータベースまたは localStorage に記録して、それらを再生して一貫したアプリの状態を取得できるようにする場合、それrootState.timer.isRunningが true であっても、タイマー オブジェクトは実行されません。

  2. 条件付きでは、ルート状態のどこにマウントさif (!getState().timer.isRunning)れているかを知っている必要があります。timerこれをライブラリとして構築しているため、timer常にルート状態に直接マウントされるとは限りません。

4

1 に答える 1

1

アクションをデータベースまたは localStorage に記録して、それらを再生して一貫したアプリの状態を取得できるようにする場合、rootState.timer.isRunning が true であっても、タイマー オブジェクトは実行されません。

これは実際には設計上正しいと思います。記録されたログを再現するときは、生成されたアクションに関して、すべてが以前に発生したのとまったく同じように発生する必要があります。

たとえば、アクションの再生中にコンピュータから実際の AJAX 要求を開始するのではなく、過去にそのユーザー セッション中にディスパッチされた、記録された AJAX 応答を再生したい場合があります。

タイマーも同じカテゴリに分類されると思います。Redux の観点からは、アクション履歴は副作用の「結果として」何が起こったかを記述し、アクションを再生するだけでアプリを同じ状態にするのに十分なはずです。実際には再び発火しませんでした。

条件付きの if (!getState().timer.isRunning) では、ルート状態のタイマーがマウントされている場所を知っている必要があります。これをライブラリとして構築しているため、タイマーが常にルート状態に直接マウントされるとは限りません。

ライブラリを構築している場合は、利用可能なサンク ミドルウェアに依存するべきではありません。アクションクリエーターでそれに依存しているようです。正確なユースケースを理解せずにこれ以上言うのは難しいです.

于 2016-04-15T21:44:56.617 に答える