小程序框架原理综合分析和 fard 的新思路
栏目: JavaScript · 发布时间: 5年前
内容简介:halo,大家好,我是 132 ,好久不贱~今天给大家带来的是一个 fre 转小程序的新框架,叫 fard,它使用了非常精彩的思路,将 fre 代码跑到小程序环境里当下国内前端环境中,几乎每一个框架作者最终都会研究小程序,如 nerv 和 taro,anu 和 nanachi
halo,大家好,我是 132 ,好久不贱~
今天给大家带来的是一个 fre 转小程序的新框架,叫 fard,它使用了非常精彩的思路,将 fre 代码跑到小程序环境里
背景
当下国内前端环境中,几乎每一个框架作者最终都会研究小程序,如 nerv 和 taro,anu 和 nanachi
加上前阵子某人发微博说出 “hooks 无法用于别处,想用就得重新实现” 这种膝盖言论
我急迫的想要给 fre 一个归宿,寻找适用于 fre 的小程序方案
现有方案
在做 fard 之前,我看了几乎所有的小程序框架,以下:
编译型 | 封装型 |
---|---|
taro | wepy |
nanachi | mpx |
mpvue | |
uniapp | |
chameleon |
以上列举的只是常见的,还有很多小众的没有写出,小程序框架比小程序还多::>_<::
编译型
对于编译型框架,基本上就是 AST 转译,写 react/vue 的语法,编译出小程序的语法
这样做的好处是理论上无所不能,啥都能转,甚至使用 parcel 的策略能让编译速度很快
但是致命缺陷是,全程写的不是真的 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
前提是要有设计精巧的抽象中间层
以上所述就是小编给大家介绍的《小程序框架原理综合分析和 fard 的新思路》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- Java 框架级 SSM 代码审计思路
- 基于spring boot框架进行二次封装,微型框架编写思路
- [译] 一个思路,如何尝试创建自己的 CSS 框架?
- 原 荐 聊聊 Go Socket 框架 Teleport 的设计思路
- 商业化游戏服务器引擎自定义框架设计思路
- CodeIgniter框架中抽取部分类库做问题追踪的思路
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。