我错误地使用了 Tailwind，所以你不必这样做

各位小伙伴们，大家好呀！看看今天我又给各位带来了什么文章？本文标题是《我错误地使用了 Tailwind，所以你不必这样做》，很明显是关于文章的文章哈哈哈，其中内容主要会涉及到等等，如果能帮到你，觉得很不错的话，欢迎各位多多点评和分享！

三年前，我开始使用Tailwind CSS，一个出色的前端开发库（本文不再赘述其优点，网上资源丰富）。我想分享一下我早期使用Tailwind时不断犯的错误，希望能帮助大家避免重蹈覆辙。

Tailwind颠覆了传统CSS的级联样式表概念，通过“实用程序类”将CSS规则直接应用于DOM元素。起初感觉陌生，但很快便上手了。我仅用一天时间就适应了它，现在除非不得已，否则不会再写纯CSS了。Tailwind与我的首选框架Nuxt集成无缝，构建美观、响应式网站非常便捷。

然而，问题出现了：选项越多，包含的样式越多，HTML代码就越混乱。另一个问题是代码冗余。作为一名DRY原则的忠实拥护者，看到模板中重复的类序列让我非常难受。

我尝试优化它。

最初的想法是将Tailwind类序列提取为字符串变量。在Vue.js（Nuxt基于Vue）中，大致如下：

<template>
  <div>
    <button class="m-2 p-2 rounded border border-2 border-yellow-500 bg-blue-500 text-black text-lg font-bold">button 1</button>
    <button class="m-2 p-2 rounded border border-2 border-yellow-500 bg-blue-500 text-black text-lg font-bold">button 2</button>
    <button class="m-2 p-2 rounded border border-2 border-yellow-500 bg-blue-500 text-black text-lg font-bold">button 3</button>
  </div>
</template>

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

虽然维护和修改更容易了，但代码可读性却值得商榷，尤其是在应用中有多个相同元素，需要将定义提升到全局常量时。

我继续寻找更好的解决方案，这时我发现了Tailwind的@apply指令。这似乎与之前的做法背道而驰：你可以创建自己的“类样式表”，用自定义类和元素填充它，而不是直接将定义放在具体元素上。不同的是，你可以用Tailwind实用程序类构建解决方案，而不是简单的CSS规则。

虽然Vue School的导师和Tailwind文档都警告我不要使用@apply，但我还是尝试了。

我用这种方法创建了几个网站，它确实有效。问题解决了，或者说…暂时解决了？

到了2024年末，我为一个网站添加新功能时，完全忘记了一年前用@apply做的“恶作剧”。突然，我发现无法组合布局。

模板中没有明显的样式，但<div>元素却渲染错误。我打开浏览器开发者工具检查渲染的HTML，发现它们应用了CSS样式。

经过一番排查，我找到了罪魁祸首：

div {
  @apply m-auto text-center text-white;
}

在tailwind.css文件中，这在2023年看起来或许是个好主意，但现在却成了问题。

谁会想到我有一天需要其他样式呢？

教训一：永远不要在元素选择器上全局使用@apply。

虽然在创建新项目时它看起来很方便，但从长远来看，它会带来麻烦。不仅容易忘记，它还会降低代码灵活性。将来，你可能会想移除它，但一旦删除全局样式，依赖它的网站功能就会崩溃。

我个人建议根本不要在tailwind.css中使用@apply（如果我有时间和精力的话，会从所有项目中移除它）。

如果你仍然坚持使用它（正如Tailwind文档所说，例如“覆盖第三方库中的样式”），至少创建类。

使用.my-cool-css-class是可以接受的，因为你必须将其附加到要设置样式的元素上。这样，每个人（包括未来的你）都能看到它，并在需要时找到它的定义。

但是…

锚元素是打破这条规则的诱人例外，因为为每个<a>元素添加类属性很繁琐。

一种替代方案是创建一个围绕锚点（或Nuxt中的<nuxt-link>）的自定义链接组件，但这可能不是你想要的。

事实上，使用@apply指令仍然是解决这个问题最常见的方案。

如果你100%确定需要全局元素样式，可以使用@apply，但这应该始终是有充分理由的决定。

教训二：Tailwind类定义过长/重复的根本原因是代码设计不当。

使用Vue等现代JavaScript框架，可以创建小型可重用组件，并将其组合构建复杂的解决方案。

上面的按钮示例可以改写成：

<template>
  <button :class="btnClass">{{ caption }}</button>
</template>

<script>
import { defineProps, computed } from 'vue';

export default {
  name: 'MyButton',
  props: {
    caption: {
      type: String,
      required: true
    }
  },
  setup(props) {
    const btnClass = computed(() => 'm-2 p-2 rounded border border-2 border-yellow-500 bg-blue-500 text-black text-lg font-bold');
    return { btnClass };
  }
};
</script>

这样，重复的代码就消失了。

看到很长的类链，总是让我觉得元素承担了过多的职责。最好的方法是退一步，重新思考导致这个问题的代码设计。

我的经验是，只需少量Tailwind类即可创建美观的设计。如果需要更多样式，通常不应该全部堆积在一个元素上。这与创建一个大型组件（或类）来做所有事情类似，最终需要停止添加更多行并开始分解事物。

在最坏的情况下，应该能够将视觉要求高的CSS元素封装到单独的组件中，以最大限度地减少所需的交互量。或者，可以使用现成的Tailwind组件库。

好了，本文到此结束，带大家了解了《我错误地使用了 Tailwind，所以你不必这样做》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！