👩‍🎓 🎅🏻 🐎 SOLID を考慮した再利用可能なコンポーネントの作成 👩‍🎓 ⛽️ 👲🏽

みなさん、こんにちは！ Ya Tutorial のフロントエンドを担当している Roma と申します。今日は、コードの重複を避け、高品質の再利用可能なコンポーネントを作成する方法を説明します。この記事は、Y. Subbotnik からのレポートに基づいて書かれました (ただし根拠のみです!) - 投稿の最後にビデオがあります。このトピックの理解に興味がある場合は、猫の下にようこそ。

この記事には、レポートに適合しなかった、原則のより詳細な分析と実践からの詳細な例が含まれています。このトピックを深く掘り下げて、再利用可能なコンポーネントの作成方法を学びたい場合は、これを読むことをお勧めします。一般的な用語で再利用可能なコンポーネントの世界に精通したい場合は、私の意見では、レポートの記録が適しています。

初めてのプログラミング言語に関する本、プログラミングコース、パーフェクトコードやクリーンコードなどの高品質のコードを書くための本で、コードの重複がよく話題になるため、コードの重複が悪いことは誰もが知っています。

フロントエンドでの重複を避けることが難しい理由と、再利用可能なコンポーネントを正しく書く方法を見てみましょう。そして、SOLID の原則が役立ちます。

コードの複製を止めるのが難しいのはなぜですか?

原理は単純に聞こえるでしょう。同時に、それが尊重されているかどうかを簡単に確認できます。コードベースに重複がない場合は、すべて問題ありません。実践が難しいのはなぜ？

コンポーネント Ya. チュートリアルのライブラリを使用して例を分析しましょう。昔々、プロジェクトは一枚岩でした。その後、便宜上、開発者は再利用可能なコンポーネントを別のライブラリに移動することにしました。そこに最初に到達したものの 1 つはボタンコンポーネントでした。コンポーネントは進化し、時間の経過とともに新しい「スキル」とボタンの設定が登場し、視覚的なカスタマイズの数が増えました。しばらくすると、コンポーネントが非常に高度になり、新しいタスクに使用してさらに拡張するのが不便になりました。

そのため、次のイテレーションでは、コンポーネントのコピー、Button2 が表示されました。これは非常に昔に起こったことであり、出現の正確な理由を覚えている人はいません。ただし、コンポーネントは作成されました。

大丈夫そうです - ボタンを 2 つにしてみましょう。結局のところ、それはただのボタンです。ただし、実際には、プロジェクトに 2 つのボタンを配置すると、長期的に非常に不快な結果が生じました。

スタイルを更新する必要があるたびに、どのコンポーネントでこれを行うかは明確ではありませんでした。他の場所のスタイルを誤って壊さないように、どのコンポーネントが使用されているかを確認する必要がありました。ボタン表示の新しいバージョンが登場したとき、どのコンポーネントを拡張するかを決定しました。新しい機能を目にするたびに、どのボタンを使用するかを考えました。また、1 つの場所で複数の異なるボタンが必要な場合もあり、2 つのボタンコンポーネントを 1 つのプロジェクトコンポーネントに一度にインポートしました。

長い目で見れば、ボタンの 2 つのコンポーネントの存在が苦痛であることが判明したという事実にもかかわらず、私たちは問題の深刻さをすぐには理解せず、アイコンで同様のことをすることに成功しました。コンポーネントを作成し、それが私たちにとってあまり便利ではないことに気付いたときは Icon2 を作成し、新しいタスクには適さないことが判明したときに Icon3 を作成しました。

ボタンの複製による悪影響のほぼすべてが、アイコンコンポーネントで繰り返されました。プロジェクトでアイコンがあまり使用されないため、少し簡単になりました。正直言って、それはすべて機能に依存します。さらに、ボタンとアイコンの両方で、新しいコンポーネントを作成するときに古いコンポーネントは削除されませんでした。削除するには、プロジェクト全体でバグが発生する可能性があるため、多くのリファクタリングが必要だったからです。では、ボタンとアイコンのケースの共通点は何でしょうか? プロジェクト内の重複の出現についても同じスキーム。現在のコンポーネントを再利用して新しい条件に適応させることは困難だったので、新しいコンポーネントを作成しました。

コンポーネントの複製を作成することで、私たちは将来の生活を複雑にします。コンストラクターのように、既成のブロックからインターフェースを組み立てたかったのです。これを便利に行うには、簡単に入手して使用できる高品質のコンポーネントが必要です。 問題の根本は、再利用を計画していたコンポーネントが正しく記述されていないことです。それを拡張して他の場所に適用することは困難でした。

