4

我试图理解通量模式。

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

在 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. “服务”的地方在哪里？

谢谢你。

4

1 回答 1

4

所有应用程序逻辑都应该存在于商店中。他们决定他们应该如何回应特定的行动，如果有的话。

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

行动不是二传手。尽量不要这样想。动作应该简单地报告现实世界中发生的事情：用户以某种方式与 UI 交互，服务器以某种方式响应，等等。

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

调度（STOP_GEOLOCATION）

调度（STOP_TRACKING）

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

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

于 2015-03-30T06:57:25.960 回答