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