jsx编译后生成什么

㈠ 为什么我推荐使用JSX开发Vue3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

但是 SFC 就不一样了。

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

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

我们一点点来讲

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我们看一个ScopedSlots的例子：

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

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

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

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

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

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

而这在 JSX 中则不复存在：

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

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

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

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

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

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

这仍然是因为 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 社区或者官方开发了插件之后才能运行。而 JSX 因为有 babel 和 typescript 的官方支持， 基本上所有新的 JS 生态工具原生都是支持的。

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

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

㈡ browserify 怎么把jsx转化js

Browserify 可以让你使用类似于 node 的 require() 的方式来组织浏览器端的 javascript 代码，通过预编译让前端 Javascript 可以直接使用 Node NPM 安装的一些库。

安装：
npm install -g browserify

示例

这是 main.js 的内容，像普通的 nodejs 程序那样使用 require() 加载库和文件：
var foo = require('./foo.js');
var bar = require('../lib/bar.js');
var gamma = require('gamma');

var elem = document.getElementById('result');
var x = foo(100) + bar('baz');
elem.textContent = gamma(x);

导出的方法：
mole.exports = function (n) { return n * 111 }

使用 browserify 编译：
$ browserify main.js > bundle.js

现在 main.js 需要的所有其它文件都会被编译进 bundle.js 中，包括很多层 require() 的情况也会一起被递归式的编译过来。

编译好的 js 可以直接拿到浏览器使用
<script src="bundle.js"></script>

㈢ 如何使用 ES6 编写一个 React 模块，并且编译后发布到 NPM

前言
如果你在使用 React， 那么肯定已经撸了好多自己的组件， 并尝试着共享出来。在 OneAPM 前端开发过程中， 我们也曾遇到了一些组件共享的问题：
例如:
是通过 git 直接发布还是通过 NPM 发布 ？
发布的是 ES5 的代码还是 ES6 的代码 ？
如何解决 Babel5 和 Babel6 的冲突 ？
这篇文章会通过编写一个叫做 MyComponet 的例子来演示发布一个模块需要注意的地方, 并不涉及单元测试和代码规范等。
前端开发果真是发展迅猛，刚享受到由模块化，组件化和单元测试带来的种种好处，又得迅速拥抱 Grunt, Gulp, Browserify， Webpack 这类自动化工具的变革。除了工具和生态圈，JavaScript 本身也在飞速发展着。ES2015(ES6) ，ES2016(ES7) ... 照这样的节奏，几乎是一年一个标准。标准多了，为解决兼容性的问题，竟也派生出了 源代码 和 编译 的概念。前端开发者通过语法糖、转化器、Polyfill 等，可以享受到标准乃至尚未定稿草案里的规范的便利，大幅提升开发效率。
至于这个模块本身,它的功能特别简单, 就是显示模块自身的的属性。
源代码
我们来编写组件 MyComponent.jsx ，放到项目的 src 目录下。

import React from 'react';

const MyComponent = props=> {
return <div>
props:
<pre>{JSON.stringify(props, null, 2)}</pre>
</div>
}

export default MyComponent;

关于各种文件放在哪里, 这里是我推荐的一些约定:
src 下用于存放源代码
lib 是编译后的代码，这个目录只读
所有包含 ES6 语法的文件名统一后缀为 .es6
所有包含 JSX 语法的文件后统一缀名为 .jsx
假设源代码里还有另外两个文件 foo.es6 和 bar.js，简化起见都丢到 src 的根目录下。
编译
为了把 ES6 代码编译成 ES5，需要安装 Babel，这个工具可以说野心极大，一次编译可以让 JavaScript 运行在所有地方。（听起来是不是有点 Java 的作风）
目前最常用的是 Babel5 版本，但是 Babel6 版本的设计更为精巧，已经非常推荐更新。也正是由于 Babel 有两个版本，所以开发过程中很有可能遇到这样的情况，
模块 A 的开发依赖于 Babel5 版本，而模块 B 依赖于 Babel6 版本。
解决这个问题最好的做法就是把 A 和 B 拆开，独立开发和发布。并且在发布到 NPM 的时候发布是的编译后的，也就是 ES5 版本的代码。
所以如果你的机器上的 babel 是全局安装的，是时候卸载它了，因为它的版本不是 5 就是 6 ，会导致一些不可预见的问题。
npm uninstall babel-cli --global
正确的安装方式是把 babel-cli 作为 develeopment 的依赖
npm install babel-cli --save-dev
使用的时候并不是直接调用全局的 Babel 而是调用依赖里的 Babel 可执行文件
./node_moles/.bin/babel
如果按照前文的约定来组织代码，src 目录结构看起来是这样的

src
├── bar.js
├── foo.es6
└── MyComponent.jsx

模块所有的代码都在一个目录下，这样编译过程就简单多了，两条命令就可以完成
./node_moles/.bin/rimraf lib
./node_moles/.bin/babel src ---files --source-maps --extensions .es6,.es,.jsx --out-dir lib
输出目录的结构

lib
├── bar.js
├── foo.js
├── foo.js.map
├── MyComponent.js
└── MyComponent.js.map

