去年在Mud,我们对CSS(即原子CSS)采用了实用程序优先的方法。 具体来说,我们决定使用实用程序类框架TailwindCSS ,该框架提供了一堆类,您可以将这些类应用于您的项目以快速构建UI。
莎拉·达扬(Sarah Dayan)去年发表了一篇很棒的文章,介绍了实用程序优先CSS的好处 ,我建议您阅读该文章,以全面了解该方法的一些好处。 在本文中,我将总结过去一年在代理机构环境中采用原子CSS所学到的知识,以及在何处或可能不适合应用它。
什么是实用程序类?
实用程序类是用于一种特定目的CSS类名称,并以此命名。 通常, .bg-blue
类的类将为您提供background-color: blue
例如background-color: blue
。 在CSS中使用实用程序类并不少见,但总体而言,它们往往很少使用-至少与诸如BEM和ITCSS之类的公认方法论一起使用。
关于实用程序类框架的兴起的思想反过来了,并主张首先使用实用程序类进行开发,这些类实际上涵盖了您可能希望应用于元素的任何通用样式。 周围有许多实用程序类框架( Tachyons是一个示例),但是Tailwind特别提供了简单的类名,它们在简洁和足够描述之间走了一条分界线。 最初记住它们可能要花一些时间,但是大多数类名都相当直观,而且我发现在与我的项目一起在文档旁边打开一个窗口几天之后,我几乎不需要引用它们完全没有 (甚至还有一个用于VS Code的插件来访问文档,因此您甚至不必离开编辑器!我没有使用过,因此无法担保。)
一串类似block p-1 mb-1 text-white bg-blue hover:bg-red
将等效于以下内容:
.some-element{
display: block ;
padding: 0.25rem ;
margin-bottom: 0.25rem ;
color: #ffffff ;
background-color: #3490dc ;
}
.some-element:hover{
background-color: #e3342f ;
}
这意味着我们的特异性树实际上是平坦的。 您实际上并没有真正使用CSS的“级联”部分-有一些例外,我们很快就会看到。
一句话关于框架
“ CSS框架”一词可能会引起误解,并为不同的人带来不同的印象。 对于许多人来说,这些词会立即使您想到Bootstrap,Foundation和其他类似框架,它们提供了HTML组件和CSS类来帮助您构建界面。 您可能会得到很多额外CSS,因为这些框架包含了您可能需要的所有内容。 如果您想要定制的东西,您还可以花费大量时间来覆盖框架的现成样式。
实用程序类框架的应用方式大不相同-尽管正如我们将看到的那样,它们本身并非没有问题。
组态
实用程序类框架的一个吸引人之处在于,一旦您习惯了语法,它可以使开发更快。 您无需在HTML和CSS文件之间来回跳动,并且类快速简便地编写-如果在编辑器中使用诸如Intellisense之类的自动完成插件,则速度更快。
缺点是您需要在配置中进行一些初始工作。 Tailwind带有config.js文件,您可以在其中定义所有变量:颜色,版式,大小(填充,边距等)等等。 有一个默认配置,但是您可能需要对它进行广泛的自定义,并且这样做确实值得。 感觉到您在编写任何代码之前就花了很多时间进行设置,但是如果您对此进行投资,则下一阶段变得更快,更容易。
(如果您是第一次尝试使用Tailwind,或者只想将其用于快速原型制作,那么不用担心,它带有默认的配置文件,因此您可以跳过此步骤。)
命名很难
在Mud,我们以前使用BEM来命名CSS类。 正确应用后,此方法总体上效果不错,但仍然容易出现人为错误或(在某些情况下)错误应用。 通常,当回到一个较旧的项目时,您可能会看到从事此项目的两个不同的人采用了不同的方法。 Tailwind通过减少任何人使用其班级名叫滑雪道的危险来消除这种不一致。
使用Tailwind意味着不必担心命名。 一个常见的问题是命名一个组件(例如.news-card
,然后发现自己将所述组件重新用于与新闻无关的事情。 不必考虑命名是一件好事。 但在另一方面,很可能你还是要命名您的组件的东西 ,所以作为卖点顺风这只让你这么远。 不过,它无疑影响了我考虑命名的方式,这些天我更加考虑可重用性。
实用程序类的作用
关于实用程序类,您可能会注意到的第一件事是,由于它们是单一用途的,因此您必须使用很多它们。 这实际上意味着将所有CSS类的简化版本放入HTML中。 这会使选择器变得很长,很繁琐,而且坦率地说很丑陋。 我不介意承认,这是我第一次尝试时就非常不合时宜的做法,并且与我的所有想法背道而驰,反对将样式放入标记中。 但是,在使用Tailwind一段时间后,它很快就变得直观了,并且可以看到HTML块并一目了然地应用了哪些样式,这有很多话要说。
这并非没有缺点。 看到所有样式都显示为HTML中的一个长字符串,这会使您更难发现发生错误的情况-选择器重复或冲突,错别字和不正确的类名都不会引起注意。 几次我都输入了我认为正确的类名,但最后还是摸不着头脑,弄清楚了为什么不应用我的样式。 (我相信Tailwind linting的作品中可能会有VS Code扩展名,但不要束手无策。)
当您有一个超长的选择器字符串要与之抗衡时,Tailwind的袖子还有另一个选择。 您可以将这些类简单地提取到CSS文件中,如下所示:
.my-super-class-name{
@apply bg-blue text-white font-bold uppercase px-2 py-1 mx-auto mb-1 border-1 w-200 ;
}
那很方便。 但是,既然我们在CSS文件中进行编写,为什么不编写常规CSS? 另外,Tailwind并没有针对每种可能CSS样式的类,因此您可能仍然需要编写一些常规CSS。 突然,我们有三种可能的方式可以应用样式:
- 内联尾风类
- 尾随CSS
- 普通的旧CSS
尽管事实上Tailwind似乎已被提倡作为解决此类难题的方法,但与Tailwind相比,我将自己束之高阁。
我发现Tailwind难以使用的另一个地方是组件变体。 我们通常需要构建同一组件的多个变体,例如包含标题,文本块和图像的部分,可能具有一些可能的布局组合,但否则将包括所有相同CSS。 使用BEM,您可能会遇到以下情况:
< articleclass=" media-object ">
< h2class=" media-object__heading "> h2>
< figureclass=" media-object__figure ">
< imgclass=" media-object__image "src=" some-image.jpg "/>
figure>
< divclass=" media-object__text-block ">< p> ... p> div>
article>
类名是描述性的,对所有这些组件变体进行一些样式更改通常意味着只需在一处更新CSS。 现在,假设您在HTML中使用utlity类,并且想要将每个组件的填充从1rem
为2rem
。 您需要进入每个HTML文件,找到该实用工具类并进行更新(不会在错误的地方意外更新)。 当您发现自己重复选择器字符串时,将样式提取到CSS文件中可能是一个好主意,但这也引发了前面提到的一些问题。 (我知道这对每个人来说都不是问题。例如,如果您在React中构建组件,例如将Tailwind与Styled Components一起使用,则可能只有一个文件并通过传递道具来说明您的变体)
外挂程式
由于Tailwind是使用Javascript配置的,因此您可以执行诸如编写函数并将其传递到配置中的操作。 优点是它为您提供了Javascript的所有功能,并且您还可以编写自己的自定义实用程序作为插件。
使用常规CSS,在Sass部分中可能有少数实用程序类,可以在需要时在整个项目中应用(例如,我经常使用一些可重用的排版样式来完成此操作)。 如果您尝试将它们与Tailwind类一起应用,则可能最终导致混乱,您可能会期望样式被覆盖,而样式不会被覆盖。 (哪种样式会覆盖,具体取决于导入的顺序。)很难学到这一点后,我建议您将自己的自定义实用程序作为Tailwind插件编写,而不要在Sass中编写。 您将获得这些输出与Tailwind的所有常规实用程序一起使用的好处,并且能够访问Tailwind的状态和断点语法(例如hover:bg-green
将使您将鼠标悬停状态为background-color: #38C172
。
不利的一面是,对于不熟悉Javascript的新手来说,这可能更像是一个学习曲线。 我还不相信了解Java语言应该是编写好HTML和CSS的先决条件。
性能
从理论上讲,实用程序类被设计为可重用,因此您应该最终交付较小CSS文件。 较小的文件应等同于更好的性能。 但是,如果不加改动,该框架将生成您可能需要的所有类,并留下全部未使用CSS负载,除非您采取措施将其剥离。 但是,期望是您实际上将永远不会交付整个框架。 该文档详细介绍了多种删除不必要CSS并减小整体文件大小的方法。
Tailwind文档中建议的一种方法是在构建过程中使用Purge CSS之类的工具。 在实践中,您需要对要删除的类保持警惕,尤其是当您使用Javascript添加某些类时。 Purge白名单是您的朋友-我花了一些时间才能正确处理此问题,而且在某些情况下,我遇到了麻烦,使其无法与关键CSS很好地配合使用。
另一件事...
这是一件小事,但是我真的很喜欢可以在CSS文件中使用的媒体查询功能。 编写@screen md
比编写常规媒体查询甚至mixins更快,更好。
何时不使用Tailwind
有些人主张对所有事物都使用实用工具,这就是说,当Tailwind中不存在实用程序时,就创建新实用程序。 我绝对不推荐这种方法。 我在CSS Grid上做了很多工作,尝试为每种可能的布局组合配置一个utitity类会很疯狂,更不用说严重限制自己才能充分利用Grid的功能。 有一个用于Tailwind的Grid插件 ,但是即使它的文档也说:
通过实用程序公开CSS Grid的所有功能并不是很实际,但是此插件是使用CSS Grid代替仅单元格的float或Flexbox网格的一个很好的例子。
尝试使用Tailwind进行复制还有很多其他CSS属性是不切实际的,因此您可能仍然需要某种形状或形式的常规CSS。
结论
Tailwind并不是解决所有CSS假定问题的灵丹妙药,也不是您作为开发人员不能理解级联。 如果您是欣赏CSS的基本原理的人,您可能会发现乍一看是违反直觉的,但是在决定是否适合您的方法之前值得坚持不懈。 尽管我不会选择在每个项目中都使用它,但有明显的好处。 我相信在Mud采用Tailwind是团队的正确决定,使CSS更具可重用性,可维护性和高性能。
翻译自: https://css-irl.info/a-year-of-utility-classes/