为什么推荐使用JSX开发Vue3

2023-07-07 17:02:03 83

在很长的一段时间中，Vue官方都以简单上手作为其推广的重点。这确实给Vue带来了非常大的用户量，尤其是最追求需求开发效率，
往往不那么在意工程代码质量的国内中小企业中，Vue占据的份额极速增长。但是作为开发者自身，我们必须要认清一个重点，简单易用重来不应该在技术选型中占据很大的份额，可维护性才是。

以防万一有的同学实在不看官方文档，我先提一嘴，SFC就是写Vue组件的时候写的.vue文件，这一个文件就是一个SFC，全称SingleFileComponent，也即单文件组件。

在开始说我个人的观点之前，我们先来看几个事实：

一是：Vue3的定义原生支持JSX，并且Vue3源码中有jsx.d.ts来便于使用JSX。不知道同学们看到这里会想到什么，
我的第一反应是：社区对于JSX的需求声音是不小的，所以会反向推动Vue3官方对于JSX的支持。

二是：AntDesign的vue3版本，基本全部都是用JSX开发的，而且Vue3现在官方的babel-jsx插件就是阿里的人一开始维护的，
虽然我向来不喜欢阿里系的KPI推动技术方式，而且现在的JSX语法支持也不是很符合我的期望，但至少在使用JSX开发是更优秀的选择这点上，我还是很认可AntDesign团队的。

OK，说这些呢，主要是先摆出一些事实作为依据，让有些同学可以不需要拿什么：

啊，这都是你空想的，你太自以为是了
你再怎么想都没用，咱们Vue就是应该用SFC开发

这些观点来批斗我，首先我都会从客观的角度来分析为什么，至少是我是能讲出优劣势的理由的。

OK，前言差不多到这里，接下来咱给您分析分析，为什么你应该选择JSX来开发Vue。

TypeScript支持

其实第一点就已经是杀手了，对于想要使用TypeScript来开发Vue3应用的同学来说，这简直就是SFC无法克服的世界难题。

一句话概括：TypeScript原生支持JSX语法，而基本无望TS官方能支持SFC的template语法。

TS毫无疑问在前端社区的重要性越来越大，但凡未来对于代码质量有一定要求的前端团队，都应该会选择使用TS来进行开发。
而且现在基本上在NPM上都能看到包你都能找到对应的TS定义，现在使用TS开发成本已经只剩下你是不是会TS语法了，在这种情况下是否支持TS则是开发模式在未来走不走的远的重要原因。

目前SFC只能通过shim让TS可以引入.vue文件，但是对于所有SFC的组件的定义都是一样的：

declaremodule'*.vue'{
import{DefineComponent}from'vue'
constcomponent:DefineComponent<{},{},{},any>
exportdefaultcomponent
}

也就是说你引入的SFC组件，TS是不知道这个组件的Props应该接收什么的。所以你无法享受到这些TS的优势：

开发时的自动提示
编译时的TS校验，让你尽早发现问题
编译组件生成你的组件定义（对于类库开发尤其重要）

当然你会说既然Vue官方能开发处SFC的语法，自然会支持这些特性。我表示这当然有可能，但是这个难度是非常大的，需要很多方面的支持，甚至可能需要TS官方团队愿意协助，
但是我想不到TS官方有什么理由来支持SFC，因为这只是Vue自己创建的方言，在其他场景下是没有使用的，TS是面向全社区的，我觉得他们不会考虑主动来支持SFC。

那么有同学要问了，JSX不也是非原生的JS语法么，他怎么就能让TS官方支持了呢，是不是FB和微硬之间有什么PY交易？

这就涉及第二点了，JSX和静态模板的灵活性区别。

JSX其实并不是方言

很多人弄错了一个问题，就是觉得SFC的模板语法和JSX是一样的，都是一种别人发明的语法，并不是JS原生的。这是事实，但又有一些区别，这个区别主要是体现在对于JSX的认知上。

一句话概括：JSX并没有扩展JS的语法，他只是缩略了JS的写法！其本质就是JS的语法糖

就像es6给增加的语法糖，比如

consta=1
constb=2

constobj={a,b}

//其实就等价于
constobj={a:a,b:b}

这种写法并没有扩展JS的能力，只是简便了写法，JSX也是一样的。

JSX其实就是方法调用，他和JS是有一对一对应关系的，我们来看一个例子：

constelement=HelloWorld

这里的JSX语法编译之后其实就是：

