👴🏾 🛫 🆗 複雑さの制御とUDFアーキテクチャ 💑 🤟 🦃

複雑さは開発者の主な敵です。そのような仮説がありますが、新しい機能を追加する過程でソフトウェア製品の時間の経過とともに複雑さが必然的に増大するという公理に帰するでしょう。変更が保証されるしきい値に達するまで成長します。 100％に近い確率で、エラーが発生します。この仮説への追加もあります。そのようなプロジェクトがさらにサポートされ続けると、遅かれ早かれ、必要な変更を加えることが不可能なほど複雑になります。松葉杖、悪名高いアンチパターンを含まないソリューションを考え出すことは不可能です。

難易度のソース

複雑さは入力要件によって必然的に導入され、このタイプの複雑さを回避することは不可能です。たとえば、すべての会計プログラムには、人に支払いを行うタスクがあり、これらの支払いの計算には、会社で一定期間以上働いた人に追加の金額を請求するという要件があります。アプリケーションコードには必然的に次のようなものが含まれます。

if(qualifiedForExtraPayment(employee)) { calculateThatExtraPayment(...) }

これは、ビジネス要件によってアプリケーションに導入される複雑さの要素です。

ただし、要件によって定義されず、開発者によって直接導入される複雑さがあります。この「人工的な」複雑さのほとんどは、 DRY原則を理解している開発者の特殊性に起因しています。

たとえば、前述の仮想会計プログラムでは、2つのほぼ同一のページを作成する必要があります。両方で、人への支払いを計算し、これらの支払いに関する詳細情報を表示する必要があります。しかし、1ページは純粋に情報提供であり、何人がお金を受け取るかを確認します。2ページ目は、実際の送金を行うための3番目のアクションが存在するエグゼクティブです。

この例は確かに架空のものですが、他の開発者のコードでも同様のことが定期的に見られます。

それを解決する方法。

最初のページでは、擬似コードは次のようになります

 const payment = calculatePayment(employee); displayPayment(payment);

2ページ目

 const payment = calculatePayment(employee); displayPayment(payment); proceedWithPayment(payment);

それは時々どのように決定されます。

2番目のメソッドを作成する代わりに、追加のパラメーターが最初のメソッドに導入されます

 const payment = calculatePayment(employee); displayPayment(payment); if(isOnlyInformation) { return; } proceedWithPayment(payment);

そして、ここに、アプリケーションの複雑さの別の要素、別の要素があります。この複雑さのポイントは要件からではなく、開発者が問題を解決する方法から来ています。

コードが既に十分に分解されている場合、2つの行が一致したため、2つのメソッドが1つに「スタック」していることがわかります。しかし、最初は、コードが最初に「額に」書かれた段階で、これらのメソッド（calculatePaymentとdisplayPayment）の実装はまだ別々のメソッドに入れられないかもしれませんが、この本体に直接書き込まれ、2つのメソッドが一致するように見えます、最初の100行。そのような場合、この「コードの重複を取り除く」ことは良い解決策のように思えるかもしれません。しかし、これは明らかにそうではありません。ドライアンチパターンに関する前回の記事で、DRY原則を使用することで回避できるアプリケーションの複雑さを実現する方法の例を既に示しました。同じコードを記述する方法を使用しますが、このパターンを使用せずに、要件に起因しないアプリケーションに複雑さを導入しません。

したがって、ある開発者の手では、要件の複雑さに比例して、アプリケーションの複雑さが線形に増加するという結論に達します。別の開発者の手では、複雑さは指数関数的に増加します。

単独責任の原則

均等に分散された複雑さは、その必然性すべてにとってそれほど有害でも危険でもありませんが、開発者が1か所に集中することは恐ろしい夢になります。関数にifがある場合、2番目のブランチを追加します。2つのブランチがあり、それがネストされているかどうかは関係ありません。メソッドをパスするための少なくとも4つの可能なオプションがあり、3番目のifは8になります。正常に分解され、各実行に4つの分岐がある他の関数に影響を与えず、それぞれが潜在的に4つのテスト、合計8を記述する必要があります。分解できない場合、このロジックはすべて1つのメソッドに含まれます。 4 * 4 => 16と書く必要があり、そのような各テストはtesよりも複雑になります最初の8の。テストの数と複雑さは、アプリケーションの最終的な複雑さを反映しており、同じ数の複雑さの要素では、半分以上異なります。

