Erkunden Sie typsichere Design-Tokens in Tailwind 4-CSS-Tutorial-php.cn

Exploring Typesafe design tokens in Tailwind 4

Tailwind 4 ist schon seit einiger Zeit in Sicht, wobei das Team seine Fortschritte erstmals im März 2024 offenlegte. Eine der bemerkenswertesten Änderungen ist meiner Meinung nach die Verschiebung von einer JavaScript-basierten Konfiguration zu einer CSS-basierten Konfiguration. Tailwind 4 befindet sich derzeit in der Beta-Phase und soweit ich weiß, hat das Team immer noch mit einigen Herausforderungen zu kämpfen, insbesondere mit der Safari-Kompatibilität.

HINWEIS: Später in diesem Artikel gehen wir davon aus, dass Sie ein komponentenbasiertes Framework/eine komponentenbasierte Bibliothek verwenden, aber die besprochenen Konzepte sind leicht auf andere Ansätze übertragbar.

Änderungen in Rückenwind 4

Der Wechsel zu einer CSS-Konfiguration

Ich habe diesbezüglich einige Beschwerden gehört, insbesondere von TypeScript-Benutzern. Die Roadmap für Tailwind 4.0 sieht jedoch die Unterstützung des klassischen tailwind.config.js als oberste Priorität vor:

Unterstützung für JavaScript-Konfigurationsdateien – Wiedereinführung der Kompatibilität mit der klassischen Datei tailwind.config.js, um die Migration auf v4 zu vereinfachen.

Dennoch scheint dies in erster Linie für Migrationszwecke gedacht zu sein und möglicherweise keine nachhaltige langfristige Lösung zu sein.

Was bedeutet das für die Typsicherheit?

Unter der Haube verwendet Tailwind 4 die neuen @property-CSS-Regeln, um interne benutzerdefinierte Eigenschaften zu definieren.

Wir verwenden @property, um unsere internen benutzerdefinierten Eigenschaften mit den richtigen Typen und Einschränkungen zu definieren

So wie es aussieht, kann ich keine anständige Syntaxhervorhebungsunterstützung für @property-Regeln im VS-Code finden. Ich habe Bluesky kontaktiert, um zu sehen, ob jemand mehr Glück hatte als ich.

Ich hoffe, dass uns in Zukunft ein besserer @property-Support helfen kann, dazu später mehr.

Was ist die @property-CSS-Regel?

Die @property-Regel stellt eine benutzerdefinierte Eigenschaftsregistrierung direkt in einem Stylesheet dar, ohne dass JavaScript ausgeführt werden muss. Gültige @property-Regeln führen zu einer registrierten benutzerdefinierten Eigenschaft, die dem Aufruf von registerProperty() mit entsprechenden Parametern ähnelt.

Was sind Design-Token?

Nachdem wir nun über die bevorstehenden Änderungen in Tailwind 4 und ihre möglichen Auswirkungen gesprochen haben, nehmen wir uns einen Moment Zeit, um über Design-Tokens zu sprechen. Wenn Sie mit dem Begriff nicht vertraut sind, finden Sie hier eine kurze Erklärung: Design-Tokens sind eine Methode zum Speichern und Verwalten von Designentscheidungen in einem konsistenten, wiederverwendbaren Format, typischerweise als Variablen. Sie stellen wichtige visuelle Eigenschaften eines Designsystems wie Farben, Typografie, Abstände und Schatten auf strukturierte Weise dar. Das Ziel besteht darin, diese Designwerte zu zentralisieren, damit sie einfach aktualisiert, gepflegt und über verschiedene Plattformen und Tools hinweg geteilt werden können.

Entwurfssysteme bestehen typischerweise aus zwei Haupttypen von Werten: Systemwerten und Komponentenwerten. Ihre Systemwerte könnten beispielsweise so aussehen:

const SYSTEM_TOKENS: ISystemTokens = {
  /* ... */
  COLORS: {
    /* ... */
    GREEN: {
      LIGHT: "#E0E5D9",
      MEDIUM: "#3F6212",
      DARK: "#28331A",
    }
    /* ... */
  },
  TYPOGRAPHY: {
    /* ... */
  }
  /* ... */
}

Nach dem Login kopieren

Sie können dann in Ihren Komponenten-Tokens wie folgt auf Ihre Systemwerte verweisen:

import { SYSTEM_TOKENS } from "...";

const BUTTON_VALUES: IButtonTokens = {
  /* ... */
  COLORS: {
    /* ... */
    BACKGROUND: SYSTEM_TOKENS.COLORS.GREEN.DARK,
    /* ... */
  },
  TYPOGRAPHY: {
    /* ... */
  }
  /* ... */
}

Nach dem Login kopieren

Wenn Sie mehr über Designsysteme erfahren möchten, lohnt es sich, bekannte Systeme wie Material Design zu erkunden.