constelement=createElement('div',{id:'root'},'HelloWorld')

而JSX就是这些了，没有什么更多的内容，所以说JSX只是方便我们写嵌套的函数调用的语法糖，而其本身没有扩展任何其他的内容。

但是SFC就不一样了。

SFC定义的不仅是语法，更是文件。

SFC的具体定义是单文件组件，它本身就是把一个文件看作一个单位，所以他的约束性是要大很多的，你必须具有固定的文件结构才能使用SFC，这做了很多的限制：

一个文件只能写一个组件
节点片段只能写在template里面，非常不灵活
变量绑定只能获取this上面的内容，不能使用全局变量（很多时候我们都要把全局变量先挂载到this上）

我们一点点来讲

一个文件只能写一个组件

这个说实话非常非常不方便，很多时候我们写一个页面的时候其实经常会需要把一些小的节点片段拆分到小组件里面进行复用（如果你现在没有这个习惯可能就是因为SFC的限制让你习惯了全部写在一个文件内）。

React生态中丰富的css-in-js方案就是很好的例子，我们可以通过：

constStyledButton=styled('button',{
color:'red',
})

如果我们这个页面需要使用特定样式的按钮，通过这种方式在页面文件里面封装一下是非常常见的。因为没必要把这个组件拆分出去，他也不是一个可复用的组件，拆分出去了还要多一次import。

Vue生态基本没有css-in-js的成熟方案其实跟这个限制也很有关系。

再来一个例子，比如我们封装了一个Input组件，我们希望同时导出Password组件和Textarea组件来方便用户根据实际需求使用，而这两个组件本身内部就是用的Input组件，只是定制了一些props：

constInput={...}

exportdefaultInput

exportconstTextarea=(props)=>

exportconstPassword=(props)=>

在JSX中可以非常简单地实现，但是如果通过SFC，你可能就要强行拆成三个文件，另外为了方便，你可能还要增加一个index.js来导出这三个组件，你能想象这多了多少工作量么。

节点片段只能写在template里面，非常不灵活

我不知道有多少同学看过Vue的template编译出来之后的代码，以我的经验来说看过的可能不会超过50%（乐观估计），建议同学们如果还不了解的，可以去尝试看一下。

为什么要看这个呢？因为你看了之后你会发现，你在template里面写的类似HTMl的内容，其实跟HTML根本没啥关系，他们也会被编译成类似JSX编译出来的结果。

{
render(h){
returnh('div',{on:{},props:{}},h('span'))
}
}

类似这样的结果，而这里面h函数调用的结果就是一个VNode，是Vue中的节点的基础单元。那么既然这些单元就是一个对象，其实理所当然的，他们是可以作为参数传递的。
也就是说，理论上他们是可以通过props把节点当作参数传递给其他组件的。

这个做法在React中非常常见，叫做renderProps，并且其非常灵活：

constComp=()=>}footer={}/>

但是因为SFC模板的限制，我们很难在SFC里面的props上写节点：

这样写是不行的，因为SFC定义了:header绑定接受的只能是js表达式，而显然不是。

因为通过props传递不行，所以Vue才发明了slot插槽的概念

虽然我们一直再说Vue简单，但是事实上ScopedSlots一度成为新手理解Vue的噩梦，很多同学都被这个绕来绕去的作用域整的死去活来。

我们看一个ScopedSlots的例子：

这里ctx是Comp里面的属性，通过这种方式传递出来，让我们在当前组件可以调用父组件里面的属性。这简直就是理解的噩梦，但是如果用JSX实现类似功能就非常简单：

{name}
}/>

我们只是给一个叫做scope的props传递来一个函数，这个函数接受一个name属性，在Comp里面会调用这个函数并传入name。
简单来说我们传入的就是一个构建节点片段的函数，就是这么简单。

这就是因为SFC的模板的限制，导致灵活性不足，Vue需要去创造概念，创造关键字来抹平这些能力的不足，而创造的概念自然就引入了学习成本。

所以其实我一直不认可Vue比React好学的说法的，如果你真的认真研究所有用法，并且总是尝试用最合理的方式实现功能，那么Vue绝对不会比React简单。

变量绑定只能获取this上面的内容，不能使用全局变量

这个体现在两个方面，一个是我们定义在全局的一些固定数据如果要在组件内使用的话，就要通过this挂载到组件上。