SOLID Principle Bookの最初の段落であるSRPと呼ばれる広く知られたコード設計原則は、このような複雑さの山と戦うことを目的としています。また、この略語の残りの文字には、ほとんどがオブジェクト指向プログラミングに関連するルールが含まれていますが、SRPは普遍的であり、プログラミングパラダイムだけでなく、アーキテクチャソリューション（他のエンジニアリング分野にも）に適用できます。残念ながら、この原則には控えめな表現が含まれており、必ずしも明確ではありませんが、何かに対する唯一の責任をどのように判断するかが重要です。たとえば、ここには100万行の神クラスがありますが、衛星を制御する唯一の責任があります。しかし、彼は他に何もしません、すべてが順番に意味するのですか？明らかにそうではありません。原則は多少言い換えることができます-コードの特定の要素、およびこれが関数、クラス、またはアプリケーションのレイヤー全体のいずれかである可能性がある場合、責任が大きすぎる場合は、分解し、断片に分割する必要があります。そして、それが多すぎるという事実は、そのような兆候によって判断することができます-そのテストが複雑すぎたり、多くのステップが含まれている場合、または多くのテストが必要な場合、責任が大きすぎて、それを分解する必要があります。これは、コードを見なくても判断できる場合があります。いわゆるコード臭、1つのクラスのファイルを開いてそこに800行のコードが表示されている場合、このコードを読んでこのクラスに多くの責任があることを確認する必要さえありません。ファイルに依存関係（インポート、yuzingなど）のページ全体が含まれている場合、同じ結論に達するために下にスクロールしてこのコードを読み始める必要はありません。もちろん、さまざまなトリックがあります。IDEは市民にコーダーをdulし、「プラス記号」の下でインポートを崩壊させます。ワイドスクリーンモニターを直立させたコーダー自身のトリックもあります。私は繰り返しますが、私はそのような開発者のコードを読む必要さえなく、私はおそらくそれが好きではないことを理解しています。

しかし、分解は絶対的な「このスティックのもう一方の端」に到達するために必要ではありません-1つのオペランドを持つ100万のメソッドは、100万のオペランドを持つ1つのメソッドよりも良くないかもしれません。繰り返しますが、過度に分解すると、これら2つの遊び心のある「プログラミングで最も難しいタスク」の最初の1つが必ず発生します。関数の命名とキャッシュの無効化です。しかし、これに到達する前に、平均的な開発者は最初に少なくとも800行のクラスで、少なくとも最小限に分解する方法を学ばなければなりません。

ところで、別のそのような遊び心のある哲学的思考があります-概念としてのクラスは、あまりにも多くの責任を担います-行動と条件。ふるまいのための機能と状態のための「プレーン」オブジェクト（POJO、POCOなど、またはCの構造体）の2つのエンティティに分割できます。したがって、OOPパラダイムは受け入れられません。それと一緒に暮らす。

複雑さとの闘いとしての建築

私が言ったように、複雑さと複雑さの乗算はプログラミングに固有のものではなく、人生のあらゆる側面に存在します。そして、この問題の解決策がシーザーによって提案されました-分割と征服。相互に関連する2つの問題は、これらの問題を別々に次々に倒すことよりも困難であり、ローマ人と戦うために団結した2つの野triな部族を倒すことはより困難です。それらが互いに何らかの形で分離されている場合、1つの部族は個別に敗北し、別の部族ははるかに簡単になります。低レベルでは、既に特定のコードを記述するとき、これは分解とSRPです。高レベルで、アプリケーション設計レベルでは、アーキテクチャソリューションがこれに役立ちます。

ここからは、UI /フロントエンドの詳細に焦点を当てます。

UIを含むアプリケーションの開発には、MVC、MVP、MVVMなどのアーキテクチャソリューションが長い間使用されてきました。これらすべてのソリューションには2つの共通の機能があります。最初の機能はM、「モデル」です。彼らは彼女にある種の定義さえ与えます、私はここでそのような単純化で管理します-プログラムの残り。 2番目はV、「ビュー」またはビューです。これはアプリケーションの他の部分から分離されたレイヤーであり、その唯一の責任はモデルからのデータの視覚的表現です。これらのアーキテクチャは、MとVが相互に通信する方法が異なります。もちろん、私はそれらを考慮しません。これらのアーキテクチャの開発に費やされたすべての努力が、ある問題を別の問題から分離することに向けられていること、そしてあなたが推測するように、アプリケーションの複雑さを減らすことに再び注意を払うだけです。

