デザイン システム スターター テンプレート - 必要なすべてのテクノロジー

Design System を設立するには、いくつかの方法があります。—ダウントップ、トップダウン、外部、設計または開発のニーズに由来するもの、そしておそらくその他の方法もあります。 1 つ確かなことは、将来のセットアップに目を光らせながら、物事を小さく始めることが重要であり、これは持続可能な成長にとって非常に重要です。

あなたが今日構築する基盤は、プロジェクトや組織内で要件が段階的に進化するのに十分なように機敏で考え抜かれながら、現在のニーズをサポートする必要があります。この記事では、拡大する野心を満たすデザイン システムを作成するために不可欠な技術的バックボーンに焦点を当てます。

? デザイン システム スターター テンプレート (DSS) は、スケーラブルで保守可能なデザイン システムの強力な技術基盤を確立するコア コンポーネントに基づいて構築されています。これらのコンポーネントにより、設計と開発の一貫性、柔軟性、効率性が確保されます。

⭐️ https://github.com/XOP/design-system-starter

次のセクションでは、DSS テンプレートのプライマリ モジュールとセカンダリ モジュール、およびそのサービスとツールについて概要を説明します。さらに、Design System の初期段階での費用対効果と、より成熟した段階での可能性を探ります。

コアコンポーネント

UI ライブラリ: デザイン システムの中心

DSS UI ライブラリは、DSS テンプレートの中心的な柱として機能し、アクセシビリティ最優先のヘッドレス UI コンポーネントを確保するために、react-aria で構築されています。 React はテンプレートに選ばれたフレームワークですが、DSS は Vue や Solid などの他のフレームワークに簡単に適応することを目的としています。この適応性により、チームは特定のスタックに縛られることなく、プロジェクトのニーズに最も合ったテクノロジーを選択できるようになります

スタイリングについて DSS UI は、堅牢でスケーラブルなゼロランタイム CSS ベースを提供する vanilla-extract に依存しています。繰り返しますが、これは柔軟な選択であり、CSS モジュール、Panda CSS、Tailwind などの代替アプローチが可能です。

安定性のために、UI コンポーネントはテスト ライブラリに依存し、第一に機能に重点を置いています。特定のテスト シナリオは、テーマ付き (ヘッドレス) コンポーネントの場合には関連しない可能性がありますが、他のシナリオでは不可欠です。

結果として得られるコンポーネント構造は非常に単純です:

Switch/
  index.ts
  Switch.css.ts       - styles created with vanilla-extract
  Switch.spec.tsx     - tests using testing-library
  Switch.stories.tsx  - documentation with Storybook stories
  Switch.tsx          - component based on react-aria

DSS UI は マルチパッケージ アプローチに従っていないにもかかわらず、Vite 設定のそれぞれのロールアップ オプションを利用してツリーシェイキングが可能であることは言及する価値があります:

// named import
import { Button } from '@ds-starter/ui';

// default import
import Button from '@ds-starter/ui/components/Button/Button';

UI ライブラリの重要な側面は、デザイン トークンの早期組み込みです。トークンは、デザイン システム全体で一貫したスタイルを維持するための基礎であり、完全な UI ライブラリを利用していないプロジェクトでも、一貫したデザイン言語の恩恵を受けることができます。適切なセマンティック トークンを配置すると、大規模なリファクタリングを必要とせずに色を簡単に変更できます。また、モジュラーアプローチでは、デザイントークンがどのように構築されるかはあまり気にせず、むしろ何が出力されるのかを気にします。

デザイントークン: 一貫性のバックボーン

デザイン トークンは、デザイン システムの一貫性と柔軟性に不可欠です。これらは、すべてのモジュールとアプリケーションにわたるテーマとスタイルに対する標準化されたアプローチを提供し、UI のすべての要素の一貫性を確保します。

