4

Flux パターンを理解しようとしています。

優れた設計では、アプリは、特定のアプリケーション ロジックによって結合された、比較的独立した普遍的な (したがって再利用可能な) コンポーネントで構成されるべきだと私は信じています。

Flux には、データとドメイン ロジックをカプセル化するドメイン固有のストアがあります。これらは、同じドメインの別のアプリケーションで再利用される可能性があります。

アプリの状態とロジックを保持するアプリケーション固有のストアもあるはずだと思います。これが接着剤です。

これを架空の「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 では、あるアクションが別のアクションを発生させてはならないと言われています。しかし、これがどのように行われるのかわかりません。

これらはUIに依存しない必要があるため、ユーザーアクションはドメインストアに直接行くことはできないと思います。むしろ、AppState (またはアプリ ロジックが存在する場所) は、ユーザー アクションをドメイン アクションに変換する必要があります。

  1. これをFluxの方法で再設計するにはどうすればよいですか?
  2. アプリケーションロジックはどこに行くべきですか?
  3. ドメイン ストアをアプリ ロジックから独立させようとするのは正しいですか?
  4. 「サービス」の場所はどこですか？

ありがとうございました。

4

1 に答える 1