そして、視覚的表現がこの層の唯一の責任であると言って、私はこれらのアーキテクチャの基本原則を意味するだけです-プレゼンテーション層にロジックがあってはなりません。絶対に。そのために、これらのアーキテクチャが考案されています。そして、MVCのアーキテクチャについて話すと、「シンコントローラー」という用語がまだありました。このアーキテクチャを使用すると、ロジックコントローラーを含めるべきではないという結論に達しました。絶対に。ロジックの場合、これはこの層の2番目の責任であり、1つであることを保証するよう努力する必要があります。

単方向データフローアーキテクチャ

やる気

このアーキテクチャの目的は、前述のアーキテクチャの目標とまったく同じです。アプリケーションの複雑さを軽減し、問題を互いに分離し、それらの間に論理的な障壁を構築することです。このアーキテクチャの利点は、以下の他のアーキテクチャよりも優先される理由です。アプリケーションは、1つの「ビュー」と1つの「モデル」に限定されるものではありません。どのアプリケーションでも、それらのいくつかがあります。そして、それらの間に何らかの接続がなければなりません。例として以下を取り上げます-表に従って金額を計算する必要があります。あるビューでは、人がテーブルにデータを入力し、別のモデルがこのデータをサブスクライブし、量を計算し、更新する必要があることをビューに伝えます。さらに、この量に対して3番目のモデルが署名されるという事実によって例を拡張します。この場合、「適用」ボタンをアクティブにする必要があります。さらに、開発者はこれが最後のアクションであると誤解される場合があります-提出の責任であり、マークアップで次のようなものを確認できます： <div *ngIf="otherModel.sumOfItems === 100">

。

これはすでに間違いです。2つの数値を比較することは、モデルが厳密に制御するロジックであり、マークアップは厳密に計算されたフラグで動作するはずです-

<div *ngIf="myModel.canProceed">

特に高度なケースでは、2つのモデル間のこの関係が記述され、外部モデルからのデータがチェックされ、そのモデルに副作用をもたらすメソッドが呼び出されます。いずれにせよ、モデル間には一種の変化伝播グラフが表示されます。

遅かれ早かれ、このグラフは制御不能になり、変更を加えると、グラフの下で発生する副作用でこれがどのような結果になるかを開発者が追跡することは容易ではありません。 Facebookからのプレゼンテーションでは、ダウンストリーム効果と呼ばれていましたが、これは用語ではありません。また、グラフの下で発生したエラーを修正しようとする別の開発者は、この問題の根本原因を追跡するのが困難になります。一部の場所では、このグラフは周期的に進むこともあり、この周期を終了する条件は、グラフ内のまったく異なるポイントでの無害な変更によって破られる可能性があります。その結果、アプリケーションがハングし、理由を理解できません。変更伝播グラフは、顧客の要件に基づいていないことは簡単にわかります。それらは実行する必要のあるシーケンシャルアクションのみを指示しますが、これらのアクションは{必要な表現を置換}としてコード中に散在し、それらの間にサブスクリプション、イベントスローなどが挿入されます。開発者の良心に既にあります。

これについては、 Reduxの動機付けでもう少し読むことができます。

UDFアーキテクチャは、2つの基本的な制限が課せられたパイプラインです。1）パイプラインの次のステージは、前のステージまたはその実行結果に影響を与える権利を持ちません。 2）コンベヤーの「ルーピング」は、ユーザーからの入力のみを生成できます。したがって、アーキテクチャの名前-アプリケーションは、ユーザーに向かって一方向にのみデータを独立して移動し、外部の影響のみがこのメインストリームの反対方向に移動できます。

パイプラインには2つの主要なステージがあり、最初のステージは状態を担当し、2番目のステージは表示を担当します。いくつかの点で、上記のアーキテクチャのモデルと表現のように見えますが、これらのアーキテクチャ間の違いは、モデルと表現の相互作用にあります。そして、これに加えて、モデル同士の相互作用において。アプリケーションの全体の状態は特定のストアに集中しており、特定の外部イベント（ユーザー入力など）が発生すると、ポイントA（外部刺激）からポイントB（刺激後）へのすべての状態変化が1つのアクションで発生する必要があります。つまり、上記と同じスクリプトでは、コードはreduxのreduxの例を使用して次のようになります。

 function userInputHappened(prev, input) { const table = updateRow(prev.table, input); const total = calculateTotal(prev.total, table); const canProceed = determineCanProceed(prev.canProceed, total); return { ...prev, table, total, canProceed }; }

