网络日志

客观评价 增长趋势比 vite 还猛的 TailwindCSS

作者:pxn > 来源:medium

有梦想,有干货,微信搜索 【大迁世界】 关注这个在凌晨还在刷碗的刷碗智。

本文 GitHub https://github.com/qq449245884/xiaozhi 已收录,有一线大厂面试完整考点、资料以及我的系列文章。

前端社群常见的宗教战争文: TailwindCSS根本邪魔歪道, Class根本不是这样用的, 看了真他妈一肚子火 —— 硬派本格 CSS/SCSS支持者

会有这样的言论,也许是你日常的工作流程中,不适合用这样的框架,又或许是你没有客观的理解过 TailwindCSS 的优点所以体会不到它的魅力。

先说结论:如果你是一个团队做 SAAS 产品,需要在统一的产品风格主题上面展开,并且使用 React 之类可以模块化x组件的前端框架,那麽 TailwindCSS 会是很值得导入的样式解决方案。

命名

我发现对我来说,打断心流状态的往往是帮组件取名这件事,在传统使用 CSS/SCSS 上,我需要停下来花时间想一组组件还有其子组件的 class name 命名,检查会不会跟已存在的元件衝突,多这一个步骤其实对开发效率上来讲是拖累的。

诚然,你可以透过 Nested classes / BEM 之类的一些命名策略来让这样的步骤有一致性并减少命名碰撞,但在写 JS 部分的组件时候已经要命名组件/命名变量,命名东命名西了,很多时候你 CSS 也只是把 JS 定义的名字改改文字格式複制贴上

例如这边有个组件 AwesomeCard

AwesomeCard -> .awesomecard
AwesomeCardIcon -> .awesomecard__icon
AwesomeCardBody -> .awesomecard__body
AwesomeCardButton -> .awesomecard__button

说穿了其实是浪费生命的重複动作。

下面还有一种情境的命名我也常常“顿爹”打断我思路

<div class="flex items-center justify-between px-3">
  <div class="flex items-center">
    <Icon/>
    <span class="ml-1">Label</span>
  </div>
  <Caret />
</div>

有时候你会需要一些额外的 div 搭配 flex 来做佈局,例如上面的代码中,我想要 IconLabel 两者垂直置中,这一组组件要跟 Caret 垂直置中并分别对齐左右边界,转成 CSS 你可能就需要用上好几个 classes

<div class="btn__container">
  <div class="btn__leftgroup">
    <div class="btn__icon" />
    <span class="btn__label">Label</span>
  </div>
  <div class="btn__caret"/>
</div>

要额外命名 btn__container btn__leftgroup 会让我很烦躁,这些步骤如果能省起来个人是觉得能大幅提升开发效率。

文件之间的切换

另外一个影响工作心流的是分开的 HTML/JS/CSS 文件 ,虽然说 separation of concern 是软件工作中很重要的一个概念,但前端实务上,三种文件的耦合度极高,通常改一者就必须改另外两者,频繁的切换文件其实很没有效率。

以 React 框架来说,已经让 Html 整合到 JSX 当中,当你习惯了这样的工作模式,你会想更进一步的把样式定义也纳进来,这也是为什麽会有各种 css-in-js 的解决方案,TailwindCSS 在某种程度上也算是 css-in-js 的一种,各种组件状态逻辑,例如说点选之后改变文字/背景颜色,可以透过 JSX 直接切换 className 来实现 (搭配 classnames 这样的 npm module 更是如虎添翼)

统一的风格样式

如果是 SAAS 产品,你会希望整个团队有一致的调色盘, 而字体大小,间隔,常用宽高等维持有限度的选择,让你在组件佈局上能更好的对齐,TailwindCSS 这点已经帮你把最常见的 text/bg color、font-size、spacing 都提取出来,框架初始自带的设定已经十分够用,通常只需针对产品品牌色定义色盘,其他参数要客制修改扩充透过设定档也十分方便。

你可能会说,SCSS裡面我也可以定义各种变量啊,的确,但变成你要自己设立一套参数规则或是参考某个框架范本 (MUI/AntD/Bootstrap) 来实作。

然后又回到一个懒人想省打字的问题上了,究竟是

<div class="bg-gray-100">...</div>

还是

<div class="card"></div>
.card {
  background-color: $gray100
}

对我来说,差别其实蛮明显的。

冗长的 class name

<div class="w-96 bg-white shadow rounded flex items-center">...</div>

通常反对 TailwindCSS 的正统硬派 CSS 使用者,最常攻击的就是 Atomic utility classes 冗长的 class name,但这个透过 React 的组件封装,其实根本不会是问题,通常你会把这些複杂度藏在可重複使用的组件中,实际上在开发的时候,代码往往是很清爽好读的

例如底下一个 navigation 的组件,在 DOM tree 裡面长这样

<ul class="flex">
  <li class="mr-6"><a class="text-blue-500 hover:text-blue-800" href="#">Link</a></li>
  <li class="mr-6"><a class="text-blue-500 hover:text-blue-800" href="#">Link</a></li>
  <li class="mr-6"><a class="text-blue-500 hover:text-blue-800" href="#">Link</a></li>
</ul>

可以把 li 给抽出来写成独立的组件

const NavItem = ({ href, children }) => <li class="mr-6"><a className="text-blue-500 hover:text-blue-800" href={href}>{children}</a></li>

如此一来,你的JSX源码就能整理成以下比较好读的格式

<ul className="flex">
  <NavItem href="#">Link</NavItem>
  <NavItem href="#">Link</NavItem>
  <NavItem href="#">Link</NavItem>
</ul>

当然,前提是搭配 React 这样可以轻易封装组合组件的框架才能发挥最大功效,如果没有用上类似框架,我也不能否认 atomic css 的 class 是真的很冗长难读。

文件更小的 Stylesheet

这点其实毋庸置疑,因为有很大部分的 Utility class 都是共用,没有多馀命名,TailwindCSS 又自带 Tree Shaking,不会产生没用到的 class,整体的 CSS stylesheet 文件可以压到很小,浏览器载入超快速。

总结

老话一句,工具没有好坏,只有适不适合,就我个人开发经验,导入 TailwindCSS 在 Developer Experience 上是颇受团队好评的,近年 TailwindCSS 的窜起,如果它没有解决一些痛点,又何来这麽多人吹捧?

如果只是心理过不去,还抱持著写传统 CSS 方法的骄傲与矜持,没有客观的去理解新工具以及其适用的场景,我是觉得蛮可惜的,毕竟用得好的话,它真的能为你带来更好的生产力以及效率,团队协作上面也因为有共同的标准而能够和谐的运作,何乐而不为?

编辑中可能存在的bug没法实时知道,事后为了解决这些bug,花了大量的时间进行log 调试,这边顺便给大家推荐一个好用的BUG监控工具 Fundebug

原文:https://medium.com/@nightspri...

交流

文章每周持续更新,可以微信搜索「 大迁世界 」第一时间阅读和催更(比博客早一到两篇哟),本文 GitHub https://github.com/qq449245884/xiaozhi 已经收录,整理了很多我的文档,欢迎Star和完善,大家面试可以参照考点复习,另外关注公众号,后台回复福利,即可看到福利,你懂的。