DSS カラートークン は ? を使用して生成されます。 Unicornix は、アクセスしやすくカスタマイズ可能なカラー パレットを作成できるツールで、ライト モードとダーク モードを簡単に開始できます。タイポグラフィーやその他のトークンは ? で作成されます。デザイントークンジェネレーター。全体として、これにより、大きな障害に遭遇することなくさらに拡張するための強固な基盤が提供されます。

ユニコーニクス - npm

Unicornix - テーマに対応したアクセス可能なカラー パレットの生成。最新バージョン: 0.7.0-beta.0、最終公開日: 9 日前。 「npm i unicornix」を実行して、プロジェクトで unicornix の使用を開始します。 npm レジストリには、unicornix を使用するプロジェクトが他に 1 つあります。

npmjs.com

DSS Tokens are available in both CSS and JavaScript formats, to reflect and support different project needs, from simple websites to complex web applications. Theming can be done in several ways, and here we fully rely on CSS custom properties.

Here is an excerpt from the generated CSS.

It’s easy to note that theme can be swapped completely by changing a single data attribute:

:root[data-theme="light"], [data-theme="light"] {
  --awsm-color-content-strong: rgb(24, 26, 27);
  --awsm-color-content-regular: rgb(45, 47, 49);
  --awsm-color-background-regular: rgb(255, 255, 255);
  --awsm-color-background-subtle: rgb(236, 237, 237);
}

:root[data-theme="dark"], [data-theme="dark"] {
  --awsm-color-content-strong: rgb(255, 255, 255);
  --awsm-color-content-regular: rgb(229, 230, 231);
  --awsm-color-background-regular: rgb(0, 0, 0);
  --awsm-color-background-subtle: rgb(9, 10, 11);
}

JS tokens can be consumed as CSS refs, containing the references to values, rather than the color strings. This approach is great for semantic variables and theming without sacrificing performance:

export const tokens = {
  content: {
    strong: "var(--awsm-color-content-strong)",
    regular: "var(--awsm-color-content-regular)",
  },
  background: {
    regular: "var(--awsm-color-background-regular)",
    subtle: "var(--awsm-color-background-subtle)",
  }
}

Icons and Fonts: Modular Visual Language

The Icons and Fonts modules add depth to the visual language. Icons are managed through an efficient process that generates components from SVG files using SVGR and tsup. This ensures that icons are consistent and can be flexibly integrated across the system.

Similar to UI components, icons can be also imported individually:

// named import
import { IconX } from '@ds-starter/icons';

// default import
import IconX from '@ds-starter/icons/lib/IconX';

// Source (SVG) import
import IconXSrc from '@ds-starter/icons/svg/x.svg';

The Fonts package offers a convenient solution for managing typography within the Design System. It supports both base64-encoded fonts for quick setups and Google Fonts integration for more robust implementations, giving teams the flexibility to choose the best approach for their project’s needs while maintaining consistent typography across all digital products.

It’s worth noting that while base64 encoding is efficient, it’s not effective for production setup. Yet in the early stages it can be a common denominator for consistent typography. Of course going further this should be replaced with the more appropriate fonts-loading strategy.

---

Now, the question arises — should you setup Icons and Fonts packages from the start? The answer naturally depends, however in most typical scenarios it will be a “no”. More agile environment in the early stages is crucial and less dependencies is the key. Yet, keeping in mind the upcoming structure and incorporating that in the early setup is a good idea, shaving off a couple of dozen “story points” in the future refactorings.

Documentation — Storybook and Beyond

Storybook: A Multi-Purpose Development Tool

Storybook is an important tool for UI development, serving primarily as a development environment and a documentation portal on early stages of Design System. It allows to visualize and interact with UI components in various states and configurations, resolving issues early in the development process.

Storybook in DSS is a standalone app that does not itself host any stories — they all are collected across the packages and composed in one central hub. This way DSS Storybook can document color palettes, typography, iconography etc. along with the UI components from different sources after a simple setup.

? Note that there is no storybook composition per se, 

yet it’s also possible as one does not deny the other.