これは、論理の通常の構築との主な違いである重要な原則を示しています。相互のサブスクリプションはなく、2つの連続した操作の間にイベントがスローされません。特定の外部刺激に対して実行する必要があるすべてのアクションは、順番に記述する必要があります。そして、そのようなコードに変更を加えると、変更の結果がすべて見えます。そして、結果として、この人為的に導入された複雑さは最小限に抑えられます。

Redux

当初、UDFフロントエンドアーキテクチャは、2つの反応およびフラックスライブラリのバンドルの一部としてFacebookによって提案されましたが、少し後にフラックスがreduxに置き換えられ、いくつかの非常に重要な変更が提供されました。まず、状態制御はクリーンなコードで記述されるようになりました。実際、すべての状態管理は1つの簡単な式で記述できます。

状 態 （ n ） = F （ 状 態 （ n - 1 ） 、 A ）

$状態（n）= F（状態（n-1）、A）$

次の状態は、前の状態と何らかの刺激の純粋な関数に等しくなります。

第二-プレゼンテーション層は今や別のクリーンな機能

H T M L = F （ 州 ）

$HTML = F（州）$

つまり、すべてのUIコンポーネントのタスクは、入力でオブジェクトを取得し、結果としてマークアップを提供することです。

したがって、次のことが達成されます。

1.「unclean」、非同期コードがアプリケーションからその端に移動します。2つは大きく、アプリケーションの定義ブロックがクリーンになったとさえ言えます。

2.非常にクールな楽器。 1つ目はホットリロードです。これにより、状態を失うことなく、オンザフライで純粋なレンダリング機能を置き換えることができます。つまり、UIレイヤーを「ホット」編集し、すぐに結果を確認できます。毎回アプリケーションを再起動せずに、バグの再生ポイントまで「クリック」する必要もありません。 2番目のツールであるタイムトラベルでは、状態（1）から状態（n）までのすべての状態を記憶し、それらに沿って前後に移動し、何が間違っているかを順番に確認できます。さらに、1つのPCでバグを再現し、タイムラインをエクスポートし、別のPCにダウンロードする、つまり、このバグを再生する手順を説明しなくても、テスターから開発者にバグを転送できます。ただし、この2番目のツールにはもう1つの要件があります。アプリケーションの状態とアクションはシリアル化可能でなければなりません。つまり MapやDateTimeなどの基本クラスも使用できません。 POJOのみ。さらに、レデューサーでは、オブジェクトの参照の等価性に依存することはできません; idなどの値で比較する必要があります。

3.再利用-自問します-何らかの種類のUIコンポーネントがモデルに忍び込み、それ自体のデータを受け取り、それを処理して表示する場合に遭遇しましたか？

同じUIを使用するために、新しいデータソースまたは異なるシナリオで異なるアクションセットを使用する新しいタスクが発生することはありますか？別のシナリオで同じマークアップを再利用することは、単に非現実的です。

オブジェクトを取得し、結果としてマークアップを生成するUIの一部を再利用することは、まったく別のことです。適切な場所に別のデータ構造がある場合でも、それをこのコンポーネントが受け入れるものに変換し、自分自身に挿入して、このオブジェクトを与えます。結果として、あなたはそれがあなたが必要とするものをレンダリングすることを完全に確信しており、副作用を全く被ることはありません。

状態管理と同じこと。テーブルの行を更新する関数があります。彼女が自分の中で何か他のことをしたり、何らかの方法でテーブルを正規化したり、ソートしたりするとします。別のスクリプトから純粋な関数を呼び出す価値は何ですか？また、副作用が発生しないと確信しています。

スクリプト全体を再利用することは不可能になります。プレゼンテーション状態の完全な分離があるという事実のため。また、そのような再利用のエントリポイントは複製する必要がありますが、そのようなエントリポイントのメインの「肉」は再利用できるため、再利用する必要があります。

残念ながら、良いものはなく、痕跡もなく、Reduxには1つの重要な制限がありません。既に述べたように、「ループ」はユーザーのみが開始でき、そのような制限はFLUXに実装されました。状態の変化にサブスクライブするためにプロセッサで新しいアクションをスローすることはできません。例外をスローします。つまり、このサブスクリプションのプロセッサ内のパーティにサブスクライブされたUIコンポーネントには、状態をさらに変更する権利がありません。レンダリングのみ、ハードコアのみ。 reduxでこの例外を減らしました。

