Ich habe Tailwind falsch verwendet, das ist also nicht nötig

Vor etwa 3 Jahren bin ich auf Tailwind CSS gestoßen, eine großartige Bibliothek für die Website-Entwicklung. Um diesen Artikel kurz zu halten, werde ich bei der Einleitung keine Worte verschwenden. Es gibt bereits viele Quellen, aus denen man lernen kann. Stattdessen möchte ich eine Geschichte über einen Fehler erzählen, den ich in meinen frühen Tagen bei Tailwind immer wieder gemacht habe. Es besteht kein Grund, in die gleiche Grube zu fallen wie ich.

Tailwind sprengt das traditionelle Konzept von Kaskaden-Stylesheets, indem es CSS-Regeln in sogenannte Dienstprogrammklassen verpackt. Anstatt CSS-Regeln in CSS-Dateien zu verfassen, verfassen Sie Klassennamen direkt in DOM-Elementen. Obwohl sich dieser Ansatz zunächst unnatürlich und seltsam anfühlt, ergibt er schnell einen Sinn. Es hat ungefähr einen Tag gedauert, bis ich mich damit beschäftigt habe, und jetzt möchte ich nicht mehr einfaches CSS schreiben, es sei denn, ich werde dazu gezwungen. Tailwind ist nahtlos in mein #1-Framework Nuxt integriert und die Einfachheit, innerhalb weniger Minuten optisch ansprechende responsive-freundliche Websites zu erstellen, ist einfach großartig.

Es gibt jedoch einen Haken. Je mehr Optionen Sie kennen und je mehr Stile Sie einschließen, desto mehr Chaos kann der HTML-Code anschwellen lassen. Das zweite Problem, das ich in meinen frühen Tagen verspürte, war, dass ich mich wiederholte. Als ehrenhafter Anhänger des DRY-Prinzips tat es mir in den Augen weh, die gleiche Abfolge von Klassen mehrmals in meinen Vorlagen zu sehen.

Ich habe versucht, dies zu optimieren.

Die erste Idee bestand darin, die Sequenz der Tailwind-Klassen als Zeichenfolgenvariable zu extrahieren. In Vue.js (Nuxt basiert auf Vue) sieht es ungefähr so ​​aus.

<-- component before -->
<template>
 <div>
  <button>





<pre class="brush:php;toolbar:false"><-- component after -->
<template>
 <div>
  <button :class="tailwindBtn">
    Button 1
  </button>
  <button :class="tailwindBtn">
    Button 2
  </button>
  <button :class="tailwindBtn">
    Button 3
  </button>
 </div>
</template>

<script setup lang="ts">
const tailwindBtn = "m-2 p-2 rounded border border-2 border-yellow-500 bg-blue-500 text-black text-lg font-bold"
</script>

Endlich ist es einfacher zu warten und zu ändern. Über die Klarheit lässt sich streiten. Vor allem, wenn Ihre App überall dieselben Elemente enthält und Sie die Definition in eine globale Konstante umwandeln müssen.

Ich suchte weiter nach einer besseren Lösung.

Und mir wurde die @apply-Direktive von Tailwind vorgestellt. Im Grunde ist es wie eine Negation des Gesamtkonzepts. Anstatt Definitionen direkt auf konkreten Elementen zu platzieren, können Sie Ihr eigenes eine Art Stylesheet erstellen und es mit benutzerdefinierten Klassen und Elementanpassungen füllen. Nur statt einfacher CSS-Regeln erstellen Sie Lösungen aus Tailwind-Dienstprogrammklassen.

Seltsam, aber es schien, als würde es mein mentales Problem mit doppelten Definitionen lösen.

Ich wurde sowohl vom VueSchool-Lehrer als auch von den Tailwind-Dokumenten NICHT gewarnt, es zu verwenden, aber natürlich habe ich nicht zugehört.

Ich habe mit diesem Ansatz einige Websites erstellt. Es hat funktioniert. Problem gelöst, oder?

Schneller Vorlauf bis Ende 2024. Ich habe einige neue Ideen für eine meiner Websites. Ich habe mit dem Codieren begonnen. Ich habe die @apply-Spielereien, die ich vor mehr als einem Jahr gemacht habe, völlig vergessen. Und plötzlich war ich nicht mehr in der Lage, mein Layout zusammenzustellen.

Obwohl in meiner Vorlage kein offensichtlicher Stil verwendet wurde, waren meine

s falsch. Was ist los? Ich habe die Entwicklungskonsole im Browser geöffnet, um den gerenderten HTML-Code zu studieren. Auf sie wurden CSS-Stile angewendet.

Ein paar frustrierende Momente später hatte ich den Täter.

Plötzlich:

<-- component before -->
<template>
 <div>
  <button>





<pre class="brush:php;toolbar:false"><-- component after -->
<template>
 <div>
  <button :class="tailwindBtn">
    Button 1
  </button>
  <button :class="tailwindBtn">
    Button 2
  </button>
  <button :class="tailwindBtn">
    Button 3
  </button>
 </div>