再利用可能なコンポーネントは、十分に用途が広く、同時にシンプルでなければなりません。彼と一緒に仕事をするのは苦痛ではなく、大砲からスズメを撃つようなものであってはなりません。一方、コンポーネントは、スクリプトを少し変更しただけでは、"Component2" を記述した方が簡単であることが明確にならないように十分にカスタマイズできる必要があります。

SOLID 再利用可能なコンポーネントに向けて

高品質のコンポーネントを作成するには、頭字語 SOLID の背後にある一連のルールが必要です。これらの規則は、関数とデータ構造をクラスに結合する方法と、クラスを互いに結合する方法を説明しています。

なぜ厳密に堅実であり、他の一連の原則ではないのですか? SOLID ルールは、アプリケーションを適切に設計する方法を教えてくれます。プロジェクトを安全に開発し、新しい機能を追加し、既存の機能を変更すると同時に、すべてを壊さないようにします。私の意見では、良いコンポーネントとは何かを説明しようとしたとき、私の基準が SOLID の原則に近いことに気付きました。

Sは単独責任の原則です。
O - オープン/クローズの原則。
L はリスコフの置換原理です。
I - インターフェースの分離の原則。
D - 依存関係逆転の原則。

これらの原則の一部は、コンポーネントの説明に適しています。他のものは、フロントエンドのコンテキストでより大げさに見えます。しかし、これらはすべて一緒に、高品質のコンポーネントに関する私のビジョンをよく表しています。

私たちは原則に従いますが、単純なものから複雑なものまで順を追って説明します。まず、多くの状況で役立つ基本的なことを見てみましょう。次に、より強力で具体的な状況を見てみましょう。

この記事では、React + TypeScript のコード例を示します。私が最もよく使うフレームワークとして React を選びました。その代わりに、好きな、または適した他のフレームワークを使用できます。TS の代わりに、純粋な JS を使用できますが、TypeScript を使用すると、コードでコントラクトを明示的に記述できるため、複雑なコンポーネントの開発と使用が簡単になります。

ベーシック

開閉原理

ソフトウェアエンティティは、拡張に対してオープンであり、変更に対してクローズする必要があります。つまり、既存のコードを変更することなく、新しいコードで機能を拡張できる必要があります。どうしてそれが重要ですか？新しい機能を追加するために既存のモジュールを編集するたびに、プロジェクト全体が不安定になります。常に変化しているので、壊れる可能性がある場所がたくさんあります。

ボタンの例で原理の適用を考えてみましょう。ボタンコンポーネントを作成し、スタイルを設定しました。これまでのところ、すべてがうまく機能しています。しかし、その後、新しいタスクが発生し、このボタンの特定の 1 つの場所で、さまざまなスタイルを適用する必要があることがわかりました。

^{ボタンは、コードを編集しないと変更できないように記述されています}

現在のバージョンで異なるスタイルを適用するには、ボタンコンポーネントを編集する必要があります。問題は、コンポーネントがカスタマイズできないことです。グローバルスタイルを記述するオプションは信頼性が低いため、考慮しません。どんな編集でも壊れる可能性があります。ボタンの代わりに、たとえば日付ピッカーコンポーネントなど、より複雑なものを配置した場合の結果は容易に想像できます。

オープン/クローズの原則に従って、新しいスタイルを追加するときにボタンのコードを書き直す必要がないようにコードを書くべきです。コンポーネントのスタイルの一部を外部に投げることができれば、すべてがうまくいきます。これを行うには、コンポーネントの新しいスタイルを記述するために必要なクラスを渡す小道具を作成します。

//    ,    
import cx from 'classnames';