ReduxおよびUDFの誤った使用例

私たちのアプリケーションの1つで、常識までの多くの事柄の違反が発見されました。

1）ロジックはUIコンポーネントに直接配置され、UIコンポーネントはどのデータをロードするかを自ら決定します

2）UIコンポーネントは互いに（病気！）いくつかの他のクラスから継承されます。

3）UIコンポーネントは*アダプターと呼ばれます（次は何ですか、*インジェクター、*工場？）

4）UIコンポーネントは、「その」データと他のコンポーネントのデータが状態ツリーのどこにあるかを「知っています」

5）UIコンポーネントは独立して状態の一部にサブスクライブし、処理の結果として新しいアクションをスローして、「独自の」状態、明らかにこれらのループが存在しないループアーキテクチャを変更します。

この設計の動機は、単一の再利用ポイントを作りたいという願望でした。さらに、この点はもちろん、UIレイヤーのマークアップにあります。このように聞こえます-UIコンポーネントを挿入すると、自動的にピックアップされます（はい、これらは、隣接するキューブから常に聞こえる単語です、ピックアップ、注入、サイン、転送、コードの匂いはすでにリモートで感じられます）、その状態、コンポーネントは状態にサブスクライブします彼のための入力を生成する隣接コンポーネント、彼が依存するデータ、彼は初期および遅延読み込みの両方のためにバックエンドからデータを受け取ります。また、3つのアプリケーションで使用されるこのコンポーネントでapiメソッドが突然変更された場合、またはこのコンポーネントに新しいロジックを追加する必要がある場合は、コンポーネントに追加します。

3つの場所の1つに異なるデータソースがある場合、またはこのコンポーネントの途中に別の処理ロジックがある場合、どうすればよいですか-このアーキテクチャソリューションはこれを提案しません。彼らが言うように-まあ、何かをしてください、tyzhprogrammer。明らかに、内部に入り、新しいロジックを作成し、ifを付ける必要があります。これにより、3番目のシナリオではオンになり、最初の2つのシナリオではオフになります。

このアプリケーションでの変更の分布のグラフは次のようになります。

人々はアプリケーションでreduxを使用し、特にマイナスの側面、特に「ノイズの多い」構文を取得しました。。

あなたは、グラフの変更の伝播を描画しようとすると、彼がとして使用された回数、と非常によく似ていることを確認することは容易であるantiprimer Facebookのプレゼンテーションに。

合計：

1）UDFアーキテクチャに違反しており、reduxはそれを実装することになっていますが、派手なpub-subとしてではありません。

2）マークアップと状態のハードカップリング

3）SRPの原則に違反しています-プレゼンテーションレイヤーのロジック

4）常識に違反しています-プレゼンテーションレイヤーのコンポーネントの名前/目的。

リアクティブプログラミングとの比較

UIアプリケーションの作成に適した別の概念があり、これも「通常のパウダーよりも優れています」。彼女にとって、また彼女のフレームワークを実装するために、多くのアジテーターがいます。

エンティティを変更するときに、依存エンティティを処理する必要がないモデル間の相互作用が含まれます。依存エンティティ自体は、変更されたことを検出し、それ自体を再集計します。

knockoutJSフレームワークの例を使用して、擬似コードを記述します。

tableVmがあり、テーブルフィールドと、このテーブルを更新できる関数があります

 tableVm.table = ko.observable(someInitialData); tableVm.updateTable = function(input) { const current = tableVm.table(); const updated = ... // some code here tableVm.table(updated); }

さらに、別の（場合によっては同じ）ビューモデルにコードがあります。

 tableTotalVm.total = ko.computed(() => tableVm.table().map(...).sum());

3番目のVMでは、次のコード

 submitVm.canProceed = ko.computed(() => tableTotalVm.total() === 100);

「スクエアツーバック」と呼ばれるものがUDFが意図的に残したものに到達したことは簡単にわかります。1つのコードが別のコードに署名され、2番目のコードが3番目に署名されます。遅かれ早かれ、変化の分布の大きく制御されないグラフになります。

さらに、変更の逆分布も予想されます。

ここでは、より低いレベルでゼロから始まるインデックスが保存され、UIで1からインデックスにマップする必要がある、つまり、UIで何かが変更されたときに、それを片側に変換する必要があり、それぞれ下位レベルに変換する必要がある、より簡単な例を示します戻る。

 lowerVm.index = ko.observable(indexLoadedFromApi); upperVm.index = ko.computed( () => lowerVm.index() + 1), (newVal) => lowerVm.index(newVal - 1) );

