小程序框架原理综合分析和 fard 的新思路
|
halo，大家好，我是 132 ，好久不贱~ 今天给大家带来的是一个 fre 转小程序的新框架，叫 fard，它使用了非常精彩的思路，将 fre 代码跑到小程序环境里 背景当下国内前端环境中，几乎每一个框架作者最终都会研究小程序，如 nerv 和 taro，anu 和 nanachi 加上前阵子某人发微博说出 “hooks 无法用于别处，想用就得重新实现” 这种膝盖言论 我急迫的想要给 fre 一个归宿，寻找适用于 fre 的小程序方案 现有方案在做 fard 之前，我看了几乎所有的小程序框架，以下：
以上列举的只是常见的，还有很多小众的没有写出，小程序框架比小程序还多::>_<:: 编译型对于编译型框架，基本上就是 AST 转译，写 react/vue 的语法，编译出小程序的语法 这样做的好处是理论上无所不能，啥都能转，甚至使用 parcel 的策略能让编译速度很快 但是致命缺陷是，全程写的不是真的 react，react 内部的遍历过程根本没走，而且还需要制定足够严格的语法约定 我认为，这个方向是走投无路的方向 封装型封装型框架，基本就是对小程序的 API 进行封装，使其长得像 vue 优点是能够最大程度的接近原生，缺点是没有足够的抽象层，无法跨端 跨端了解完两种类型的框架，我们来探讨一下“跨端” 跨端一直是很多人乐此不疲的事情，跨端的关键点在于寻找一个【抽象中间层】
(以上仅仅是举例，不要深究他们的原理) 所以，fard 只需要寻找一个中间层，就完事了 Fard 原理好吧，通篇，就这段是重点 ::>_<:: 首先，fard 是 fre 转小程序的框架，fre 是 react like 框架，它包含了整个 reconciler reconciler 全程都是 js 的遍历行为，能够跑在任何 js 环境中，小程序也不例外 所以最终 fard 的方案，就和 RN 类似，在小程序端跑 fre reconciler 过程，跑完再通过某个【桥】反馈给小程序视图 好吧，上图
如图，首先，在小程序里，跑 fre reconciler 的所有逻辑，hooks 就位于这个阶段，所以 hooks 所有逻辑，都是在 fre 中跑完的 跑完后就好说了，我们拿到了一个 vdom (也可以说 fiber，但是我们只需要子集 vdom ) 拿到这个 vdom 后，就去 setData，附加给 Page 好的，到这里，可以说全程 js 逻辑，该拿到的都拿到了，就差怎么反馈给视图了 小程序自身也是 vdom 机制的，如果说它默认提供 vdom 的接口的话，我们直接将 vdom 附加过去即可 但是并没有，小程序开放的唯一的修改视图的方法就是 template 所以我们需要根据 vdom 改造 template，使其成为桥梁 这个也非常简单，比如 vdom 长这个样子： let vdom = {
name:'@2',type:'view',children:[
{
name:'@1',0);">'text'
}
]
}
复制代码
我们完全可以通过 template 模拟出来 <template is="@2">
<view>
<block wx:for="{{props.children}}" wx:key="">
<{{item.name}}"></template>
</block>
</view>
</template>
<"@1">
<text></text>
</template>
复制代码
我们可以通过 template 模拟出整个 vdom，很好，bridge 就这么搞定了 其实到这里，fard 就搞定了 剩下的就是，增加更多的 case，封装更多的通用 API，提高性能了 综合分析我们看到 fard 是类似 RN 的原理，我们高度抽象 fre 的 reconciler 层和小程序的 template bridge，使得整个设计非常的简单却精彩 而且它能够完美的支持 jsx 和 hooks API，不存在任何约定任何限制任何规范 毕竟，这才是 jsx 真正的意义 同样的，hooks API 自出现以来，关于它内部的黑魔法也一直令人津津乐道，我用实际行动证明，hooks API 完全可以用到任何端，也包括 webgl 前提是要有设计精巧的抽象中间层 （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
