使用JSX对Vue3进行开发的好处有哪些-创新互联

declare module '*.vue' {
  import { DefineComponent } from 'vue'
  const component: DefineComponent<{}, {}, {}, any>
  export default component
}

const a = 1
const b = 2

const obj = { a, b }

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

const element = Hello World

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

const element = createElement('div', { id: 'root' }, 'Hello World')

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

但是 SFC 就不一样了。

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

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

• 一个文件只能写一个组件

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

• 变量绑定只能获取this上面的内容，不能使用全局变量（很多时候我们都要把全局变量先挂载到this上）

  
  

我们一点点来讲

一个文件只能写一个组件

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

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

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

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

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

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

const Input = { ... }

export default Input

export const Textarea = (props) => 

export const Password = (props) => 

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

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

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

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

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

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

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

const Comp = () => } 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 中则不复存在：

const citys = []

const Comp = () => {
  return citys.map(c => 
{c}
)
}

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

• 多了注册组件这个步骤，增加代码量

• 通过字符串名注册自然就会出现可能的冲突问题

• 模板解析组件支持不同的样式，比如和，容易导致风格不一的问题

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

const Comp = {...}

const App = () => 

需要通过directive来扩展能力

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

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

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

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

const App = () => (
  

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

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

const App = () =>
  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进行开发的好处有哪些了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注创新互联行业资讯频道。