そして、そのようなシステムでUIが上限値を変更すると、computeはこの変更を下位モデルにプッシュします。なぜなら下位モデルが変更された場合は、上位モデルを再度カウントし、それに応じてUIを更新する必要があります。まだそのような状況が存在する可能性があります-ある値を一番上に置いて、この更新の渦から、コードのエラーまたはファジーロジックのために別の値が再カウントされました。この場合、循環依存関係検出フレームワークでは、メカニズムが正常に動作しない可能性があり、完全に理解できない場所で例外を「ハング」または取得するか、サイレントエラーメッセージ、またはスタックオーバーフローが発生します。

そして、そのようなメカニズムが存在するという事実は、いわば、ループする依存関係を作成する危険性があることを示しています。また、ビジネス要件によって周期的な依存関係が決まる場合があります。科学、文化、生産の3つのスライダーがあるCivilizationのようなゲームを想像してください。それらの合計は常に100％である必要があります。 3つの計算で何かを実装してみてください。または、例えば、生命シミュレーター。これは、相互に依存する1000の計算されたものではなく、1つの観測可能なものであり、アプリケーション全体のモデル全体が存在することがわかります。そして問題は、アプリケーションでこれを観察できるようにする必要があるかどうかです。

こっちリアクティブプログラミングを提唱している著者の意見は、ノックアウトの場合とまったく同じではありませんが、症状はまったく同じであるという疑いがあります。そして、作者は絵文字を使ってUDFを「悪い光の下で」喜んで公開します。これは、UIアプリケーションの作成の専門家であると考える人でさえ、おそらく当然のこととしてそれらを考慮する人でも、このアーキテクチャをまったく理解していないことを非常に明確に示しています。長年使用していたすべてのものを壊してしまうため、本当に理解するのは簡単ではありません。

この誤解は、ダイアグラムの描画方法で見ることができ、単一のモデル、単一のビューで描画されるため、開発者の心をつかむUDFの正確性が明確ではありません。すべてのアーキテクチャが見栄えがよく、一般的にそれらの違いを理解するのは簡単ではありません。そして、これらのモデルとビューがたくさんある状況を描く必要があります。そして、それらの多くがリアクティブプログラミングを使用している場合、変更分布図は次のようになります。

ここでは、view1のすべてのユーザーアクションと同様に、変更が異なる計算対象に順次配信され、次に観測可能な対象に分散されます。そしてcompute5が2回再カウントされ、view3も2回更新されることは明らかです。ノックアウトアプリケーションでは、計算された1つが配列内の要素の数によってN回再カウントされる効果も発生しました。ノックアウトは必要なものだけを更新し、そのジェットモデルは生産性を世界にもたらし、その瞬間に突然爆発するという主張された大きな利点。

UDFを使用したアプリケーション

リアクション/リデュースアプリケーションの例を調べたとき、完全に開発されていないと感じました。特に、reduxの著者自身であるDen Abramovは、UIコンポーネントに直接、いわゆるファイルと同じファイルに書き込むことを提案しています。以下のprops uiコンポーネントでハングするdispatchToProps関数

 (dispatch) => { return { someMethod: (someData) => { dispatch({type: Actions.someAction, someData }); } } };

これらのメソッドはより複雑になり、非同期操作を含むコンテンツが拡大する場合があります

 (dispatch) => { return { async someMethod: (someId) => { dispatch({type: Actions.startedLoadingAction }); const someData = await api.loadSomeData(someId); dispatch({type: Actions.someAction, someData }); } } };

これがビジネスロジックであることは簡単にわかります。そして、長い間、UIレイヤーにはビジネスロジックの場所がないというトピックについては十字架につけられていました。さらに、パイプラインの2番目のステップにあるこのロジックは、UDFアーキテクチャ自体に違反する最初のステップに影響します。あなたがこれを行うことができないという事実は、すぐに明らかになりました、どうすればできますか？しばらくして、調査、試行錯誤の後、答えが出ました。さらに、この答えの明快さは、その単純さに顕著です。パイプラインのN番目のステップに影響するコードは、N-1パイプラインのステップ上にある必要があります。さらに、非同期コードをアプリケーションのエッジにシフトする必要があるというステートメントは、どのエッジに洗練されているかを取得します。突然、これはバックエンドが存在する場所であり、接続は非同期です。パズルが開発され、靴下でさえ色が一致しました。コンベアのもう1つのステップを作成する必要があります。サービスし、制御状態ステップの前に配置します。

