共计 3418 个字符,预计需要花费 9 分钟才能阅读完成。
作者: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
来做佈局,例如下面的代码中,我想要 Icon
跟 Label
两者垂直置中,这一组组件要跟 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 和欠缺,大家面试能够参照考点温习,另外关注公众号,后盾回复 福利,即可看到福利,你懂的。