モジュラー React アーキテクチャ-jsチュートリアル-php.cn

Modular React architecture

モジュラーアーキテクチャについて

モジュラーアーキテクチャとは何ですか?そうではない例を見てみましょう。
私たちはそれを変革するために取り組んでいきます。最後までに、あなたはそのことに納得するかもしれません
メリットがあるのか、それとも膨大な時間の無駄なのか。

これは、私が仕事で成長を意識して経験した実際のシナリオです。名前と詳細
匿名化されていますが、共通の概念の実例を見て歩くのは楽しいはずです
少なくとも。

要件とその検索方法

私たちのサイトにはサイトヘッダーにボタンがあります。いくつ表示されます
ユーザーが残した V-Bucks には、いくつかのビジネスロジックが組み込まれています:

サイトに初めてアクセスする場合は、ポップオーバーを開いて歓迎します V-Bucks で何かできることを示してください
彼らが < を持っている場合残り 5 V-Bucks、ポップオーバーのアップセルをさらに表示
ユーザーが Basic ユーザーの場合は、1 つのスタイルのボタンを表示します。 SuperDuper ユーザーの場合、表示別のさらに派手なボタン

など。弊社のプロダクトマネージャーやプロジェクトマネージャーもそのようなケースが多いです
そして、デザインマネージャーとグループV-Bucksのディレクターは、私たちが次のことを行う必要があると夢見ていました
ハンドル。

インターンのジンボは、これを実装する任務を負っています。なぜなら、それは単なる
だからです。ボタン!

彼は、Figma デザインの 15 の矛盾する反復を精査します。彼は
を見つけました要件は、PM の数と同じ数の個別の Word ドキュメントに記載されます。彼は組織化して

を明らかにするために、7 つのチームとの 7 回の知識伝達セッションに耐えます。どのサービスが必要なデータを提供するかについての古代の独自の知識
ユーザーのタイプと V-Bucks の数。コンテンツチームは、
について彼を安心させました。すべての文字列の最終バージョンは、年末までに法務およびマーケティングによって承認される予定です
これで、このボタンを作成する準備が整いました。

ハッカーのアプローチ

これが彼の V-Bucks ボタン、ポップオーバー、および関連性の最初の反復です
ビジネスロジック。

Jimbo は、自分が考え出したシンプルなディレクトリ構造に満足しています。

そこで彼はこのボタンを作り始めました。それはまったく無邪気に始まりました。

彼は初めての試みを実装しました。 VBucksPopover も同様に複雑です
ビジネスロジック、エラー処理、状態管理、スタイル、およびコメント
配送という名の技術的負債。

このボタンは 400 行弱で、非常にシンプルです。たとえポップオーバーが
であってもさらにスパゲッティを500本。本当に「掃除」するのか、それとも分割するのか
私たちやユーザーに何らかの利益をもたらしますか？場合によります。これだけあれば十分です
このボタン、気にしないでください。先に進みましょう!

しかし、2 か月が経過し、別の製品チームの PM とデザイナーが気に入っています
あなたのボタンをアプリのヘッダーに含めたいと考えています。彼らは単純なリストを持っていますが、
はありません彼らの側からの圧力、彼らがあなたに対応してもらいたいいくつかの変更、そしてもし
LT の一日の終わりまでに到着予定日をお知らせいただけると助かります、ありがとうございます:

ボタンのスタイルを更新し、表示されるアプリに基づいてテキストを表示します
アプリごとにまったく異なるポップオーバーのセットを表示します
ユーザーが V-Bucks を使い果たしたときに、新しい全社標準のアップセルモーダルを開きます。ただし、一部の地域でのみ、16 歳以上のユーザーのみが対象です。実験グループA

Jimbo はこの新しい機能をすべて同じコンポーネントに組み込むことができますか?

はい。分割やリファクタリングはユーザーに利益をもたらしますか、それともマネージャーに好印象を与えますか?

いいえ。しかし、このレベルの複雑さでは、リファクタリングにはいくつかの強力な議論があります。

開発者の正気
リファクタリングをしなかったために PIP を受けた Jimbo を置き換える開発者の正気
回数を増やすと、次回は最初からうまくできます
後でブログに書くこと

モジュール式アーキテクチャのアプローチ

クリーンコードの道徳を開始し、それを十分に知っている他の肛門タイプ
Stack Overflow で定期的に答えてください、そしてあなたの祖父母さえも何かを見てください
このように:

KISS、DRY、およびその他の頭字語ブランケット
関心事の分離
原子性!デカップリング！オノマトペ!

