如何避免动作链

Question

我正在尝试理解 Flux 模式。

我相信，在任何好的设计中，应用程序都应该由相对独立且通用（因此可重用）的组件组成，这些组件通过特定的应用程序逻辑粘合在一起。

在 Flux 中有特定领域的 Store 封装数据和领域逻辑。这些可能会在同一域的另一个应用程序中重用。

我认为还应该有特定于应用程序的商店来保存应用程序状态和逻辑。这是胶水。

现在，我尝试将其应用于虚构的“GPS Tracker”应用：

...

当用户点击[Stop Tracking]按钮​​时，对应的ViewController会引发STOP_CLICK。

• AppState.on(STOP_CLICK):

  • dispatch(STOP_GEOLOCATION)
  • dispatch(STOP_TRACKING)

• GeolocationService.on(STOP_GEOLOCATION):

  • stopGPS(); this.on = false; emit('change')

• TrackStore.on(STOP_TRACKING):

  • saveTrack(); calcStatistics(); this.tracking = false; emit('change')
  • dispatch(START_UPLOAD)

所以，我有一个事件滚雪球。

据说在 Flux 中一个 Action 不应该引发另一个 Action。 但我不明白这是怎么做到的。

我认为用户操作不能直接转到域商店，因为这些应该与 UI 无关。 相反，AppState（或应用逻辑所在的任何位置）应该将用户操作转换为域操作。

1. 如何重新设计这种 Flux 方式？
2. 应用程序逻辑应该去哪里？
3. 尝试保持域存储独立于应用程序逻辑是否正确？
4. “服务”的地方在哪里？

谢谢。

Answer 1

所有应用程序逻辑都应该存在于存储中。他们决定应该如何响应特定操作（如果有的话）。

商店没有二传手。进入 store 的唯一方法是通过 dispatch 的 action，通过 store 向 dispatcher 注册的回调。

动作不是设置器。尽量不要这样想。操作应该只是报告现实世界中发生的事情：用户以某种方式与 UI 交互，服务器以某种方式响应某种方式等。

这在我看来很像二传手的想法：

调度（STOP_GEOLOCATION）

调度（STOP_TRACKING）

相反，调度实际发生的事情：STOP_TRACKING_BUTTON_CLICKED（或 TRACKING_STOPPED，如果您想与 UI 无关）。然后让商店弄清楚该怎么做。所有商店都将收到该操作，并且如果需要，他们都可以对其做出响应。您响应两个不同操作的代码应该响应同一个操作。

通常，当我们发现我们想要在一个调度中调度时，我们只需要备份到发生的原始事情并让整个应用程序对此做出响应。