優れたコンポーネントライブラリに基づいて独自のホイールを作成する場合でも、二次パッケージングを作成する場合でも、通常、誰もが日々の開発において豊富なビジネスコンポーネントを蓄積しています。時が経つにつれ、コンポーネントの数が増えると、これらのビジネスコンポーネントの管理と共有が負担になる可能性があります。この記事では、このシナリオに新しいソリューションを提供するためにビットを紹介します。
ビットとは？
ビットはコンポーネントを活用して、アプリケーション内で再利用できるようにするだけでなく、コンポーネントをアプリケーション間およびリポジトリ間で共有できるエコシステムを提供します。
ビットは、異なるプロジェクトのコンポーネントを共有および同期できるツールです。
BitはUIコンポーネントのコラボレーションプロセスを簡素化し、チームメンバーは異なるプロジェクトから分離されたコンポーネントを共有、維持、同期できます。
ビットはどのように機能しますか？
この記事では、コンポーネント構成、コンポーネントライフサイクル、ビットワークフローと従来のコンポーネントライブラリ管理の違いを紹介するビットワークフローという3つのモジュールを紹介します。
部品
各コンポーネントについて、Bitは3つの要素を格納します
ソースコード（テストとドキュメントを含む）
コンポーネントのコンテンツは、ソースコード自体だけでなく、スタイルファイル、アセット（画像、フォント）、テストコード、ドキュメントなどの他の関連ファイルでもあります。
ディペンデンシーグラフ
ソースをBitコンポーネントに追加すると、Bitはそれが含むすべての依存関係を分析します（つまり、コード内のステートメントのインポートと要求）
依存関係グラフはコンポーネントを独立させ、参照を失うことなくコンポーネントをプロジェクト内で移動できるようにします。
構成アイテム
コンパイラー、ビットはコンパイラーを提供しますbit.envs/compilers/[email protected]
テスターは、ビットによって提供される拡張機能であり、コンポーネントに関連付けられたテストを実行してステータスを返すために使用されます。
ソースコードは、元のコンポーネントライブラリのソースコード部分に少し似ています。依存関係グラフは、インポート依存関係フェーズの分析中にwebpackによって生成されたマップに似ており、構成アイテムはwebpack.config.jsに似ています。 Bitがコンポーネントのパッケージ化を完了するのに非常に便利である理由は、その理由の一部は、Bitがコンポーネントライブラリのパッケージ化とコンパイルを支援したことです。
コンポーネントライフサイクル
プロダクションコンポーネント
プロダクションコンポーネントには、追跡、バージョン、エクスポートの3つのアクションがあります。
トラック：ワークスペースでコンポーネントファイルを指定します。
バージョン：マークされたバージョンは、そのバージョンのファイルのコンテンツとメタデータをロックします。コンポーネントにコンパイラーがある場合、Bitはコンポーネントをビルドし、ビルドされたコンポーネントをロックします（git commitとnpm releaseのようなものだと考えてください）。
エクスポート：エクスポートコマンドは、コンポーネントの一意のIDを作成します。一意のIDは、リモートスコープ名とローカルコンポーネント名です。リモートスコープ名には、任意の名前空間（username.collection？.Namespace）を含めることができます。bit.dev/yangzhedi/t ...
コンシューマーコンポーネント
は、リモートサーバーにアップロードされている限り、他のワークスペースで使用できます。コンポーネントを使用する方法は、インストールまたはインポートです。
インストール：Bitはコンポーネントを通常のNPMパッケージとしてnode_modulesフォルダーに追加します。コンポーネントをインストールする場合（ビットインストール/ npmインストール/ヤーン追加）、コンポーネントはpackage.jsonに追加され、インストールされているバージョンをポイントします： "@ bit / yangzhedi.test.list"： "0.0.1"。インストールされたコンポーネントのコードは変更されません。
'@ bit / yangzhedi.test.list'からリストをインポート;
Import：Bitはワークスペースコンポーネントフォルダーにコンポーネントを追加し、その変更を追跡します。インポートすると、package.jsonがローカルファイルを指していることがわかります： "@ bit / yangzhedi.test.list"： "file：./ components / list"、
コードの変更を追跡し、新しいバージョンにエクスポートできます。イジェクト：新しいバージョンをエクスポートする場合、インストールされているコンポーネントに戻すことができます。この場合、package.jsonは "@ bit / yangzhedi.test.list"に更新されます： "0.0.2"
ビットワークフロー
アドホック共有（一時的な共有）
_ | _
このワークフローは以下に適しています。
UIコンポーネントライブラリを備えた製品がいくつかあります。
UI / UXはプロジェクト間で一貫している必要があります。
コンポーネントを維持するための専門チームを編成する時間や能力はありません。
メリット
既存のプロジェクトで既に開発されたコンポーネントを共有するUIコンポーネントの共有ライブラリを構築して維持するために長い時間を費やす必要はありません。
デモやドキュメントなど、ポータル内のすべてのコンポーネントを収集するための検出ポータルとしてbit.devを使用します。
任意のプロジェクトのコンポーネントコードを変更でき、プロジェクト内のコンポーネントのローカル変更を保持しながら、受信する更新とマージできます。
コンポーネントはnpm / yarnを使用してインストールできるため、プロジェクト開発者の通常のワークフローに適しています。
リスク
コンポーネントのエクスポートプロセスを標準化する
中央図書館
このワークフローは以下に適しています。
UIコンポーネントを共有する必要がある集中型リポジトリ
共有UIコンポーネントを管理する専門チーム
共有コンポーネントを使用する複数のプロジェクトがあります
メリット
プロデューサー向け
Bitは、個別のパッケージを維持するオーバーヘッドを増加させることなく、各コンポーネントをより高い粒度で自動的にパックし、コンポーネントの依存関係の変更に従ってコンポーネントのバージョン管理を自動的に実行します
プロジェクトコンテキストなしでローカルにコンポーネントを構築すると、他のプロジェクトでコンポーネントが呼び出される方法に関するフィードバックループが短縮されます。
コンポーネントをbit.devに公開して、すべてのチームに見えるようにして、コンポーネントの採用率を高めます。Bitは、コンポーネントを変更しているユーザーを制御するのに役立ちます。
消費者向け
各プロジェクトに必要な小さな個別のコンポーネントを取得するには、次のようにします。アプリケーションのバンドルサイズを縮小します。
必要なコンポーネントのみを紹介できます。最終的なパッキング量を減らし、ビルド時間を短縮します。
よりきめ細かな呼び出しコンポーネントライブラリを使用すると、プロジェクトの安定性を向上させることができます。
リスク
統合されたコンポーネントライブラリの保守に専念するチームがある場合、粒度が細かすぎると負担になります
npmと何が違うのですか？
ビットは、コード分析に基づいてコードのパッケージ化を自動化します。
ビットは、プロジェクトコンテキストを離れることなくパッケージにアクセスできます（ビットインポート）。
プロデューサーの場合、コンポーネントを個別にコピーする必要はなく、直接アップロードできます
コンシューマーの場合、コンポーネントを変更する場合、クローンコンポーネントライブラリは必要ありませんが、プロジェクトで直接変更できます。
Bitは任意のプロジェクトでコンポーネントコードを使用し、直接変更することができます。
上記では、この記事では主にbit cliの使用法を紹介し、bitはnpm.orgに類似したプラットフォームのWebサイト、bit.devも提供しています。また、bit.devでコンポーネントのスタイルと呼び出しメソッドを直接確認することもできます。ドキュメントを書く必要はありません。
