乐趣区

关于css:CSS-书写禅机

这是将来的趋势所向,如是我行。

留神:原文发表于 2017-9-6,随着框架一直演进,局部内容可能已不实用。

CSS 日渐惹人憎恨。

究其原因颇多,归根结底,皆因 CSS 给人的感觉总是飘渺迷蒙、变幻莫测。

譬如微调某个款式后,却出其不意地殃及一些看似毫无瓜葛的布局,尤其是筹备部署之时。

这类教训如果你从未领会过的话,你要么是不明就里的老手,要么是登峰造极的高人。

故此 JavaScript 社区又开始撸起袖子着手炮制,只消数载,各色各样的 CSS 库宛如雨后春笋不断涌现,它们统称为 CSS-in-JS。

然而 CSS 最辣手的问题兴许并不需要 CSS-in-JS 亦可解决,对此你可能还不知情。

假使果真如此,那么编写 CSS 将是一种惬意的享受,而非苦楚的忍耐,此外,CSS-in-JS 也会产生新的问题要去解决,未免有点旁生枝节。

本文并非要和 CSS-in-JS 唇枪舌剑,也不否定社区所做的致力,它在 JS 生态中如此沉闷,且每周都有新的想法呈现。

其实我目标是想介绍一种让人更加欢快的代替计划 —— 它就是带有真正 CSS 的单文件组件!

CSS 最大的问题

CSS 中的一切都是全局的,正因如此,为某个标记上编写的款式,可能会使另一个标记受到牵连。

也正因如此,开发者常常借助于各种命名空间的约定(而非“规定”,因为难以施行),但此法只会徒增 RSI 的危险。

如果你置身于团队之中,状况更加顽劣。别人所写的款式无人敢改,通常无奈猜想它们是做什么用的,利用在哪些标记了,以及如果删掉会带来什么劫难。

其后果是:样式表必须 只增不减

你无奈得悉哪些代码能够平安地删除。因而常见的做法是用一些更具体的款式来笼罩现有款式,哪怕是在绝对较小的我的项目上亦是如此。

单文件组件扭转乾坤

SFC 背地的思维非常简略:在一份 HTML 文件中编写组件,该文件能够蕴含形容组件款式的 <style> 和形容行为的 <script> 标记。

Svelte、Ractive、Vue 以及 Polymer 都是遵循这种模式。

(显然咱们在文章其余内容都将应用 Svelte,然而如果应用模板会让你胆战心惊的话,其实你的放心是多余的,不过这又是另一个话题了,那你能够应用 Vue,它容许你在 SFC 中编写 JSX)

如果你从未接触过 Svelte,无妨先参看这篇文章:无招胜有招:为何咱们没有及早悟到这个方法?,或者看看用户的评估。

利用这种模式,后果会产生几件美好的事件:

  • 组件的款式都是部分款式(scoped),不会向外泄露,没有不可预知的级联状况,彻底解脱为了避免名称抵触而硬取的超级啰嗦的类名。
  • 你无需再去文件夹中苦苦追究那些毁坏你款式的规定。
  • 编译器(例如 Svelte)可能辨认和删除有效的款式,从此不再是“只增不减”了!

上面咱们来试试探明到底。

< 因不反对插入视频,点击此处观看视频 >

这就是所谓的“use the platform”?

所有代码编辑器都能辨认这些 CSS,其内置了主动实现、监测、语法高亮等等性能,无需额定的 JS 各种庞杂的工具。

同时,这些都是真正的 CSS,并非那些应用了驼峰命名及双引号无处不在的滥竽充数的货色。

咱们能够在 devTools 中对款式进行修葺调整,再复制粘贴回代码中,如此行云流水的工作形式,我再也无奈来到这种酸爽。

不得不说,CSS source maps 性能已是开箱即用的,因而你能疾速定位问题所在的行。

其重要性显而易见:

当你应用所见即所得(WYSIWYG)的模式之时,你不会从组件树的角度去思考问题的,因而亟需一个万全之策使有问题的款式暴露无遗。

如果组件本就出自别人之手,状况尤其堪忧。(我敢保障,这种 CSS 工作形式能极大晋升你的生产力,来到 source maps,毋庸置疑你是在虚耗时光,因为我已经就是如此。)

Svelte 转译你的 CSS 选择器来实现让款式只利用在部分范畴内,它同时也实用于受影响的元素的属性,只管确切的机制无关紧要,并且可能会有所变动。

未应用的规定会被移除并收回正告,而后你能够将精简后的后果写到 .css 文件中。

还有一个实验性的新性能,就是能够编译组件为 Web Components,而后将款式封装到 shadow DOM 中(如果这刚好就是你所冀望的话)。

所有皆有可能,因为你的 CSS 在标记的上下文中被解析(应用 css-tree)和动态剖析。

动态剖析为将来各种令人振奋的可能性关上大门:更智能的优化伎俩,各种提醒……

然而如果你的款式须要在运行时才去动静计算的话,则做这些事件要艰难得多。

咱们也才刚刚开始。

但咱们也能够借助工具来做啊 [X]!

如果你看了视频后的反馈是:“很好,然而 —— 咱们应用 TypeScript,且为各种编辑器编写插件,也能取得主动实现和语法高亮的性能啊。”

换而言之,为了取得与 CSS 等价的成果,而去折腾构建、文档、推动及保护等等一堆辅助性的我的项目,如果你认为这些事件意义重大……

那么,多说无益,你和我是道不同,不相为谋了!

咱们依然没有全副答案

综上所述。

诚然,CSS-in-JS 的确对一些悬而未决的问题给出了答案:

  • 如何从 npm 装置款式?
  • 咱们如何重用一些定义在同一个中央的常量?
  • 如何组合申明?

就集体而言,我认为所得的益处,没有超出上述这些问题的范畴。

你的抉择可能有不同的优先秩序,使你放弃 CSS 有足够的理由。

但总的来说,你还是必须理解 CSS 的,不管酷爱还是憎恨,最终都在劫难逃要学习它。

作为 Web 的守望者,咱们能够做抉择:

创立高深莫测的形象,让 Web 开发者的学习曲线更加平缓,或者一起解决 CSS 糟粕局部。

怎么抉择,我已成竹在胸。

\<The End\>

– 窗明几净,静候时日变迁 –

退出移动版