31

AngularJS の実践経験が豊富な開発者として、React を使用して Flux で Web アプリを作成するメンタル モデルを調整するにはどうすればよいですか?

私は Flux+React とAngularの答えを探しているわけではありません (すでにオンラインでたくさんあります) が、2 つの「考え方」の最大の違いは何かを知りたいです。相対的に、The React Wayとは何ですか?

Angular ユニバースを離れて Flux に移行するときに、注意を払い始める必要がある重要なことは何ですか?

最初に相違点、次に類似点: AngularJS は非常に独断的であり、いくつかの非常に大きな禁止事項がありました。たとえば、UI/DOM コードをコントローラーに配置しないでください。Reactの大きな禁止事項と意見は何ですか?

最後に大事なことを言い忘れましたが、Facebook は Fluxを MVC の代替と呼んでいますが、私が見ている限り、React はビュー エンジンであり、ストアは単一のドメインに焦点を当てたモデル コンテナーであり、ディスパッチャーとアクションはコントローラーを形成します。これは実際には別の名前の MVC ではありませんか?

4

1 に答える 1

53

Angular との比較/対照は他の人に任せますが、2 つの質問に対する回答をいくつか示します。

これは実際には別の名前の MVC ではありませんか?

データ/ロジックレイヤーとビューレイヤーの間の懸念事項の分離が Flux に存在しても、MVC にはなりません。他の多くのパターンにも同様の分割があります。最も顕著なのは CQRS であり、間違いなく Flux に最も近いいとこです。MVC の意味で、Flux にはコントローラーはありません。アクションとディスパッチャーはコントローラーにはなりません。コントローラービューは似ていますが、実際にはコントローラーのような側面がかなり制限されています。主な違いは、MVC コントローラーにはアプリケーション ロジックが含まれており、モデルに基づいて動作することです。対照的に、フラックス ストアにはすべてのアプリケーション ロジックが含まれ、セッターはありません。

Angular ユニバースを離れて Flux に移行するときに、注意を払い始める必要がある重要なことは何ですか?

Flux の主な値:

  • 複雑さよりもシンプルさ。
  • プログラマーのメンタル モデルは、少なくともコード自体と同じくらい重要です。
  • アプリケーションの各部分は高度に分離し、他の部分についてできるだけ「認識」しないようにする必要があります。
  • コントロールの反転: すべてのコントロールは、状態が管理されるストアに常駐する必要があります。店舗は行動を起こすのではなく、行動によって情報を得ます。
  • アプリケーションは、成長しても回復力と柔軟性を維持し、予期しない新しい機能をより迅速かつ簡単に開発できるようにする必要があります。

Flux の主要な概念:

  • 一方向のデータフロー: アクション → ディスパッチャー → ストア → ビュー
    • 状態のすべての変化とすべての新しいデータは、ディスパッチされたアクションから始まります。
    • この 4 ステップのデータ フローは、Flux プログラマーのコア メンタル モデルです。
  • ディスパッチは、アプリケーション全体のアプリケーション状態の変換を引き起こします。
    • これは、変化のスナップショットを作成する瞬間です。これは簡単に推論できます。
    • 発送中に発送することはできず、このシンプルさを維持しています。したがって、必然的な変化は元のアクションによって引き起こされなければなりません。
  • Flux ストアはドメイン モデルであり、ORM モデルではありません。アプリケーション内の特定の論理ドメインのすべてのロジックを含み、すべての状態を管理します。これらには、コレクション、特異値、または両方の組み合わせが含まれる場合があります。
  • Flux は、派生データ(あるストアが別のストアの変更に依存する場合) は、モデルまたはストアが正規化されたデータを管理する複雑なアプリケーションの不測の事態であると想定しています。これに対処するには、Flux Dispatcher はstore 内でこの依存関係を宣言的に管理するメカニズムを公開する必要があります。Facebook の Dispatcher では、これはwaitFor()メソッドで行われます。これにより、あるストアはアクションに対する別のストアの応答を待ってから、独自の応答を進めることができます。

Flux アプリケーションの主要部分:

  • Actions : 新しいデータと特定のタイプを含むオブジェクト リテラル。これにより、Store はそれがドメインに関連しているかどうかを識別できます。
  • Dispatcher : コールバックを介してペイロード (アクション) を登録者 (ストア) に配布するコールバックのレジストリ。それ自体には知性がありません。すべてのインテリジェンスはストアにあります。
  • Stores : Dispatcher に自身を登録し、状態が変化するたびに「change」イベントを発行するドメイン モデル。
  • Controller-views : コンポーネント ツリーのルート近くにあるコンポーネントを表示します。それらはストアの「変更」イベントをリッスンし、ストアの公開された getter メソッドを介して新しいデータを取得し、それを子に渡すことで、このイベントに応答します。コントローラー ビューとビューの唯一の違いは、このリッスン機能です。
  • Views : Controller-View コンポーネントのステートレスな子で、純粋な関数のようにデータを送受信します。ビューとコントローラー ビューは、ほとんどの場合、React で実装されます。これは、パフォーマンスの損失がほとんどなく、自由に再レンダリングできるためです。
  • Utils : 異なるモジュール間で簡単に共有できる純粋関数のライブラリ。

概要、詳細: http://facebook.github.io/flux/docs/overview.html

チュートリアル: http://facebook.github.io/flux/docs/todo-list.html

例: https://github.com/facebook/flux/tree/master/examples

アクションとディスパッチャー: http://facebook.github.io/react/blog/2014/07/30/flux-actions-and-the-dispatcher.html

テスト: http://facebook.github.io/react/blog/2014/09/24/testing-flux-applications.html

野生の詳細: http://facebook.github.io/react/blog/2014/10/17/community-roundup-23.html

于 2014-12-03T08:41:59.917 に答える