css的四种粒度
css
<div style="{ borderRadius: '0.5rem', padding: '1rem' }"> Click </div>
css
<div class="rounded-lg p-4"> Click </div>
css
<div class="button"> Click </div>
.button {
...
}
css
<Button> Click </Button>
越往下走,颗粒度越来越大,约束性变高,自由性不足。而 TailwindCSS
位于第二层。
Tailwindcss 优势
提供UI规范性的约束
在文件theme里面,我们可以自定义任意我们需要用到的颜色、字体、字体大小、间距、圆角等等,在开发过程中,我就将UI提供的设计规范对应的这些属性尺寸颜色全部写入了tailwind.config.js里面。
css
// tailwind.config.js 官网实例配置
module.exports = {
content: ['./src/**/*.{html,js}'],
theme: {
colors: {
'blue': '#1fb6ff',
'purple': '#7e5bef',
'pink': '#ff49db',
'orange': '#ff7849',
'green': '#13ce66',
'yellow': '#ffc82c',
'gray-dark': '#273444',
'gray': '#8492a6',
'gray-light': '#d3dce6',
},
fontFamily: {
sans: ['Graphik', 'sans-serif'],
serif: ['Merriweather', 'serif'],
},
extend: {
spacing: {
'8xl': '96rem',
'9xl': '128rem',
},
borderRadius: {
'4xl': '2rem',
}
}
},
}
备注:也可以自定义常用的class,来实现这个约束。
.lg {
}
.sm { }
打包的css体积很小,未使用的类名不会打包输出。
对比,css module形式管理组件,删除组件某个功能时候,还需要仔细找到 这个功能对应的class类,删除对应的css文件。
举例:
javascript
function component() {
return (
<div>
.....
<div className="A B C others">
</div>
</div>
)
}
// 样式文件
.A {
color: red;
}
.B {
...
}
.C {
...
}
.others {
...
}
Tailwind 的经验可以让我更好的维护实用类/原子类
实用类确实能增加一些开发效率,所以我在自己维护的样式库中增加了不少实用类。
Tailwindcss 劣势
前期类名不熟悉带来的低效
开始开发的时候,最大的麻烦就是大量的类名,自己根本是记不住,所以经常是一个简单的css样式,比如width:100%,自己往往就是先去文档里面找width的菜单,然后再到width的类名里面找到表示width:100%的类名,虽然官方提供了智能的类名提示插件Tailwind CSS IntelliSense,但是前期由于对类名不熟悉的原因,还是存在了大量查找的工作量。
有点像我们在使用UI框架的时候,比如我们需要实现一个面包屑,我们需要在对应UI框架里面找到面包屑的代码然后复制,不同的是,TailWind CSS寻找类名的过程更加麻烦,而且往往一个小小的组件需要使用的类名都是几十个上百个,前期这样造成的工作量其实还是蛮大的。
设计稿调整以及后期维护带来的巨大不便
项目过程中,难免会出现设计稿的调整,这时候,就需要我们修改标签类名了。然而这个时候,我才算碰到TailWind CSS带来的最麻烦的地方。比如说,设计告诉我们,有一块的内边距由12px改为20px,那我就去找这个元素,然后我发现这个元素有20多个类名,我眼睛瞟了几圈终于发现表示内边距12px的类名,正当我高兴之时,我才发现这个类名是xl断点下的,而我需要修改的是sm断点下的,于是我又重新去找sm断点
大量写类名,会降低开发者css能力
实践中细节上的问题
以下 red 与 blue 两个样式哪个会生效?无法确定。
arduino
<div class="red blue"> </div>
// css
.blue {
}
.red {
}
class
在样式表中的顺序决定,而非在 class 中的先后顺序