Modèle de démarrage de système de conception – Toute la technologie dont vous aurez besoin

Il existe plusieurs manières de fonder un système de conception — de bas en haut, de haut en bas, de manière externe, en fonction des besoins de conception ou de développement et probablement d'autres. Une chose est sûre  : il est important de commencer petit, tout en gardant un œil sur la configuration future, cruciale pour une croissance durable.

La fondation que vous construisez aujourd'hui doit prendre en charge les besoins actuels tout en étant agile et réfléchie pour suffire à l'évolution progressive des exigences au sein d'un projet ou d'une organisation. Cet article se concentre sur la épine dorsale technique, essentielle pour créer un Design System capable de satisfaire des ambitions croissantes.

Le ? Le Modèle de démarrage du système de conception (DSS) est construit sur les composants de base qui établissent une base technique solide pour un système de conception évolutif et maintenable. Ces composants garantissent que la conception et le développement sont cohérents, flexibles et efficaces.

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

Dans les sections suivantes, nous présenterons les modules primaires et secondaires du modèle DSS, ainsi que ses services et outils. De plus, nous explorerons leur rentabilité dans les premières étapes du Design System et leur potentiel dans les étapes plus matures.

Les composants de base

Bibliothèque d'interface utilisateur : le cœur du système de conception

La bibliothèque DSS UI sert de pilier central du modèle DSS, construit avec React-aria pour garantir l'accessibilité des composants d'interface utilisateur sans tête. Bien que React soit le framework sélectionné pour le modèle, DSS est censé être facilement adapté à d'autres frameworks comme Vue ou Solid. Cette adaptabilité permet aux équipes de choisir les technologies les plus adaptées aux besoins de leur projet sans être enfermées dans une stack spécifique

Pour le style, l'interface utilisateur DSS s'appuie sur vanilla-extract, qui fournit une base CSS robuste, évolutive et sans exécution. Encore une fois, c'est un choix flexible, permettant des approches alternatives comme les modules CSS, Panda CSS, Tailwind etc.

Pour la stabilité, les composants de l'interface utilisateur s'appuient sur la bibliothèque de tests, en se concentrant en premier lieu sur la fonctionnalité. Des scénarios de tests spécifiques peuvent ne pas être pertinents dans le cas de composants thématiques (sans tête), mais essentiels dans d'autres scénarios.

La structure des composants résultante semble plutôt simple :

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

Il convient de mentionner que même si l'interface utilisateur DSS ne suit pas une approche multi-package, elle permet toujours le tremblement d'arborescence, en exploitant les options de cumul respectives dans la configuration Vite :

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

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

Un aspect essentiel de la bibliothèque d'interface utilisateur est l'incorporation précoce des jetons de conception. Les jetons sont essentiels au maintien d'un style cohérent dans tous les systèmes de conception, permettant même aux projets qui n'utilisent pas la bibliothèque complète de l'interface utilisateur de bénéficier d'un langage de conception cohérent. Avec les jetons sémantiques appropriés en place, les couleurs peuvent être facilement modifiées sans avoir besoin d’une refactorisation massive. De plus, avec l'approche modulaire, nous ne nous soucions pas vraiment de comment les jetons de conception sont construits, mais plutôt de ce qui est généré.

Jetons de conception : l'épine dorsale de la cohérence

Les jetons de conception font partie intégrante de la cohérence et de la flexibilité du système de conception. Ils fournissent une approche standardisée en matière de thème et de style dans tous les modules et applications, garantissant ainsi que chaque élément de l'interface utilisateur reste cohérent.

Les

DSS les jetons de couleur sont générés à l'aide de ? Unicornix, un outil qui permet de créer des palettes de couleurs accessibles et personnalisables, permettant de démarrer facilement avec les modes clair et sombre. La typographie et quelques autres jetons sont créés avec ? Générateur de jetons de conception. Dans l’ensemble, cela fournit une base solide pour une mise à l’échelle ultérieure sans rencontrer d’obstacles majeurs.

unicornix-npm

Unicornix - génération de palettes de couleurs thématiques et accessibles. Dernière version : 0.7.0-beta.0, dernière publication : il y a 9 jours. Commencez à utiliser unicornix dans votre projet en exécutant « npm i unicornix ». Il y a 1 autre projet dans le registre npm utilisant unicornix.

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

• et plus encore…

? Seriez-vous intéressé par un article dédié à ce sujet ? Faites-le-moi savoir !

⭐️ De plus, vous avez dépassé les 2000 mots, champion de la lecture !

L'objectif du modèle DSS n'est pas de se conformer à chaque scénario, mais de suggérer les meilleures pratiques moyennes du secteur qui peuvent être davantage adaptées à l'expérience souhaitée. C'est compréhensible, le modèle ne s'adapte pas à de nombreux systèmes, mais les modèles et extraits présentés peuvent être explorés, réutilisés, améliorés et, espérons-le, inspirer de nouvelles créations.

Sélectionné, recommandé, avisé

Tout au long de l'article, nous avons observé que plusieurs technologies étaient utilisées afin de composer le modèle DSS et d'offrir une expérience de développement holistique et fonctionnelle. En fait, il y en a plus sous le capot, bienvenue pour explorer la documentation complète.

Ces technologies peuvent être essentiellement regroupées en catégories « Sélectionnées », « Recommandées » et « Opinionnées », de sorte que chacune des technologies suivantes soit plus biaisée que le précédent.

Considérez des exemples :

• React est Sélectionné pour être la solution la plus populaire pour les bibliothèques d'interface utilisateur, elle est parfaite pour la démonstration de l'échafaudage de bibliothèque d'interface utilisateur.
• React-Aria est Recommandé, car c'est la solution d'interface utilisateur sans tête qui donne la priorité à l'accessibilité ; nous n'avons pas besoin d'inventer la roue avec des modèles fonctionnels typiques et de résoudre de nombreux problèmes d'accessibilité dès le départ.
• Utiliser Biome pour le peluchage et le formatage est un choix avisé (j'apprécie la configuration clé en main et les performances époustouflantes) et peut être remplacé par ESLint et c'est-à-dire plus joli.

Parmi tous les autres choix technologiques, je voudrais (en plus) souligner les avisés :

• L'extrait de vanille en tant que solution CSS est idéal pour les projets évolutifs qui donnent la priorité aux performances et à la compatibilité du rendu côté serveur. Bien qu'il ait un seuil d'entrée un peu plus élevé, il offre une expérience CSS-in-JS très conviviale sans inconvénients CSS-in-JS.
• Nanostores est la solution incontournable en matière de gestion globale minimaliste et efficace de l’état dans les applications. Il brille dans l’architecture insulaire et les projets Astro en particulier. DSS Docs propose des nanostores pour les opérations de base telles que le changement de thème ou de code source, mais il est capable de gérer des tâches beaucoup plus complexes.

Enfin, Typescript est la technologie qui se démarque en étant dans les trois groupes simultanément. Il existe depuis un certain temps pour devenir un standard de l'industrie, il est généralement recommandé pour des projets complexes comme Design System et je l'utiliserais également davantage pour des raisons similaires.

---

Pensées finales

La création de n'importe quel produit nécessite une base solide, une feuille de route claire, des préparations minutieuses et des révisions en temps opportun à chaque étape. À mesure que les exigences évoluent au fil du temps, votre technologie doit être suffisamment résiliente pour s'adapter efficacement aux nouveaux paramètres.

Avec Design Systems, c'est tout cela, plus l'élément de mouvement perpétuel. Pouvez-vous penser à une approche de développement universelle capable de gérer l’imprévisibilité et la polyvalence des projets au-delà du bon vieux balisage et style ? Peut-être plus tard, mais pour l'instant, c'est ainsi que les choses se passent.

Le ? Le Modèle de démarrage du système de conception peut vous aider à établir un noyau technologique solide et peut même devenir un excellent point de départ, fournissant une solution modulaire et flexible pour votre prochaine conception. Défi du système. Cependant, pour l’essentiel, il s’agit de fonds de réflexion et d’étincelles d’inspiration. Cela m'est arrivé plusieurs fois lors du développement de DSS au point de pivoter sur les outils, c'est pourquoi je pense que c'est utile. Je vous attends avec impatience et vous invite aux prochaines rencontres.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!