小程序框架原理综合分析和 fard 的新思路

halo,你们好,我是 132 ,很久不贱~前端

今天给你们带来的是一个 fre 转小程序的新框架,叫 fard,它使用了很是精彩的思路,将 fre 代码跑到小程序环境里vue

背景

当下国内前端环境中,几乎每个框架做者最终都会研究小程序,如 nerv 和 taro,anu 和 nanachireact

加上前阵子某人发微博说出 “hooks 没法用于别处,想用就得从新实现” 这种膝盖言论git

我急迫的想要给 fre 一个归宿,寻找适用于 fre 的小程序方案github

现有方案

在作 fard 以前,我看了几乎全部的小程序框架,如下:web

编译型 封装型
taro wepy
nanachi mpx
mpvue
uniapp
chameleon

以上列举的只是常见的,还有不少小众的没有写出,小程序框架比小程序还多::>_<::小程序

编译型

对于编译型框架,基本上就是 AST 转译,写 react/vue 的语法,编译出小程序的语法weex

这样作的好处是理论上无所不能,啥都能转,甚至使用 parcel 的策略能让编译速度很快app

可是致命缺陷是,全程写的不是真的 react,react 内部的遍历过程根本没走,并且还须要制定足够严格的语法约定框架

我认为,这个方向是走投无路的方向

封装型

封装型框架,基本就是对小程序的 API 进行封装,使其长得像 vue

优势是可以最大程度的接近原生,缺点是没有足够的抽象层,没法跨端

跨端

了解完两种类型的框架,咱们来探讨一下“跨端”

跨端一直是不少人乐此不疲的事情,跨端的关键点在于寻找一个【抽象中间层】

  • 好比 taro 等使用 AST 做为抽象中间层
  • flutter 使用各个端都支持的渲染引擎做为抽象中间层
  • RN 本身搞了个 bridge,把桥做为抽象中间层
  • weex 利用 v8 搞了个 runtime 做为抽象中间层

(以上仅仅是举例,不要深究他们的原理)

因此,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',
            type:'text'
        }
    ]
}
复制代码

咱们彻底能够经过 template 模拟出来

<template is="@2">
    <view>
        <block wx:for="{{props.children}}" wx:key="">
            <template is="{{item.name}}"></template>
      </block>
    </view>
</template>

<template is="@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

前提是要有设计精巧的抽象中间层

总结

最终,放上 fre 和 fard 的地址,有兴趣的能够看看:

github.com/132yse/fard

github.com/132yse/fre

相关文章
相关标签/搜索