大家好，今天给大家分享jsx是什么，一起来看看吧。
为什么需要CSS解决方案市面上有非常多「CSS解决方案」，比如：
- BEM命名规范
- CSS Module规范
- 原子CSS（比如TailwindCSS）
- CSS-in-JS（比如emotion）
为什么需要这些方案？原生CSS哪里不好？在这里，我们举个小例子（例子来源于「React Conf 2019」）。考虑如下代码：
CSS文件如下：
.blue {color: blue;}.red {color: red;}HTML文件如下：
<p class=&34;>我是什么颜色？</p>请问p标签是什么颜色的？
从class来看，blue在red后面，p应该是蓝色的么？
实际上，样式取决于他们在样式表中定义的顺序，.red的定义在.blue后面，所以p应该是红色的。
是不是已经有点晕了？再增加点难度。如果.red和.blue分别在两个文件中定义呢？
css文件2.red {color: red;}那p的样式就取决于终打包代码中样式文件的加载顺序。
上面只是原生CSS中「选择器优先级相关的一个缺陷」（除此外还有其他缺陷，比如「作用域缺失」...）。随着项目体积增大、项目维护时间变长、项目维护人员更迭，这些缺陷会被逐渐放大。
正是由于这些原因，才出现了各种「CSS解决方案」。
StyleX的基本使用StyleX的API很少，掌握下面两个就能上手使用：
- stylex.create，创建样式
- stylex.props，定义props
比如：
import * as stylex from &39;;// 创建样式const styles = stylex.create({red: {color: &39;},});// 定义propsconst redStyleProps = stylex.props(styles.red);使用时：
<div {...redStyleProps}>文字颜色是红色</div>stylex是如何解决上面提到的red blue优先级问题呢？其实很简单，考虑如下代码：
import * as stylex from &39;;// 创建样式const styles = stylex.create({red: {color: &39;},blue: {color: &39;}});// 使用<p {...styles.props(styles.red, styles.blue)}></p>样式的优先级只需要考虑styles.props中的定义顺序（blue在red后面，所以颜色为blue），不需要考虑样式表的存在。
有些同学会说，看起来和常见的CSS-in-JS没啥区别啊。那stylex相比于他们的优势是啥呢？
相比其他CSS-in-JS的优势首先要明确，stylex虽然以CSS-in-JS的形式存在，但本质上他是一种「用JS描述CSS的规范」。文章开头也提到，他的定位类似JSX。
既然是规范，那他就不是对CSS的简单封装、增强，而是一套「自定义的样式编写规范」，只不过这套规范终会被编译为CSS。
作为对比，Less、Sass这样的「CSS预处理器」就是对CSS语法的封装、增强
那么，stylex都有哪些规范呢？
比如，stylex鼓励将样式与组件写在同一个文件，类似Vue的SFC（单文件组件）。这么做除了让组件的样式与逻辑更方便维护，也减少了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的代码：
import * as stylex from &39;;// 创建样式const styles = stylex.create({red: {color: &39;},});// 定义propsconst redStyleProps = stylex.props(styles.red);编译后的产物包括如下两部分：
JS的编译产物：
import * as stylex from &39;;const redStyleProps = {className: &39;};CSS的编译产物：
.x1e2nbdu {color: red;}所以，运行时实际运行的代码始终为：
<div {...{className: &39;}}>...</div>对于再复杂的样式，stylex都会通过编译生成「可复用的原子类名」。
即使是跨文件使用样式，比如我们在另一个文件也定义个使用color: &39;样式的stylex属性foo：
import * as stylex from &39;;const styles = stylex.create({foo: {color: &39;,},bar: {backgroundColor: &39;,},});会得到如下编译结果，其中x1e2nbdu是一个原子类名，他是上一个文件中styles.red的编译产物：
import * as stylex from &39;;const styles = {foo: {color: &39;,$$css: true,},bar: {backgroundColor: &39;,$$css: true,},};随着项目体积增大，样式表的体积也能控制在合理的范围内。这种对原子类名的控制粒度是其他「CSS-in-JS库」办不到的。
相比于原子CSS的优势stylex相比TailwindCSS这样的原子CSS有什么优势呢？
这就要谈到原子CSS的一个特点 —— 使用约定好的字符串实现样式。比如，使用TailwindCSS定义图片的样式：
<img class=&34; src=&34; alt=&34; width=&34; height=&34;>效果如下：
由于样式都是由不同的「原子类名字符串」组合而成，TS没法分析，这就没法实现「样式的类型安全」。
什么叫「样式的类型安全」？通俗的讲，如果我实现一个组件，组件通过style props定义样式，我只希望使用者能够改变color与fontSize两个样式属性，不能修改其他属性。如果能实现这一点，就是「样式的类型安全」。
「样式的类型安全」有什么意义呢？举个例子：设想开发基础组件库的团队使用stylex。那么当业务团队使用该组件库时，就只能自定义组件的一些样式（由组件库团队约束）。
当基础组件库升级时，组件库团队能很好对组件样式向下兼容（因为知道只有哪些样式允许被修改）。
在stylex中，由于stylex.create的产物本质是对象，所以我们可以为每个产物定义类型声明。比如在如下代码中，我们限制了组件style props只能接受如下stylex样式：
import type {StyleXStyles} from &39;;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，你怎么看？
参考资料[1]
React Conf 2019: https://www.*******/watch?v=9JZHodNR184&t=270s
以上就是jsx是什么的内容分享，希望对大家有用。
