Halo, hello, I’m 132. I’ve been a long time
Today I’m going to show you a new framework for fRE to applet, called Fard, which uses a very clever idea to run FRE code into the applet environment
background
In the current domestic front-end environment, almost every framework author will eventually work on small programs, such as Nerv and Taro, anu and Nanachi
Plus a few days ago someone tweeted something like, “Hooks can’t be used elsewhere, need to be reimplemented.
I urgently want to give FRE a home, looking for small program solution suitable for FRE
Existing programs
Before doing fard, I looked at almost all the small program frameworks, as follows:
A compiled | Encapsulation type |
---|---|
taro | wepy |
nanachi | mpx |
mpvue | |
uniapp | |
chameleon |
There are more applets than applets ::>_<::
A compiled
For compiled frameworks, it’s basically an AST translation, writing the react/vue syntax, and compiling the syntax for small programs
The advantage of this is that you can theoretically do anything, and even use the strategy of using parcel to make compilations faster
However, the fatal flaw is that react is not really written throughout. The traversal process inside React is not implemented at all, and strict enough syntax conventions need to be formulated
In my opinion, this direction is the direction of no way out
Encapsulation type
Encapsulation framework, is basically a small program API encapsulation, so that it looks like VUE
The advantage is that it can be as close to the native as possible. The disadvantage is that there is not enough abstraction layer, which can not cross ends
Across the
With these two types of frameworks in mind, let’s talk about “cross-ends”
Cross-end has always been something that many people enjoy. The key point of cross-end is to find an abstract middle layer.
- Taro, for example, uses AST as an abstract intermediate layer
- Flutter uses a rendering engine that is supported on all sides as an abstract middle layer
- RN makes a bridge of its own, using the bridge as an abstract middle layer
- Weex uses V8 to create a Runtime as an abstract middle layer
(The above are just examples, don’t go into their principles)
So, fard just needs to find an intermediate layer and be done with it
Fard principle
Well, the whole article, just this paragraph is the main point :>_<::
First, the FARD is the Framework for the FRE to the Reconciler, which is the React Like framework, which contains the entire Reconciler
Reconciler is a FULLY iterated JS behavior that can run in any JS environment, and small programs are no exception
So in the end, Fard’s program, similar to RN, runs the Fre Reconciler process on the reconciler’s side of the reconciler program, feeding it back to the reconciler view through a bridge
Okay, picture above
First, in the small program, we run all of the logic in the Fre Reconciler, which is where the hooks are located, so the hooks run all of their logic in the FRE
After the run, we have a VDOM (also called fiber, but we only need a subset of vDOM).
Once you’ve got the VDOM, go setData and attach it to the Page
Okay, so at this point, we can say that we’ve got all the JS logic we need, except how to feed it back to the view
Applets themselves are also vDOM mechanism, if it provides the default interface to vDOM, we can directly attach vDOM to it
But it doesn’t, and the only way the applet opens up to modifying the view is the template
So we need to adapt the Template to the VDOM to make it a bridge
This is also very simple, such as vDOM looks like this:
let vdom = {
name:2 '@'.type:'view'.children:[
{
name:1 '@'.type:'text'}}]Copy the code
We can simulate this completely with 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>
Copy the code
We can simulate the entire VDOM from template, and good, bridge is done
In fact, at this point, fard is done
All that remains is to add more cases and encapsulate more common apis to improve performance
Comprehensive analysis of
We see that fARD is similar to RN’s principles, and that our highly abstract Reconciler layers of FRE and the template Bridge of the small program make the whole design very simple and wonderful
And it supports the JSX and hooks APIS perfectly, without any conventions, restrictions, or specifications
After all, that’s what JSX is really about
Likewise, hooks API has been a source of much talk about the dark magic inside of it since its inception, and I have shown that hooks API can be used on any end, including WebGL
The premise is a well-designed abstract middle layer
conclusion
Finally, add the addresses of fre and fard.
github.com/132yse/fard
github.com/132yse/fre