Design System Starter-Vorlage – alle Technologien, die Sie jemals brauchen werden

Es gibt verschiedene Möglichkeiten, wie Design-Systeme gegründet werden können – „down-top“, „top-down“, „extern“, „entstanden aus Design- oder Entwicklungsanforderungen“ und wahrscheinlich noch einige andere. Eines ist sicher: „Es ist wichtig, im Kleinen anzufangen und gleichzeitig die Zukunft im Auge zu behalten, die für nachhaltiges Wachstum von entscheidender Bedeutung ist.“

Das eigentliche Fundament, das Sie heute aufbauen, muss aktuelle Bedürfnisse unterstützen und gleichzeitig agil und durchdacht sein, um der schrittweisen Entwicklung der Anforderungen innerhalb eines Projekts oder einer Organisation gerecht zu werden. Dieser Artikel konzentriert sich auf das technische Rückgrat, das für die Schaffung eines Designsystems unerlässlich ist, das wachsenden Ambitionen gerecht werden kann.

Das ? Design System Starter Template (DSS) basiert auf den Kernkomponenten, die eine starke technische Grundlage für ein skalierbares und wartbares Design System bilden. Diese Komponenten stellen sicher, dass Design und Entwicklung konsistent, flexibel und effizient sind.

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

In den folgenden Abschnitten geben wir einen Überblick über die primären und sekundären Module der DSS-Vorlage sowie deren Dienste und Tools. Darüber hinaus werden wir ihre Kosteneffizienz in den frühen Phasen des Design Systems und ihr Potenzial in ausgereifteren Phasen untersuchen.

Die Kernkomponenten

UI-Bibliothek: Das Herzstück des Designsystems

Die DSS-UI-Bibliothek dient als zentrale Säule der DSS-Vorlage, die mit React-Aria erstellt wurde, um barrierefreie, kopflose UI-Komponenten sicherzustellen. Während React das ausgewählte Framework für die Vorlage ist, soll DSS einfach an andere Frameworks wie Vue oder Solid angepasst werden. Diese Anpassungsfähigkeit ermöglicht es Teams, die Technologien auszuwählen, die am besten zu ihren Projektanforderungen passen, ohne an einen bestimmten Stack gebunden zu sein

Für das Styling stützt sich die DSS-Benutzeroberfläche auf Vanilla-Extract, das eine robuste, skalierbare Null-Laufzeit-CSS-Basis bietet. Auch hier handelt es sich um eine flexible Wahl, die alternative Ansätze wie CSS-Module, Panda CSS, Tailwind usw. ermöglicht.

Aus Gründen der Stabilität stützen sich UI-Komponenten auf die Testbibliothek, wobei der Schwerpunkt in erster Linie auf der Funktionalität liegt. Spezifische Testszenarien sind bei thematischen (Headless-)Komponenten möglicherweise nicht relevant, in anderen Szenarien jedoch unerlässlich.

Die resultierende Komponentenstruktur sieht ziemlich einfach aus:

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

Es ist erwähnenswert, dass die DSS-Benutzeroberfläche zwar nicht einem Multi-Paket-Ansatz folgt, aber dennoch ein Tree-Shaking ermöglicht und die entsprechenden Rollup-Optionen in der Vite-Konfiguration nutzt:

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

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

Ein kritischer Aspekt der UI-Bibliothek ist die frühzeitige Einbindung von Design-Tokens. Token sind von grundlegender Bedeutung für die Aufrechterhaltung eines konsistenten Stils in allen Designsystemen, sodass selbst Projekte, die nicht die gesamte UI-Bibliothek nutzen, von einer kohärenten Designsprache profitieren können. Wenn die richtigen semantischen Token vorhanden sind, können Farben problemlos geändert werden, ohne dass umfangreiche Umgestaltungen erforderlich sind. Außerdem ist es uns beim modularen Ansatz nicht wirklich wichtig, wie Design-Tokens erstellt werden, sondern vielmehr, was ausgegeben wird.

Design-Tokens: Das Rückgrat der Konsistenz

Design-Tokens sind ein wesentlicher Bestandteil der Konsistenz und Flexibilität des Design-Systems. Sie bieten einen standardisierten Ansatz für die Gestaltung und Gestaltung aller Module und Anwendungen und stellen so sicher, dass jedes Element der Benutzeroberfläche kohärent bleibt.

DSS Farbtokens werden mit ? generiert Unicornix, ein Tool, das die Erstellung zugänglicher und anpassbarer Farbpaletten ermöglicht und einen einfachen Einstieg in die Hell- und Dunkelmodi ermöglicht. Typografie und einige andere Token werden mit ? erstellt. Design-Token-Generator. Insgesamt bietet dies eine solide Grundlage für eine weitere Skalierung, ohne auf größere Hindernisse zu stoßen.

Einhornix - npm

Unicornix – thematisch anpassbare und zugängliche Farbpaletten-Generierung. Neueste Version: 0.7.0-beta.0, letzte Veröffentlichung: vor 9 Tagen. Beginnen Sie mit der Verwendung von Unicornix in Ihrem Projekt, indem Sie „npm i unicornix“ ausführen. Es gibt ein weiteres Projekt in der NPM-Registrierung, das Unicornix verwendet.

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

• und mehr…

? Hätten Sie Interesse an einem speziellen Artikel zu diesem Thema? Lass es mich wissen!

⭐️ Außerdem hast du mehr als 2000 Wörter, Lesemeister!

Das Ziel der DSS-Vorlage besteht nicht darin, jedes einzelne Szenario zu erfüllen, sondern darin, die Branchendurchschnitts-Best Practices vorzuschlagen, die weiter auf das gewünschte Erlebnis zugeschnitten werden können. Verständlicherweise passt die Vorlage nicht auf viele Systeme, die präsentierten Muster und Schnipsel können jedoch erkundet, wiederverwendet, verbessert und hoffentlich zu neuen Kreationen inspiriert werden.

Ausgewählt, empfohlen, kommentiert

Im gesamten Artikel haben wir beobachtet, dass mehrere Technologien verwendet werden, um die DSS-Vorlage zu erstellen und ein ganzheitliches und funktionales Entwicklererlebnis zu bieten. Tatsächlich steckt noch mehr unter der Haube. Schauen Sie sich gerne die umfassende Dokumentation an.

Diese Technologien können grundsätzlich in die Kategorien „Ausgewählt“, „Empfohlen“ und „Meinungsvoreingenommen“ eingeteilt werden, so dass jede weitere voreingenommener ist als das vorherige.

Betrachten Sie Beispiele:

• React wurde als beliebteste Lösung für UI-Bibliotheken ausgewählt und eignet sich perfekt für die Demonstration des UI-Bibliotheksgerüsts.
• React-Aria wird empfohlen, da es sich um die Headless-UI-Lösung handelt, die der Barrierefreiheit Priorität einräumt; Wir müssen nicht das Rad mit typischen Funktionsmustern erfinden und viele Barrierefreiheitsprobleme sofort lösen.
• Die Verwendung von Biome zum Flusen und Formatieren ist eine Meinung Wahl (ich schätze die schlüsselfertige Konfiguration und die hervorragende Leistung) und kann durch ESLint und damit Prettier ersetzt werden.

Von allen anderen technologischen Entscheidungen möchte ich (zusätzlich) die Meinungswilligen hervorheben:

• Vanilla-Extract eignet sich als CSS-Lösung hervorragend für skalierbare Projekte, bei denen Leistung und serverseitige Rendering-Kompatibilität im Vordergrund stehen. Obwohl die Einstiegsschwelle etwas höher ist, bietet es ein sehr benutzerfreundliches CSS-in-JS-Erlebnis ohne Nachteile von CSS-in-JS.
• Nanostores ist die Lösung der Wahl, wenn es um minimalistisches und effektives globales Zustandsmanagement in den Apps geht. Es glänzt vor allem in der inselähnlichen Architektur und bei Astro-Projekten. DSS Docs verfügt über Nanostores für grundlegende Vorgänge wie das Umschalten von Themes oder Quellcode, ist aber in der Lage, viel komplexere Aufgaben zu verwalten.

Schließlich ist Typescript die Technologie, die sich durch alle drei Gruppen gleichzeitig auszeichnet. Es gibt es schon seit einiger Zeit und es hat sich zum Industriestandard entwickelt. Es wird allgemein für komplexe Projekte wie Design System empfohlen und ich würde es aus ähnlichen Gründen auch weiterhin verwenden.

---

Schlussgedanken

Die Entwicklung eines Produkts erfordert eine solide Grundlage, eine klare Roadmap, sorgfältige Vorbereitungen und zeitnahe Überarbeitungen bei jedem Meilenstein. Da sich die Anforderungen im Laufe der Zeit weiterentwickeln, sollte Ihre Technologie robust genug sein, um sich effektiv an neue Umgebungen anzupassen.

Bei Design Systems ist es all das, plus das Element des Perpetuum Mobile. Können Sie sich einen universellen Entwicklungsansatz vorstellen, der die Unvorhersehbarkeit und Vielseitigkeit von Projekten über das gute alte Markup und den Stil hinaus bewältigen kann? Vielleicht später, aber im Moment ist das einfach der Lauf der Dinge.

Das ? Design System Starter Template kann Ihnen helfen bei der Etablierung eines starken technologischen Kerns und kann sogar ein toller Ausgangspunkt werden und eine modulare und flexible Lösung für Ihr nächstes Design bieten Systemherausforderung. Meistens ist es jedoch die Grundlage für Erkenntnisse und Funken der Inspiration. Dies ist mir mehrmals während der Entwicklung von DSS passiert, soweit ich auf Tools umgestiegen bin, weshalb ich es für nützlich halte. Ich freue mich auf jeden Fall und lade Sie zu den nächsten Begegnungen ein.

Das obige ist der detaillierte Inhalt vonDesign System Starter-Vorlage – alle Technologien, die Sie jemals brauchen werden. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!