具体解释一下各个命令的作用：
第一条命令 ./node_moles/.bin/rimraf lib
作用 编译前清空之前的 lib 目录，这是一个好习惯，可以杜绝对 lib 下的文件的任何手动更改。
第二条命令
./node_moles/.bin/babel src --out-dir lib --source-maps --extensions .es6,.es,.jsx ---files
作用 遍历 src 目录下的文件，如果后缀名是 .es/.es6/.jsx 中的一种，就编译成 ES5，否则就直接拷贝到输出目录 lib 下
参数详解:
--out-dir lib 指定输出目录为 lib
--extensions .es6,.es,.jsx 指定需要编译的文件类型
---files 对于不需要编译的文件直接拷贝
--source-maps 生成 souce-map 文件
编译过程中还隐含了一个步骤就是加载 .babelrc 文件里的配置，该文件内容如下

{
"presets": [
"es2015",
"stage-0",
"react"
]
}

这是因为 Babel6 采用了插件化的设计，做到了灵活配置：如果要转换 JSX 语法文件，就加上 react 的 preset，同时项目依赖里要添加
babel-preset-react

npm install babel-preset-react --save-dev

样例代码
开发和调试 React 模块目前最好用的打包工具还是 Webpack，在项目跟目录下，新建一个 example 目录：
example/index.html

<!DOCTYPE html>
<html lang="zh-cn">
<head>
<meta charset="UTF-8">
<title>Example</title>
</head>
<body></body>
<script src="bundle.js"></script>
</html>

example/src/index.jsx

import React from 'react';
import MyComponent,{foo,bar} from '../../';
import {render} from 'react-dom';

var element = document.createElement("div");
document.body.appendChild(element);
render(<MyComponent name="myComponent"/>, element);

webpack.config.js

var path = require('path');

mole.exports = {
entry: path.join(__dirname, 'example', 'src', 'index.jsx'),
output: {
filename: 'bundle.js'
},
mole: {
loaders: [{
test: /\.jsx$/,
loader: 'babel',
include: [
path.join(__dirname, 'example')
]
}]
},
devServer: {
contentBase: path.join(__dirname, 'example')
}
}

运行样例代码

./node_moles/.bin/webpack-dev-server

发布
发布前，还有一件事就是为你的模块添加一个入口文件 index.js

mole.exports = require('./lib/MyComponent');
exports.default = require('./lib/MyComponent');
exports.bar = require('./lib/bar');
exports.foo = require('./lib/foo');

接下来就是发布到 NPM 了。

npm publish

使用
别的开发者在使用你新发布的模块的时候可以这样导入

import MyComponent,{foo,bat} from 'react-component-example'

导入的直接是 ES5 代码，跳过编译从而避免了出现 Babel 版本不一致的问题，并且速度更快，是不是很棒！
不过假设你的模块包含很多组件，开发者可能只想用其中的一个或某几个，这时可以这样导入：

import MyComponent from 'react-component-example/src/MyComponent.jsx'

导入的是 ES6 代码，并且会被加入父级项目的编译过程。

㈣ 怎么在html5中直接编译jsx

/newscodejs.asp?lm2=84&list=5&icon=/img/fk.gif&tj=0&font=9&hot=0&new=0&line=0&lmname=0&open=1&n=36&more=0&t=0&week=0&zzly=0&hit=0&pls=0
这个文件显示的结果必须是js格式
如输出<img src="1.jpg" />
需要写成
document.write("<img src=\"1.jpg\" />")

㈤ PS导入.jsx文件后生成的东西可能为xml吗（人物的动作动画）

不能，ps无法生成xml。

㈥ js 和 jsx 有什么区别

js就是前端开发语言，jsx是React框架下用的，要在React框架中的编译器编译成js语言才能使用的

㈦ 如何使用react-tools将jsx编译成JavaScript

使用react-tools将jsx编译成JavaScript方法：
1,通过npm安装react-tools
npm –g react-tools
2,通过cmd进入项目根目录执行watch命令 jsx --watch src/ build/
src路径下存放的是jsx文件，编译后的js存放到build路径下
3,当目标文件变化以后，自动构建生成新的js文件。

㈧ 如何使用react-tools将jsx编译成JavaScript

jsx--watchsrc/build/

目前官方已经停止维护 jsx 工具，推荐使用 babel 来替代。

㈨ jsx是javascript的一种语法扩展吗

对的，JSX就是Javascript和XML结合的一种格式。React发明了JSX，利用HTML语法来创建虚拟DOM。当遇到<，JSX就当HTML解析，遇到{就当JavaScript解析。

如下(JS写法)

varchild1=React.createElement('li',null,'FirstTextContent');
varchild2=React.createElement('li',null,'SecondTextContent');
varroot=React.createElement('ul',{className:'my-list'},child1,child2);

等价于(JSX写法)

varroot=(
<ulclassName="my-list">
<li>FirstTextContent</li>
<li>SecondTextContent</li>
</ul>
);

后者将XML语法直接加入JS中,通过代码而非模板来高效的定义界面。之后JSX通过翻译器转换为纯JS再由浏览器执行。在实际开发中，JSX在产品打包阶段都已经编译成纯JavaScript，JSX的语法不会带来任何性能影响。另外，由于JSX只是一种语法，因此JavaScript的关键字class, for等也不能出现在XML中，而要如例子中所示，使用className, htmlFor代替，这和原生DOM在JavaScript中的创建也是一致的。JSX只是创建虚拟DOM的一种语法格式而已,除了用JSX,我们也可以用JS代码来创建虚拟DOM。