</template>

<script setup lang="ts">
const tailwindBtn = "m-2 p-2 rounded border border-2 border-yellow-500 bg-blue-500 text-black text-lg font-bold"
</script>

in der Datei tailwind.css schien keine so gute Idee zu sein wie im Jahr 2023.

Wer sollte wissen, dass ich eines Tages etwas anderes brauchen werde, oder?

LEKTION Nr. 1

Verwenden Sie @apply niemals und niemals global für einen Elementselektor.

Während es praktisch aussieht, wenn Sie ein neues Projekt planen, kann es Ihnen auf lange Sicht schaden. Nicht nur, dass man es genauso leicht vergessen kann wie ich. Es macht die Dinge auch weniger flexibel. Eines Tages werden Sie weiser zurückkommen und bereit sein, es loszuwerden – aber sobald Sie den globalen Stil entfernen, wird die Hälfte der darauf basierenden Website unerwartet auseinanderbrechen. Sind Sie mental bereit, das gesamte Design zu überdenken?

Ich persönlich würde jetzt empfehlen, @apply überhaupt nicht in tailwind.css zu verwenden (wenn ich nur Zeit und Geduld hätte, es aus all meinen Projekten zu entfernen, in denen ich es platziert habe).

Wenn Sie immer noch darauf bestehen, es ohne guten Grund zu verwenden („möchte die Stile in einer Bibliothek eines Drittanbieters überschreiben“, wie es in der Tailwinds-Dokumentation heißt), verwenden Sie es zumindest, um Klassen zu erstellen .

Es ist entschuldbar, eine .my-cool-css-Klasse zu haben, denn zumindest müssen Sie sie an das Element anhängen, das Sie formatieren möchten. Auf diese Weise kann jeder (einschließlich Ihres zukünftigen Selbst) es dort sehen und bei Bedarf seine Definition finden.

JA, ABER

Verlockende Kandidaten für einen Verstoß gegen diese Regel sind Ankerelemente. Denn es wäre wirklich mühsam, jedem .

ein Klassenattribut hinzufügen zu müssen

Eine mögliche Alternative besteht darin, eine benutzerdefinierte Linkkomponente zu erstellen, die den Anker umschließt (oder um den integrierten in Nuxt). Aber es könnte dir nicht gefallen und ich werde dir keine Vorwürfe machen.

Tatsächlich ist die Verwendung der @apply-Direktive immer noch eine erstklassige Lösung.

Vielleicht können Sie noch mehr Beispiele erfinden, bei denen globale Elementstile sinnvoll wären. Wenn Sie 100 % sicher sind, verwenden Sie sie. Aber es sollte immer eine fundierte Entscheidung sein.

LEKTION Nr. 2

Der wahre Grund, warum Sie zu lange/doppelte Tailwind-Klassendefinitionen haben, ist das schlechte Design Ihres Codes.

Mit modernen JavaScript-Frameworks wie Vue waren Sie in der Lage, kleine wiederverwendbare Komponenten zu erstellen und diese zu komplexen Lösungen zusammenzufügen. Benutze es.

Das Schaltflächenbeispiel von oben kann wie folgt umgewandelt werden:

<-- MyButton.vue -->
<Vorlage>
  <Schaltfläche>



<p>Und schon ist der duplizierte Code verschwunden.</p><p>Wenn ich andererseits wirklich lange Unterrichtsketten sehe, denke ich immer, dass das arme Element mit zu vielen Sorgen belastet wurde. Am besten halten Sie sich zurück und überdenken die Entscheidungen, die Sie dorthin führen.</p>

<p>Meine Erfahrung ist, dass Sie mit nur einer Handvoll Tailwind-Klassen gut aussehende Designs erstellen können. Und wenn Sie Lust haben, noch mehr hinzuzufügen, sollten diese normalerweise nicht auf nur einem Element gestapelt werden. Es ist so ziemlich das Gleiche, als würde man eine große Komponente (oder eine Klasse, wenn Sie so wollen) erstellen, die alles erledigt. Irgendwann müssen Sie wirklich aufhören, weitere Zeilen hinzuzufügen, und stattdessen anfangen, die Dinge aufzuteilen.</p>

<p>Im schlimmsten Fall sollten Sie in der Lage sein, visuell anspruchsvolle CSS-Elemente in separate Komponenten zu kapseln und so die Anzahl der erforderlichen Interaktionen zu minimieren. Aber um ehrlich zu sein, hat das wahrscheinlich schon jemand gemacht und Sie müssen nur noch die richtige Tailwind-Komponentenbibliothek finden, die Sie in Ihrem Projekt verwenden können.</p>


          

            
        

Das obige ist der detaillierte Inhalt vonIch habe Tailwind falsch verwendet, das ist also nicht nötig. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Erklärung dieser Website

Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn