Reduxを書いたとき

またはクラーケンハント 。 前のメモ（ こことここ ）で、さまざまなアーキテクチャスタイル、特にModel-View-ControllerとFluxについてBraindumpを共有しました。



私は、Fluxに直面して何の革命も見なかったことに注意しました。このテンプレートは新しいものではありません。 1979 Reenskaug-MVCに似ていることがわかりました 。 また、コードからRedux（Flux実装の1つ）を削除することを決めたと述べました。 これらの点をより詳細に説明する必要があるように思えます。 私の目標は、読者にFluxをMVCと呼ぶべきであると納得させることでも、reduxモジュールが不良であり、完全に放棄されるべきだと言うことでもありません。

では、Fluxはどうですか？

まず、Fluxとは何かを判断する必要があります。 まず、それは間違いなくアーキテクチャスタイルであり、現時点では、Webクライアントアプリケーションだけのものではありません。 次に、明確に定義されたコンポーネントと用語のセットです。



この概念の実装はすでに多数ありますが、最も人気のあるものはFacebook / Flux 、 Redux 、 Fluxxor 、 Reflux 、 Vuejs / Vuex 、 Mobxのみです。 SAM.js （State-Action-Model）の形式でエキゾチックなものがあります。



しかし、重要なことは、 Dispatcher 、 Action 、 Store、およびStateという用語が、現代のクライアントアプリケーションアーキテクチャで厳しい位置を占めていることです。 新しいシステムに来た開発者がコントローラーレイヤーを探すのと同じように、今ではストレージまたはディスパッチャーを探しています。



それでこれにどう関係するのでしょうか？ 治療は間違いなく良いです。 私にとって、Fluxは第2レベルのSoC（懸念の分離）であり、特定のMVCコンポーネント内の責任の区分です。 これは新しいアイデアではなく、 Taligent-MVPがコントローラーレイヤーが再考され、いくつかの他のレイヤーに分割されたときに実行しようとしたことです。



これは代替ではなく、次のラウンドであり、これはアーキテクチャパターンの進化です。









「新しいものはすべて忘れ去られている」というメモから









I.パニンのプレゼンテーション「なぜドメインが最初なのか」から

やる気

責任の分離は、プロジェクトのコードを、触手がランダムに絡み合ってコード構造の迷路を構築する恐ろしいパスタモンスターに変えないようにするアプローチです（ クラーケン、前のメモを参照 ）。



ただし、前述したように、すべてのコンセプトまたはテンプレートは、それらが発明された問題から始まります。 Facebookは大企業であり、巨大な割合のWebアプリケーションであり、最高レベルの双方向性の量です。 それがFluxが発明したものです。 しかし、それがまさにこのコンセプトがコミュニティに受け入れられない理由です。 同様のソフトウェアを開発している企業はいくつありますか？



複数のリポジトリを実際に必要とするアプリケーションをいくつ開発したかを考えてください。 アプリケーションをいくつ開発する場合、このテンプレートは本当に役立ちますか？



各ロックには独自のキーが必要です。 キーがいくつかのロックに来ることもあれば、力で押してドアを開けることもあります。 私の頭の中にフレーズが現れます：

理性の声に耳を傾けず、サイレンの声で万能薬を歌う売り手に注意を払いたくない

V. M.タースキー（F.ブルックスの「神話的人間月」の本から）

宣伝されている標準から頭を失い、主なタスクを忘れている開発者のグループを見ました：クライアントの利益を実現する

R.マーティン



Reduxはコミュニティに恋をしました。 この実装は、平均的なアプリケーションに必要なものです。 私がこのテクノロジースタックに移行したとき、最初のアプリケーションは標準的に書かれたものでした。 React-Redux-Thunk（ミドルウェア）の束を使用しました。 アクションのタイプにはアクション クリエーターと文字列定数の両方があり、いわゆるバインドアクションクリエーターもありました 。 すべては公式サイトガイドにあります。



しかし、ある時点で、この魔法のモジュールのペアが内部でどのように機能したかという疑問が生じました。 Documentum Foundation Classesコードベースを扱っていた私のような開発者にとって、redtop-moduleのいくつかの機能を扱うためにWebtopに統合されたExtJS 3.1のソースを読むことは難しくありません。 他のほとんどの経験豊富なプログラマーと同様。 しかし、さまざまなレベルの開発者がプロ​​ジェクトに取り組むことは誰にとっても秘密ではありません。 最年少でさえ、このまさに「 フード 」の下で何が起こっているのかを把握できるようにするにはどうすればよいでしょうか？ 結局のところ、プログラマーは自分のツールを知っている必要があります。



私の周りの開発者全員がこの魔法がどのように機能するのか、ウサギが帽子からどのように現れるのかを理解していない、または少なくとも単に疑問に思っているという事実に直面しました。 これはおそらく、Flux / Redux実装を作成するための触媒として機能した最初のポイントでした。 最後に、何かを理解し、何かを再考する最良の方法は、自分でそれを書くことです。 コードはチーム全体で利用でき、誰でも何かを追加または削除したり、デバッガーを使用して、行の目的を理解したりできます。



残りの動機付けのポイントを見ていきましょう。 単方向データフローの概念は明確でなければなりません。 単方向のデータフローは、触手でモンスターを殺すことを可能にします。 そして、おそらく、このアプローチで最もあいまいな瞬間はJavaScriptの非同期性であり、それが単方向データストリームの概念にどのように当てはまるかです。



この点を決定するために人々が選択するいくつかのオプションがあります。 1つの例はサンクです。 個人的には、 ミドルウェア（中間コンピューティング）は、Fluxアーキテクチャスタイル内の一種の副作用のように見えます。 純粋な形でのテンプレートの使用を妨げる穴を塞ぐ試み。 OOPのUtils、Helper、またはServiceクラスのようなものです。 開発者が特定のビジネスクラスにロジックを持ち込めない場合、彼はこの魔法のような場所を利用して、このようなすべての担保（有用？）機能を配置し始めます。 実際、この副作用はリポジトリの機能にすぎません。 ストレージは永続的であり、これが単音節CRUD操作のプリズムを通してデータについて考えることを妨げるものです。



間違いなくコードはきれいでなければなりません。 これは、プロのプログラマーがプロジェクトで努力していることです。 幅広いタスク用に作成されているため、ほとんどのツールは冗長です。 それらはプロジェクト用に作成されたものではなく、タスクのタイプ用に作成されたものでもありません。 しかし、誰もがトレンドを追いかけ、誰もが万能薬を追いかけています。



サンクとbindActionCreatorsは私にとって副作用です。 接続関数の2番目の引数、つまりmapDispatchToPropsを必要としないアプローチを選択します。 ところで、プロジェクトでconnect関数の3番目の引数を使用したことがある人はいますか？ 謎の旗は純粋かも？



触媒として機能した2番目のポイントは、使用するツールの冗長性です 。



ところで、Nicklaus Wirthのお気に入りのフレーズの1つ：

ツールはタスクに適している必要があります。 ツールがタスクに対応していない場合、それに対応する新しいツールを考え出す必要があり、既存のツールを適応させようとしないでください。

3番目のポイントは、 「できるから」です。 はい、そうです、私たちはプログラマでもあり、独自のツールを書くこともできます。 たとえば、ReactやSpringフレームワークを書き直したいわけではありません。 しかし、Spring全体を、それを必要としないプロジェクトにドラッグしても意味がありません。 たとえば、土曜日の夜に小規模なFlux実装に費やすのは決して怠け者ではありません。これにより、アプリケーションのニーズが満たされます。 それは私にとっても喜びです。

自転車か、彼にArtuxという名前を付けてください

Reduxは機能的なスタイルで書かれています。プログラミングのパラダイムの観点から言えば、JavaScriptはマルチパラダイムのカーテンを開く素晴らしい言語です。 私は暗い面と明るい面のバランスをとっています。



しかし、クラスはインターフェースを記述する方が簡単です。 「ストレージ」と言うと、1つの名前で結合された一連の関数よりも、特定のAPIメソッドを持つオブジェクトとして認識する方が簡単です。



以下は、ストレージ実装のインターフェイスです。 unsubscribe関数がパブリックメソッドに登場したことを除いて、Reduxバージョンと非常に似ています。 reduxモジュールでは、 subscribe関数で閉じられます。









Storage Designerは、対応するReducer / Receiverを備えたModelsマップを受け入れます。



モデルは、ドメインの一部である特定のビジネスエンティティに対応する、ウェアハウスの論理的な名前付き部門です。 私の見解では、Vaultにはビジネス情報のみが含まれ、チェックボックスやラジオボタンなどのグラフィックウィジェットの状態は含まれません。



ハンドラーは、外部から受信したコマンドに応答する関数またはクラスであり、チームが運ぶ有用な情報に基づいて、モデルの状態を変更します。



以下は、 StoreProviderクラス（ストレージプロバイダー）のインターフェイスです。これは、 元のクラスとほぼ同じであり、ストレージインスタンスをアプリケーションコンテキストに単に配置します。









以下は、 subscribeToStore関数が生成する高次コンポーネント/ HoCインターフェースの説明であり、connect関数を置き換えます。









前述したように、冗長性を削除し、ストレージ状態リスナーのみが入力に転送されるようになりました。 このコンポーネントと混在する主なロジックは、リッスンされているデータと次の状態から取得した値を確認することです。 新しい値を取得する場合、コンポーネントライフサイクルメソッドが起動され、その結果、ビュー全体のすべてまたは一部が更新されます。



そして、私の謙虚な実装の最後のコンポーネント。 ディスパッチャインターフェイス









コンポーネントの主な目的は、リポジトリにメッセージを送信することです。 このインターフェイスは、アクションオブジェクトを作成できるメソッドと、永続的な操作の非同期性を「 埋める 」アクションをディスパッチするメソッドを提供します。 約束は捨てられず、システム内の反応は特定のモデルの状態の変化に基づいてのみ発生するという読者の注意を引きます。



アクションは、次のフィールドを含むJSONオブジェクトです。

• タイプ（タイプ） -文字列リテラル、ユーザーアクションの名前。
• 有用な情報（ペイロード） -スカラー値またはデータ構造にすることができます。
• メタまたはサイド情報（メタ） -このプロパティを介して、アクションに匹敵する操作を実行するために必要な追加のデータ（入力引数など）を転送できます。
• エラーインジケータ（エラー） -アクションに匹敵する操作の成功または失敗を反映するブール値。

また、 プロキシとReflect es6オブジェクトを使用して、より便利なデバッグのために状態変更コンソールにロギングメカニズムが追加されました。

アプリケーションデバイス

ビューの最上位にあるのはPagesです。 これらは、グラフィカルウィジェットのツリー全体の親であるコンテナコンポーネントです。



ページは、ストレージ状態の変更をサブスクライブし、データストリームをツリーに転送するHoCコンポーネントです。 また、そのような各オブジェクトには独自のインタラクターレイヤーがあります。 このレイヤーは、ページまたはアンカー間の遷移とアクション（コマンド）の実行の初期化の2種類の操作を組み合わせます。



相互作用クラスは、実際には、1つの場所でDispatcherおよびRouterとの通信を組み合わせることができるブリッジです。 以下は、このクラスのインターフェースの例です。









システム内の各モデルは、そのハンドラー（リデューサー/レシーバー）に対応し、受信したアクションに基づいて、モデルの状態を変更するか、変更しないのは彼です。



ラインを通じて多くの用語を書いて、ネーミングの2つのバリエーションを示します。 これにより、ビヘイビアデザインパターンにより、多くの人にとって既に馴染みのある同様の概念を実装できることに注意してください。



ハンドラーの私のバージョンはReducersです。 私は、アクションの種類（PENDING、SUCCESS、FAIL）の分岐のために記述しなければならない大量の定数に常に悩まされていました。 最初に、ハンドラー内でリテラルに直接取り組むことにしました。 第二に、オブジェクトアクションは、必要なすべての情報を伝えることができる非常に柔軟なツールだと思います。 第三に、個人的には、GET_ITEMS FAILと呼ばれるユーザーのアクションを知覚するのは難しいです。 同意します。これは、エンドユーザーが実行したいアクションではなく、GET_ITEMSを実行しました。リポジトリ内のモデルに到達するのはこのアクションです。











これで、アプリケーションの一般的な概要を表示できます。 彼女はこんな感じだった

#DMP_END

他の回路と同様に、このアーキテクチャも触手のあるタコになります。 このバージョンで最も厚い場所はパフォーマンスです。 ただし、ここでは、React自体が、プレゼンテーション層の実装に特化したライブラリである私たちを支援するために呼び出されます。 また、 コンポーネントの継承（HoCおよびOOPの継承）など、多くの手法があります。 タスクはほぼ単純です-新しいモンスター-FSUV（Fat Stupid Ugly View）の誕生を防ぐために。



説明の中で、reduxモジュールバージョン3.6.0に言及していることを明確にする必要があります。 正直なところ、私はパフォーマンスであまり勝ちませんでした。ページのレンダリングは同時に行われます。 しかし、突然このモジュールがnpmから完全に消えた場合、すでに理解しているように、私はさほど悲しいことではありません。



要約すると、各タスク用のツールがあり、ツールの独自の小さな実装を作成しましたが、後続のアプリケーションには適さない場合があります。 多分それはもっと普遍的なものに進化するか、多分私は再び標準の反応スタックに戻るでしょう。



ちなみに、メソッドの実装を具体的に示したのではなく、インターフェイスのみを示しました。これは、読者が使用するライブラリのソースコードを見に行き、自分のプロジェクトに合った独自の小さな実装を作成しようとする動機です。



このメモでは、Fluxアーキテクチャについての考えから混乱したテーマである、混dumpとしたダンプをカットします。 artur.basak.devingrodno@gmail.comのフィードバックをお待ちしています。

参照資料

+フラックス標準アクション

+ Redux

+フラックス

+ I.パニン「なぜドメインが最初なのか？」