使い方は変わりません。スタイルを渡すことで実現できます。使うとデザインシステムコンポーネントを簡単に実装できます。デザインシステムを実装する上で優れていると感じた点を紹介します。レベルがあわず、利用したかった機能が使えなかった、という体験をしたことがあるでしょう。ライブラリとして提供されています。レベルを気にすることなく、新しい機能を使うことができます。愛好者たちにとって素晴らしいニュースだと思います。コンポーネントを実装する場合を考えてみましょう。両方を使わなければなりませんでした。定義したどのようなスタイルが実際に適用されるのか、プレビューで確認するのは難しく、実際にビルドしてみなければならないことがほとんどでした。デザインシステムを適用する場合を見てみましょう。併用する必要はほとんどありません。コンポーネントの実装ができると言えるでしょう。ある同名の定義に上書きされる可能性があります。prefix(dls_、internal_など)をつけて重複を回避する解決法がありますが、根本的な解決策ではありません。おかげで解決できます。するなど、簡単に可視性を制御できます。Composableこれはデザインシステムを実装するにあたって強い機能だと思います。システムでは、サブビューをパラメータとして受けとって表示できるコンポーネントを作る場合にどれくらい大変か想像してみてください。これはデザインシステムコンポーネントのデザインによくある設計です。関数を使ってコンポーネントを構築することが一般的です。パラメータで受け取ることができます。移行することをお勧めします。さんに寄稿いただいたゲスト記事です。System)はプロダクト開発において重要な役割を担うようになっています。オープンソースのデザインシステムを採用する例や、自社のデザインシステムを構築する例は多くみられます。使ったデザインシステムの実装をしました。今回は、その実装方法をご紹介します。いうデザインシステムがすでに存在しているのに、「なぜ別で構築する必要があるのだろうか?」という疑問を持つ方もいらっしゃるのではないでしょうか。スペックがフィットしないケースが多々あります。ある程度カスタマイズし、拡張することが必要になります。:本記事はデザインシステムそのものに関する説明ではありません。略称で、コードのコンフリクトを避けるために、プレフィックスとして使われています。デザイン技術的観点に集中するために、とてもシンプルなデザインシステムを用意しました。プロダクトレベルのデザインシステムとの違いは規模感(スタイルの数と種類)だけで、基本の考え方は変わりません。種類のスタイルを用意しました。これから実装していきます。Style(Token)まず使用する色を定義します。これらをまとめたカラーパレットを用意することで、テーマやブランドに応じて配色を切り替えられるようにします。Color(0xFFFF3D71)}次にカラーパレットのインターフェースを定義します。色をオーバーライドするために用意しました。Colors}定義したカラーパレットを実装することで、実際の配色を定義します。カラーをオーバーライドすることは必須ではありません。実装時に色を指定するコードを減らすことができます。同様にダークモード用のカラーパレットも用意します。色が入れ変わっています。プロダクトレベルのデザインシステムでは、カラーテーマごとに違うパレットを用意するといった構築方法も利用されます。サイズ指定サイズの定義はとてもシンプルです。デバイス画面のサイズによってサイズを変更するといった複数のバリエーションを持つ必要がある場合は、カラーパレットと同様の方法で対応できます。64.dp)Typographyタイポグラフィもサイズの定義と同様、シンプルに定義します。テーマに応じてフォントを使い分ける必要がある場合、また言語によって使用するフォントを切り替えたい場合など、複数のフォントバリアントのサポートが必要な場合があります。その場合は、配色と同様に実装することで対応できます。フォントをオーバーライドするために用意しました。追加する必要があります。テーマ(ブランド)によって変化する可能性のあるスタイルを外から受け取れます。