一般的な図は次のとおりです。

ページ/アプリケーションに入る時点で、ストアを作成し、パイプラインの最初の入力メソッドを呼び出す必要があります。これをいらいらさせるメソッドと呼び続けます。また、サイドごとに1つのサブスクリプションUIを発行します。対応するアクションを呼び出すことによる刺激メソッドは、状態を「進行インジケーター」位置に初期化し、UIサブスクリプションはそれに応じて機能し、外観を描画します。

刺激メソッドは、次のアクションにより、初期データのロード時に非同期アクションを引き起こします。サーバーから応答が来ると、パイプラインで次のパスが発生し、別のレンダリングが行われます。

マークアップには、類似のものがあります

 <button onClick={() => service.userClickedApply()} ></button>

したがって、UIレイヤーにはビジネスロジックはなく、対応するユーザーアクションでどの刺激メソッドをプルする必要があるかを示すだけです。

この場合、開発者はアプリケーションのすべてのページに共通のルートがあるか、各ページに独自のルートがあるかを判断できます。後者の場合、ストアを初期化する各ページはそのレデューサーを示す必要があります。

パイプラインの最初のステップと2番目のステップの相互作用。

サービスの名前は、この例専用に構成されたUIコンポーネントの名前に対応しています。ページは左パネル、右パネル、フッターに分解され、一部のコンポーネントを左パネルとフッターに配置することも想定されています。PaymentsとUserDataは右パネルにあります。対応するサービスとUIの対応する状態はコンポーネントに属しませんが、これらのコンポーネントが対応し、これらのコンポーネントが受け入れる形式を持っていることに注意してください。

ユーザー入力が特定のコンポーネントに関係する場合、つまり要件に従って、このユーザー入力は画面上の何かに影響を与えなくなり、この特定のコンポーネントに対応するサービスが呼び出され、そのメソッドはその状態の定義の隣にあるアクションを作成します。インターフェイス（タイムスクリプトを意味します）、および実際には減速機です。サービスは当然、このコンポーネントのレデューサーと直接接続していないため、矢印が点線で示されています。アクションは、中央のエントリポイントstに送られます。

より興味深いケースは、要件が2つのコンポーネントの状態で一度に何かを変更することを意味する場合です（たとえば、UserDataコンポーネントで）、ユーザーが[過去1年間の支払いを表示]ボタンをクリックすると、支払いテーブルが更新され、UserDataコンポーネントの[合計]フィールドが変更されます。この場合、右側のパネルに対応するサービスを呼び出し、対応するアクションをスローし、右側のパネルレデューサーがその状態と状態フィールドに対して適切なアクションを実行し、対応する純粋な関数を呼び出します。私が建築の動機付けで与えた例のように。同様に、ページ上の多くのすべてを更新する必要がある場合、たとえば、別のユーザーが選択されている場合、すべてのデータをリロードした後、ページサービスでページレデューサーレベルのアクションを呼び出す必要があります。これにより、すべてが一度に更新されます。代わりにたとえば、左パネルと右パネルのデータを別々にロードして、別々の進行状況インジケーターを表示できる場合、ページサービスから左パネルと右パネルサービスの対応するメソッドを呼び出すことができます。必要に応じてこのアクションを再生したり、これらの要求を並行して組み合わせたり、シーケンシャルにしたり、要件に最適なように独立して実行したりできます。

コンベアの3番目のステップ