//    — mix
const Button = ({ children, mix }) => {
  return (
    <button
      className={cx("my-button", mix)}
    >
      {children}
    </button>
}

これで、コンポーネントをカスタマイズするためにコードを編集する必要がなくなりました。

このかなり一般的な方法を使用すると、コンポーネントの外観をカスタマイズできます。追加のクラスがコンポーネント自体のクラスと混ざっているため、これはミックスと呼ばれます。コンポーネントを外部からスタイル設定する方法は、クラスを渡すことだけではないことに注意してください。 CSS プロパティを持つオブジェクトをコンポーネントに渡すことができます。 CSS-in-JS ソリューションを使用できますが、本質は変わりません。ミックスは、MaterialUI、Vuetify、PrimeNG など、多くのコンポーネントライブラリで使用されます。

ミックスについてどのような結論を導き出すことができますか?実装が簡単で用途が広く、最小限の労力でコンポーネントの外観を柔軟にカスタマイズできます。

しかし、このアプローチにも欠点があります。自由度が高いため、セレクターの特異性に問題が生じる可能性があります。また、カプセル化も解除されます。正しい CSS セレクターを生成するには、コンポーネントの内部構造を知る必要があります。これは、コンポーネントをリファクタリングするときにそのようなコードが破損する可能性があることを意味します。

成分変動

コンポーネントには、そのコアとなるパーツがあります。それらを変更すると、別のコンポーネントが得られます。ボタンの場合、これは状態と動作のセットです。ホバーとクリックの効果により、ユーザーはボタンをチェックボックスなどと区別します。一般的な作業ロジックがあります。ユーザーがクリックすると、イベントハンドラーがトリガーされます。これはコンポーネントのコアであり、ボタンをボタンにするものです。はい、例外はありますが、ほとんどのユースケースでそのように機能します。

また、使用する場所によって部品が変化する部分もあります。スタイルはこのグループに属します。別のサイズや色のボタンが必要になるかもしれません。異なるストロークとフィレット、または異なるホバー効果。すべてのスタイルは、コンポーネントの変更可能な部分です。ボタンが違うように見えるたびに新しいコンポーネントを書き直したり作成したりしたくはありません。

頻繁に変更されるものは、コードを変更せずに微調整する必要があります。そうしないと、古いコンポーネントをカスタマイズして追加するよりも新しいコンポーネントを作成する方が簡単な状況に陥ってしまいますが、十分な柔軟性がないことが判明しました。

テーマ

ボタンの例を使用したコンポーネントビジュアルのカスタマイズに戻りましょう。次の方法は、テーマを適用することです。テーマとは、コンポーネントが複数のモードで異なる場所に表示される機能を意味します。この解釈は、明るいテーマと暗いテーマのコンテキストでのテーマ設定よりも広いです。

テーマの使用は、ミックスによる以前の方法を除外するものではありませんが、それを補完します。コンポーネントには複数の表示メソッドがあり、使用する場合は目的のメソッドを指定する必要があると明示的に言います。

import cx from 'classnames';
import b from 'b_';

const Button = ({ children, mix, theme }) => (
  <button
    className={cx(
     b("my-button", { theme }), mix)}
  >
    {children}
  </button>
)

たとえば、プロジェクトに 20 個のボタンがあり、各ボタンのスタイルがアプリケーションの場所で設定されているため、すべてが少し異なって見える場合、テーマ設定を使用すると、スタイルの動物園を避けることができます。このアプローチは、オーバーエンジニアリングを恐れることなく、すべての新しいコンポーネントに適用できます。コンポーネントの外観が異なる場合があることがわかっている場合は、最初から明示的にテーマを設定することをお勧めします。これにより、さらなるコンポーネント開発が簡素化されます。

ただし、欠点もあります。この方法はビジュアルのカスタマイズにのみ適しており、コンポーネントの動作に影響を与えることはできません。

コンポーネントのネスト

新しい関数を追加するときにコンポーネントコードの変更を回避する方法をすべて挙げたわけではありません。他の原則は、残りの原則を調べることによって示されます。ここでは、子コンポーネントとスロットについて言及したいと思います。

Web ページは、コンポーネントのツリーのような階層です。各コンポーネントは、何をどのようにレンダリングするかを決定します。しかし、常にそうとは限りません。たとえば、ボタンを使用すると、内部でレンダリングされるコンテンツを指定できます。React では、主なツールはchildren propsとrender propsです。Vue には、より強力なスロットの概念があります。これらの機能を使用して単純なコンポーネントを作成する場合、問題はありません。ただし、複雑なコンポーネントであっても、コンポーネントが上から表示する必要のある一部の要素のスローを使用できることを忘れないでください。

上級

以下に説明する原則は、より大きなプロジェクトに適しています。対応する手法により柔軟性が向上しますが、設計と開発の複雑さが増します。

単一責任の原則

単一責任の原則は、モジュールが変更する理由はただ 1 つでなければならないことを意味します。

どうしてそれが重要ですか？原則に違反した場合の結果には、次のようなものがあります。

システムの一部を編集するときに、別のものを壊すリスク。
悪い抽象化。その結果、複数の機能を実行できるコンポーネントが作成され、コンポーネントが何をすべきで何をすべきでないかを正確に理解することが難しくなります。
コンポーネントの不便な作業。すべてを一度に実行するコンポーネントを改善したり、バグを修正したりすることは非常に困難です。

テーマの例に戻って、単一責任の原則が尊重されているかどうかを見てみましょう。すでに現在の形で、テーマはそのタスクに対処していますが、これはソリューションに問題がなく、改善できないという意味ではありません。

^{1 つのモジュールがさまざまな人によってさまざまな理由で編集されている}

すべてのスタイルを 1 つの css ファイルに入れたとしましょう。さまざまな理由でさまざまな人によって編集される可能性があります。単独責任の原則に違反していることが判明しました。誰かがスタイルをリファクタリングでき、別の開発者が新しい機能を微調整します。そのため、何かを簡単に壊すことができます。

SRP 準拠のテーマ設定がどのように見えるかを見てみましょう。完璧な絵: ボタンと、それ用のテーマのセットが別にあります。ボタンにテーマを適用して、テーマ付きのボタンを取得できます。ボーナスとして、たとえばコンポーネントライブラリに配置するために、いくつかの利用可能なテーマでボタンを組み立てたいと思います。

^{念願の塗装。テーマは個別のエンティティであり、ボタンに適用できます。}

テーマはボタンをラップします。これは、当社の内部コンポーネントライブラリである Lego で使用されているアプローチです。 HOC (High Order Components) を使用して基本コンポーネントをラップし、新しい機能を追加します。たとえば、テーマを付けて表示する機能。

HOC は、コンポーネントを受け取り、別のコンポーネントを返す関数です。テーマを持つ HOC は、ボタン内にスタイルを持つオブジェクトをスローできます。以下はかなり教育的なオプションです。実際には、よりエレガントなソリューションを使用できます。たとえば、クラスをコンポーネントにスローして、そのスタイルを HOC にインポートしたり、CSS-in-JS ソリューションを使用したりできます。

ボタンのテーマを設定するための単純な HOC の例:

const withTheme1 = (Button) =>
(props) => {
    return (
        <Button
            {...props}
            styles={theme1Styles}
        />
    )
}

const Theme1Button = withTheme1(Button);

HOC は、特定のテーマが指定されている場合にのみスタイルを適用できます。それ以外の場合は、何もしません。そのため、一連のテーマでボタンを組み立て、テーマの小道具を指定することで必要なものをアクティブにすることができます。

複数の HOC を使用して、目的のテーマのボタンを収集します。

import "./styles.css";
 
//   .     
const ButtonBase = ({ style, children }) => {
 console.log("styl123e", style);
 return <button style={style}>{children}</button>;
};
 
const withTheme1 = (Button) => (props) => {
 // HOC  ,     "theme1"
 if (props.theme === "theme1") {
   return <Button {...props} style={{ color: "red" }} />;
 }
 
 return <Button {...props} />;
};
 
const withTheme2 = (Button) => (props) => {
 // HOC  ,     "theme2"
 if (props.theme === "theme2") {
   return <Button {...props} style={{ color: "green" }} />;
 }
 
 return <Button {...props} />;
};
 
// -      HOC
const compose = (...hocs) => (BaseComponent) =>
 hocs.reduce((Component, nextHOC) => nextHOC(Component), BaseComponent);
 
//  ,    
const Button = compose(withTheme1, withTheme2)(ButtonBase);
 
export default function App() {
 return (
   <div className="App">
     <Button theme="theme1">"Red"</Button>
     <Button theme="theme2">"Green"</Button>
   </div>
 );
}

そして、ここで私たちは責任の領域を分割する必要があるという結論に達します。コンポーネントが 1 つあるように見えても、そうですか?おそらく、それはいくつかの層に分割されるべきであり、それぞれが特定の機能を担当します。ほとんどの場合、ビジュアルレイヤーはコンポーネントロジックから切り離すことができます。

テーマを個別のエンティティに分離すると、コンポーネントの使いやすさが向上します。ライブラリにボタンを配置して、必要に応じてユーザーが独自のテーマを作成できるようにすることができます。トピックはプロジェクト間で簡単に手探りできます。これにより、インターフェイスの一貫性を維持し、元のライブラリを過負荷にすることはありません。

レイヤーへの分割を実装するためのさまざまなオプションがあります。上記の例は HOC を使用していましたが、合成も可能です。ただし、テーマはスタンドアロンのコンポーネントではないため、テーマの場合は HOC の方が適切だと思います。

別のレイヤーに取り込めるのはビジュアルだけではありません。ただし、問題は非常に全体的なものであるため、HOC へのビジネスロジックの転送について詳しく検討する予定はありません。私の意見では、自分が何をしているのか、なぜそれが必要なのかを理解していれば、これを行うことができます。

複合部品

より複雑なコンポーネントに移りましょう。Select を例として取り上げ、単一責任の原則の使用法を見てみましょう。Select は、より小さなコンポーネントの構成と考えることができます。

コンテナ - 他のコンポーネント間の通信。
フィールド - 通常の選択のテキストと、ユーザーが何かを入力する CobmoBox コンポーネントの入力。
アイコン - 選択用のフィールドにある従来のアイコン。
メニューは、選択項目のリストを表示するコンポーネントです。
アイテムはメニュー内の別のアイテムです。

単一責任の原則に準拠するには、すべてのエンティティを個別のコンポーネントに取り、全員が編集する理由を 1 つにする必要があります。ファイルをカットすると、次の質問が発生します。結果として得られるコンポーネントのセットをどのようにカスタマイズするか? たとえば、フィールドに暗いテーマを設定する必要がある場合は、アイコンを拡大してメニューの色を変更します。これを実現するには 2 つの方法があります。

オーバーライド

最初の方法は簡単です。ネストされたコンポーネントのすべての設定を元のコンポーネントの props に移動します。ただし、ソリューションを「正面から」適用すると、選択には非常に多くの小道具があり、理解しにくいことがわかります。それらを何とか便利に整理する必要があります。ここでオーバーライドの出番です。これは、コンポーネントに転送される構成であり、各要素をカスタマイズできます。

<Select
  ...
  overrides={{
    Field: {
      props: {theme: 'dark'}
    },
    Icon: {
      props: {size: 'big'},
    },
    Menu: {
      style: {backgroundColor: '#CCCCCC'}
    },
  }}
/>

props をオーバーライドする簡単な例を示しました。ただし、オーバーライドはグローバル構成と考えることができます。これにより、コンポーネントがサポートするすべてが構成されます。これが実際にどのように機能するかは、BaseWebライブラリで確認できます。

全体として、オーバーライドを使用すると、複合コンポーネントを柔軟にカスタマイズでき、このアプローチも適切に拡張できます。短所: 複雑なコンポーネントの構成は非常に大きくなり、オーバーライドの力にはマイナス面があります。内部コンポーネントを完全に制御できるため、奇妙なことをしたり、無効な設定を公開したりできます。また、ライブラリを使用せずに自分でアプローチを実装したい場合は、構成を理解するようにコンポーネントに教えるか、それを読み取ってコンポーネントを正しく構成するラッパーを作成する必要があります。

依存関係逆転の原則

構成をオーバーライドする代替案を理解するために、SOLID の文字 D に目を向けましょう。これが依存関係逆転の原則です。彼は、高レベルのポリシーを実装するコードは、低レベルの詳細を実装するコードに依存すべきではないと主張しています。

選択に戻りましょう。コンテナは、コンポーネントの他の部分間の通信を担当します。実際、残りのブロックのレンダリングを制御するのはルートです。これを行うには、それらをインポートする必要があります。

依存関係の反転を使用しない場合、複雑なコンポーネントのルートは次のようになります。

import InputField from './InputField';
import Icon from './Icon';
import Menu from './Menu';
import Option from './Option';

コンポーネント間の依存関係を分析して、何が問題になるかを理解しましょう。これで、上位レベルの Select は下位レベルの Menu に依存します。これは、それ自体をインポートするためです。依存関係逆転の原則が破られています。これにより問題が発生します。

まず、メニューを変更する場合は、選択を編集する必要があります。
次に、別のメニューコンポーネントを使用する場合は、選択コンポーネントも編集する必要があります。

^{別のメニューで選択する必要がある場合はどうすればよいかわかりません}

依存関係を拡張する必要があり^ます。メニューコンポーネントが選択に依存するようにします。依存関係の反転は依存関係の挿入によって行われます - Select は、パラメーターの 1 つとしてメニューコンポーネントを受け入れる必要があります。ここでタイピングが役に立ちます。Select が期待しているコンポーネントを示します。

//     Select      
const Select = ({
  Menu: React.ComponentType<IMenu>
}) => {
  return (
    ...
    <Menu>
      ...
    </Menu>
    ...
  )
...
}

これは、小道具が特定のインターフェースを満たすメニューコンポーネントが選択に必要であることを宣言する方法です。次に、DI 原則が指示するように、矢印が反対方向を指します。

^{矢印が展開されています。これが依存関係逆転の仕組みです。}

依存関係の問題は解決しましたが、糖衣構文とヘルパーツールはここで歓迎します。

毎回、すべての依存関係をレンダリング場所のコンポーネントに投入するのは面倒ですが、bem-react ライブラリには依存関係レジストリと構成プロセスがあります。彼らの助けを借りて、依存関係と設定を一度パッケージ化するだけで、既製のコンポーネントを使用することができます。

import { compose } from '@bem-react/core'
import { withRegistry, Registry } from '@bem-react/di'

const selectRegistry = new Registry({ id: cnSelect() })

...

selectRegistry.fill({
    'Trigger': Button,
    'Popup': Popup,
    'Menu': Menu,
    'Icon': Icon,
})

const Select = compose(
    ...
    withRegistry(selectRegistry),
)(SelectDesktop)

上記の例は、bem-react の例を使用したコンポーネントアセンブリの一部を示しています。完全なサンプルコードとサンドボックスは、yandex UIストーリーブックにあります。

依存関係逆転の使用から何が得られますか?

フルコントロール - コンポーネントのすべてのコンポーネントをカスタマイズする自由。
柔軟なカプセル化 - コンポーネントを非常に柔軟で完全にカスタマイズできるようにする機能。必要に応じて、開発者はコンポーネントを構成するすべてのブロックをオーバーライドして、必要なものを取得します。この場合、構成済みの既製のコンポーネントを作成するオプションが常にあります。
スケーラビリティ - この方法は、あらゆるサイズのライブラリに適しています。

Yandex.Tutorial では、DI を使用して独自のコンポーネントを作成しています。内部の Lego コンポーネントライブラリもこのアプローチを採用しています。しかし、これには重大な欠点が 1 つあります。それは、はるかに複雑な開発です。

再利用可能なコンポーネントの開発の難しさ

再利用可能なコンポーネントを開発する上での難しさは何ですか?

まず、長くて丁寧なデザイン。コンポーネントの構成部品と変更可能な部品を理解する必要があります。すべての部分を変更可能にすると、理解するのが難しい大量の抽象化になってしまいます。変更可能なパーツが少なすぎると、コンポーネントの柔軟性が不十分になります。将来の再利用の問題を回避するには、改善する必要があります。

第二に、コンポーネントに対する高い要件。コンポーネントがどの部分で構成されるかを理解しています。次に、お互いについて何も知らなくても、一緒に使用できるようにそれらを作成する必要があります。再利用性を考慮せずに開発するよりも難しいです。

第三に、前のポイントの結果としての複雑な構造。本格的なカスタマイズが必要な場合は、コンポーネントのすべての依存関係を再構築する必要があります。これを行うには、それがどの部分で構成されているかを深く理解する必要があります。プロセスには、優れたドキュメントが不可欠です。

チュートリアルには、教育力学が配置されている内部コンポーネントライブラリがあります。これは、子供たちが問題を解決する際に対話するインターフェースの一部です。そして、教育サービスの共有ライブラリがあります。異なるサービス間で再利用したいコンポーネントをそこに置きます。

すでに動作するコンポーネントがあり、新しい機能を追加しない場合、1 人の整備士の転送には数週間かかります。この作業のほとんどは、コンポーネントを独立したチャンクに分割し、それらを共有できるようにすることです。

リスコフの置換原則

前の 2 つの原則は何をすべきかに関するもので、最後の 2 つの原則は何を壊してはならないかに関するものです。

バーバラ・リスコフの置換原理から始めましょう。彼は、プログラム内のオブジェクトは、プログラムの正しい実行を中断することなく、サブタイプのインスタンスに置き換えられるべきだと言っています。

通常、コンポーネントをクラスとして作成したり、継承を使用したりすることはありません。すべてのコンポーネントは、箱から出してすぐに交換できます。これが現代のフロントエンドの基礎です。強い型付けは、間違いを避け、互換性を維持するのに役立ちます。

すぐに使用できる交換可能性はどのように壊れますか? コンポーネントには API があります。API とは、コンポーネントの一連の小道具と、フレームワークに組み込まれたメカニズム (イベントハンドラーメカニズムなど) を意味します。IDE での強い型付けと lint は、API の非互換性を強調することができますが、コンポーネントは外部と対話し、API をバイパスできます。

グローバルストアに対して何かを読み書きする、
ウィンドウと対話し、
クッキーとの対話、
ローカルストレージの読み取り/書き込み、
ネットワークにリクエストを送信します。

コンポーネントは環境に依存し、別の場所や別のプロジェクトに移動すると壊れる可能性があるため、これはすべて安全ではありません。

リスコフの置換原則に準拠するには、次のものが必要です。

タイピング機能を使用し、
コンポーネント API をバイパスする相互作用を避ける
副作用を避ける。

非 API インタラクションを回避する方法は? コンポーネントが依存するすべてのものを API に入れ、外の世界からのデータを props に転送するラッパーを作成します。たとえば、次のように:

const Component = () => {
   /*
       ,     ,       .
      ,          .
          ,   ,   .
   */
   const {userName} = useStore();
 
   //     ,       ( ,       ).
   const userToken = getFromCookie();
 
   //  —   window      .
   const {taskList} = window.ssrData;
 
   const handleTaskUpdate = () => {
       //    API .      .
       fetch(...)
   }
 
   return <div>{'...'}</div>;
  };
 
/*
          .
      ,         .
*/
const Component2 = ({
   userName, userToken, onTaskUpdate
}) => {
   return <div>{'...'}</div>;
};

インターフェース分離の原則

多くの専用インターフェイスは、1 つの汎用インターフェイスよりも優れています。この原則をフロントエンドコンポーネントに明確に伝えることはできませんでした。そのため、API に注意を払う必要があると理解しています。

できるだけ少ないエンティティをコンポーネントに転送し、コンポーネントで使用されていないデータを転送しないようにする必要があります。コンポーネント内の多数の props は注意が必要です。ほとんどの場合、SOLID の原則に違反しています。

どこでどのように再利用しますか?

高品質のコンポーネントを作成するのに役立つ原則について説明しました。次に、それらをどこでどのように再利用するかを見てみましょう。これは、発生する可能性のある他の問題を理解するのに役立ちます。

コンテキストは異なる場合があります。同じページの他の場所でコンポーネントを使用する必要がある場合や、たとえば、他の会社のプロジェクトでコンポーネントを再利用したい場合など、これらはまったく異なるものです。いくつかのオプションを強調します

。まだ再利用は必要ありません。コンポーネントを作成しましたが、それは特定のものであり、他の場所で使用する予定はないと考えています。追加の努力をする必要はありません。また、元に戻したい場合に役立ついくつかの簡単な手順を実行できます。したがって、たとえば、コンポーネントが環境にあまり結び付いていないこと、および依存関係がラップされていることを確認できます。将来のカスタマイズのための予約をすることもできます: テーマを追加するか、コンポーネントの外観を外部から変更する機能 (ボタンの例のように) - 時間はかかりません。

同じプロジェクトで再利用します。コンポーネントを作成し、現在のプロジェクトの他の場所で再利用したいと確信しています。上に書いたことはすべてここに関連しています今になって初めて、外部ラッパーのすべての依存関係を削除することが不可欠であり、外部からカスタマイズできることが非常に望ましいです (テーマまたはミックス)。コンポーネントに多くのロジックが含まれている場合、どこでも必要かどうか、または一部の場所で変更する必要があるかどうかを検討する必要があります。 2 番目のオプションについては、カスタマイズの可能性を考慮してください。ここでは、コンポーネントの構造について考え、必要に応じてパーツに分割することも重要です。

同様のスタックで再利用します。コンポーネントが、自分と同じスタックを持つ隣接するプロジェクトで役立つことを理解しています。これは、上記のすべてが必須になる場所です。さらに、依存関係とテクノロジーを注意深く監視することをお勧めします。隣接するプロジェクトは、あなたとまったく同じバージョンのライブラリを使用していますか? SASS と TypeScript は同じバージョンを使用していますか?

また、SSR などの別のランタイム環境での再利用についても強調したいと思います。コンポーネントが SSR でレンダリングできるかどうか、またレンダリングできる必要があるかどうかを決定します。その場合は、事前に期待どおりにレンダリングされることを確認してください。deno や GraalVM などの他のランタイムがあることに注意してください。使用する場合は、それらの機能を考慮してください。

コンポーネントライブラリ

コンポーネントを複数のリポジトリやプロジェクト間で再利用する必要がある場合は、ライブラリに移動する必要があります。

スタック

プロジェクトで使用されるテクノロジが増えるほど、互換性の問題を解決することが難しくなります。動物園を減らし、フレームワーク、言語、大規模なライブラリのバージョンなど、使用されるテクノロジーの数を最小限に抑えるのが最善です。本当に多くのテクノロジーが必要だと理解すれば、それを受け入れることを学ばなければなりません。たとえば、Web コンポーネント上でラッパーを使用したり、すべてを純粋な JS で収集したり、コンポーネントにアダプターを使用したりできます。

サイズ

ライブラリの単純なコンポーネントを使用すると、バンドルに数メガバイトが追加される場合、それは問題ありません。このようなコンポーネントは再利用したくありません。なぜなら、独自の軽量バージョンをゼロから作成する可能性が正当化されるからです。 size-limit などのサイズ制御ツールを使用して問題を解決できます。

モジュール性を忘れないでください。コンポーネントを使用したい開発者は、すべてのライブラリコードをプロジェクトにドラッグするのではなく、コンポーネントだけを使用できるようにする必要があります。

モジュラーライブラリが 1 つのファイルにコンパイルされていないことが重要です。また、ライブラリが使用する JS バージョンを追跡する必要もあります。ES.NEXT でライブラリをビルドし、ES5 でプロジェクトをビルドすると、問題が発生します。また、古いバージョンのブラウザー用にアセンブリを適切に構成し、すべてのライブラリユーザーがその内容を理解できるようにする必要があります。これが複雑すぎる場合は、別の方法があります - 各プロジェクトで独自のライブラリ構築ルールを設定します。

更新

ライブラリを更新する方法を事前に検討してください。すべてのクライアントとそのカスタムスクリプトを知っているとよいでしょう。これは、移行と破壊的変更についてよりよく考えるのに役立ちます。たとえば、あなたのライブラリを使用しているチームは、リリース前に重大な変更を伴うメジャーアップデートについて知るのは非常にイライラするでしょう。

他の誰かが使用しているライブラリにコンポーネントを移動すると、リファクタリングのしやすさが失われます。リファクタリングの負担が大きくならないように、新しいコンポーネントをライブラリにドラッグしないことをお勧めします。それらは変更される可能性が高いため、互換性の更新と維持に多くの時間を費やす必要があります。

カスタマイズとデザイン

デザインは再利用性に影響しませんが、カスタマイズの重要な部分です。私たちのチュートリアルでは、コンポーネントはそれ自体では存在せず、その外観はデザイナーによって設計されています。デザイナーにはデザインシステムがあります。コンポーネントがシステムとリポジトリで異なって見える場合、問題を回避することはできません。デザイナーと開発者は、インターフェイスの外観について同じ考えを持っていないため、不適切な決定につながる可能性があります。

コンポーネントショーケース

コンポーネントショーケースは、デザイナーとのやり取りを簡素化するのに役立ちます。人気のあるショーケースソリューションの 1 つは Storybookです。このツールまたは別の適切なツールを使用して、開発者以外の誰にでもプロジェクトコンポーネントを見せることができます。

ショーケースにインタラクティブ機能を追加します - デザイナーはコンポーネントを操作し、それらがどのように表示され、さまざまなパラメーターで機能するかを確認できる必要があります。

コンポーネントを更新するときにストアフロントが自動的に更新されるように構成することを忘れないでください。これを行うには、プロセスを CI に移動する必要があります。これで、設計者はプロジェクトに含まれる既製のコンポーネントをいつでも確認して使用できます。

デザインシステム

開発者にとって、デザインシステムは、プロジェクト内のコンポーネントの外観を管理する一連のルールです。コンポーネントの動物園が大きくならないようにするために、カスタマイズを制限することができます。

もう 1 つの重要な点は、プロジェクト内の設計システムとコンポーネントのタイプが互いに異なる場合があることです。たとえば、大幅な再設計があり、コード内のすべてを更新できない場合や、コンポーネントを調整する必要があるが、設計システムに変更を加える時間がない場合などです。このような場合、機会があればすぐにデザインシステムとプロジェクトを同期させることは、あなたの利益にもデザイナーの利益にもなります。

最後の普遍的かつ明白なアドバイスは、コミュニケーションと交渉です。デザイナーを開発の傍ら、レイアウトの作成・編集のみを行う者として捉える必要はありません。彼らと緊密に連携することで、高品質のインターフェースを設計および実装するのに役立ちます。最終的に、これは共通の目的に利益をもたらし、製品のユーザーを喜ばせます。

結論

コードが重複すると、開発が困難になり、フロントエンドの品質が低下します。結果を回避するには、コンポーネントの品質を監視する必要があり、SOLID の原則は高品質のコンポーネントを作成するのに役立ちます。

現時点で問題を迅速に解決するコンポーネントよりも、将来に備えて優れたコンポーネントを作成する方がはるかに困難です。同時に、優れた「レンガ」は解決策の一部に過ぎません。コンポーネントをライブラリに持ち込む場合は、それらの操作を便利にする必要があり、設計システムと同期する必要もあります。

ご覧のとおり、タスクは簡単ではありません。高品質の再利用可能なコンポーネントを開発することは難しく、時間がかかります。その価値はありますか？誰もがこの質問に自分自身で答えると信じています。小規模なプロジェクトの場合、オーバーヘッドが非常に高くなる可能性があります。長期的な開発が計画されていないプロジェクトの場合、コードの再利用に投資することも物議を醸す決定です。しかし、「これは今は必要ない」と言ったとしても、再利用可能なコンポーネントが不足しているため、発生しなかった可能性のある多くの問題が発生する状況に陥ってしまうことは容易に見過ごされます。だから、私たちの過ちを繰り返さないで、自分自身を繰り返さないでください!

レポートを見る

SOLID を考慮した再利用可能なコンポーネントの作成