Strukturieren von Komponentendesign-Tokens mit Tailwind

Vor etwa einer Woche habe ich einen Artikel geschrieben, in dem ich einen alternativen Ansatz bespreche, den ich zum Erstellen von Komponentenvarianten mit Tailwind CSS verwende. Kurz gesagt untersucht der Artikel, wie wir CSS-Variablen zusammen mit Tailwind nutzen können, um komplexe Varianten zu verwalten und Variantenwerte durch dynamische Komponenten-Requisiten und Variablenzuordnung inline festzulegen. Wenn Sie neugierig sind, wie ich zu diesem Ansatz gekommen bin, können Sie hier mehr darüber lesen: Ein anderer Ansatz zum Schreiben von Komponentenvarianten mit Tailwind CSS.

Wir sollten damit beginnen, die Teile unserer Komponente zu identifizieren, die von Design-Tokens abhängen. Wie bereits erwähnt, umfasst dies Farben, Typografie, Abstände und alle anderen festen Systemwerte, die für Ihr Design von wesentlicher Bedeutung sind. Werfen wir einen Blick auf die folgende Button-Komponente ohne Design-Token:

<button>



<p>In the example above, we can pinpoint several values that can be tokenized. Each of the following classes could correspond to a value in our design system:</p>

<ul>
<li>p-4</li>
<li>bg-red</li>
<li>text-white</li>
</ul>

<p>Now that we've identified the values that can be tokenised, we can categorise them into two groups: static values and dynamic values. Static values are those in your component that remain constant, while dynamic values are those that can change based on the props passed to the component. For our example we'll make the padding (p-4) static, while the text colour (text-white) and background (bg-red) should be set dynamically via a theme prop.</p>

<h3>
  
  
  Creating the tokens
</h3>

<h4>
  
  
  Tailwind 4 config
</h4>

<p>First we need to define our System tokens in the new Tailwind CSS config:<br>
</p>

<pre class="brush:php;toolbar:false">@import "tailwindcss";

@theme {
  --color-white: #FFFFFF;
  --color-green-light: #E0E5D9;
  --color-green-medium: #3F6212;
  --color-green-dark: #28331A;
  --color-red-light: #F4CCCC;
  --color-red-medium: #D50000;
  --color-red-dark: #640000;

  --spacing-sm: 1rem;
  --spacing-md: 2rem;
}

Nach dem Login kopieren

Systemtokens

Als nächstes müssen wir unsere system.tokens.ts-Datei erstellen:

export type TColor = "--color-white" | "--color-green-light" | "--color-green-medium" | "--color-green-dark" | "--color-red-light" | "--color-red-medium" | "--color-red-dark";

export type TSpacing = "--spacing-sm" | "--spacing-md";


interface ISystemTokens {
  COLORS: {
    WHITE: TColor;
    GREEN: {
      LIGHT: TColor;
      MEDIUM: TColor;
      DARK: TColor;
    },
    RED: {
      LIGHT: TColor;
      MEDIUM: TColor;
      DARK: TColor;
    }
  },
  SPACING: {
    SMALL: TSpacing;
    MEDIUM: TSpacing;
  }
}

export const  SYSTEM_TOKENS: ISystemTokens {
  COLORS: {
    WHITE: "--color-white";
    GREEN: {
      LIGHT: "--color-green-light";
      MEDIUM: "--color-green-light";
      DARK: "--color-green-light";
    },
    RED: {
      LIGHT: "--color-red-light";
      MEDIUM: "--color-red-medium";
      DARK: "--color-red-dark";
    }
  },
  SPACING: {
    SMALL: "--spacing-sm";
    MEDIUM: "--spacing-md";
  }
}

Nach dem Login kopieren

Systemdesign-Tokens können in Designs wie folgt referenziert werden:
$system.COLORS.GREEN.LIGHT.

In einer idealen Welt könnten wir Typen direkt aus den @property-Regeln unserer CSS-Datei in unsere TColor- und TSpacing-Typen exportieren, ähnlich wie SCSS-Importe in JavaScript umgewandelt werden können. Leider ist dies zum jetzigen Zeitpunkt meines Wissens nach nicht möglich.

Komponenten-Token

Da wir nun unsere System-Tokens implementiert haben, können wir mit der Integration in unsere Komponenten beginnen. Der erste Schritt besteht darin, unsere Datei .tokens.ts einzurichten. Um dies zu veranschaulichen, nehmen wir das Beispiel der Button-Komponente, die wir zuvor betrachtet haben, und erstellen eine entsprechende Button.tokens.ts-Datei.

Um es noch einmal zusammenzufassen: So war unsere Button-Komponente aufgebaut:

<button>