これらは素晴らしいもので、Jimbo の次の試みを知らせるのに役立ちます。
以降、彼は PIP を受けませんでした予定より早く配信し、共有することで実際にプロモーションを獲得しました
会議や書類がたくさんあります。

しかし今では彼はより賢明になり、これらの格言を実践するクールな方法を学びました。見えます
このようなもの:

ボタンとポップオーバーの定型文が大量にあるように見えます。なぜこれが
になるのでしょうか？良いですか?

場合によります。以下はジンボ氏の簡単な概要と根拠です:

各コンポーネントをコンテナーとレンダラーに分割します
状態とビジネスロジックをフックに移動します
コンテナはフックを使用し、すべての小道具をレンダラーに渡します
レンダラーは、提供されたものをレンダリングすることだけに関係します
共通の機能、ビジネスロジック、または定数をユーティリティに含めることができます
タイプごとにファイルを分けます。複数のファイルでインポートされる傾向があります。とにかく抽出する必要がある円形のdepsになります
抽出された TailwindCSS -- 詳細は以下で説明します

無限に拡張可能です! これらの構成要素は
によって分解されません。コード行や「複雑さ」などの任意のルール。それらは
によって分解されます。目的: それぞれの概念的な境界は単一の目的を果たします。

PM が新しいポップオーバーを 10 個作成することを要求していますか?問題ありません -- Jimbo のアーキテクチャは可能です
対処してください。

リーダーは一部のアプリの売上に関するより良い指標を望んでいますが、他のチームは望んでいません
これをサポートするテレメトリを構築するための資金を持っています。素晴らしい！私たちは
を持っていますさまざまな変化に合わせて水平方向に拡張できるテレメトリユーティリティ
要件。

大幅な再設計は、すべてのポップオーバーに異なるものを表示する必要があることを意味します。
さまざまな条件に基づいて。通常、 がすべて になったので、
はるかに
簡単になります。私たちがレンダリングするものと、それをレンダリングするために使用するすべてのロジックは、明確に定義された
内に存在します。ブロック。それらはもはや対立と論理の巨大な山の中に混在していません

チェーンの長さは 20 行です。

このコンテナ/レンダラパターンのサンプルは次のとおりです:

余談
: TailwindCSS ドキュメントでは、このような共通クラスの抽出に @apply を使用しないことを明示的に推奨しています。これにより、バンドルサイズの違いはほぼゼロになり、「クラス名を考え出す必要がある」という点を除けば、それ以外の違いは生じません。実稼働グレードの CSS は、ほとんどの場合、特定のコンポーネント内でスタイルを必要とする要素の数を増やすと、数十行の長さになります。このトレードオフは、90% の場合、価値があると思われます。

残りの既存および新規のビジネスロジックはフックとユーティリティ内に存在します!

この新しいアーキテクチャは熱狂的な人々を満足させ、物事の拡張や拡張を容易にします
削除するか移動します。

明確に定義されているため、単体テストの作成が苦痛でなくなります
境界線。レンダラーは、
に対して 10 個の異なるサービスをモックする必要がなくなりました。入力が与えられると、一連の光沢が表示されることを検証します。あなたのフックは次のことができます
意図したビジネスロジックと一致するかどうかを単独でテストします。

州層全体が変更されただけですか?あなたの
にコードが含まれていたら残念です。フックはそれを使用するコードと密接に結合していましたが、今ではより単純になりました

変更しても、レンダラーはまだ入力を待っているだけです。

最終的な考え

このモジュール式アーキテクチャは多くのボイラープレートを追加し、最終的には次のことを実現します

メリットはゼロです。

情熱的なプロジェクトに取り組んでいる場合や、
配送と価値の提供を何よりも優先します。何かありましたら
時間の経過とともに範囲が拡大する可能性があるようです。
POC 後に完全にオーバーホールすると、技術的負債を削減できる場合があります。

Plop などのツールを使用して、このボイラープレートを生成できます。

では、ジンボの作品とモジュラーアーキテクチャから実際に何を学んだのでしょうか?

学校で習うクリーンコードと頭字語、そして世界のウェル・アシュアリーズ
スペクトルの一端です。機能的なスパゲッティコードをハッキングするのは別の作業です

最終的にすべてのコードは技術的負債であるため、多くの場合は非常にうまく機能します。

最良の解決策は、ある量子状態またはこれらの目的の組み合わせに存在し、
私たちが選択する道は、おそらく以下に基づいて決定されます: