你了解 JSX,那你了解 StyleX 么?

大家好,我卡颂。

近日,Meta开源了一款CSS-in-JS库 ------ StyleX。看命名方式,Style - X是不是有点像JS - X,他们有关系么?当然有。

JSX是一种用JS描述HTML 的语法规范,广泛应用于前端框架中(比如ReactSolidJS...),由Meta公司提出。

同样的,按照Meta的设想,StyleX是一种用JS描述CSS的语法规范。

早在React Conf 2019Meta工程师Frank 就介绍了这种Meta内部使用的CSS-in-JS库

Meta内部使用,到大会对外宣传,这期间肯定已经经历大量内部项目的洗礼。而从做完宣传到最终开源,又经历了快5年时间。

那么,这款Meta出品、打磨这么长时间的CSS-in-JS库,到底有什么特点呢?

本文让我们来聊聊。

免费领取卡颂原创React教程(原价359)、加入人类高质量前端群

为什么需要CSS解决方案

市面上有非常多CSS解决方案,比如:

  • BEM命名规范

  • CSS Module规范

  • 原子CSS(比如TailwindCSS

  • CSS-in-JS(比如emotion

为什么需要这些方案?原生CSS哪里不好?在这里,我们举个小例子(例子来源于React Conf 2019)。考虑如下代码:

CSS文件如下:

css 复制代码
.blue {color: blue;}
.red {color: red;}

HTML文件如下:

html 复制代码
<p class="red blue">我是什么颜色?</p>

请问p标签是什么颜色的?

class来看,bluered后面,p应该是蓝色的么?

实际上,样式取决于他们在样式表中定义的顺序,.red的定义在.blue后面,所以p应该是红色的。

是不是已经有点晕了?再增加点难度。如果.red.blue分别在两个文件中定义呢?

css 复制代码
# css文件1
.blue {color: blue;}
css 复制代码
# css文件2
.red {color: red;}

p的样式就取决于最终打包代码中样式文件的加载顺序。

上面只是原生CSS选择器优先级相关的一个缺陷 (除此外还有其他缺陷,比如作用域缺失...)。随着项目体积增大、项目维护时间变长、项目维护人员更迭,这些缺陷会被逐渐放大。

正是由于这些原因,才出现了各种CSS解决方案

StyleX的基本使用

StyleXAPI很少,掌握下面两个就能上手使用:

  • stylex.create,创建样式

  • stylex.props,定义props

比如:

js 复制代码
import * as stylex from 'stylex';

// 创建样式
const styles = stylex.create({
  red: {color: 'red'},
});

// 定义props
const redStyleProps = stylex.props(styles.red);

使用时:

html 复制代码
<div {...redStyleProps}>文字颜色是红色</div>

stylex是如何解决上面提到的red blue优先级问题呢?其实很简单,考虑如下代码:

js 复制代码
import * as stylex from 'stylex';

// 创建样式
const styles = stylex.create({
  red: {color: 'red'},
  blue: {color: 'blue'}
});

// 使用
<p {...styles.props(styles.red, styles.blue)}></p>

样式的优先级只需要考虑styles.props中的定义顺序(bluered后面,所以颜色为blue),不需要考虑样式表的存在。

有些同学会说,看起来和常见的CSS-in-JS没啥区别啊。那stylex相比于他们的优势是啥呢?

相比其他CSS-in-JS的优势

首先要明确,stylex虽然以CSS-in-JS的形式存在,但本质上他是一种用JS描述CSS的规范 。文章开头也提到,他的定位类似JSX

既然是规范,那他就不是对CSS的简单封装、增强,而是一套自定义的样式编写规范 ,只不过这套规范最终会被编译为CSS

作为对比,LessSass这样的CSS预处理器 就是对CSS语法的封装、增强

那么,stylex都有哪些规范呢?

比如,stylex鼓励将样式与组件写在同一个文件,类似VueSFC(单文件组件)。这么做除了让组件的样式与逻辑更方便维护,也减少了stylex编译的实现难度。

再比如,CSS中各种选择器的复杂组合增强了选择器的灵活性。但同时也增强了不确定性。举个例子,考虑如下三个选择器:

  • .className > *

  • .className ~ *

  • .className:hover > div:first-child

这些对.className应用的选择器将影响.className的某些后代。当这样的选择器多了后,很可能会在开发者不知道的情况下改变某些后代元素的样式。

遇到这种情况我们一般会怎么处理呢?正确的选择当然是找到上述影响后代的选择器,再修改他。

但大家工作都这么忙,遇到这种问题,多半就是用新的选择器覆写样式,必要的时候还会加!important后缀。久而久之,这代码就没法维护了。

为了规避这种情况,在stylex中,除了可继承样式 (指当父元素应用后,子孙元素默认会继承的样式 ,比如color)外,不支持这些可以改变子孙后代样式的选择器

那我该如何让子孙组件获得父组件同样的样式呢?通过props透传啊~

也就是说,stylex禁用了CSS中可能造成混淆的选择器,用JS的灵活性弥补这部分功能的缺失。

有些同学可能会说:这些功能,其他CSS-in-JS库也能做啊。

这就要谈到CSS-in-JS库最大的劣势 ------ 为了计算出最终样式,在运行时会造成额外的样式计算开销。

stylex通过编译来减少运行时的开销。比如对于上面提到过的stylex的代码:

js 复制代码
import * as stylex from 'stylex';

// 创建样式
const styles = stylex.create({
  red: {color: 'red'},
});

// 定义props
const redStyleProps = stylex.props(styles.red);

编译后的产物包括如下两部分:

JS的编译产物:

js 复制代码
import * as stylex from 'stylex';
const redStyleProps = {className: 'x1e2nbdu'};

CSS的编译产物:

css 复制代码
.x1e2nbdu {
  color: red;
}

所以,运行时实际运行的代码始终为:

js 复制代码
<div {...{className: 'x1e2nbdu'}}>...</div>

对于再复杂的样式,stylex都会通过编译生成可复用的原子类名

即使是跨文件使用样式,比如我们在另一个文件也定义个使用color: 'red'样式的stylex属性foo

js 复制代码
import * as stylex from '@stylexjs/stylex';

const styles = stylex.create({
  foo: {
    color: 'red',
  },
  bar: {
    backgroundColor: 'blue',
  },
});

会得到如下编译结果,其中x1e2nbdu是一个原子类名,他是上一个文件中styles.red的编译产物:

js 复制代码
import * as stylex from '@stylexjs/stylex';

const styles = {
  foo: {
    color: 'x1e2nbdu',
    $$css: true,
  },
  bar: {
    backgroundColor: 'x1t391ir',
    $$css: true,
  },
};

随着项目体积增大,样式表的体积也能控制在合理的范围内。这种对原子类名的控制粒度是其他CSS-in-JS库办不到的。

相比于原子CSS的优势

stylex相比TailwindCSS这样的原子CSS有什么优势呢?

这就要谈到原子CSS的一个特点 ------ 使用约定好的字符串实现样式。比如,使用TailwindCSS定义图片的样式:

html 复制代码
<img class="w-24 h-24 rounded-full mx-auto" src="/sarah-dayan.jpg" alt="" width="384" height="512">

效果如下:

由于样式都是由不同的原子类名字符串 组合而成,TS没法分析,这就没法实现样式的类型安全

什么叫样式的类型安全 ?通俗的讲,如果我实现一个组件,组件通过style props定义样式,我只希望使用者能够改变colorfontSize两个样式属性,不能修改其他属性。如果能实现这一点,就是样式的类型安全

样式的类型安全 有什么意义呢?举个例子:设想开发基础组件库的团队使用stylex。那么当业务团队使用该组件库时,就只能自定义组件的一些样式(由组件库团队约束)。

当基础组件库升级时,组件库团队能很好对组件样式向下兼容(因为知道只有哪些样式允许被修改)。

stylex中,由于stylex.create的产物本质是对象,所以我们可以为每个产物定义类型声明。比如在如下代码中,我们限制了组件style props只能接受如下stylex样式

js 复制代码
import type {StyleXStyles} from '@stylexjs/stylex';

type Props = {
  // ...
  style?: StyleXStyles<{
    color?: string;
    backgroundColor?: string;
    borderColor?: string;
    borderTopColor?: string;
    borderEndColor?: string;
    borderBottomColor?: string;
    borderStartColor?: string;
  }>;
};

总结

我猜想,当更多人知道stylex后,他会收到比当初TailwindCSS火时更多的两级分化的评价。

毕竟,stylex的设计初衷是为了解决Meta内部复杂应用的样式管理。如果:

  • 你项目没有达到Meta这样的体量

  • 你项目没有多年的迭代周期

  • 你项目前前后后没有多个工程师经手

那大概率是不能接受stylex设计理念中的这些约束。

对于stylex,你怎么看?

相关推荐
m0_748247551 小时前
Web 应用项目开发全流程解析与实战经验分享
开发语言·前端·php
m0_748255022 小时前
前端常用算法集合
前端·算法
真的很上进2 小时前
如何借助 Babel+TS+ESLint 构建现代 JS 工程环境?
java·前端·javascript·css·react.js·vue·html
web130933203982 小时前
vue elementUI form组件动态添加el-form-item并且动态添加rules必填项校验方法
前端·vue.js·elementui
NiNg_1_2343 小时前
Echarts连接数据库,实时绘制图表详解
前端·数据库·echarts
如若1233 小时前
对文件内的文件名生成目录,方便查阅
java·前端·python
滚雪球~4 小时前
npm error code ETIMEDOUT
前端·npm·node.js
沙漏无语4 小时前
npm : 无法加载文件 D:\Nodejs\node_global\npm.ps1,因为在此系统上禁止运行脚本
前端·npm·node.js
supermapsupport4 小时前
iClient3D for Cesium在Vue中快速实现场景卷帘
前端·vue.js·3d·cesium·supermap
brrdg_sefg4 小时前
WEB 漏洞 - 文件包含漏洞深度解析
前端·网络·安全