<p>Earlier, we discussed the distinction between static values (like p-4) and dynamic values (like bg-red and text-white). This distinction will guide how we organise our design tokens. Static properties, like p-4, should be grouped under STATIC, while dynamic properties, like bg-red and text-white, should be grouped under the appropriate prop identifier. In this case, since we’re controlling bg-red and text-white through a theme prop, they should be placed under the THEME section in our tokens file. For our example we'll assume 2 theme variables - PRIMARY and SECONDARY.<br>
</p>

<pre class="brush:php;toolbar:false">import { SYSTEM_TOKENS, TColor, TSpacing } from "./system.tokens.ts";
import { TTheme } from "./Button"; // PRIMARY, SECONDARY

interface IButtonStaticTokens {
  padding: TSpacing;
}

interface IButtonThemeTokens {
  backgroundColor: TColor;
  textColor: TColor;
}

export const STATIC: IButtonStaticTokens {
  padding: "--spacing-sm";
}

export const THEME: IButtonStaticTokens {
  PRIMARY: {
    backgroundColor: "--color-red-dark";
    textColor: "--color-red-light";
  },
  SECONDARY: {
    backgroundColor: "--color-green-dark";
    textColor: "--color-green-light";
  };
}

Nach dem Login kopieren

Komponentendesign-Tokens können in Designs wie folgt referenziert werden: $component.Button.THEME.PRIMARY.backgroundColor. Meine bevorzugte Namenskonvention ist die Verwendung von:
$component...tokenName

$component: Unterscheiden Sie zwischen $system- und $component-Tokens
: Befolgen Sie die interne Dateibenennungskonvention für Komponenten
PROP_NAME: Konstanter Fall
PROP_VALUE: Sollte der internen Schreibweise des Prop-Werts folgen
Tokenname (Hintergrundfarbe): Camel case*

Dies ist letztendlich eine Frage Ihrer persönlichen Vorlieben und es liegt an Ihnen, zu entscheiden, was für Ihren Arbeitsablauf am besten funktioniert.

Bei der Benennung von Tokens weiche ich leicht von der Camel-Schreibweise ab, wenn ich ein Token für den Zustand eines Elements angeben muss, z. B. :hover. In diesen Fällen stelle ich dem Tokennamen den Status voran, gefolgt von zwei Unterstrichen, etwa so: hover__backgroundColor.

Verwendung von Design-Tokens in Komponenten

Wie ich weiter oben in dem Artikel erwähnt habe, habe ich zuvor über die Erforschung eines anderen Ansatzes zum Schreiben von Komponentenvarianten mit Tailwind CSS geschrieben. Ich werde hier auf diesen Ansatz verweisen. Wenn Sie ihn also noch nicht gelesen haben, könnte es hilfreich sein, ihn zuerst auszuprobieren, um den Kontext hinter dieser Methode zu verstehen.

In diesem Teil des Artikels wird davon ausgegangen, dass Sie ein Javascript-Framework oder eine Javascript-Bibliothek zum Erstellen Ihrer Komponenten verwenden.

Aktualisieren der Button-Komponente

Wir müssen die vorhandenen tokenisierbaren Klassen durch Tailwind-Klassen ersetzen, die auf CSS-Variablen basieren. Beachten Sie, dass die Variablennamen mit denen in unseren 2-Button-Komponenten-Token-Schnittstellen, IButtonStaticTokens und IButtonThemeTokens;
, übereinstimmen

<Schaltfläche>



<p>Nachdem wir unsere Klassen aktualisiert haben, müssen wir die Komponentenstile dynamisch anwenden und die Variablen aktualisieren. Um dies zu erreichen, verwenden wir eine variableMap-Funktion für die Komponente. Im Wesentlichen ordnet diese Funktion unsere Token aus Button.tokens.ts Inline-CSS-Variablen direkt auf der Komponente zu, auf die unsere Klassen dann verweisen können. Ein Beispiel für eine Variablenzuordnung finden Sie am Ende dieses Artikels.<br>
</p>

<pre class="brush:php;toolbar:false"><template>
  <-Taste
    :style="[variableMap(STATIC), variableMap(THEME[props.THEME])]"
   >



<h2>
  
  
  Abschluss
</h2>

<p>Ich freue mich auf die Veröffentlichung von Tailwind 4 und darauf, welche Änderungen das Team bis dahin vornehmen wird. Es hat mir Spaß gemacht, mit Ideen zu experimentieren, um einige der Herausforderungen rund um Design-Tokens, Varianten und Typsicherheit zu bewältigen.</p>

<p>Dies ist ein experimenteller Ansatz, zu dem es sicher einige starke Meinungen geben wird.</p>

<p>Wenn Sie diesen Artikel interessant oder nützlich fanden, folgen Sie mir bitte auf Bluesky (ich bin hier am aktivsten), Medium, Dev und/oder Twitter.</p>

Nach dem Login kopieren

Das obige ist der detaillierte Inhalt vonErkunden Sie typsichere Design-Tokens in Tailwind 4. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!