2017 年 1 月 9 日凌晨，微信正式推出小程序，为移动端宗族添加了新的事务形状和玩法，自此各大渠道纷繁跟进，短短4年内，各大巨型运用都现已拥有了自己的小程序生态，而这对开发者而言不可避免的带来了更多重复的开发作业，这促进了很多小程序结构（mpvue/ Chameleon/uni-app/taro）向多端适配上面跨进。
Taro 作为在开源社区中最为活泼的小程序开发结构，其结构架构的改变无疑是咱们学习小程序跨渠道开发结构的最好教程，所以今天咱们经过本文来讨论 Taro 是怎样如何做结构支撑多 DSL 的完成探索，使得开发者能够运用任意抢手结构/语法/DSL 来编写小程序运用，一起复用相关生态的。
如何用 React 写小程序
在开端探讨 Taro 的做法之前，咱们能够先想一想自己有没有什么好的办法来让小程序跑在 React 上。
有一个简略的比如，咱们在浏览器不支撑 ES6 的写法时咱们是怎样在代码里写 ES6 的呢？
从 Babel 开端
上述问题不需赘述，经过 Babel 咱们能够将代码转化成笼统语法树（AST），再将语法树依据咱们需求适应的渠道来转化生成支撑的代码。那么同理，其实咱们彻底能够将 React 的写法先转化成笼统语法树，再生成对应小程序的代码来达成咱们用 React 来写小程序的意图。
实际上初代的 Taro 最根本的原理便是如此，为此 Taro 在1.x 的版别中专门保护了一个包 taro/packages/taro-transformer-wx at v1.3 NervJS/taro 来将 React 的各种写法依据 AST 转化成小程序代码来到达运用 React DSL 书写小程序的意图。
Taro 的初代架构
根据 Babel 转化代码的原理，Taro 初代的架构分为 编译时 和 运转时
编译时
在初版 Taro 的编译时，Taro 会依据装备来将入口文件中的 config 进行遍历处理，判别页面依赖、获取页面模板并依据对应编译渠道输出成对应渠道的小程序文件。
其中原 Taro 组件的 render 部分会被移除，经过 Babel 来解析生成页面的模板(xxx.wxml)，其余部分则会被 Taro 经过 Babel 转化成其运转时包装处理的部分，大约的结果咱们能够经过一个简略的比如来看：
// 编译前
import Taro, { Component } from '@tarojs/taro'
import { View, Text } from '@tarojs/components'
import './index.css'
export default class Index extends Component {
componentWillMount () { }
componentDidMount () { }
componentWillUnmount () { }
componentDidShow () { }
componentDidHide () { }
config = {
navigationBarTitleText: '首页'
}
render () {
return (
<View className='index'>
<Text>Hello world!</Text>
</View>
)
}
}
// 编译后
var Index = (_temp2 = _class = function (_BaseComponent) {
_inherits(Index, _BaseComponent);
function Index() {
var _ref;
var _temp, _this, _ret;
_classCallCheck(this, Index);
for (var _len = arguments.length, args = Array(_len), _key = 0; _key < _len; _key++) {
args[_key] = arguments[_key];
}
return _ret = (_temp = (_this = _possibleConstructorReturn(this, (_ref = Index.__proto__ || Object.getPrototypeOf(Index)).call.apply(_ref, [this].concat(args))), _this), _this.$usedState = [], _this.config = {
navigationBarTitleText: '首页'
}, _this.customComponents = [], _temp), _possibleConstructorReturn(_this, _ret);
}
_createClass(Index, [{
key: '_constructor',
value: function _constructor(props) {
_get(Index.prototype.__proto__ || Object.getPrototypeOf(Index.prototype), '_constructor', this).call(this, props);
this.$$refs = new _tarojs_taro_weapp__WEBPACK_IMPORTED_MODULE_0___default.a.RefsArray();
}
}, {
key: 'componentWillMount',
value: function componentWillMount() {}
}, {
key: 'componentDidMount',
value: function componentDidMount() {}
}, {
key: 'componentWillUnmount',
value: function componentWillUnmount() {}
}, {
key: 'componentDidShow',
value: function componentDidShow() {}
}, {
key: 'componentDidHide',
value: function componentDidHide() {}
}, {
key: '_createData',
value: function _createData() {
this.__state = arguments[0] || this.state || {};
this.__props = arguments[1] || this.props || {};
var __isRunloopRef = arguments[2];
var __prefix = this.$prefix;
;
Object.assign(this.__state, {});
return this.__state;
}
}]);
return Index;
}(_tarojs_taro_weapp__WEBPACK_IMPORTED_MODULE_0__["Component"]), _class.$$events = [], _class.$$componentPath = "pages/index/index", _temp2);
/* harmony default export */ __webpack_exports__["default"] = (Index);
Component(__webpack_require__(/*! @tarojs/taro-weapp */ "./node_modules/@tarojs/taro-weapp/index.js").default.createComponent(Index, true));
咱们能够显着看到编译后的代码中 render 函数现已不存在了，且代码中原先引证 Component 的部分被替换成了 Taro 的 BaseComponent 和 createComponent，这两位便是 Taro 初版运转时的核心。
运转时
Taro 的运转时会经过内置的 BaseComponent 和 createComponent 来达成对小程序页面的组件化，并完成对 data、props、声明周期事情等的绑架。
在 Taro 规划的初期，由于微信小程序刚推出的自定义组件功用并不完善，完成不了传入自定义函数等问题，无法满足组件化灵活运用的需求，所以 Taro 的组件化架构是选用 template 标签来完成的，其有两个首要问题：
- JS 逻辑与模板阻隔，需求分别处理，导致组件传参非常麻烦，难以对齐
- template 完成的自定义组件无法嵌套子组件
所以在小程序更新了自定义组件，并完善了其自定义函数的传递问题之后， Taro 跟进了该项更新，经过将 Taro 的组件直接编译成小程序的原生组件的 Component 办法调用，并在运转时把各个生命周期的回调绑定到对应的组件声明周期，将 props 、函数等绑定到小程序组件对应的装备中，来对组件参数、生命周期适配、以及事情的处理，然后凭借小程序的组件化才能来完成 Taro 的组件处理。
暂时无法在文档外展现此内容
在编译时会将引证的 react 经过 babel 直接替换成 taro-weapp，所以实际上初版的 Taro 中 react 仅仅纯写法罢了。
和 mpvue 的区别
在同类的结构中， mpvue 作为官方出品的小程序结构也分为编译时和运转时。
编译时
在 mpvue 的编译时，其做的作业和 Taro 相同，都是将其 vue template 语法经过编译器转化成小程序的 wxml 格局。
运转时
在 mpvue 的运转时，其会完成一次 Vue 实例化的过程，在实例化后会调用 Page 来实例化小程序页面，而小程序的 data 则会被 vue 的呼应式 data 阻拦，在 data 改变后会直接触发 vue 的 render patch 等阶段，如果使咱们平常自己运用 vue ，这儿就会开端调用浏览器的更新 dom api来改变 dom，可是由于小程序中没有操作 dom 的办法，所以在 mpvue 中会屏蔽 patch 之后的 dom 操作办法（经过置空对应 dom api），转而运用 $updateDataToMp 将 vue 中的 data 更新到小程序的 data 中，能够视作调用一次小程序原生的 setData 办法。
相比 Taro 的编译时自己造各种语法转化的轮子，mpvue 凭借于 vue 和小程序都有模板的特色，使其在编译时的作业量大大减小，而在运转时，相比 Taro 的仅仅运用了 React 的写法，mpvue 则是直接将 vue 跑在了小程序的 js 引擎里，简略地替换了其操作 dom 的 api，大大的减少了作业量，然后避免了项目杂乱度引起的更多问题，一起完好的支撑了 vue 的特性而非 Taro 的假支撑。
Babel 的问题
在经过 Babel 完成了对 React 语法的适配的一起，Babel 带来的学习和保护成本也成为了 Taro 新的痛点。
保护难
大量转化代码都在 Taro 的 CLI 中，这意味着每次需求新增/改动一个功用，例如支撑解析 Markdown 文件或许支撑 JSX 的一个新语法，就需求直接改动 CLI，这意味着功用之间的耦合极高，一不小心就可能导致保护者新增功用的一起影响到了原功用。
上手难
Babel 的代码处理判别分支杂乱，且自身如果对 AST 不了解的同学还需求了解各种概念和变量含义，这导致了社区用户很难参加到 Taro 的开发中去，并且 Taro 这种高度定制化的处理，Babel 的社区为项目带来的帮助几近于无，全赖自己探索，这更加大了上手的困难度。
扩展难
在最开端的版别里，Taro 运用的构建体系是自研的一套体系，其在规划之初没有考虑到后续的扩展性，导致开发者想要添加自定义的功用无从下手。
Taro 2.0 的改变
暂时无法在文档外展现此内容
为了解决自建构建体系和 Babel 带来的问题，Taro 2.0 运用 webpack 作为底层的构建体系，在其上层又添加了一层插件层来解决这些问题。
经过 Taro 自己的插件层，用户能够直接操控 webpack 的装备，并且能够自行在 Taro 层的构建生命周期中做自己需求的特殊处理，然后大大提高了用户运用 Taro 的灵活性和可扩展性。举个比如，如果想为 Taro 添加 less 文件的解析，在开始的版别里，你只能修正 CLI 来内置支撑的预处理器，而经过 2.x 版别，你能够经过 Taro Plugin 修正 webpack 装备支撑预处理对应文件。
而根据 webpack 的办法也让之前把所有编译时处理逻辑内置到 CLI 的办法产生了改变，经过 webpack 的 loader 和 plugin 把编译时的处理分解抽离，使得 2.0 版别的 CLI 体积适当轻量，仅仅做了初始化一个编译对象的作业，剩下的处理大都交由 webpack 进行，如此大大降低了参加 Taro 的保护和开发成本。
Taro Next【3.0】 跨渠道架构
从浏览器中运用 react vue 等结构带来的考虑
Taro Next 的架构诞生来源于对现代结构开发的考虑，从图中咱们能够清楚地看到，不管你运用什么结构，最后为了在浏览器上进行烘托，都会调用浏览器的 DOM BOM API ，也便是说在前端开发结构的最底层一直都是 BOM 和 DOM ，那么咱们换一个方向想：是不是只需有了 BOM 和 DOM，都能轻松地适配结构呢？
把 DOM 和 BOM 搬到小程序
答案当然是必定的，小程序和 web 开发最大的不同点就在于为了功能/安全性，小程序的 webview(烘托层) 移除了所有的 DOM 和 BOM 操作，Taro 为了保证各种前端结构都能在小程序中跑起来，给出的解决方案便是新增一个 runtime 包，其效果便是为小程序扩展一套简易的 BOM 和 DOM API ，用户每次经过结构都会更改 runtime 中的虚拟 dom，而每次 render 则会触发小程序自己的 setData 然后到达结构到小程序运转的意图，这也便是 Taro Next 的开放式结构最大的特色：经过供给一致的 Runtime ，来支撑各种不同的结构接入小程序。
Taro 中接入结构
抱负情况下，在有了 DOM 和 BOM 之后，彻底根据这些 API 开发的结构就能够直接接入 Taro 为 Taro 新增结构支撑了，可是某些结构，例如 React，为了保证烘托的兼容性，其有一层自己的封装(React Dom)，为了抹平这一部分差异，Taro 供给了胶水层和接入结构的 Taro 插件在运转时解决这一类问题，详细的比如能够参阅 小程序跨结构开发的探索与实践 | Taro 文档 React 和 Vue 的完成部分来了解。
Taro 的事情派发
有了 Taro 的 Runtime 层，理论上 Taro 能够完成一套各结构通用的事情逻辑，而不是运用小程序的事情。
为了做一个通用的事情处理机制，咱们需求不管在哪个节点产生了事情的都需求准确定位节点，而 Runtime 实际上是供给了一个仅有值的，且其在 eventSource 中也存储了这个 sid 和对应节点的映射关系。
根据此，咱们能够经过 Runtime中的 document.getElementById 办法清楚地知道哪个节点产生了事情。
经过这些 api 的合作，Taro 推出了如下的事情机制：
新架构的编译时
咱们从之前的文章中提到，Taro 在曩昔的版别中一直有将 render 办法中的 JSX 经过 Babel 转化成模板的做法，可是在新架构中编译时产生了一些改变。
在有了 Taro 的 Runtime 之后，结构对 Dom 的操作映射到了 Runtime 中，每次 render 都会改变 Runtime 中的虚拟 Dom 树，而虚拟 Dom 树的节点数据能够作为小程序的 data 用于烘托整个小程序页面。
所以 Taro 在 3.x 中供给了一个共用模板，这个模板包含了小程序的所有根本组件，且每个子模板都支撑循环嵌套，也便是说咱们只需有小程序的 dom 树 data，咱们就能够把这个 data 经过这个模板循环烘托成完好的小程序节点。
<wxs module="xs" src="./utils.wxs" />
<template name="taro_tmpl">
<block wx:for="{{root.cn}}" wx:key="uid">
<template is="tmpl_0_container" data="{{i:item,l:''}}" />
</block>
</template>
...
<template name="tmpl_0_slide-view">
<slide-view show="{{i.show}}" buttons="{{i.buttons}}" bindbuttontap="eh" bindshow="eh" children="{{i.children}}" bindhide="eh" id="{{i.uid}}">
<block wx:for="{{i.cn}}" wx:key="uid">
<template is="{{xs.e(cid+1)}}" data="{{i:item,l:l}}" />
</block>
</slide-view>
</template>
<template name="tmpl_0_video-swiper">
<video-swiper swiperKey="{{i.swiperKey}}" items="{{i.items}}" current="{{i.current}}" videoShow="{{i.videoShow}}" id="{{i.uid}}">
<block wx:for="{{i.cn}}" wx:key="uid">
<template is="{{xs.e(cid+1)}}" data="{{i:item,l:l}}" />
</block>
</video-swiper>
</template>
<template name="tmpl_0_container">
<template is="{{xs.a(0, i.nn, l)}}" data="{{i:i,cid:0,l:xs.f(l,i.nn)}}" />
</template>
...
得益于小程序能够经过 a.b.c.d 来作为 data 的键值来更新，在 Runtime 层还能够做到细粒度更低的更新。
这样的做法，彻底省掉了之前需求用 Babel 进行 JSX 语法转化成小程序模板的过程，也便是说在新版别的 Taro 中，是没有剩余的编译时处理的，在编译时只需求做的事便是经过 webpack 为大局注入Taro Runtime 和做结构到 Runtime 的桥接，其能够说是全运转时的。
开放式架构
根据 Taro 自身的插件机制，结合 webpack ，Taro 在 3.1 版别中将原有支撑各渠道的处理彻底抽离到了其自身的插件里，这意味着之后无论是扩展支撑的渠道、还是扩展支撑的结构，开发者都能够自行开发或许寻觅对应的插件接入 Taro 然后直接开端开发。
总结
引证
小程序跨结构开发的探索与实践 | Taro 文档
凹凸技能揭秘 Taro 从跨端到开放式跨端跨结构
JELLY | 凹凸技能揭秘 Taro 开放式跨端跨结构之路
