小程序能不能用react
本篇内容主要讲解“小程序能不能用react”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“小程序能不能用react”吧!
创新互联公司：成立与2013年为各行业开拓出企业自己的“网站建设”服务，为上千余家公司企业提供了专业的成都网站设计、成都网站制作、网页设计和网站推广服务， 按需制作网站由设计师亲自精心设计，设计的效果完全按照客户的要求，并适当的提出合理的建议，拥有的视觉效果，策划师分析客户的同行竞争对手，根据客户的实际情况给出合理的网站构架，制作客户同行业具有领先地位的。
小程序能用react，其使用方法：1、基于“react-reconciler”实现一个渲染器，生成一个DSL；2、创建一个小程序组件，去解析和渲染DSL；3、安装npm，并执行开发者工具中的构建npm；4、在自己的页面中引入包，再利用api即可完成开发。
小程序能用react吗？
能。
在微信小程序中直接运行React组件
在研究跨端开发时，我的一个重要目标，是可以让react组件跑在微信小程序中。在这个过程中，我探索了微信小程序的架构，并且引发了很多思考。而作为跨端开发，实际上很难做到 write once，run anywhere，因为每个平台所提供的能力是不一样的，例如微信小程序提供了原生的能力，例如调起摄像头或其他需要原生环境支持的能力，在微信小程序中开发虽然也是在webview中开展，但是，却需要一些原生的思维。所以，要做到 write once 就必须有一些限制，这些限制注定了我们无法完全利用小程序的能力，仅仅只用到一些布局的能力而已。所以，奉劝各位，在做跨端开发时，要有个心理准备。但如果跳出跨端开发，我现在只开发小程序，那我能否用我熟悉的react来开发呢？甚至，能否用我开发的nautil框架来开发呢？答案是可以的，本文将带你一步一步实现自己的react小程序开发之路，帮助你在某些特定的场景下，完成react项目往小程序迁移的目标。
小程序运行React的方案对比
目前业界能够比较好支持小程序（没有特别注明的情况下，小程序特指微信小程序）运行React组件的，有3套方案，分别是京东凹凸实验室的taro，蚂蚁金服某团队（未找到具体团队名）的remax，微信某团队的kbone。
Taro
编译，新版本也基于运行时
解析为wxml+js
老牌，不断发展，全平台支持，持续迭代
Remax
运行时，带编译宏
基于reconciler
最优雅，增量更新
不够成熟，后续发展未知
Kbone
运行时，依赖webpack
自己实现一套DOM API
可兼容vue，甚至任意基于DOM渲染的框架
性能问题（全量检查），几乎停更
3套方案各有不同，而且在各自的思路上都是独树一帜。就我个人而言，如果不考虑跨端开发，自己实现一套DOM API这种方案是非常有价值的，因为DOM接口是HTML标准，你不需要自己去发明一套标准出来，而一旦实现了DOM API，那么所以其他基于DOM实现的应用理论上都支持在这上面跑。但是，它的不足就是你每换一个平台，就要针对这个平台去实现一套DOM API，这个成本是非常大的，因为DOM接口标准极其庞大，实现的时候也很容易出bug。在我看来，最优雅的实现还是Remax的那种思路，基于react-reconciler做一个渲染器，这个渲染器将react组件实例抽象为一个统一的DSL，在不同的平台上，去解析渲染这个DSL。
但是remax迭代更新之后，它开始强依赖自己的编译工具，这直接导致我放弃在项目中使用它。因为对于我们自己的项目而言，我们其实有可能不需要它的全部，我们只是使用react来完成我们整个小程序中的某些部分（比如有些已经用react写好的h6我们想要渲染到小程序，其他部分我们还是在原来的项目中跑）。如果对它的编译工具有依赖，我们就不得不把整个项目迁移到它的编译工具，那我还不如直接使用taro这个老牌比较稳定的工具。
整体实现思路
经过一番研究之后，我决定采用remax的思路，也就是基于react-reconciler实现一个渲染器，生成一个DSL，再创建一个小程序组件，去解析和渲染这个DSL。在完成实现之后，我把所有这些逻辑构建为最终产物，并以npm的形式发布产物，对于小程序开发者而言，只需要npm安装之后，执行开发者工具中的构建npm即可，之后在自己的页面中引入这个包，利用api即可完成开发，而不在需要使用另外的编译工具。
这一方案的最大好处是，对编译工具的弱（无）依赖，这样就可以让我们的这套方案可以在任意的项目中去跑，而不需要额外引入编译工具切换工具栈。另外，因为reconciler的部分已经打包进npm包了，所以它是一个可以独立运行的模块，所以，你甚至可以在mpvue等vue风格或小程序原生风格项目中使用这个npm包来渲染react的组件。
微信小程序中运行react组件的思路
如上图所示，我们将一个react组件通过基于react-reconciler的渲染器，创建了一个DSL的纯对象（包含回调函数），我们在page的js文件中，通过this.setData把这个对象发送给渲染线程，在wxml中使用了我们提供的一个自引用嵌套的组件对DSL进行渲染。这里需要注意一个点，react-reconciler会在组件更新的时候，触发对应的钩子，此时，会再次生成新的DSL，并再次通过this.setData发送渲染。所以，这个渲染器和单纯使用createElement的结果是不同的，渲染器支持hooks等react内置的功能。
接下来，我将对其中的具体细节进行讲解，以让你尽可能自己可以手写出本文所阐述的代码，以让你在自己的项目中可以实现本文一致的效果。你可以克隆这个仓库到本地，运行效果看看，研究它的整个实现过程。
将react组件渲染为纯JS对象
react的渲染器本质上是一个基于react调度系统的副作用执行器，副作用的结果在web环境下就是DOM的操作，在native环境下就是调用渲染引擎光栅化图形，在art环境下就是调用声卡播放声音，而在我们这次的计划中，我们需要渲染器生成一个纯js对象，以方便交给小程序在小程序的两个线程之间作为消息体进行传递，并基于这个对象在小程序中渲染界面。
有同学对我发出疑问：jsx编译之后React.createElement的执行结果不就是纯JS的对象么？这里需要了解react的本质。react的组件，实际上为react提供了一套描述系统，它描述了react所表达的具体对象的结构。但是，这个描述是抽象的，只有当你把它实例化，运行起来时，它才有意义。我们在组件中所做的描述，可不单单只有jsx的部分，它还包括业务和程序层面的逻辑。比如很多场景下，我们需要根据组件状态来决定返回那一部分jsx，从而渲染不同的界面。而这部分内容，需要依赖一个环境来执行，也就是react渲染器。
在以前，我们只能模拟react-dom，按照它的运行逻辑，自己手写一个渲染器。而现在，react把它的调度器专门做了一个库，react-reconciler，帮助开发者快速接入react的调度系统，从而可以构建自己的渲染器。这里有一个视频（自备梯子），介绍了react-reconciler的基本用法和使用效果。
import Reconciler from 'react-reconciler'
const container = {}
const HostConfig = {
// ... 极其复杂的一个配置
}
const reconcilerInstance = Reconciler(HostConfig)
let rootContainerInstance = null
export function render(element, { mounted, updated, created }) {
if (!rootContainerInstance) {
rootContainerInstance = reconcilerInstance.createContainer(container, false, false)
}
return reconcilerInstance.updateContainer(element, rootContainerInstance, null, () => {
notify = { mounted, updated, created }
created && created(container)
mounted(container.data)
})
}
上面代码中，没有给出的HostConfig的具体内容是关键，它用于配制一个Reconciler，从代码的角度，它就是一个钩子函数的集合，我们需要在每个钩子函数内部写一些副作用来操作container，你可以看到，在不同的时刻，我们传入的created, mounted, updated会被调用，而它们接收被操作过的container，从而让我们获得这个js对象（container上还有一些函数，但我们可以不用理会，因为this.setData会自动清除这些函数）。
由于这一配置内容太过复杂，要讲解清楚需要花费比较大的篇幅，所以我直接把源码地址贴在这里，你可以通过阅读源码来了解它都有哪些配置项，并且你可以把这部分代码拆分出来后，运行一个自己的组件，通过console.log来观察它们被调用的时机以及顺序。
总而言之，这些接口都是知识层面的，不是什么复杂的逻辑，了解每一个配置项的作用和执行时机之后，你就能写出自己的渲染器。理论上，它没有什么难度。
基于react-reconciler，我在react运行时的每一个环节都做了一些副作用操作，这些副作用的本质，就是修改一个纯js对象，当react被运行起来时，它会经历一个生命周期，这在我的一个视频中有讲到react的生命周期的具体过程。你也可以关注我的个人微信公众号 wwwtangshuangnet 和我讨论相关的问题。在每一个生命周期节点上，调度器就会执行一个副作用，即修改我提供的那个纯js对象。
我提供了两个方法，用于在小程序的渲染器中，获得生成好的js对象。得到这个js对象之后，就可以调用小程序的this.setData，把这个对象发送到渲染线程进行渲染。
利用react渲染器得到的纯对象上存在一些函数，调用这些函数会触发它们对应的逻辑（比如调用setState触发hooks状态更新），从而触发调度器中的钩子函数执行，container对象再次被修改，updated被再次调用，this.setData被再次执行，这样，就实现了真正的react运行时在小程序中的植入。
嵌套递归自引用组件
渲染线程接收到this.setData发送过来的js对象后，如何将这个对象作为布局的信息，渲染到界面上呢？由于小程序的特殊架构，它为了安全起见，渲染线程中无法执行可操作界面的脚本，所有的渲染，都得依靠模板语法和少量的wxs脚本。所以，要怎么做呢？
小程序提供了自定义组件的功能，在app.json或对应的page.json中，通过usingComponents来指定一个路径，从而可以在wxml中使用这个组件。而有趣的地方在于，组件本身也可以在组件自己的component.json中使用usingComponents这个配置，而这个配置的内容，可以直接指向自己，例如，我在自己的组件中，这样自引用：
// dynamic.json
{
"usingComponents": {
"dynamic": "./dynamic"
}
}
自己引用自己作为组件之后，在其wxml中，我们就可以使用组件自己去渲染子级数据，即一种嵌套递归的形式进行渲染。
我规定了一种特别的数据结构，大致如下：
{
type: 'view',
props: {
class: 'shadow-component',
bindtap: (e) => { ... },
},
children: [
{
type: 'view',
props: {},
children: [
...
],
},
],
}
模板中，通过对type的判断，选择不同的模板代码进行渲染。
在wxml中把所有组件通过这种形式枚举出来之后，这个组件就能按照上述的数据结构递归渲染出整个结构。
当然，这里还需要处理一些细节，例如响应data的变化，事件响应函数等，你可以通过源码了解具体要怎么处理。另外，微信小程序this.setData限制在1M以内，我虽然还没有尝试过很大的数据，但是，这个限制肯定在将来是一个风险点，我现在还没有解决，还在思考应该怎么最小化更新粒度。
不支持直接JSX的变通方法
小程序的编译，没有办法自己配置支持新语法，所以如果我们在小程序代码中使用jsx，就必须先走一遍自己的编译逻辑。有两种解决办法，一种是不使用jsx语法，而是使用hyperscript标记语法，比如：
import { createElement as h } from 'react'
function Some() {
return h(
'view',
{ class: 'some-component' },
h(
'view',
{ class: 'sub-view' },
'一段文字',
),
'一段文字',
)
}
这样的写法显然没有直接写jsx来的方便，但是阅读上没有什么障碍，且不需要将jsx编译的过程。
另一种办法是走一遍编译，在小程序的页面目录下，创建一个页面同名的.jsx文件，再利用bebel将它编译为.js文件。但是这样的话，你需要在发布小程序的时候，忽略掉所有的.jsx文件。另外，还有一个坑是，小程序的编译不提供process.env，所以编译react的结果用的时候会报错。解决办法是把react的cjs/react.production.min.js作为react的入口文件，通过小程序的构建npm的相关配置逻辑，指定react构建的文件。
到此，相信大家对“小程序能不能用react”有了更深的了解，不妨来实际操作一番吧！这里是创新互联网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
文章标题：小程序能不能用react
文章地址：http://ybzwz.com/article/jjsjeo.html