比如我们缓存了一份城市数据，这种数据基本上是不会改的，所以也没必要挂载到组件上让其能够响应式。但是在SFC里面这是做不到的，
因为模板的执行上下文是在编译时绑定。你在模板里面访问的变量，都会在编译时自动绑定到this上，因为模板需要编译，其本身也是字符串不具有作用域的概念。

而这在JSX中则不复存在：

constcitys=[]

constComp=()=>{
returncitys.map(c=>{c})
}

另外一个方面则是在组件使用上，在SFC中，组件必须事先注册，因为我们在模板里面写的只能是字符串而不能是具体某个组件变量。
那么模板中的组件和真实的组件对象只能通过字符串匹配来实现绑定。这带来了以下问题：

多了注册组件这个步骤，增加代码量
通过字符串名注册自然就会出现可能的冲突问题
模板解析组件支持不同的样式，比如和，容易导致风格不一的问题

在JSX中则没有这些问题，因为JSX里面直接使用组件引用作为参数：

constComp={...}

constApp=()=>

需要通过directive来扩展能力

其实上面能看出来，除了SFC本身的问题之外，Vue使用字符串模板也会带来很多的灵活性问题。
最直接的证据，就是Vue使用了directive来扩展功能（当然这不是Vue发明的，老早的模板引擎就有类似问题）。

为什么说directive是不得已的选择呢？因为静态模板缺失逻辑处理的能力。我们拿列表循环举例，在JS中我们可以非常方便地通过map函数来创建列表：

constlist=arr.map(name=>{name})

而因为JSX本身就是函数调用，所以上面的代码和JSX结合起来也非常自然：

constApp=()=>(


{arr.map(name=>(
{name}
))}

)

上面的例子对应到JS如下：

constApp=()=>
createElement('div',{},[
,
arr.map(name=>createElement('span',{key:name},name)),
])

这仍然是因为JSX只是JS的语法糖的原因，所有能在JS中实现的在JSX里面都能实现。

而SFC的模板是基于字符串编译的，其本身就是一段字符串，我们不能直接在模板里面写map来循环节点，（当然我们可以在可以接收表达式的地方写，比如v-on里面）。

那么我们不能循环节点，有需要这样的功能来渲染列表，怎么办呢？就是发明一个标志来告诉编译器这里需要循环，在Vue中的体现就是v-for指令。

同学们可能要问了，既然Vue能实现v-for，为什么不直接实现表达式循环列表呢？他当然也可以实现，但是他肯定不会这么选，因为成本太高了。
他要这么做就相当于他要实现一个JS引擎，而其实里面很多内容又是不必须的，一个v-for其实就能够适用大部分情况了。

但有了v-for就需要v-if，那么后面还会需要其他各种能力，这就是一种方言的产生和发展的过程。

当然指令也不仅仅是JS表达式的代替品，其本身也是增加了一些其他能力的，比如它能够让我们更方便地访问DOM节点，
但是嘛，我们用框架的理由不就是为了能够尽可能的屏蔽DOM操作嘛～

总结

以上就是我对应该选择使用JSX还是SFC进行开发的分析，其实归根到底SFC的问题在于其没有拥抱JS，
他的语法是自己发明的，他需要有一个JS实现的compiler来让其最终能在JS环境中运行，这本质上就是一种发明，
我们不能否认发明确实有优点，但我们也不能只看有点不看问题，没能拥抱JS自然就很难完全复用JS社区的优势
而JS社区一直在蓬勃发展，好用的工具一直在涌现，而SFC想要使用JS社区的这些工具还要自己再实现一份，我们可以细数以下SFC做了哪些兼容

vue-loader之于webpack
eslint-plugin-vue之于eslint
rollup-plugin-vue之于rollup
vue-jest之于jest
Vetur用来做代码提醒

基本上常用的工具我们都需要等待Vue社区或者官方开发了插件之后才能运行。而JSX因为有babel和typescript的官方支持，
基本上所有新的JS生态工具原生都是支持的。

在这Vue3开始预备发力的阶段，我们还是希望Vue社区能够使用更优秀更规范的方式来进行开发，
其实如果我们直接使用JSX开发Vue3，我们会发现很多时候我们都不需要用到emit、attrs这些概念，
甚至如果Vue3的JSX插件支持，我们甚至能够抛弃slots。

但是因为Vue3一定要考虑兼容Vue2，导致本身潜力很好的Vue3总是显得缩手缩脚，这不得不说是一种遗憾。

以上就是为什么推荐使用JSX开发Vue3的详细内容，更多关于用JSX开发Vue3的资料请关注毛票票其它相关文章！