私が言ったように、州への加入は1つでなければなりません。この例では、このページレベルのサブスクリプション。ページは同様のコードを想定しています

 import {store} from ... import {LeftPanel, RightPanel, Footer } from ... export class Page extends React.Component { componentWillMount() { store.subscribe(() => this.setState(store.getState())); } render() { return ( <div> <h1>Title here</h1> <LeftPanel state={this.state.leftPanel} /> <RightPanel state={this.state.rightPanel} /> <Footer state={this.state.footer /> </div> ); } }

さらに、スマートコンポーネントと愚かなコンポーネントへのまさに分割が想定されています。右側のパネルを担当するコンポーネントはこのページに固有であり、他の場所で呼び出されるとは想定されていないため、スマートにできます。つまり、特定のユーザーアクションによってトリガーされる必要がある特定の刺激を知る必要があります。また、UserDataコンポーネントは自由にバカにすることができます。また、あるシナリオでは、1つのサービスと対応するレデューサーがメモリ内のデータを管理でき、別のシナリオでは、別のページで別のサービスが非同期メソッドを呼び出します。

このようになります

 import {rightPanelService, userDataService} from ... import {UserData } from ... export class RightPanel extends React.PureComponent{ render() { const state = this.props.state; return ( <div class="right-panel"> <UserData state={state.userData} onLastYearClicked={() => rightPanelService.lastYearClicked()} onUserNameChanged={(userName) => userDataService.userNameChanged(userName)} /> <Payments state={state.payments} ...etc. /> </div> ); } }

ここでは、PureComponentが使用されているという事実に注意を払うことができます。これは、この状態でページの状態を更新するときにrightPanelフィールドの値が同じ場合、変更がページの他の部分のみに影響し、この部分には影響しない場合、右パネル以下のすべてのレンダリングが切断されることを意味します。純粋なリデューサーコードがレンダリングパフォーマンスにプラスの効果をもたらします。以前は、このPureComponentは実装が非常に簡単であるか、Redux作成者の別のライブラリからインポートされるため、自分で作成する必要がありましたが、このコンポーネントは直接リアクションに含まれます。格納庫（バージョン2、4、5 ...）では、コンポーネントの更新戦略がこれを担当します。ここで、@ Inputsのいずれも変更されていない場合（参照の等価性が暗示されている場合）、このコンポーネントのダーティチェック、実行する必要はありません。また、マークアップ内のすべての子コンポーネントはサイクルから除外されます。つまり、reactのようにレンダーブランチ全体を切断できます。

次に、UserDataコンポーネント自体

 export function UserData({state, onLastYearClicked, onUserNameChanged}) { return ( <div class="user-data"> <input value={state.userName} onChange={(newVal) => onUserNameChanged(newVal)} /> ...etc. </div> ); }

極端なテスト

少し前に別の考えが訪れました。実際、ロジックを持たないフロントエンドアプリケーションは、マークアップレンダリングがなくても機能できることがわかりました。そして、そのような事実を議論に持ち込む場合：

1）ブラウザを呼び出すことは、UI層の動作テストで時間的に最も費用のかかる操作です。

2）マークアップの機能は、アプリケーションの他の部分と比較して比較的小さい

3）マークアップは、開発者のコストの観点からテストするのに費用がかかり、一部の要素を他の要素にクロールするなどのバグを排除する通常非常に安い。

つまりテストコストは、特定できるバグの価値はありません。

しかし、そのようなアプリケーションをnodeJSで直接テストするとどうなりますか？ブラウザーを開かずに、レンダリングを実行せずに、テストで直接ストアを作成し、サービスメソッドを呼び出し、刺激的なメソッドを呼び出してユーザーアクションをシミュレートし、そのような操作の結果としてストアで判明したデータをテストします。セレン（またはそこで使用するもの）とやり取りするためのコードを記述する必要すらなく、テストは通常のテストよりも数十倍または数百倍も速くなるため、さらにテストする時間ができます。

もちろん、ブラウザでアプリケーションの起動を追加で確認するオプションもあります。各ページに一度アクセスし、ルーティングの動作をテストし、ページのルートでサブスクリプションを実行することもできます。そして、そのようなテストは、長期ストレステストがある場所に置くことができます。それは、配達の2週間ごとに1回、よく、または一晩実行されます。そして、まだ動作テストであり、まだ単体テストのレベルに落ちていないテストのほとんどは、すでに十分に高速で実行されているため、すべてのコミットで、少なくとも開発プロセスのくしゃみで実行できます。

残念ながら、このようなトリックはアンギュラーでは機能しません。アプリケーションが機能するために、すべてのサービスは@Injectableでラップされ、バックエンドリクエストにはHttp角度サービスを使用します。依存関係注入メカニズムを放棄しようとすると、Httpの代わりにネイティブフェッチを使用し、Observableの代わりにPromiseを使用すると失敗する場合があります。たとえば、async / awaitがサポートされていないことがわかっているなど、zone.jsライブラリでサポートされていないスクリプトが実行される危険性があります。

最後に

次の記事では、reduxを使用して生活を簡素化し、4つのコードのうち3つをその場で自動的に生成できるソリューションを自分から絞り出す予定です。ソリューションは、typescriptにのみ適用されます。インターフェイスで状態ツリーを記述するという事実に基づいています。

複雑さの制御とUDFアーキテクチャ