Explore the deployed demo here: https://ds-starter-storybook.vercel.app/

Beyond its direct functionality, DSS Storybook is additionally equipped with Visual Regression Testing (VRT) and Accessibility Testing using Playwright. Such automation is essential for large design systems, where manual testing could quickly grow ineffective and time-consuming. By integrating these tests into the development workflow (early), DSS ensures that the Design System can evolve fast without fear of regressions.

While being an irreplaceable tool for early-stage documentation, consolidating component documentation and visual examples into a single platform, Storybook is not actually a documentation website. With time, more sophisticated, content-oriented and customizable solution is demanded, especially for the Design System consumers far apart from technology.

Documentation Website: Design System Knowledgebase

As the Design System matures, the need for more detailed and accessible documentation becomes paramount. The DSS Documentation Website (DSS Docs) addresses this need by providing a dedicated application for organizing and presenting information about the Design System.

Explore the deployed demo here: https://ds-starter-docs.vercel.app/

DSS Docs is designed to be minimalistic yet highly functional and customizable. It includes several modules that can be tweaked and modified to meet the project purpose. Powered by Astro and enhanced with nanostores state manager, DSS Docs implies two main types of content: Articles and Component Documentation.

Articles offer in-depth insights into Design System concepts, provide guidelines, patterns and describe foundational layers in detail. To add a new Article is as easy as simply to place a Markdown file into the respective folder.

Component Documentation includes interactive examples dynamically loaded from the Storybook stories. This integration solves a couple of issues — it ensures consistency across the “Dev” and “Prod” documentation and avoids redundancy in content creation. 

? As a bonus — component examples can be edited in the UI library and will be automatically picked up by Docs running in dev mode. Not a Storybook replacement, but can be useful for cosmetic updates.

New Component Documentation can be added with a MDX file, following a particular schema. Apart from the main description, extra sections can be added following the “Usage” pages example.

Expandable structure of DSS Docs allows for easy updates and tweaks, making it an essential tool for teams looking to step up from Storybook without significant effort and creating redundancy. The Documentation app is themed with DSS Tokens to ensure a consistent look and feel of the main product.

Automation and Workflow Best Practices

Scripts and Github Actions Automation

DSS leverages a series of scripts to handle essential tasks like testing, linting, formatting, and dependency management. Turborepo offers great help for running scripts effectively, especially when every module adheres to a unified standard.

What’s more, everything that we run locally, including Visual Regression Testing — can be done on CI, thanks to Github Actions. Apart from the thorough quality checks, Github Actions will take care of apps deployment too (powered by Vercel). Naturally, all scripts are configurable and optional.

Changelog and Release Management

DSS uses Changesets to automate the processes of changelog generation and packages releases, ensuring every change is tracked and properly versioned. Needless to say, both processes are supported by Github Actions as well.

Here are some examples of published NPM packages:

• @ds-starter/fonts

• @ds-starter/icons

• @ds-starter/tokens

• @ds-starter/ui

Component Generator

To further enhance productivity, DSS includes a Turbo-powered Generator that simplifies the process of scaffolding new UI components. Apart from saving time, this allows to greatly reduce the human-error-copy-paste factor.

# Run a generator
$ pnpm run gen:ui

After replying to a series of prompts, you will get the following:

• New component scaffolded in the DSS UI package, containing all respective files

• Same component added to the DSS Docs application, with the correct MDX frontmatter data

Like almost everything in DSS, generator template can and most probably need to be tweaked to the project needs. This is a completely arbitrary operation, however using generator can be very beneficial for contributors, onboarding of team members and scenarios like codebase migration.

Flexible Technology Stack

Main Design Principle

Design System technological stack is an arbitrary matter, however it’s for sure not random. It’s a natural effect of multiple contributing factors, including, but not limited to:

• product scope and project peculiarities

• initial size and future ambitions

• teams expertise and proficiency

• contributors and consumers proficiency

• client requirements and technical stack

• overall codebase age and historical reasons

• existing technical debt

• cross-platform and cross-browser support

• maintainability requirements

• existing or upcoming deadlines

• industry trends and market volatility

• organization structural changes

• その他…

?これに関する特別な記事にご興味はありますか?教えてください!

⭐️ また、読書チャンピオン、あなたは 2000 語を超えました!

DSS テンプレートの目的は、すべてのシナリオに準拠することではなく、希望するエクスペリエンスに合わせてさらに調整できる業界平均のベスト プラクティスを提案することです。当然のことですが、テンプレートは多くのシステムには適合しませんが、提示されたパターンやスニペットは調査、再利用、改善でき、新しい創作のインスピレーションとなることが期待されます。

選択された、推奨された、意見が述べられた

記事全体を通じて、DSS テンプレートを構成し、総合的で機能的な開発者エクスペリエンスを提供するために複数のテクノロジーが使用されていることがわかりました。実際には、内部にはさらに多くの機能があります。包括的なドキュメントを参照してください。

これらのテクノロジーは基本的に「選択」、「推奨」、「意見あり」のカテゴリに分類できるため、次のテクノロジーはそれぞれより偏ったものになります。前回。

例を考えてみましょう:

• React は UI ライブラリの最も人気のあるソリューションとして選ばれ、UI ライブラリ スキャフォールディングのデモンストレーションに最適です。
• React-Aria はアクセシビリティを優先したヘッドレス UI ソリューションであるため、推奨です。一般的な機能パターンで車輪を発明したり、アクセシビリティに関する多くの懸念事項をすぐに解決したりする必要はありません。
• リンティングとフォーマットに Biome を使用することは 意見のある選択であり (ターンキー構成と優れたパフォーマンスに感謝しています)、ESLint や Prettier に置き換えることもできます。

他のすべての技術的選択肢のうち、意見のあるものを (さらに) 強調したいと思います。

• CSS ソリューションとしての Vanilla-extract は、パフォーマンスとサーバー側レンダリングの互換性を優先するスケーラブルなプロジェクトに最適です。エントリのしきい値は若干高くなりますが、CSS-in-JS の欠点がない、非常にフレンドリーな CSS-in-JS エクスペリエンスを提供します。
• Nanostores は、アプリ内で最小限かつ効果的なグローバル状態管理を行う場合に頼りになるソリューションです。特に島のような建築物やアストロプロジェクトでそれが光ります。 DSS Docs は、テーマやソース コードの切り替えなどの基本操作用のナノストアを備えていますが、さらに複雑なタスクを管理することもできます。

最後に、Typescript は、3 つのグループすべてに同時に属している の中で際立っているテクノロジーです。これは業界標準になるまでしばらく前から存在しており、一般に Design System のような複雑なプロジェクトに推奨されており、私も同様の理由でさらに使用する予定です。

---

最後に

製品を構築するには、強固な基盤、明確なロードマップ、慎重な準備、そしてマイルストーンごとのタイムリーな改訂が必要です。時間の経過とともに要件が進化するにつれて、テクノロジーは新しい設定に効果的に適応できる十分な回復力を備えている必要があります。

デザイン システムでは、すべてに永久運動の要素を加えたです。古き良きマークアップとスタイルを超えて、プロジェクトの予測不可能性と多用途性に対処できる普遍的な開発アプローチを考えられますか?おそらく後になるかもしれませんが、今のところ、これが単なるやり方です。

? デザイン システム スターター テンプレート は、強力な技術コアの確立に役立ち、次の設計にモジュール式で柔軟なソリューションを提供する優れた出発点になる可能性もあります。システムチャレンジ。ただし、ほとんどの場合、それは洞察のための基礎とインスピレーションの火花です。 DSS の開発中に何度か、ツールに重点を置いてこのようなことが起こったので、これが役立つと思います。次の出会いを楽しみにしています。

以上がデザイン システム スターター テンプレート - 必要なすべてのテクノロジーの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。