DEV Community: 幻魂

The responsive state engine Helux's playground has been released

幻魂 — Sat, 13 Jan 2024 12:30:24 +0000

The responsive state engine Helux's playground has been released. Welcome to experience it, real time editing of code and viewing of runtime effects helps to quickly learn the basic usage methods of APIs.

Focusing on optimization, surpassing immer, limu finally reaches the top of immutable data performance

幻魂 — Sat, 06 Jan 2024 04:34:08 +0000

limu is designed for modern browsers. It only considers the operating environment that supports Proxy and uses the mechanism of shallow copy on read and mark update on write. This allows users to operate variable data like original data. During the operation, only proxy objects are generated for the read nodes and returned to the user. After reading, the parent and child nodes are directly connected with shallow clone nodes. The proxy object is hidden in the meta data of the node. , after the operation is completed, a new data with structural sharing characteristics is generated, and the meta data generated during the reading process is removed.

This design brings three major benefits:

Transparent data structure
limu is currently the only immutable operation library that can view the data structure of drafts in real time, and is debugging friendly.
Excellent performance
Since the shallow cloning operation is done in advance, and only the read path is cloned and the path pointing between the parent and child nodes is changed, when ending the draft, you only need to judge whether the modified variable is true or false to instantly complete the new copy generation action. In scenarios with large amounts of data and few reads, the performance exceeds that of immer by more than 20 times (the data before 3.12 was about 4 times)
Simple code structure
Since only supporting Proxy is considered, the code design has no historical baggage and can focus on core scenarios of immutable data such as data reading and writing, proxy generation, and frozen implementation, which is conducive to later upgrades and expansion of more features oriented to modern browser standards.

optimization process

Before 3.12, although the performance of limu was several times better than immer, it was far away from structura and mutative These new immutable data operation libraries still have many gaps, so they can only be debugged friendly and several times faster than immer as a promotional point. If you want to pursue the ultimate speed, it is recommended by default. mutative.

After 3.12, limu finally smoothed out these gaps. Let’s start to share the performance optimization process to see how limu cultivates and reaches the peak of performance.

Place meta

At the beginning of the article, we mentioned the point of meta data hiding. meta data records important information such as the proxy object of the current node, father, child, reachable path, data version number, etc. In order to prevent users from perceiving this data exists, and two attempts have been made.

symbol hides meta

Internally uses a symbol tag to store meta

const LIMU_META = symbol('LIMU_META');
const obj = { a: 1, b: { b1: 1 } };

// When reading obj.b, the object { b1: 1 } hides a meta
{ b1: 1, [LIMU_META]: { parent, path, version, modified ... } }

Then at the end of the operation draft, the levelScopes operation force needs to use the delete keyword to remove these redundant data. The inconvenience caused by this method is that when printing the data, you will see a very dazzling LIMU_META attribute in the object. , creating a psychological burden for users to pollute their data.

proto hides meta

In order to keep the data clean, in addition to continuing to use the symbol LIMU_META as a private attribute, this attribute is promoted to __proto__ and hidden. Then the problem arises. If __proto__ is directly operated, the prototype chain will be polluted.

var a = 1;
a.__proto__.meta = 1;
var b = 2;
console.log(b.__proto__.meta); // 1
a.__proto__.meta = 100;
console.log(b.__proto__.meta); // 100 ❌ The prototype chain has been contaminated

In order to bypass contamination, a separate prototype object is created for each object and mixed in the original prototype chain, as shown below:

before:
a.__proto points to Object.Prototype
after:
a.__proto points to Limu.Prototype, Limu.ProtoType points to Object.Prototype
// Each Limu.Prototype is a clean object generated by Object.create(null)

The simplified version of the code is implemented as follows

export function injectLimuMetaProto(rawObj) {
   const pureObj = Object.create(null);
   Object.setPrototypeOf(pureObj, Object.prototype);
   Object.setPrototypeOf(rawObj, pureObj);
   return rawObj;
}

This achieves the effect of using symbol to hide private attributes and using the reconstructed prototype chain to promote private attributes to the prototype chain without polluting the prototype chain.

Performance loss analysis

Although meta has been used to achieve the goal of generating structural shared data, the test results are still 4 to 5 times different from structura and mutative, which makes me believe that limu must still have huge room for improvement.

So I started to fine-tune the source code and run performance test scripts to find possible performance loss points.

Remove meta

When finishing the draft, we need to remove meta to avoid memory leaks. Then we will use the delete operator to disconnect the LIMU_META pointed to by the parent node. After I blocked this delete operation, the performance improved by 2 About times, then the key point becomes how to bypass the delete operation

function finishDraft(){
levelScopes()
}

function levelScopes()(
scopes.forEach((scope)=>{
// Comment out deletaMeta, performance improved by 2 times
// deletaMeta(scope);
});
)

Prototype chain reorganization

The injectLimuMetaProto mentioned above actually involves a process of prototype chain re-pointing, including two setPrototypeOf operations. This function is deliberately shielded and the lower part of meta is placed on the object. The performance is improved by about 4 times. It is found that setPrototypeOf of a large number of nodes actually causes a lot of performance loss.

injectLimuMetaProto(obj),
setMeta(obj, newMeta());
// Replace with the following writing method, performance improved by 4 times
obj[LIMU_META] = newMeta();

Customized optimization plan

After analyzing the performance loss points by constantly annotating the code and running the script, our goal is very clear. How to block the two major performance consumers of delete and setPrototypeOf, and also keep the data clean and meta can be obtained normally.

Finally, I came up with the new data structure Map of es6. When createDraft, a metaMap is generated for each draft, which is used to place the meta corresponding to the data. The pseudo code is as follows:

function getProxy(metaMap, dataNode){
  const meta = !getMeta(dataNode);
  if(!meta){
    const copy = shallowCopy(dataNode);
    const meta = newMeta(copy, dataNode);
    // Use the shallow clone reference of the node itself as the key to store meta
    metaMap[copy] = meta;
  }
  // Meta already exists, return the generated proxy object
  return meta.proxyVal;
}

function createDraft(base){
  const metaMap = new Map();
  return new Proxy(base, {
    get(parent, key){
      const dataNode = parent[key];
      return getProxy(metaMap, dataNode);
    },
  });
}

With this metaMap, there is no more setPrototypeOf behavior. At the same time, continue to operate this metaMap in the finishDraft step and cut off the relevant meta records. Compared with delete, map.delete More efficient, our data is stored in map, so we no longer need to deal with delete.

The pseudo code is as follows

function finishDraft(){
  levelScopes();
}

function levelScopes(){
  scopes.forEach((scope)=>{
  // Comment out deletaMeta, performance improved by 2 times
  // deletaMeta(scope);
  });
}

So far, we have completed the purpose of completely blocking delete and setPrototypeOf. At the same time, the user's data is completely clean and transparent. Next, we enter the optimized performance testing process.

Performance Testing

We have placed the performance test-related code into benchmark. You only need to perform the following steps to experience the performance test performance of the latest version.

git clone git@github.com:tnfe/limu.git
cd limu
cd benchmark
npm i

Then execute the following four sets of commands and observe the printing results.

npm run s1 // Does not operate the draft array, the result is not frozen
npm run s2 // Manipulate the draft array, the result will not be frozen
npm run s3 // Does not operate the draft array, the result is frozen
npm run s4 //Operation draft array, the result is frozen

Test data design

In order to simulate complex data, our test data contains a dictionary of 20+keys.

The data depth corresponding to the key is 26 layers

At the same time, an array of length 10000 will be generated.

Test role preparation

In addition to the four libraries immer, limu, mutative, and structura, the test role also adds pstr and native

pstr uses JSON.parse and JSON.stringify to simulate immer’s produce

// code of pstr
exports.createDraft = function (obj) {
   return JSON.parse(JSON.stringify(obj));
};

exports.finishDraft = function (obj) {
   return obj;
};

exports.produce = function (obj, cb) {
   cb(exports.createDraft(obj));
};

native does nothing but manipulates native objects.

exports.createDraft = function (obj) {
   return obj;
};

exports.finishDraft = function (obj) {
   return obj;
};

exports.produce = function (obj, cb) {
   cb(exports.createDraft(obj));
};

The purpose of adding pstr and native is to compare the performance difference between immutable operation efficiency and hard cloning JSON.parse(JSON.stringify(obj)) and the original operation.

Test code writing

In order to test the reading and writing of complex data, multiple deep-level reading and writing operations will be performed, and operateArr will be added to control whether it is convenient for array operations. Part of the suggestion code as follows:

runPerfCase({
   loopLimit: 1000,
   arrLen: 10000,
   userBenchmark: (params) => {
     const { lib, base, operateArr, moreDeepOp } = params;
     const final = lib.produce(base, (draft) => {
       draft.k1.k1_1 = 20;
       if (moreDeepOp) {
         draft.a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z = 666;
         draft.a1.b.c.d.e.f.g.h.i.j.k.l.m.n = 2;
         draft.a2.b.c.d.e.f.g.h.i.j.k.l.m.n = 2;
         draft.a3.b.c.d.e.f.g.h.i.j.k.l.m.n = 2;
         draft.a4.b.c.d.e.f.g.h.i.j.k.l.m.n = 2;
         draft.a5.b.c.d.e.f.g.h.i.j.k.l.m.n = 2;
         draft.a6.b.c.d.e.f.g.h.i.j.k.l.m.n = 2;
         draft.a7.b.c.d.e.f.g.h.i.j.k.l.m.n = 2;
       }

       if (operateArr) {
         draft.arr[draft.arr.length - 1].a = 888;
         // draft.arr.forEach((item, idx) => { // bad way
         lib.original(draft.arr).forEach((item, idx) => { // good way
           if (idx === 100) {
             draft.arr[1].a = 888;
           }
         });
       }
     });

     if (base === final) {
       die('base === final', lib);
     }
   },
}).catch(console.error);

Each character will be warmed up before officially starting to execute, and then start 1000 traversals. At the end of each traversal, a time is obtained. The final time consumption is summed and divided by 1000 to get the average time consumption of each traversal. Part of Schematic code is as follows:

function oneBenchmark(libName, options) {
   const { userBenchmark, arrLen } = options;
   let lib = immutLibs[libName]; // Get different immutable libraries
   const base = getBase(arrLen);
   const start = Date.now();
   try {
     //Execute user-written performance test cases
     userBenchmark({
       libName,
       lib,
       base,
       operateArr: OP_ARR,
       moreDeepOp: MORE_DEEP_OP,
     });
     const taskSpend = Date.now() - start;
     return taskSpend;
   } catch (err) {
     console.log(`${libName} throw err`);
     throw err;
   }
}

function measureBenchmark(libName, options) {
   const loopLimit = options.loopLimit || LOOP_LIMIT;

   let totalSpend = 0;
   const runForLoop = (limit) => {
     for (let i = 0; i < limit; i++) {
       totalSpend += oneBenchmark(libName, options);
     }
   };
   // preheat
   oneBenchmark(libName, options);
   runForLoop(loopLimit);
   console.log(`loop: ${loopLimit}, ${libName} avg spend ${totalSpend / loopLimit} ms`);
}

Test result display

My machine is macbook pro 2021, M1 chip, 32GB memory.

Executing npm run s1 means that the draft array will not be operated and the result will not be frozen. The result is as follows

loop: 1000, immer avg spend 13.19 ms
loop: 1000, limu avg spend 0.488 ms
loop: 1000, mutative avg spend 0.477 ms
loop: 1000, structura avg spend 0.466 ms
loop: 1000, pstr avg spend 17.877 ms
loop: 1000, native avg spend 0.084 ms

The visualization result is (unit ms, the lower the column, the better the performance)

Executing npm run s2 means operating the draft array and the result is not frozen. The result is as follows

loop: 1000, immer avg spend 11.315 ms
loop: 1000, limu avg spend 0.95 ms
loop: 1000, mutative avg spend 0.877 ms
loop: 1000, structura avg spend 0.646 ms
loop: 1000, pstr avg spend 9.945 ms
loop: 1000, native avg spend 0.107 ms

Executing npm run s3 means that the draft array will not be operated and the result will be frozen. The result is as follows

loop: 1000, immer avg spend 18.931 ms
loop: 1000, limu avg spend 5.274 ms
loop: 1000, mutative avg spend 8.468 ms
loop: 1000, structura avg spend 17.328 ms
loop: 1000, pstr avg spend 10.449 ms
loop: 1000, native avg spend 0.02 ms

structura and immer perform worse than hard clone pstr in this scenario, limu performs best, and mutative comes second.

Executing npm run s4 means operating the draft array and the result is frozen. The result is as follows

loop: 1000, immer avg spend 58.359 ms
loop: 1000, limu avg spend 26.142 ms
loop: 1000, mutative avg spend 32.264 ms
loop: 1000, structura avg spend 74.851 ms
loop: 1000, pstr avg spend 32.481 ms
loop: 1000, native avg spend 0.481 ms

Due to the operation of an array of 10,000 lengths, the time is improved by 2 to 3 times compared to the previous group. structura and immer are still not as good as hard clone pstr in this scenario, limu performs best, and mutative performs best `The next best thing.

Test conclusion

After the above multiple rounds of testing, it is concluded that in the non-freezing scenario, the difference between limu, structura and mutative is not big, all between 10 times and 30 times.

In the frozen scene, limu performs best, followed by mutative, and structura performs worse than immer. The performance is as follows when displayed as a radar chart.

Note: The smaller the area, the better the performance

Conclusion

After the above complete disclosure of optimization details and summary of test results, the performance test results of limu in various non-freezing scenarios are on par with structura and mutative, and are 1 to 2 ahead of structura and mutative in freezing scenarios. times, it can now be claimed that limu has reached the pinnacle of immutable data performance.

In addition to excellent performance, limu data can be viewed in real time. After deep expansion, it becomes json instead of Proxy. It is very friendly for debugging. If you have the ultimate pursuit of performance and do not consider compatibility with non-Proxy environments, limu It will be your best choice. It maintains the same API design as immer. If you do not use the applyPatches related API of immer, you can achieve seamless replacement.

one more thing

helux based on limu will be announced soon, hoping to redefine the react development paradigm and comprehensively improve react applications DX&UX (development experience, user experience), welcome to pay attention and understand in advance.

Friendly links:

❤️ Your little star is our biggest spiritual motivation for open source. Welcome to pay attention to the following projects:

limu The fastest immutable data js operation library.

hel-micro Toolchain-independent runtime module federation sdk.

helux A state engine that integrates atom, signal, and dependency tracking, and supports fine-grained response updates

The sword refers to immer, the faster and stronger immutable data js tool limu stable version released!

幻魂 — Fri, 18 Aug 2023 09:31:20 +0000

Preface

Welcome to understand and pay attention to limu, visit documentation and right-click to bring up the console, you can ** Real-time experience **limu api and immer api for comparison (limu and immer objects are bound globally).

Next, let us learn more about the birth process of limu ^_^

The state of immutable data

Immutable data has the characteristics of structure sharing, which allows some frameworks that rely heavily on shallow comparisons to quickly gain performance benefits (such as react), and also allows some scenarios that require strict immutable data to avoid deep cloning. Redundant performance overhead, and apart from the two very popular tool libraries immutablejs and immer, is there an immutable data tool library with better performance and ease of use than them? Before answering this question, let's look at the dilemma that immutablejs and immer got into.

As a pioneer, immutablejs, the earliest git submission record can be traced back to April 2014. With the immutable state programming concept of react, it became more and more popular after 2015, and has now reached 30K+ stars. In the js language world, it has an important position as a guide for immutable data, leading everyone to realize the importance of immutable data in certain specific programming fields.

However, its problems are also more prominent, mainly attributed to 2 points

1 The api is complex and isolated from the original js operation processing, which has a heavy learning cost and memory burden
2 A set of its own data structure is built in, and it is necessary to directly convert between ordinary json and immutable data through fromJs and toJs, which brings additional overhead.

// additional learning cost and memory burden
immutableA = Immutable. fromJS([0, 0, [1, 2]]);
immutableB = immutableA.set 1, 1;
immutableC = immutableB. update 1, (x) -> x + 1;
immutableC = immutableB. updateIn [2, 1], (x) -> x + 1;

However, immer, which was born in 2018, perfectly solved the above two problems. It cleverly uses Proxy to proxy the original data, allowing users to complete all immutable data operations like the original js (unsupported environments are automatically downgraded defineProperty), so that users do not have any learning cost and memory burden.

const { produce } = limu;
const baseState = {
   a: 1,
   b: [ 1, 2, 3 ],
   c: {
     c1: { n: 1 },
     c2: { m: 2 },
   }
};
// Operate immutable data as smoothly as original js
const nextState = produce(baseState, (draft)=>{
   draft.a = 2;
   draft.b['2'] = 100;
});

console.log(nextState === baseState); // false
console.log(nextState.a === baseState.a); // false
console.log(nextState.b === baseState.b); // false
console.log(nextState.c === baseState.c); // true

But is immer really the ultimate answer? The performance problem of immer is more prominent in large arrays and deep-level object scenarios. See this issue description, many authors in the community began to try to make breakthroughs, and noticed that structura and mutative, I found that it is indeed many times faster than immer as they said, but it still fails to solve the problem of both fast speed and good development experience. I will analyze the two issues in detail below.

limu is born

At the end of 2021, I started to conceive the v3 version of the state library concent, one of the key points is to support deep dependency collection (v2 only supports the first collection of state One-layer read dependency), then you need to use Proxy to complete this action in depth, and use immer in depth to find that viewing drafts in debug mode is very frustrating, and you need to use JSON.parse(JSON.stringify(draft)) to complete, although it was later discovered that the current interface can export a draft copy and view the data structure, but it really annoys me to insert extra current and then erase it at compile time, and current itself has a lot of problems Overhead, plus the following similar performance problems of immer found through issue

 const demo = { info: Array.from(Array(10000).keys()) };
 produce(demo, (draft) => {
   draft.info[2000] = 0; // take long time
 });

I began to try to design and implement limu, expecting to maintain the same API as immer, but faster and better to use, so after countless small iterations, I found some key speed-up techniques (will be introduced below to), solved the memory leak problem, and reached two key points to ensure quality:

Run through 370+ test cases

Test coverage reached 97%

At the same time, after making the performance and ease of use meet my ideals, I can finally officially announce the release of the stable version, and it has begun to serve as a basic component in News Portal, and then we will focus on the three major advantages of limu.

faster

Different from the copy-on-write mechanism of immer, limu adopts shallow clone on read and mark-on-write mechanism. Let’s take the following figure as an example to explain the specific operation process. After using the produce interface to generate draft data , limu will only make a shallow clone of the relevant data nodes passing through the draft data reading path

When the value under the target node is modified, all path nodes from the node to the root node will be traced back and marked as modified

When finalizing the draft and generating the final object, limu only needs to replace the copies of all marked modified nodes from the root node to the corresponding positions, and no copies will be used for nodes without marked modified (note: generating a copy does not mean that it has been completed) modified)

Such a mechanism performs exceptionally well in scenarios where the original hierarchical relationship of the object is complex and the modification path is not wide, and there is no need to freeze the original object, which can reach 5 times or more faster than immer. Only when the modified data gradually spreads When the entire object has all nodes, the performance of limu will show a linear download trend, gradually approaching immer, but it is also much faster than immer.

Test Validation

In order to verify the above conclusions, users can follow the procedure below to obtain performance test comparison data for limu and immer

git clone https://github.com/tnfe/limu
cd limu
npm i
cd benchmark
npm i
node opBigData.js // Trigger the test execution, the console echoes the result
# or
node caseReadWrite.js

We prepare two use cases, one adapted from immer's official performance test case (Note: see the header after the jump the link to)

Execute node opBigData.js to get the following results (the shorter the bar, the faster)

Note: The above is the v9 version. Immer released the v10 version in April 23. After testing, it was found that the results did not change much, and the performance improvement was not obvious

One is a deep-level json read and write case prepared by ourselves, and the results are as follows (the shorter the bar, the faster)

Different test strategies can be adjusted by injecting ST value, for example ST=1 node caseReadWrite.js, the default is 1 when not injected

ST=1, turn off freezing, do not operate arrays

ST=2, turn off freeze, operate array

ST=3, enable freezing, do not operate arrays

ST=4, enable freezing, operate array

Stronger

limu uses Symbol and the prototype chain to hide the proxy metadata, so that the metadata always follows the draft node and is erased after the draft is over, so that users can not only operate immutable data like operating native js, but also view native json to view the draft data (only need to expand a layer of proxy), and always allow the user to synchronize the modified data of the draft to the viewable node in real time, which greatly improves the debugging experience.

Here we will respectively enumerate the diagrams of limu, immer, mutative, and structura to expand the draft in the debugging state:

limu can view all nodes of the draft arbitrarily, and the data is always synchronized to the modified data
structura can view the original structure of the draft, but the draft data is expired (note: but the log data is correct)
mutative maintains a structure similar to immer and cannot be viewed quickly
immer uses Proxy layer by layer proxy, unable to quickly view

Lightweight

imu is designed as an immutable data js library for modern browsers. It only runs in js environments that support proxy features. The native support root objects are Map, Set, Array, Object, compared to immer 6.3kb The size capacity is nearly reduced by 1/3.

At the same time, more practical APIs are provided

immut

Generate an unmodifiable object im, but modifications to the original object will affect im synchronously

import { immut } from 'limu';

const base = { a: 1, b: 2, c: [1, 2, 3], d: { d1: 1, d2: 2 } };
const im = immut(base);

im.a = 100; // modification is invalid
base.a = 100; // modification will affect im

You can still read the latest value after merging

const base = { a: 1, b: 2, c: [1, 2, 3], d: { d1: 1, d2: 2 } };
const im = immut(base);
const draft = createDraft(base);
draft.d.d1 = 100;

console.log(im.d.d1); // 1, unchanged
const next = finishDraft(draft);
Object. assign(base, next);
console.log(im.d.d1); // 100, im and base always keep data in sync

immut adopts the shallow proxy mechanism when reading, which will have better performance than deepFreeze. It is suitable for scenarios where the original object is not exposed, but only the generated immutable object is exposed, and onOperate is used to collect read dependencies.

onOperate

Support for createDraft, produce, immt to configure onOperate callback to monitor all read and write changes (note: immut can only monitor read changes)

For example the following code:

const { createDraft, finishDraft } = limu;
const base = new Map([
   ['nick', { list: [1,2,3], info: { age: 1, grade: 4, money: 1000 } }],
   ['fancy', { list: [1,2,3,4,5], info: { age: 2, grade: 6, money: 100000000 } }],
   ['anonymous', { list: [1,2], info: { age: 0, grade: 0, money: 0 } }],
]);
const draft = createDraft(base, { onOperate: console. log });
draft. delete('anonymous');
draft.get('fancy').info.money = 200000000;
const final = finishDraft(draft);

The following monitoring results will be generated, which is very beneficial for the upper framework to collect read and write dependencies

The upcoming helux v3 has completed a lot of interesting functions based on the limu driver, please look forward to it.

Conclusion

After 2 years of hard work, it was an unexpected result for me to make a work that was initially a bit of a toy (incorporating concent and helux) into the ground. Combined with the recent Korean team of room temperature superconductors as an analogy, their LK-99 was burnt. For more than 20 years, no matter whether the result is satisfactory or not, at least one who loves science can persevere. Thinking of countless nights of npm run test and optimizing the code, why not indulge in it because of maintaining a true love heart What about refining code pills?

Regardless of whether limu will be submerged in the sea of stars in history, the release of the stable version is an explanation for myself. I hope that all coders will also maintain a steady stream of curiosity to refine the elixir in their hearts.

Friends Link

Welcome to follow my other projects 👇

Toolchain-independent sdk-based module federation hel-micro
Upcoming new state library helux v3 with deep and shallow dependency collection dual strategy and directed graph architecture

Helux 2 released to solve the side effect double call mechanism of react18

幻魂 — Tue, 30 May 2023 05:47:00 +0000

react 18 has added a heuristic concurrent rendering mechanism. The side effect function may be called multiple times due to component re-rendering. In order to help users clarify the correct way to use side effects, when StrictMode is enabled in the development mode, it will be deliberately called twice The side effect function is used to achieve the effect of checking user logic, but this also brings troubles to some users who upgrade. This article will discuss how helux can avoid this problem.

Introduction to helux

helux is a react state library that focuses on lightweight, high-performance, and zero-cost access. Your application only needs to replace useState is useShared, and then you can achieve the effect of upgrading the local state of react to a global shared state without modifying a single line of other codes. You can visit this online example to learn more.

import React from 'react';
+ import { createShared, useShared } from 'helux';
+ const { state: sharedObj } = createShared({a:100, b:2});

function HelloHelux(props: any) {
- const [state, setState] = React. useState({ a: 100, b: 2 });
+ const [state, setState] = useShared(sharedObj);

    // The current component only depends on a change to trigger re-rendering
    // helux will dynamically collect the latest dependencies of each round of rendering of the current component to ensure accurate updates
    return <div>{state.a}</div>;
}

The default shared object is non-responsive. It is expected that the user will change the state in a react way. For example, after the user sets enableReactive to true, a responsive object can be created

const { state, setState } = createShared({ a: 100, b: 2 }, true);
// or
const { state, setState } = createShared({ a: 100, b: 2 }, { enableReactive: true });

// will update all component instances using `sharedObj.a` values
sharedObj.a++;
setState({a: 1000});

What 2.0 brings

The 2.0 version has made the following three adjustments

Simplified api naming

The original useSharedObject api is re-exported as a more streamlined useShared, which cooperates with createShared to improve the user's writing efficiency and reading experience.

Add signal record (experimental)

Added signal-related record data internally to prepare the relevant infrastructure for helux-signal (a react signal mode implementation library based on helux packaging) to be released in the future. helux-signal is still in the prototype stage. The timing of the beta version experience will be released.

When not using signals, you need createShared and useShared to match the two together. createShared creates the shared state, and useShared is responsible for consuming the shared state. It returns specific readable state values and update functions.

 const { state: sharedObj } = createShared({a:100, b:2}); // create
 function HelloHelux(props: any) {
   const [state, setState] = useShared(sharedObj); // use
   // render logic...
 }

When using a signal, you only need to call helux-signal an interface createSignal to complete the creation of the state, and then the component can skip the useShared hook function and directly read the shared state.

It should be noted that at present, helux 2 has only completed the relevant infrastructure internally, and the helux-signal, which is responsible for the specific implementation of the upper layer, is still in the experimental stage. At this stage, the community has already provided signals-react library to support the development of react components in signal mode.

An envisioned and complete example of developing react components based on helux-signal is as follows:

 import { createSignal, comp } from 'helux-signal';

 const { state, setState } = createSignal({a:100, b:2}); // create signal
 // The following two methods will trigger component re-rendering
 state.a++;
 setState({a: 1000});

 // <HelloSignal ref={ref} id="some-id" />
 const HelloSignal = comp((props, ref)=>{ // Create a react component that can read the signal
 return <div>{state.a}</div>; // The dependency of the current component is state.a
 })

Add useEffect, useLayoutEffect

The v2 version adds useEffect and useLayoutEffect two interfaces, which are also the two interfaces that this article will focus on. Why does helux provide these two interfaces to replace the original interface? Let’s see the details below.

side effects of react18

React 18 has added a heuristic concurrent rendering mechanism. The side effect function may be called multiple times due to component re-rendering. In order to help users discover possible problems caused by improper use of side effects (for example, forgetting to do cleanup), enable it in development mode In StrictMode, the side-effect function will be deliberately called twice to achieve the effect of checking the user logic, hoping that the user can correctly understand the side-effect function.

In the actual situation, under what circumstances will multiple mount behaviors occur? The new document specifically mentions an example, because in 18, react will separate the state of the component from the unloading behavior (unloading not controlled by user code), that is, the state of the component is still maintained after unmounting, and it will be restored by react when it is mounted again, for example Off-Screen Rendering scenes require this feature.

The trouble with double calls

However, this move has also brought troubles to some upgrade users. Take the following example as an example:

function UI(props: any) {
   useEffect(() => {
     console.log("mount");
     return () => {
       console.log("clean up");
     };
   }, []);
}

In strcit mode print the following

mount
clean up
mount

After the user actually uninstalled the component, there was still a clean up print, which made many users mistakenly thought it was a bug, and went to the react warehouse to file an issue description. After upgrading to 18, useEffect produced two calls. Later, the react official explained that this problem is normal Phenomenon, a double-call mechanism deliberately made to assist users with unreasonable side-effect functions.

However, in some scenarios, users do expect only one call during development (such as data initialization of components), so there are various ways to fight against double calls as follows.

Remove StrcitMode

The simplest and rude way is to remove the StrcitMode package at the root component to completely shield this double-call behavior.

root. render(
- <React. StrictMode>
     <App />
- </React. StrictMode>
);

Users may only need unparalleled calls in some places, and double calls in other places to check the correctness of side effects, but this is a one-shot killing of all scene behaviors and is not very general.

Partial wrapping StrcitMode

In addition to wrapping the root component, StrcitMode also supports wrapping any subcomponent, and the user can wrap it where needed

  <React.StrictMode><YourComponent /></React.StrictMode>

Compared with global removal, this method is milder, but wrapping StrictMode is a compulsive behavior. It needs to be exported at the code to arrange where wrapping is needed and where wrapping is not required. It is more troublesome. Is it possible to wrap StrcitMode in the root component and also What about the way to partially shield the double call mechanism? Users start from the code level, to be precise, start from the useEffect callback

Use useRef to mark the execution status

The general idea is to use useRef to record whether a side-effect function has been executed, so that the second call is ignored.

 function Demo(props: any) {
   const isCalled = React. useRef(false);

   React. useEffect(() => {
     if (isCalled. current === false) {
       await somApi.fetchData();
       isCalled. current = true;
     }
   }, []);
 }

This has certain limitations, that is, if the dependency is added, isCalled cannot be controlled, and isCalled.current is set to false in the side effect cleaning function according to thinking, so that when the id value is changed during the lifetime of the component, mock api fetch is not printed twice despite double call behavior

  React. useEffect(() => {
     if (isCalled. current === false) {
 isCalled. current = true;
       console.log('mock api fetch');
 return ()=>{
 isCalled. current = false;
 console.log('clean up');
 };
     }
   }, [id]); // When the id changes, a new request is initiated

But as written above, two calls still occur when the component is mounted for the first time, and the printing order is

mock api fetch
clean up
mock api fetch

Is there a real perfect solution, so that when the StricMode is wrapped based on the root component, the side effects of the subcomponent’s initial mount and lifetime will only be called once? Next, let useEffect provided by helux solve this problem completely.

use helux's useEffect

We only need to understand the reason for the double call of react: let the component unload and separate the state, that is, the existing state of the lifetime of the component will be restored when the component is mounted again. Since there is a restoration process, the starting point is very easy Yes, the main thing is to observe the operation log at the moment when the component is restored to find the law.

First mark a sequence auto-increment id as the component example id, and observe which instance the mount behavior is for

 let insKey = 0;
 function getInsKey() {
   insKey++;
   return insKey;
 }

 function TestDoubleMount() {
   const [insKey] = useState(() => getInsKey());
   console.log(`TestDoubleMount ${insKey}`);
   React. useEffect(() => {
     console.log(`mount ${insKey}`);
     return () => console. log(`clean up ${insKey}`);
   }, [insKey]);
   return <div>TestDoubleMount</div>;
 }

You can observe the log as shown in the figure below. It can be found that the gray print TestDoubleMount is the second call initiated by react intentionally. The side effects are all for example No. 2, and No. 1 is discarded by react as a redundant call.

Since the id is self-increasing, react will deliberately initiate two calls to the same component, discard the first and repeat the side effects for the second call (mount-->clean-->mount ---> after the component is unloaded clean), then we only need to check whether there is a side effect record in the previous example when the second side effect is executed, and record the execution times of the second side effect at the same time, it is easy to shield the side effect of the second mode, that is (mount -->clean-->mount ---> clean after component uninstallation) is changed to (mount ---> clean after component uninstallation), and execute the set clean when the component is actually uninstalled.

The pseudo code is as follows

function mayExecuteCb(insKey: number, cb: EffectCb) {
   markKeyMount(insKey); // Record the number of times the current instance id is mounted
   const curKeyMount = getKeyMount(insKey); // Get the current instance mount information
   const pervKeyMount = getKeyMount(insKey - 1); // Get the mount information of the previous instance
   if (!pervKeyMount) { // The previous example has no mount information, which is a double call behavior
     if (curKeyMount && curKeyMount.count > 1) { // The user's side effect function is being executed only when the current instance is mounted for the second time
       const cleanUp = cb();
       return () => {
         clearKeyMount(insKey); // Clear the mount information of the current instance
         cleanUp && cleanUp(); // return cleanup function
       };
     }
   }
}

On this basis, encapsulating a useEffect to the user can achieve the purpose we mentioned above: when wrapping StricMode based on the root component, the sub-component's initial mount and lifetime side effects only occur once.

 function useEffect(cb: EffectCb, deps?: any[]) {
   const [insKey] = useState(() => getInsKey()); // Write as a function to avoid key auto-increment overhead
   React. useEffect(() => {
     return mayExecuteCb(insKey, cb);
   }, deps);
 }

If you are interested in the specific implementation of useEffect, you can check the warehousecode

Now you can use the useEffect exported by helux just like using the native useEffect, and enjoy the benefit of not requiring double-call detection in some scenarios.

import { useEffect } from 'helux';

useEffect(() => {
   console.log('mock api fetch', id);
   return () => {
     console.log('mock clean up');
   };
}, [id]); // When the id changes, a new request is initiated

Conclusion

Understanding the design intention and process of double call will help us understand more clearly how side-effect functions are managed, and it can also help us make better decisions to avoid the double call mechanism.

helux belongs to the module federation sdk hel-micro subpackage, original intention It is to provide a more flexible and low-cost state sharing method for react. If you are interested in helux or hel-micro, please pay attention and give us more feedback for improvement.

Introducing Helux, A React state library that encourages service injection and supports reactive updates

幻魂 — Mon, 17 Apr 2023 09:15:56 +0000

about Helux

Helux is a brand new data flow solution that encourages service injection and supports responsive change React. Its predecessor was concent (a high-performance state management framework similar to Vue development experience), but Concent itself needs to be compatible with class and function syntax to maintain consistency, and in order to set up its function, the internal code volume is too large, with over 70 kb compressed and the API exposed, resulting in a sharp increase in learning difficulty, In order to better conform to the coding trend of the current popular DDD to build a domain model around business concepts, helux was initially designed as a lightweight react data flow solution that encourages service injection, supports responsive changes, and supports dependency collection.

It has the following advantages:

Lightweight, 2kb compressed
Simple, only 7 APIs are exposed, and only 4 interfaces createShared, useObject, useSharedObject, useService are used frequently
High performance, built-in dependency collection
Responsive, supports the creation of responsive objects, changing objects outside the view will update the view synchronously
Service injection, with the useService interface to easily control complex business logic, always return a stable reference, can completely avoid the useCallback dependent annoyance
The state has been changed to 0, so you only need to replace useObject with useSharedObject to share the state to other components
Avoid forwordRef hell, the built-in exposeService mode will easily solve the problem of obscurity and contagion of ref forwarding when the parent drops the child (generational components need to be forwarded layer by layer)
ts-friendly, 100% written in ts, providing you with all-round type hints

All the following APIs correspond to online Example 1 and Example 2, welcome to fork and modify the experience.

Why is it named helux, although I developed it as the concent v3 version in my heart, but because it has changed too much, it does not inherit any concent features except for dependent collection, and it is also developed with me hel-micro has produced a work, I expect it to be a luxury-level contribution to the hel-micro ecology, so I put together the words hel-micro and luxury Became helux.

Welcome to pay attention to helux, although it is relatively new, it has played an indispensable role in my own usage scenarios, It has joined the hel-micro ecological warehouse, and looks forward to becoming a satisfactory data flow solution that you are willing to choose.

Quick start

The ultimate simplicity is the biggest advantage of helux. After understanding the following 6 APIs, you can easily handle any complex scene. The biggest charm lies in the two interfaces of useSharedObject and useService, and see the following API introduction

useObject

There are two benefits to using useObject

1 When defining multiple state values, it is convenient to write a lot less useState
2 An unmount judgment is made internally, so that asynchronous functions can also safely call setState to avoid warnings in react: "Called SetState() on an Unmounted Component" Errors

// Initialize a view state based on the object
const [state, setState] = useObject({a:1});
// Initialize a view state based on the function
const [state, setState] = useObject(()=>({a:1}));

useForceUpdate

Forcibly update the current component view, which can be used to refresh the view in some special scenarios

const forUpdate = useForceUpdate();

createSharedObject

Create a shared object that can be transparently passed to useSharedObject, see useSharedObject for specific usage

// Initialize a shared object
const sharedObj = createSharedObject({a:1, b:2});
// Initialize a shared object based on the function
const sharedObj = createSharedObject(()=>({a:1, b:2}));

createReactiveSharedObject

Create a responsive shared object that can be transparently passed to useSharedObject

// Initialize a shared object
const [reactiveObj, setState] = createReactiveSharedObject({a:1, b:2});

sharedObj.a = 111; // Modify the a property anywhere to trigger view rendering
setSharedObj({a: 111}); // Use this method to modify the a property, which can also trigger view rendering. Deep data modification can use this method

createShared

function signature

function createShared<T extends Dict = Dict>(
   rawState: T | (() => T),
   enableReactive?: boolean,
): {
   state: SharedObject<T>;
   call: <A extends any[] = any[]>(
     srvFn: (ctx: { args: A; state: T; setState: (partialState: Partial<T>) => void }) => Promise<Partial<T>> | Partial<T> | void,
     ...args: A
   ) => void;
   setState: (partialState: Partial<T>) => void;
};

Create a responsive shared object that can be transparently passed to useSharedObject. It is a combination of createReactiveSharedObject and createSharedObject. When you need to call a service function that is out of the function context (that is, when you do not need to perceive component props), you can use this Interface, the second parameter is whether to create a reactive state, when it is true, the effect is the same as the sharedObj returned by createReactiveSharedObject

  const ret = createShared({ a: 100, b: 2 });
  const ret2 = createShared({ a: 100, b: 2 }, true); // create reactive state
  // ret.state can be transparently passed to useSharedObject
  // ret.setState can directly modify the state
  // ret.call can call the service function and transparently transmit the context

The following will give examples of two specific ways to define service functions, and then users can call these service functions in other places to modify the shared state. If you need to perceive the component context (such as props), you need to use the useService described belowInterface to define service functions.

// The first way to call the service function is to directly call the defined function and modify the state with ret.setState
function changeAv2(a: number, b: number) {
    ret. setState({ a, b });
}
*
// In the second way, use ret.call(srvFn, ...args) to call the service function defined in the first parameter of the call function
function changeA(a: number, b: number) {
    ret.call(async function (ctx) { // ctx is the transparent call context,
      // args: the transparent parameter list when using call to call the function, state: state, setState: update state handle
      // Here you can all perceive the specific type
      // const { args, state, setState } = ctx;
      return { a, b };
    }, a, b);
  }

useSharedObject

function signature

function useSharedObject<T extends Dict = Dict>(sharedObject: T, enableReactive?: boolean): [
   SharedObject<T>,
   (partialState: Partial<T>) => void,
]

Receive a shared object, which will be shared in multiple views. There is a dependency collection mechanism inside, and data changes that do not depend on it will not affect the current component update

const [ obj, setObj ] = useSharedObject(sharedObj);

useSharedObject returns a non-responsive state by default. If you need to use a reactive state, just pass through the second parameter to true

const [ obj, setObj ] = useSharedObject(sharedObj);
// now obj is reactive
  setInterval(()=>{
   state.a = Date.now(); // trigger view update
  }, 2000);

useService

function signature

/**
  * Develop react components using the service model:
  * @param compCtx
  * @param serviceImpl
  */
function useService<P extends Dict = Dict, S extends Dict = Dict, T extends Dict = Dict>(
   compCtx: {
     props: P;
     state: S;
     setState: (partialState: Partial<S>) => void;
   },
   serviceImpl: T,
): T & {
   ctx: {
     setState: (partialState: Partial<S>) => void;
     getState: () => S;
     getProps: () => P;
   };
}

It can be used together with useObject and useSharedObject. It will create a service object and return it. The service object is a stable reference, and all the methods it contains are also stable references. It can be safely passed to other components and will not Break the pros comparison rules of components to avoid the annoying useMemo and useCallback missing related dependencies

When paired with useObject

function DemoUseService(props: any) {
   const [state, setState] = useObject({ a: 100, b: 2 );
   // srv itself and the methods it contains are a stable reference,
   // It is safe to hand over the srv.change method to other components without breaking the pros comparison rules of the components
   const srv = useService({ props, state, setState }, {
     change(a: number) {
       srv.ctx.setState({ a });
     },
   });

   return <div>
     DemoUseService:
     <button onClick={() => srv.change(Date.now())}>change a</button>
   </div>;
}

When using useSharedObject, you only need to replace useObject, and other codes do not need to be changed

+ const sharedObj = createSharedObject({a:100, b:2})

function DemoUseService(props: any) {
- const [state, setState] = useObject({ a: 100, b: 2 );
+ const [state, setState] = useSharedObject(sharedObj);

getState and getProps

Because state and props are unstable, so the service internal function needs to be retrieved from srv.ctx.getState or srv.ctx.getProps

// abstract service function
export function useChildService(compCtx: {
   props: IProps;
   state: S;
   setState: (partialState: Partial<S>) => void;
}) {
   const srv = useService<IProps, S>(compCtx, {
     change(label: string) {
       // !!! do not use compCtx.state or compCtx.state due to closure trap
       // console.log("expired state:", compCtx.state.label);

       // get latest state
       const state = srv.ctx.getState();
       console.log("the latest label in state:", state.label);
       // get latest props
       const props = srv.ctx.getProps();
       console.log("the latest props when calling change", props);

       // your logic
       compCtx. setState({ label });
     }
   });
   return srv;
}

export function ChildComp(props: IProps) {
   const [state, setState] = useObject(initFn);
   const srv = useChildService({ props, state, setState });
}

  return (
     <div>
       i am child <br />
       <button onClick={() => srv.change(`self:${Date.now()}`)}>
         change by myself
       </button>
       <h1>{state.label}</h1>;
     </div>
   );

exposeService

When the exposeService function is transparently passed on the child component props, useService will automatically transparently pass the service object to the parent component, which is a more convenient mode to escape from forwardRef to complete the parent tune

import { ChildSrv, Child } from "./Child";

function App() {
   // save the child's service
   const childSrv = React. useRef<{ srv?: ChildSrv }>({});
   const seeState = () => {
     console.log("seeState", childSrv.current.srv?.ctx.getState());
   };

   return (
     <div>
       <button onClick={() => childSrv.current.srv?.change(`${Date.now()}`)}>
         call child logic
       </button>
       <Child
         unstableProp={`${Date.now()}`}
         exposeService={(srv) => (childSrv. current. srv = srv)}
       />
     </div>
   );
}

Conclusion

helux is a brand new work after extracting and reprocessing all the inner essence of concent, I hope you will like it. ❤️

Why is hel-micro a better implementation of module federation

幻魂 — Fri, 14 Oct 2022 06:24:53 +0000

hel-micro, module federation sdk, build-free, hot update, toolchain-independent micro-module solution, welcome to pay attention and understand

Example Name/Function	Use Demonstration	Template Address	Template Description	Hosting Location
Remote ts library	codesandbox	hel-lodash	webpack development and packaging	unpkg meta
Remote react js components	codesandbox	remote-react-comp	webpack development and packaging	unpkg meta
Remote react ts components	codesandbox	remote-react-comp-ts	webpack development and packaging	unpkg meta
Remote vue2 js component	codesandbox	remote-vue-comp	webpack development and packaging	unpkg meta, github.io index.html , unpkg index.html
Remote vue3 ts components	codesandbox	remote-vue3-comps-ts	vite or webpack development, webpack packaging	unpkg meta

The origin of the module federation

Since the sudden emergence of Google's chrome browser and the official announcement of the release of the v8 js engine on September 2, 2008, it has swept the Internet world with extremely high operating efficiency, and has also captured a large number of users. The momentum of blocking made other major technology companies (apple, moliza, microsoft) feel a huge murderousness, and then everyone began to recruit troops and sharpen their knives to fight a bloody path. Since then, the js engine has entered the period of the arms race, among which Microsoft even He did not hesitate to abandon IE and began to push the edge browser with Microsoft's new js engine Chakra behind it. It is conceivable how much everyone attaches great importance to the cake of js engine, and The birth of v8 catalyzed a large number of well-known open source works, so that the js ecosystem has always maintained a very strong vitality, the most famous of which isnodejsborn in 2009, a server-side js runtime based onv8`, allowing The language js began to bloom from the front to the back, so that the following ridicule that was born very early is still circulating:

Any application that can be written in JavaScript, will eventually be written in JavaScript.

Modular Specifications

nodejs brings the modularization of commonjs to the server side, which makes the organization of large-scale js projects more orderly. At the same time, it also brings the super killer of npm, which improves the efficiency of module distribution and sharing to an unprecedented height.

The front-end application has also doubled with the complexity of network applications, which has led to a period of rapid expansion of code volume. At this time, an effective modular solution is urgently needed to solve how to split modules gracefully, and how to improve code reuse and scalability. maintenance and other issues.

At this time, the two mainstream modular solutions amd and cmd began to compete in the front end and finally established a large position. Their representative implementations are requirejs and seajs respectively. Little friends know or use it.

Engineering system

Although requirejs and seajs bring the implementation of modular specifications to the front end and inject a solid foundation for large-scale js projects, the modular specification alone still cannot solve the problem of how to communicate with npm ecology, and how to manage increasingly Complex module dependencies, if compatible with a series of problems such as new js features, in the final analysis, this involves a keyword engineering system, and then webpack and babel were born, and their goals are very clear , which solves the 4 major problems in the following figure

Then it became the de facto infrastructure standard for the front-end to start engineering system development.

webpack relies on excellent plug-in and loader mechanism, so that its ecology can continue to grow bigger and stronger, and eliminate other opponents such as gulp, grunt that are more tool-oriented in the process

The curse of npm

webpack and npm almost form a perfect partner state, but the resources originally obtained from cdn in the front end are merged into one package body by the packaging tool, which brings fatal update and deployment efficiency problems.

In some scenarios that need to be dynamically updated, this all in one packaging mechanism greatly reduces the deployment efficiency of the package body. This is not a problem of webpack and npm, but people's natural needs for the web environment Typical scenario requirements brought about by rapid iteration and high requirements for express delivery experiments.

Note: externals itself cannot completely solve the demands of dynamic update, it is only suitable for externally linking the underlying PR dependency package to cdn

bundless is coming

At the same time, as the project volume of webpack becomes larger and larger, new problems such as poor development experience (slow hot update), increased package size, and slow build speed (node_modules black hole) are also born. At this time, the development of the new generation The tools snow and vite are starting to eat away at the webpack market in the name of not packing.

They all use the browser's native modularization capability esm, skip the dependency analysis and packaging process required by webpack, and achieve millisecond-level debugging and startup under this design.

However, the extremely fast experience they bring cannot shake the deep siege of the entire webpack ecology. In fact, everyone is in the dual-engine drive mode of debugging based on vite and using webpack for production and packaging. After all, esm is popular It will take time.

The module federation sounded the horn of counterattack

Since everyone complains that wepack is slow to build, is there a way to skip the build step and allow users to combine multi-level dependency modules in their own way?

Of course there are, that is to take the pre-built path

Therefore, module federation was born. Its greatness lies in maintaining the current high-efficiency system of modularization, componentization and engineering of front-end development, allowing independent development and deployment of modules, and direct sharing through CDN, thus breaking free from npm packages. The shackles that cannot be updated dynamically, thus promoting the development and operation experience of the entire front-end world to a new level.

As long as there are more modules that can be promoted to the federation, the local startup speed will be faster!

Moreover, federated modules are born with dual identities, that is, they can be module consumers or module providers, which makes a natural grid relationship between module federation applications, and module distribution efficiency, deployment efficiency, and sharing efficiency are unprecedented. Boost!

The Achilles Heel of the Modular Federation

Is the implementation of module federation really perfect with webpack 5 or other tools? It does solve the problems of free build, dynamic update, cross-project sharing module

However, based on the existing compile-time plug-in mechanism, it is impossible to avoid the problems of strong binding of tool chain and remote module consumption relationship can only be determined at compile time

Just imagine, you need to use the technology of module federation, how many preconditions you need to do, and you need to upgrade a real toolchain! And the federation modules before different toolchains are mutually exclusive! The liquidity of modules is tied to the toolchain of your choice.

Module Federation New Revolution

The only solution to these two major problems is to sdk them, which is hel-micro's new thinking on the realization of module federation, and it is also the secret weapon to initiate a new revolution of module federation.

After sdkization, any technology stack and any tool chain can access the module federation technology losslessly and painlessly.

Module consumption relationship at runtime

The return from the tool chain to the js language itself means that the module consumption relationship is upgraded from compile time to runtime, which will greatly improve the flexibility of dynamic loading of remote modules and enable more complex services.

dimensionality reduction strike

Compared with the module federation implemented by relying on tool plug-ins, the implementation of hel-micro from the language level will cause a dimensionality reduction blow to other module federation implementations.

Compared with the traditional npm sharing method, hel-micro also has more efficient code sharing capabilities (runtime sharing)

Decrypt the sdkized core implementation

To achieve sdkization means that we must tap the hidden capabilities of the js language itself, and jump out of the traditional packaging process thinking, in order to achieve our ultimate goal.

Asynchronous import hidden capabilities

Usually we use the import keyword to statically import other modules in the header file, but in fact, import can be used as a function call to import a module asynchronously and return a promise object

ts const mod = await import('./some-mod');`

So we can fine-tune the loading order of modules to achieve the effect of injecting new code into a module before it is statically imported by other modules

The early injection effect brought by this asynchronous import has become a key implementation point for hel-micro to inject remote runtime code into the module proxy object, so that hel-micro can provide users with lazy loading and preloading two loading methods .

There are two core interfaces in the above figure: libReady interface is responsible for exposing modules, preFetchLib interface is responsible for pulling modules, and each module acts as a provider or consumer by calling the interface behavior.

Runtime Dependency Analysis

hel-micro makes remote modules with multiple levels of dependencies efficient, safe and orderly through the internally maintained event bus, module pool, style pool, metadata pool four data structures load.

The module pool can ensure that the module is not loaded repeatedly and reused by the upper-layer callers.

Metadata - the soul of modules

The essence of a module is a collection of build product files. hel-micro provides build-time plug-ins, collects the network path of the product and stores it according to the protocol specified by the sdk, so that the sdk can download and execute all the files on the network later. remote module.

Dual build mechanism

hel-micro uses rollup to package local statically importable proxy files, and uses webpack to package the actual running code of remote injection, so that the proxy module objects in node_modules can be statically imported locally and get complete type hints. Let users get the ultimate development experience of using remote modules as if they were using local modules

There are 4 default directories hel_dist, hel_proxy, hel_proxy_es, hel_bundle to carry different products for package.json to configure different entries.

Among them, the files in the hel_proxy, hel_proxy_es directories are the entry files of the module proxy object we mentioned. We can see that the file is almost an empty shell, so its impact on the package size of the module user can almost be omitted. Excluding.

Platform and Ecology

Hel-mirco sdk mainly relies on the standardized metadata format for remote module loading, so as long as any user provides the metadata of the module according to the standardized format, it can be loaded by hel-micro, which will be very beneficial to the development of hel-micro The construction and development of the upper ecology.

Supports arbitrary deployment of modules

The sdk is decoupled from the platform. By default, we provide support with hel pack and npm unpkg, but it allows you to publish modules to any file service on the network, as long as you know the deployment address.

If the user saves the hel-meta.json metadata to the background database (which can be combined with the devops pipeline), a centralized module management and control platform similar to hel pack can be quickly built

The centralized module management and control platform will be particularly convenient for modules to implement version preview, grayscale volume, second-level rollback, etc., but it does not prevent the sdk from de-neutralizing. Loading multi-platform packages, because sdk inherently supports pulling and using remote modules from multiple different platforms at the same time, such as loading modules from two platforms, unpkg and hel pack at the same time, the platform value will be used as a namespace to isolate different platforms. named module.

Upper-level ecological construction

hel-micro itself only provides the ability to load remote modules. The specific ui adaptation layer also needs to be implemented in the upper encapsulation library area. The current plan is as follows

Taking hel-micro-react as an example, it provides lazy loading of remote components in the form of react hook function, and provides shadow dom style isolation function at the same time

When to adopt hel-micro

At the moment when you encounter any of the following situations, using hel-micro is definitely worth your effort to try.

roadmap 2022~2023

Conclusion

The module federation can play an even more powerful role in the construction of super-large js projects, and the module deployment efficiency and sharing efficiency of giant applications will be easily solved. At the same time, it is matched with micro-container related frameworks (such as wujie, rame), etc., to ensure your isolation operation requirements. Escort, welcome to star hel-micro, understand and use it.

My other open source works friend chain (welcome to follow and understand):

concent, a react data flow solution with built-in dependency collection and setup features

limu, a more efficient js immutable operation library than immer

Limu, a fast js lib for immutable data

幻魂 — Sat, 23 Jul 2022 14:13:00 +0000

limu 🍋

limu is short of love immutable, born for efficient creation and operation of immutable object.

It is fast, It is nearly more than 2 or 20 times faster than immer in different situations.
Click this online perf demo to review the amazing result.

See more perf test result

1. git clone git@github.com:tnfe/limu.git 
2. cd benchmark 
3. npm i 
4. node ./limu-vs-immer.js

Why is Limu born? Because I plan to release concent V3 next year, I need a more fast immutable data JS operation tool, so Limu was born

Performance ⚡️

It is nearly more than 2 or 20 times faster than immer in different situations.

Simple Demo

Execute cd benchmark and node ./readme-demo.js bash command.

Run Code below:

const immer = require('immer');
const limu = require('limu');

immer.setAutoFreeze(false);
limu.setAutoFreeze(false);

function getBase() {
  const base = {
    a: { b: { c: { d: { e: { f: { g: { h: { i: { j: { k: { l: { m: { n: 1 } } } } } } } } } } } } },
    a1: { b: { c: { d: { e: { f: { g: { h: { i: { j: { k: { l: { m: { n: 1 } } } } } } } } } } } } },
    a2: { b: { c: { d: { e: { f: { g: { h: { i: { j: { k: { l: { m: { n: 1 } } } } } } } } } } } } },
    a3: { b: { c: { d: { e: { f: { g: { h: { i: { j: { k: { l: { m: { n: 1 } } } } } } } } } } } } },
    a4: { b: { c: { d: { e: { f: { g: { h: { i: { j: { k: { l: { m: { n: 1 } } } } } } } } } } } } },
    a5: { b: { c: { d: { e: { f: { g: { h: { i: { j: { k: { l: { m: { n: 1 } } } } } } } } } } } } },
    a6: { b: { c: { d: { e: { f: { g: { h: { i: { j: { k: { l: { m: { n: 1 } } } } } } } } } } } } },
    a7: { b: { c: { d: { e: { f: { g: { h: { i: { j: { k: { l: { m: { n: 1 } } } } } } } } } } } } },
    a8: { b: { c: { d: { e: { f: { g: { h: { i: { j: { k: { l: { m: { n: 1 } } } } } } } } } } } } },
    a9: { b: { c: { d: { e: { f: { g: { h: { i: { j: { k: { l: { m: { n: 1 } } } } } } } } } } } } },
    a10: { b: { c: { d: { e: { f: { g: { h: { i: { j: { k: { l: { m: { n: 1 } } } } } } } } } } } } },
    a11: { b: { c: { d: { e: { f: { g: { h: { i: { j: { k: { l: { m: { n: 1 } } } } } } } } } } } } },
    a12: { b: { c: { d: { e: { f: { g: { h: { i: { j: { k: { l: { m: { n: 1 } } } } } } } } } } } } },
    arr: [1, 2, 3],
    b: null,
  };
  return base;
};

function die(label) {
  throw new Error(label);
};

function oneBenchmark(lib, base) {
  const start = Date.now();
  const draft = lib.createDraft(base);
  draft.a.b.c.d.e.f.g = 999;
  draft.arr[1] = 100;
  const final = lib.finishDraft(draft);
  if (final === base) {
    die('should not be equal');
  }
  if (final.arr[1] !== 100) {
    die('final.arr[1] !== 100');
  }
  if (base.arr[1] !== 2) {
    die('base.arr[1] !== 1');
  }

  const draft2 = lib.createDraft(base);
  delete draft2.b;
  const final2 = lib.finishDraft(draft2);
  if (final2 === base) {
    die('should not be equal');
  }
  if (base.b !== null) {
    die('base.b should be null');
  }

  const taskSpend = Date.now() - start;
  return taskSpend;
}


function measureBenchmark(label, loopLimit) {
  const immutLibs = { limu, immer };
  const lib = immutLibs[label];

  console.log(` ------------- ${label} benchmark ------------- `);
  const base = getBase();
  let totalSpend = 0;
  for (let i = 0; i < loopLimit; i++) {
    totalSpend += oneBenchmark(lib, base);
  }
  console.log(`${label} avg spend ${totalSpend / loopLimit} ms \n`);
}

measureBenchmark('limu', 10000);
measureBenchmark('immer', 10000);

at MacBook 2021 m1 max, the perf result is:

 ------------- limu benchmark ------------- 
limu avg spend 0.0066 ms 

 ------------- immer benchmark ------------- 
immer avg spend 0.0446 ms

as you see limu is almost seven times faster than immer at the case mentioned above.

Complex Demo

Follow the steps below to heck more complex perf test

1. cd benchmark
2. npm i
3. node ./limu-vs-immer.js

You can change the params hasArr、lessDeepOp to test perf of different situations

// // ************************************************************************
const curStrategy = process.env.ST || strategyConsts.BASE_F_AUTO_F;
// change params 'hasArr'、'lessDeepOp' to test limu and immer performance in different situations
// then run npm cmd: `npm run s1`、`npm run s2`、`npm run s3`、`npm run s4` to see perf result
const hasArr = false; // operate arr or not
const lessDeepOp = true; // has more deep operation or not
// ************************************************************************

The perf result at macbook 2021 max pro is:

-----------------------[ hasArr true, lessOp true ]-------------------
(reuseBase: true,  autoFreeze: true)  immer 2.797 ms : limu 1.287 ms
(reuseBase: false, autoFreeze: true)  immer 2.835 ms : limu 1.313 ms
(reuseBase: true,  autoFreeze: false) immer 2.049 ms : limu 0.089 ms
(reuseBase: false, autoFreeze: false) immer 2.096 ms : limu 0.146 ms

-----------------------[ hasArr true, lessOp false ]------------------
(reuseBase: true,  autoFreeze: true)  immer 2.946 ms : limu 1.268 ms
(reuseBase: false, autoFreeze: true)  immer 3.005 ms : limu 1.345 ms
(reuseBase: true,  autoFreeze: false) immer 2.162 ms : limu 0.147 ms
(reuseBase: false, autoFreeze: false) immer 2.169 ms : limu 0.161 ms

-----------------------[ hasArr false, lessOp true ]--------------------------
(reuseBase: true,  autoFreeze: true)  immer 2.253 ms : limu 0.659 ms
(reuseBase: false, autoFreeze: true)  immer 2.261 ms : limu 0.705 ms
(reuseBase: true,  autoFreeze: false) immer 1.386 ms : limu 0.015 ms
(reuseBase: false, autoFreeze: false) immer 1.469 ms : limu 0.017 ms

-----------------------[ hasArr false, lessOp false ]--------------------------
(reuseBase: true,  autoFreeze: true)  immer 2.266 ms : limu 0.604 ms
(reuseBase: false, autoFreeze: true)  immer 2.201 ms : limu 0.643 ms
(reuseBase: true,  autoFreeze: false) immer 1.565 ms : limu 0.055 ms
(reuseBase: false, autoFreeze: false) immer 1.479 ms : limu 0.061 ms

Submit your test

You are very welcome to submit your test to the benchmark directory of limu git repo

Hello, concent-pro

幻魂 — Sat, 27 Mar 2021 14:06:01 +0000

Center Pro is a project that helps users integrate the ecology of center and react, and has built-in best practice guidance, so as to provide users with out of the box experience, including but not limited to the following functions:

Demonstration of common center API
Model directory organization demonstration
TS integration demonstration
Test case writing demonstration
UseSetup case

Help ssr, use concent to add some material to the nextjs application

幻魂 — Mon, 21 Dec 2020 10:32:18 +0000

Open source is not easy, thank you for your support, ❤ star concent^_^

Preface

nextjs is a very popular React server-side rendering application framework. It is very lightweight, easy to use, and has an active community. So when we use react to write an application that requires ssr (server side render), it is basically The city’s first choice is nextjs. concent is a new generation of react state management solution. It has a built-in dependency collection system. It also has the characteristics of 0 intrusion, predictability, gradual and high performance, and provides lifecyle, composition api and other flexible APIs are super simple to write, allowing you to easily control ultra-large-scale react applications.

Hello next

Here we will use the create-next-app command to install a basic next sample application

npx create-next-app hello-next

After execution, you can see a directory structure as follows

|____public
|____pages
| |____ _app.js // The default root component of the next application
| |____index.js // Default homepage
| |____api // api routing file
| | |____hello.js

After we execute npm run dev in the project root directory, we will see a default homepage of ssr driven by next

Hello concent

Here we will use the create-react-app command to install a basic concent sample application

npx create-react-app hello-concent --template concent-ts

After execution, you can see a directory structure as follows

|____index.tsx
|____App.tsx
|____types // store type definition
|____features // List of functional components
| |____counter // counter function
| | |____Counter.tsx // counter component
| | |____model // counter model (including state, reducer, computed)
|____models // Other global model definitions
|____configs

Enter the project directory and execute npm i, and then execute npm start to see a default counter page

You can also click here to understand and edit it online.

Of course, integrating concent in an existing project is also super simple, because it does not need to provide a Provider at the top level, just configure the model in advance.

import {run} from'concent';

run({ // Define a counter model
  counter: {
    state: {num: 1, bigNum: 10 },
    reducer: {
      add(payload, moduleState) {
        return {num: moduleState + 1 };
      },
      async asyncAddBig() {
        await new Promise(resolve => setTimeout(resolve, 1000));
        return {bigNum: moduleState + 10 };
      }
    },
    computed: {
      doubleNum: ({ num }) => num * 2, // This function is triggered only when num changes
    }
  }
})

After that, you can plug and play globally. Both class components and function components can use the same way to read data or call methods, click on the key point, *if the ui is a conditional statement to control whether to consume state or derived data If it is, it is recommended to write delayed deconstruction, so that the minimum granularity of the view to the data collected after each round of rendering *

// ###### Function component
function Demo(){
  // If state and moduleComputed are read on demand, it is recommended to write delayed deconstruction
  const {state: {num, numBig }, moduleComputed: {doubleNum }, mr} = useConcent('counter');
  // ... ui logic, binding data, binding method
}

// ###### Class component
const DemoCls = register('counter')(
  class DemoCls extends React.Component{
   render(){
      const {state: {num, numBig }, moduleComputed: {doubleNum }, mr} = this.ctx;
      // ... ui logic, binding data, binding method
    }
  }
)

Introduce concent in next

There is a _app.js file in the next basic example directory, which is the root component of the next application

import'../styles/globals.css'

function MyApp({ Component, pageProps }) {
  return <Component {...pageProps} />
}

export default MyApp

Because the model must be configured in advance before using concent, we only need to create a runConcent.js file in advance

import {run} from'concent'
import * as models from'./models';

run(models);

Then import it in the _app.js file, so that all sub-components under the root component can correctly obtain the store's data and mobilize the store's method.

import'../styles/globals.css'
+ import'./runConcent'

function MyApp({ Component, pageProps }) {
  return <Component {...pageProps} />
}

export default MyApp

Then we create a counter.js file in the next pages directory, representing that this is a page component, so that the browser can use the /counter route to access the rendering view of this component.

import React from'react'
import {useConcent} from'concent'
import router from'next/router'

// use next/router to do browser side router jump
function toHomePage(){
  router.push('/');
}

export default function Counter() {
  const {state, mr, moduleComputed} = useConcent('home')

  return (
    <div>
      this is counter page
      <h1>num: {state.num}</h1>
      <h1>doubleNum: {moduleComputed.doubleNum}</h1>
      <button onClick={mr.add}>add</button>
      <button onClick={toHomePage}>to home page</button>
    </div>
  );
}

That's it, a next application with concent is created. Isn't it particularly simple? ^_^

Support pre-rendering

next provides two levels of pre-rendering interfaces, namely getServerSideProps and getStaticProps. The difference between the two is the execution timing. getServerSideProps is executed every time a page is requested, while getStaticProps is executed during construction. Let's deal with the situation of getServerSideProps first, and see how to combine concent for pre-rendering support.

First of all, we do not consider the existence of concent. To do pre-rendering support in next, we only need to expose a getServerSideProps interface in your page component.

// This function is called every time a page change is requested
export async function getServerSideProps() {
  // Call external API to get the list of blog posts
  const res = await fetch('https://.../posts')
  const posts = await res.json()

  // By returning {props: posts} object, the PostPage component will receive the `posts` parameter when rendering
  return {
    props: {posts },
  }
}

function PostPage({ posts }) {// The posts parameter is received here
  // Render posts...
}

export default PostPage

The reason why Blog can receive posts, in addition to exposing the interface of getServerSideProps, let us observe the content of the root component file of _app.js, and we can find the key points!

function MyApp({ Component, pageProps }) {
  return <Component {...pageProps} />
}
export default MyApp

The pageProps in the parameter list is the object pointed to by the props in the return result of getServerSideProps, and then next transmits it to the target page component, so we can deconstruct it in the PostPage parameter list. posts.

So our entry point can start from here, we put the return result of getStaticProps into a format constraint, like a structure like {module:string, state: object}, and then record it in the _app.js file Go to the store

// This function is called on every request
export async function getServerSideProps() {
  // Call external API to get the list of blog posts
  await delay();
  const posts = [
    {id: 1, name:'post1 -----' },
    {id: 2, name:'post2 --- welcome to use concent' },
  ];
  // This returned object will be transparently transmitted to the pageProps of the root component, where the module and the state entity object to which the state belongs are returned
  // record the status to the store there
  return {
    props: {
      module:'test',
      state: {posts },
    }
  };
}

The root component file at this time is changed as follows

import'../styles/globals.css';
+ import'./runConcent';
+ import {setState} from'concent';

function MyApp({ Component, pageProps }) {
  // Record the return status of getServerSideProps to the corresponding module of store here
+ if (pageProps.module) {
+ setState(pageProps.module, pageProps.state);
+}
  return <Component {...pageProps} />
}
export default MyApp;

Then we implemented the page component post-page code as follows

const PostList = React.memo(function () {
  const {state} = useConcent('test');
  return (
    <div>
      {state.posts.map(item => <h3 key={item.id}>{item.name}</h3>)}
    </div>
  );
});

const PostLength = React.memo(function () {
  const {state} = useConcent('test');
  return <h1>{state.posts.length}</h1>;
});

export default function PostPage() {
  return (
    <div>
      <h1>this is post page</h1>
      <PostList />
      <PostLength />
      <button onClick={toHomePage}>to home page</button>
    </div>
  );
}

Then we open the browser to visit the /post-page page, click to view the source code and you will see that this is a server-side pre-rendered page

For the same reason, we can also replace getServerSideProps with getStaticProps, the whole process above will still work normally, you are welcome to see the clone sample code to experience it yourself.

git clone https://github.com/concentjs/ssr-demo-1

Appendix

doc

-next-js doc
-concent doc

CloudBase CMS

Welcome brothers to pick up CloudBase CMS to create a one-stop cloud content management system, which is developed by the cloud and based on Node.js Headless The content management platform provides a wealth of content management functions, is simple to install, easy for secondary development, and is closely integrated with the cloud development ecosystem to help developers improve development efficiency.

concent has provided strong support for its management background, and the new version of the management interface is more beautiful and considerate.

FFCreator

You are also welcome to pick up FFCreator, it is a lightweight and flexible short video processing library based on node.js. You only need to add a few pictures or video clips and a background music, you can quickly generate a cool video clip.

FFCreator is a lightweight and simple solution, it only requires few dependencies and low machine configuration to quickly start working. And it simulates 90% of the animation effects of animate.css. You can easily convert the animation effects on the web page side into videos, which is really awesome.

Talk about Concent & Recoil in detail, explore the new development model of react data flow

幻魂 — Fri, 20 Nov 2020 04:04:03 +0000

Open source is not easy, thank you for your support, ❤ star me if you like concent ^_^

Preface

Recently, more and more of the latest state management solutions from facebook recoil have been mentioned gradually. Although it is still in an experimental state, everyone has already started privately. I want to try it. After all, I was born famous and has fb endorsement, and I will definitely shine.

However, after I experienced recoil, I remained skeptical about the precise update advertised in it, and there were some misleading suspicions. This point will be analyzed separately below. Whether it is misleading, readers can naturally draw conclusions after reading this article , In short, this article mainly analyzes the code style differences between Concent and Recoil, and discusses their new influence on our future development model, and what kind of change in thinking needs to be done.

3 major genres of data flow solutions

The current mainstream data flow solutions can be divided into the following three categories according to the form

-redux genre
Redux, other works derived from redux, and works similar to redux ideas, representative works include dva, rematch, and so on.

-mobx genre
With the help of definePerperty and Proxy to complete data hijacking, so as to achieve the representative of the purpose of responsive programming, there are also many mobx-like works, such as dob.

-Context genre
Context here refers to the Context api that comes with React. Data flow solutions based on Context api are usually lightweight, easy to use, and less overview. Representative works are unstated, constate, etc. The core code of most works may not exceed 500 Row.

At this point, let's see which category Recoil should belong to? Obviously it belongs to the Context genre according to its characteristics, so the main light weight we said above
Recoil is not applicable anymore. Open the source code library and find that the code is not done in a few hundred lines. Therefore, it is not necessarily lightweight based on the Context api that is easy to use and powerful. It can be seen that facebook is against Recoil It is ambitious and gives high hopes.

Let's also see which category Concent belongs to? After the v2 version of Concent, the data tracking mechanism was refactored, and the defineProperty and Proxy features were enabled, so that the react application not only retains the pursuit of immutability, but also enjoys the performance improvement benefits of runtime dependency collection and precise UI update. Now that defineProperty and Proxy are enabled, it seems that Concent should belong to the mobx genre?

In fact, Concent belongs to a brand new genre. It does not rely on React's Context API, does not destroy the form of the React component itself, maintains the philosophy of pursuing immutability, and only establishes a logical layer state on top of React's own rendering scheduling mechanism. Distributed scheduling mechanism, defineProperty and Proxy are only used to assist in collecting instances and derived data dependent on module data, and modifying the data entry is still setState (or dispatch, invoke, sync based on setState encapsulation), so that Concent can be accessed with zero intrusion Into the react application, true plug-and-play and non-perceived access.

The core principle of plug and play is that Concent builds a global context parallel to the react runtime, carefully maintains the attribution relationship between the module and the instance, and at the same time takes over the update entry setState of the component instance , Keep the original setState as reactSetState. When the user calls setState, in addition to calling reactSetState to update the current instance ui, Concent also intelligently judges whether there are other instances in the submitted state that care about its changes, and then take them out and execute these instances in turn The reactSetState achieves the purpose of all the states are synchronized.

Recoil first experience

Let's take the commonly used counter as an example to get familiar with the four frequently used APIs exposed by Recoil
-atom, defines the state
-selector, define derived data
-useRecoilState, consumption state
-useRecoilValue, consumption derived data

Define status

Use the atom interface externally, define a state where the key is num and the initial value is 0

const numState = atom({
  key: "num",
  default: 0
});

Define derived data

Use the selector interface externally, define a key as numx10, and the initial value is calculated again by relying on numState

const numx10Val = selector({
  key: "numx10",
  get: ({ get }) => {
    const num = get(numState);
    return num * 10;
  }
});

Define asynchronous derived data

The get of selector supports defining asynchronous functions

The point to note is that if there is a dependency, the dependency must be written before the asynchronous logic is executed.

const delay = () => new Promise(r => setTimeout(r, 1000));

const asyncNumx10Val = selector({
  key: "asyncNumx10",
  get: async ({ get }) => {
    // !!! This sentence cannot be placed under delay, the selector needs to be synchronized to determine the dependency
    const num = get(numState);
    await delay();
    return num * 10;
  }
});

Consumption status

Use the useRecoilState interface in the component to pass in the state you want to get (created by atom)

const NumView = () => {
  const [num, setNum] = useRecoilState(numState);

  const add = ()=>setNum(num+1);

  return (
    <div>
      {num}<br/>
      <button onClick={add}>add</button>
    </div>
  );
}

Consumption derived data

Use the useRecoilValue interface in the component to pass in the derived data you want to get (created by selector). Both synchronous and asynchronous derived data can be obtained through this interface

const NumValView = () => {
  const numx10 = useRecoilValue(numx10Val);
  const asyncNumx10 = useRecoilValue(asyncNumx10Val);

  return (
    <div>
      numx10 :{numx10}<br/>
    </div>
  );
};

Render them to see the results

Expose these two defined components, View online example

export default ()=>{
  return (
    <>
      <NumView />
      <NumValView />
    </>
  );
};

The top node wraps React.Suspense and RecoilRoot, the former is used to meet the needs of asynchronous calculation functions, the latter is used to inject the context of Recoil

const rootElement = document.getElementById("root");
ReactDOM.render(
  <React.StrictMode>
    <React.Suspense fallback={<div>Loading...</div>}>
      <RecoilRoot>
        <Demo />
      </RecoilRoot>
    </React.Suspense>
  </React.StrictMode>,
  rootElement
);

Concent first experience

If you have read the concent document (still under construction...), some people may think that there are too many APIs and it is difficult to remember. In fact, most of them are optional syntactic sugar. Let’s take counter as an example, and only need to use The following two apis
-run, define module status (required), module calculation (optional), module observation (optional)

After running the run interface, a concent global context will be generated
-setState, modify state

Define status & modify status

In the following example, we first break away from ui and directly complete the purpose of defining state & modifying state

import {run, setState, getState} from "concent";

run({
  counter: {// Declare a counter module
    state: {num: 1 }, // define state
  }
});

console.log(getState('counter').num);// log: 1
setState('counter', {num:10});// Modify the num value of the counter module to 10
console.log(getState('counter').num);// log: 10

We can see that this is very similar to redux, a single state tree needs to be defined, and the first-level key guides users to modularize the management of data.

Introducing reducer

In the above example, we directly drop one setState to modify the data, but the real situation is that there are many synchronous or asynchronous business logic operations before the data falls, so we fill in the reducer definition for the module to declare the modification of the data Method collection.

import {run, dispatch, getState} from "concent";

const delay = () => new Promise(r => setTimeout(r, 1000));

const state = () => (( num: 1 ));//State statement
const reducer = {// reducer declaration
  inc(payload, moduleState) {
    return {num: moduleState.num + 1 };
  },
  async asyncInc(payload, moduleState) {
    await delay();
    return {num: moduleState.num + 1 };
  }
};

run({
  counter: {state, reducer}
});

Then we use dispatch to trigger the method of modifying the state

Because dispatch returns a Promise, we need to wrap it up with an async to execute the code

import {dispatch} from "concent";

(async ()=>{
  console.log(getState("counter").num);// log 1
  await dispatch("counter/inc");// Synchronous modification
  console.log(getState("counter").num);// log 2
  await dispatch("counter/asyncInc");// Asynchronous modification
  console.log(getState("counter").num);// log 3
})()

Note that the dispatch call is based on the string matching method. The reason why this call method is retained is to take care of the scenes that need to be dynamically called.

import {dispatch} from "concent";

await dispatch("counter/inc");
// change into
await dispatch(reducer.inc);

In fact, the reducer set defined by the run interface has been centrally managed by concent and allows users to call it in the way of reducer.${moduleName}.${methodName}, so here we can even base it on the reducer Make a call

import {reducer as ccReducer} from'concent';

await dispatch(reducer.inc);
// change into
await ccReducer.counter.inc();

Connect to react

The above example mainly demonstrates how to define the state and modify the state, then we need to use the following two APIs to help the react component generate the instance context (equivalent to the rendering context mentioned in the vue 3 setup), and obtain the consumption concentration module Data capabilities

-register, the registered component is a concent component
-useConcent, register the function component as a concent component

import {register, useConcent} from "concent";

@register("counter")
class ClsComp extends React.Component {
  changeNum = () => this.setState({ num: 10 })
  render() {
    return (
      <div>
        <h1>class comp: {this.state.num}</h1>
        <button onClick={this.changeNum}>changeNum</button>
      </div>
    );
  }
}

function FnComp() {
  const {state, setState} = useConcent("counter");
  const changeNum = () => setState({ num: 20 });

  return (
    <div>
      <h1>fn comp: {state.num}</h1>
      <button onClick={changeNum}>changeNum</button>
    </div>
  );
}

Note that the difference between the two writing methods is very small, except for the different definition of components, in fact, the rendering logic and data sources are exactly the same.

Render them to see the results

Online example

const rootElement = document.getElementById("root");
ReactDOM.render(
  <React.StrictMode>
    <div>
      <ClsComp />
      <FnComp />
    </div>
  </React.StrictMode>,
  rootElement
);

Comparing with Recoil, we found that there is no top layer and no Provider or Root similar component package, the react component has been connected to the concentration, which achieves true plug-and-play and non-perceptual access, while the api remains It is consistent with react.

Component calls reducer

Concent generates an instance context for each component instance, which is convenient for users to directly call the reducer method through ctx.mr

mr is shorthand for moduleReducer, and it is legal to write it directly as ctx.moduleReducer

// --------- For class components -----------
changeNum = () => this.setState({ num: 10 })
// ===> amended to
changeNum = () => this.ctx.mr.inc(10);// or this.ctx.mr.asynInc(10)

//Of course, this can also be written as ctx.dispatch call, but it is more recommended to use the above moduleReducer to call directly
//this.ctx.dispatch('inc', 10); // or this.ctx.dispatch('asynInc', 10)

// --------- For function components -----------
const {state, mr} = useConcent("counter");// useConcent returns ctx
const changeNum = () => mr.inc(20); // or ctx.mr.asynInc(10)

//For function groups, the dispatch method will also be supported
//ctx.dispatch('inc', 10); // or ctx.dispatch('asynInc', 10)

Asynchronous calculation function

The run interface supports the extension of the computed attribute, which allows users to define a collection of calculation functions for derived data. They can be synchronous or asynchronous, and support one function to use the output of another function as input. In the second calculation, the input dependency of the calculation is automatically collected.

 const computed = {// Define the collection of calculation functions
  numx10({ num }) {
    return num * 10;
  },
  // n:newState, o:oldState, f:fnCtx
  // Structure num, indicating that the current calculation dependency is num, and this function is triggered to recalculate only when num changes
  async numx10_2({ num }, o, f) {
    // It is necessary to call setInitialVal to give numx10_2 an initial value,
    // This function is only executed once when the first computed trigger is triggered
    f.setInitialVal(num * 55);
    await delay();
    return num * 100;
  },
  async numx10_3({ num }, o, f) {
    f.setInitialVal(num * 1);
    await delay();
    // use numx10_2 to calculate again
    const ret = num * f.cuVal.numx10_2;
    if (ret% 40000 === 0) throw new Error("-->mock error");
    return ret;
  }
}

// Configure to the counter module
run({
  counter: {state, reducer, computed}
});

In the above calculation function, we deliberately let numx10_3 report an error at some point. For this error, we can define errorHandler in the second options configuration of the run interface to catch it.

run({/**storeConfig*/}, {
    errorHandler: (err)=>{
        alert(err.message);
    }
})

Of course, it is better to use the concent-plugin-async-computed-status plugin to complete the unified management of the execution status of all module calculation functions.

import cuStatusPlugin from "concent-plugin-async-computed-status";

run(
  {/**storeConfig*/},
  {
    errorHandler: err => {
      console.error('errorHandler', err);
      // alert(err.message);
    },
    plugins: [cuStatusPlugin], // Configure asynchronous calculation function execution status management plugin
  }
);

The plug-in will automatically configure a cuStatus module to concent, so that components can connect to it and consume the execution status data of related calculation functions

function Test() {
  const {moduleComputed, connectedState, setState, state, ccUniqueKey} = useConcent({
    module: "counter",// belongs to the counter module, the state is obtained directly from the state
    connect: ["cuStatus"],// Connect to the cuStatus module, the status is obtained from connectedState.{$moduleName}
  });
  const changeNum = () => setState({ num: state.num + 1 });

  // Get the execution status of the calculation function of the counter module
  const counterCuStatus = connectedState.cuStatus.counter;
  // Of course, the execution status of the specified settlement function can be obtained in a more granular manner
  // const {['counter/numx10_2']:num1Status, ['counter/numx10_3']: num2Status} = connectedState.cuStatus;

  return (
    <div>
      {state.num}
      <br />
      {counterCuStatus.done? moduleComputed.numx10:'computing'}
      {/** Errors obtained here can be used for rendering, of course also thrown out */}
      {/** Let components like ErrorBoundary capture and render the degraded page */}
      {counterCuStatus.err? counterCuStatus.err.message:''}
      <br />
      {moduleComputed.numx10_2}
      <br />
      {moduleComputed.numx10_3}
      <br />
      <button onClick={changeNum}>changeNum</button>
    </div>
  );
}

View online example

Accurate update

At the beginning, I said that I remain skeptical about the precise update mentioned by Recoli, and there are some misleading suspicions. Here we will uncover the suspicion

Everyone knows that hook rules cannot be written in conditional control statements, which means that the following statements are not allowed

const NumView = () => {
  const [show, setShow] = useState(true);
  if(show){// error
    const [num, setNum] = useRecoilState(numState);
  }
}

So if the user does not use this data for a certain state in the UI rendering, changing the value of num somewhere will still trigger the re-rendering of NumView, but the state and from the instance context ofconcentmoduleComputed is a Proxy object, which collects the dependencies required for each round of rendering in real time. This is true on-demand rendering and accurate update.

const NumView = () => {
  const [show, setShow] = useState(true);
  const {state} = useConcent('counter');
  // When show is true, the rendering of the current instance depends on the rendering of state.num
  return {show? <h1>{state.num}</h1>:'nothing'}
}

Click me to view the code example

Of course, if the user needs to do other things when the num value has been rendered after the ui is changed, similar to the effect of useEffect, concent also supports users to extract it into setup and define effect to complete this Scenario requirements, compared to useEffect, the ctx.effect in the setup only needs to be defined once, and only the key name is passed. Concent will automatically compare the value of the previous moment and the current moment to determine whether to trigger the side effect function.

conset setup = (ctx)=>{
  ctx.effect(()=>{
    console.log('do something when num changed');
    return ()=>console.log('clear up');
  }, ['num'])
}

function Test1(){
  useConcent({module:'cunter', setup});
  return <h1>for setup<h1/>
}

More about effect and useEffect, please check this article

current mode

Regarding the question of whether concent supports current mode, let’s talk about the answer first. concent is 100% fully supported, or further, all state management tools are ultimately triggered by setState or forceUpdate. We As long as you don't write code with any side effects during the rendering process, letting the same state input to the power of the rendering result is safe to run in current mode.

current mode just puts forward more stringent requirements on our code.

// bad
function Test(){
   track.upload('renderTrigger');// Report rendering trigger event
   return <h1>bad case</h1>
}

// good
function Test(){
   useEffect(()=>{
      // Even if setState is executed only once, the component may be rendered repeatedly in current mode,
      // But React internally guarantees that the side effect will only be triggered once
      track.upload('renderTrigger');
   })
   return <h1>bad case</h1>
}

We first need to understand the principle of current mode because the fiber architecture simulates the entire rendering stack (that is, the information stored on the fiber node), which allows React to schedule the rendering process of the component in the unit of component. Stop and enter the rendering again, arrange the high priority to render first, and the heavily rendered components will slice repeatedly rendering for multiple time periods, and the context of the concentration itself is independent of the existence of react (the access to the concentration does not require anymore The top-level package is any Provider), which is only responsible for processing the business to generate new data, and then dispatching it to the corresponding instance on demand (the state of the instance itself is an island, and concent is only responsible for synchronizing the data of the dependent store), and then react In its own scheduling process, the function that modifies the state will not be executed multiple times due to repeated reentry of the component (this requires us to follow the principle of writing code that contains side effects during the rendering process), react is only scheduling the rendering timing of the component , And the component's interruption and reentry are also aimed at this rendering process.

So the same, for concent

const setup = (ctx)=>{
  ctx.effect(()=>{
     // effect is an encapsulation of useEffect,
     // This side effect is only triggered once in current mode (guaranteed by react)
      track.upload('renderTrigger');
  });
}

// good
function Test2(){
   useConcent({setup})
   return <h1>good case</h1>
}

Similarly, in the current mode mode of dependency collection, repeated rendering only triggers multiple collections. As long as the state input is the same, the rendering result is idempotent, and the collected dependency results are also idempotent.

// Assuming that this is a time-consuming component to render, rendering may be interrupted in current mode
function HeavyComp(){
  const {state} = useConcent({module:'counter'});// belongs to the counter module

 // Two values of num and numBig are read here, and the dependencies are collected
 // That is, only when the num and numBig of the counter module change, the re-rendering is triggered (the setState is finally called)
 // When other values of the counter module change, the setState of the instance will not be triggered
  return (
    <div>num: {state.num} numBig: {state.numBig}</div>
  );
}

Finally, we can sort out the fact that hook itself is a custom hook (function without ui return) that supports the stripping of logic, and other state management is just another layer of work to guide users to strip the logic to them Under the rules, the business processing data is finally returned to the react component to call its setState or forceUpdate to trigger re-rendering. The introduction of current mode will not affect the existing state management or the new state management The solution has any impact, but it puts higher requirements on the user's ui code, so as not to cause bugs that are difficult to eliminate because of current mode

For this reason, React also provides the React.Strict component to deliberately trigger the dual call mechanism, https://reactjs.org/docs/strict-mode.html#detecting-unexpected-side-effects to guide users to write more The react code conforms to the specification to adapt to the current mode provided in the future.

All new features of react are actually activated by fiber. With fiber architecture, it has derived hook, time slicing, suspense and the future Concurrent Mode, both class components and function components You can work safely in Concurrent Mode, as long as you follow the specifications.

Taken from: https://reactjs.org/docs/strict-mode.html#detecting-unexpected-side-effects

Strict mode can’t automatically detect side effects for you, but it can help you spot them by making them a little more deterministic. This is done by intentionally double-invoking the following functions:

-Class component constructor, render, and shouldComponentUpdate methods
-Class component static getDerivedStateFromProps method
-Function component bodies
-State updater functions (the first argument to setState)
-Functions passed to useState, useMemo, or useReducer

So, React.Strict actually provides auxiliary APIs to guide users to write code that can run in Concurrent Mode. First let users get used to these restrictions, step by step, and finally launch Concurrent Mode .

Conclusion

Recoil advocates more fine-grained control of state and derived data. The demo looks simple in writing, but in fact, it is still very cumbersome after the code is large.

// define state
const numState = atom({key:'num', default:0});
const numBigState = atom({key:'numBig', default:100});
// Define derived data
const numx2Val = selector({
  key: "numx2",
  get: ({ get }) => get(numState) * 2,
});
const numBigx2Val = selector({
  key: "numBigx2",
  get: ({ get }) => get(numBigState) * 2,
});
const numSumBigVal = selector({
  key: "numSumBig",
  get: ({ get }) => get(numState) + get(numBigState),
});

// ---> Consumption status or derived data at ui
const [num] = useRecoilState(numState);
const [numBig] = useRecoilState(numBigState);
const numx2 = useRecoilValue(numx2Val);
const numBigx2 = useRecoilValue(numBigx2Val);
const numSumBig = useRecoilValue(numSumBigVal);

Concent follows the essence of redux single state tree, respects modular management data and derived data, and at the same time relies on the ability of Proxy to complete the perfect integration of runtime dependency collection and immutability pursuit.

run({
  counter: {// Declare a counter module
    state: {num: 1, numBig: 100 }, // define state
    computed:{// Define the calculation, and determine the dependency when deconstructing the specific state in the parameter list
       numx2: ((num))=> num * 2,
       numBigx2: ((numBig))=> numBig * 2,
       numSumBig: ({num, numBig})=> num + numBig,
     }
  },
});

// ---> The consumption state or derivative data at ui, the dependency is generated only after the structure at ui
const {state, moduleComputed, setState} = useConcent('counter')
const {numx2, numBigx2, numSumBig} = moduleComputed;
const {num, numBig} = state;

So you will get:
-Dependency collection at runtime, while also following the principle of react immutability
-Everything is a function (state, reducer, computed, watch, event...), can get more friendly ts support
-Support middleware and plug-in mechanism, easy to be compatible with redux ecology
-Supports centralized and fractal module configuration, synchronous and asynchronous module loading at the same time, which is more friendly to the flexible reconstruction process of large projects

❤ star me if you like concent ^_^

Edit on CodeSandbox

learning composition api to improve your react development experience

幻魂 — Fri, 21 Aug 2020 11:52:53 +0000

Open source is not easy, thank you for your support, ❤ star me if you like concent ^_^

Here is a list of status management in the collection, welcome friends who are interested to know ^_^
awesome-state

In this article, we will see the big difference between composition style and hook style in react code.

Preface

composition api (combination api) and optional api (optional api) are two ways to organize code. I believe you have learned a lot in the various related introduction articles of vue3, they can exist at the same time, It is not mandatory that you can only use which one, but the two major advantages of combined api do make developers more inclined to use it instead of optional api.

Package the reusable logic based on the function and inject it into any component, making the decoupling of the view and business more elegant
Let the businesses of the same function be placed more closely together without being separated, improving the development and maintenance experience

The above two points are elegantly solved by hook in React, so what are the advantages of combined api compared to hook? I’m not going to sell it here. I believe that some friends have already known when Youda introduced the combined api. The combined api is statically defined, which solves the performance problem that the hook must regenerate the temporary closure function every time it is rendered. In the hook, the old value trap, manual detection dependence and other coding experience problems are solved.

However, react is the coding method of all in js, so as long as we dare to think and do, all excellent programming models can be absorbed. Next, we use native hook and concentrated setup and pass Examples and explanations, to completely solve the pain point of hook mentioned by You Da^_^

react hook

We first design a traditional counter, the requirements are as follows

There is a decimal and a large number
There are two groups of plus and minus buttons, which operate on decimal and large numbers respectively, the decimal button adds and subtracts 1, and the large number button adds and subtracts 100
Pull the welcome greeting when the counter is first mounted
When the decimal reaches 100, the button turns red, otherwise it turns green
When the large number reaches 1000, the button turns purple, otherwise it turns green
When the big number reaches 10,000, the number of the big number is reported
When the calculator is uninstalled, report the current number

In order to complete this requirement, we need to use the following 5 hooks

useState

After the requirement, we need to use the first hook useState to initialize the state of the component's first rendering

function Counter() {
  const [num, setNum] = useState(6);
  const [bigNum, setBigNum] = useState(120);
}

useCallback

If you need to use the cache function, you need to use the second hook useCallback, here we use this hook to define the addition and subtraction functions

  const addNum = useCallback(() => setNum(num + 1), [num]);
  const addNumBig = useCallback(() => setBigNum(bigNum + 100), [bigNum]);

useMemo

If you need to use the cached calculation results, you need to use the third hook useMemo, here we use this hook to calculate the button color

 const numBtnColor = useMemo(() => {
    return num> 100?'red':'green';
  }, [num]);
  const bigNumBtnColor = useMemo(() => {
    return bigNum> 1000?'purple':'green';
  }, [bigNum]);

useEffect

To handle the side effects of the function, the fourth hook useEffect is needed. Here we are used to deal with the two requirements

When the big number reaches 10,000, the number of the big number is reported
When the calculator is uninstalled, report the current number

  useEffect(() => {
    if (bigNum> 10000) api.report('reach 10000')
  }, [bigNum])
  useEffect(() => {
    return ()=>{
      api.reportStat(num, bigNum)
    }
  }, [])

useRef

The writing of useEffect using the cleanup function above will be warned in the IDE, because of the internal use of num, bigNum variables (not writing dependencies will fall into the trap of the old value of the closure), so we are required to declare dependencies

However, if we change to the following method to avoid IDE warnings, obviously it is not our intention. We just want to report the number when the component is uninstalled, instead of triggering the cleanup function every round of rendering

  useEffect(() => {
    return ()=>{
      api.reportStat(num, bigNum)
    }
  }, [num, bigNum])

At this time we need the fifth hook useRef to help us fix our dependencies, so the correct way of writing is

  const ref = useRef();// ref is a fixed variable, and each round of rendering points to the same value
  ref.current = {num, bigNum};// Help us remember the latest value
  useEffect(() => {
    return () => {
      const {num, bigNum} = ref.current;
      reportStat(num, bigNum);
    };
  }, [ref]);

Complete counter

After using 5 hooks, our complete component is as follows

function Counter() {
  const [num, setNum] = useState(88);
  const [bigNum, setBigNum] = useState(120);
  const addNum = useCallback(() => setNum(num + 1), [num]);
  const addNumBig = useCallback(() => setBigNum(bigNum + 100), [bigNum]);
  const numBtnColor = useMemo(() => {
    return num> 100? "red": "green";
  }, [num]);
  const bigNumBtnColor = useMemo(() => {
    return bigNum> 1000? "purple": "green";
  }, [bigNum]);
  useEffect(() => {
    if (bigNum> 10000) report("reach 10000");
  }, [bigNum]);

  const ref = useRef();
  ref.current = {num, bigNum};
  useEffect(() => {
    return () => {
      const {num, bigNum} = ref.current;
      reportStat(num, bigNum);
    };
  }, [ref]);

  // render ui ...
}

Of course, we can abstract this code separately as a hook based on the customizable characteristics of hook. In this case, we only need to export the data and methods, so that the Counter components expressed by multiple uis can be reused, while also achieving ui It is isolated from the business and facilitates maintenance.

function useMyCounter(){
  // .... slightly
  return {num, bigNum. addNum, addNumBig, numBtnColor, bigNumBtnColor}
}

concent setup

The hook function must be re-executed during each round of rendering, so it is inevitable that a large number of temporary closure functions will be generated during each round of rendering. If we can omit them, it can indeed help reduce gc Some recovery pressure, now let's take a look at what the Counter will look like after using setup.

Using concent is very simple, just use the runapi to start it before the root component, so we don't have a module definition, just call it directly.

import {run} from'concent';

run();// Start first, in render
ReactDOM.render(<App />, rootEl)

Then we slightly modify the above logic, and wrap it all inside setup. The logic inside the setup function will only be executed once. The APIs provided by the rendering context ctx that need to be used include initState, computed, effect, setState, and the state state that needs to be read when calling setState are also obtained by ctx.

function setup(ctx) {// rendering context
  const {initState, computed, effect, state, setState} = ctx;
  // setup is executed only once before the component is rendered for the first time, we can write related business logic internally
}

initState

initState is used to initialize the state, instead of useState, when our component state is large, we still don't need to consider how to divide the state granularity.

initState({ num: 6, bigNum: 120 });

The function initialization state is also supported here

initState(()=>({ num: 6, bigNum: 120 }));

computed

computed is used to define the calculation function. When deconstructing from the parameter list, the input dependency of the calculation is determined. Compared with useMemo, it is more direct and elegant.

// This calculation function is triggered only when num changes
computed('numBtnColor', ({ num }) => (num> 100?'red':'green'));

Here we need to define two calculation functions. The calculation function can be configured with the description body of the calculation object, so that you only need to call computed once.

computed({
  numBtnColor: ({ num }) => num> 100?'red':'green',
  bigNumBtnColor: ({ bigNum }) => bigNum> 1000?'purple':'green',
});

effect

The usage of effect is exactly the same as useEffect, the difference is that only the key name is passed in the dependent array. At the same time, effect internally encapsulates the life cycle of function components and class components. Make any changes and migrate to class components

effect(() => {
  if (state.bigNum> 10000) api.report('reach 10000')
}, ['bigNum'])
effect(() => {
  // Here you can write what needs to be done when the first rendering is completed
  return () => {
  // Cleanup function triggered when uninstalling
    api.reportStat(state.num, state.bigNum)
  }
}, []);

setState

It is used to modify the state. After we define the method in setup based on setState, then return. Then we can get these method handles through ctx.settings in any component that uses this setup Can call

function setup(ctx) {// rendering context
  const {state, setState} = ctx;
  return {// export method
    addNum: () => setState({ num: state.num + 1 }),
    addNumBig: () => setState({ bigNum: state.bigNum + 100 }),
  }
}

Complete Setup Counter

Based on the above apis, the logic code of our final Counter is as follows

function setup(ctx) {// rendering context
  const {initState, computed, effect, state, setState} = ctx;
  // Initialization data
  initState({ num: 6, bigNum: 120 });
  // Define calculation function
  computed({
    // When the parameter list is deconstructed, the input dependency of the calculation is determined
    numBtnColor: ({ num }) => num> 100?'red':'green',
    bigNumBtnColor: ({ bigNum }) => bigNum> 1000?'purple':'green',
  });
  // define side effects
  effect(() => {
    if (state.bigNum> 10000) api.report('reach 10000')
  }, ['bigNum'])
  effect(() => {
    return () => {
      api.reportStat(state.num, state.bigNum)
    }
  }, []);

  return {// export method
    addNum: () => setState({ num: state.num + 1 }),
    addNumBig: () => setState({ bigNum: state.bigNum + 100 }),
  }
}

After defining the core business logic, we can use useConcent to assemble our defined setup inside any function component to use it. useConcent will return a rendering context (and the parameter list of the setup function refers to Is the same object reference, sometimes we also call the instance context), we can get the target data and methods from ctx on demand, for this example, we can export
You can use the three keys of state (data), settings (the method returned by the setup package), and refComputed (container of the calculation function result of the instance).

import {useConcent} from'concent';

function NewCounter() {
  const {state, settings, refComputed} = useConcent(setup);
  // const {num, bigNum} = state;
  // const {addNum, addNumBig} = settings;
  // const {numBtnColor, bigNumBtnColor} = refComputed;
}

We mentioned above that setup can also be assembled to class components, just use register. Note that the assembled class components can be directly obtained from this.ctx to the rendering context generated by concent At the same time, this.state and this.ctx.state are equivalent, and this.setState and this.ctx.setState are also equivalent, which is convenient for users to change the code 0 to access concentUse.

import {register} from'concent';

@register(setup)
class NewClsCounter extends Component{
  render(){
   const {state, settings, refComputed} = this.ctx;
  }
}

Conclusion

Compared with native hooks, setup fixes the business logic in a function that will only be executed once, provides a more friendly api, and is perfectly compatible with class components and function components, allowing users to escape the troubles of the use rules of hook ( Think about useEffect and useRef, is there a significant cognitive cost?), instead of passing these constraints on learning barriers to users, it is also more friendly to gc. I believe everyone has already defaulted to hook yesAn important invention of react, but in fact, it is not for users, but for frameworks. Users do not need to understand the details and rules of brain-burning. For concent users, they only need one hook to open one. The portal can implement all business logic in another space, and these logics can also be reused on class components.

My dear guest official has seen so much, don’t hurry up and try it out. The following links are provided in two ways for you to play with😀

one more thing

If you want to share the state of the two hook counters, we need to modify the code to connect to redux or build a self-built Context, but in the development mode of concent, setup does not require any modification, just declare one in advance Module, and then register the module that belongs to the component. This silky migration process allows users to flexibly deal with various complex scenarios.

import {run} from'concent';

run({
  counter:{
    state: {num:88, bigNum: 120 },
  },
  //reducer: {...}, // If the operation data process is complicated, the business can be promoted here
})

// For function components
useConcent({setup});
// ---> Change to
useConcent({setup, module:'counter'})

// For function components
@register({setup});
// ---> Change to
@register({setup, module:'counter'});

-shared Counter

Finish

❤ star me if you like concent ^_^

Edit on CodeSandbox

Edit on StackBlitz

If you have any questions about concent, you can scan the QR code and join the group consultation or send email to me( zhongzhengkai@gmail.com ). We will try our best to answer questions and help you learn more 😀.

Hello Concent, a funny way to develop react app.

幻魂 — Fri, 19 Jun 2020 08:05:22 +0000

star me if you like concent ^_^

concent

❤️ Build-in dependency collection, a predictable、zero-cost-use、progressive、high performance's react develop framework

review this gif source code or see a full demo

📦Quick start

Make sure you have installed nodejs。

Install concent

Install concent with npm command.

$ cd cc-app
$ npm i --save concent

or yarn command

$ yarn add concent

Define module

Use run to define a module.

import { run } from 'concent';

run({
  counter: {// declare a moudle named 'counter'
    state: { num: 1, numBig: 100 }, // define state
  },
  // you can also put another module here.
});

Cosume state & change state

Use register to specify a module for class component, or useConcentfor function component.

it will let concent konw which module current component belong to.

import { register, useConcent } from 'concent';

@register('counter')
class DemoCls extends React.Component{
  // now setState can commit state to store 
  // and broadcast state to other refs which also belong to counter module
  inc = ()=> this.setState({num: this.state.num + 1})
  render(){
    // here if read num, it means current ins render dep keys is ['num']
    const { num } = this.state;
    // render logic
  }
}

function DemoFn(){
  const { state, setState } = useConcent('counter');
  const inc = ()=> setState({num: state.num + 1});
  // render logic
}

Attention that state is a proxy object, for helping concent collect every instantce's dep keys in every render period, that makes exact update become true

Initialize component

There is no need to wrap with the root component with a Provider, you can just initialize the concent component any where you want, here you can view the demo.

const rootElement = document.getElementById("root");
ReactDOM.render(
  <React.StrictMode>
    <div>
      <ClsComp />
      <FnComp />
    </div>
  </React.StrictMode>,
  rootElement
);

Define reducer

If you have many logic code before changing state, we recommend put them to reducer

concent emphasize user should always return a partial state instead of whole state, it will let concent working in best performance mode, so just return what you changed in the reducer function.

run({
  counter: {
    state: { /** ... */},
    reducer: {
      inc(payload, moduleState) {
        return { num: moduleState.num + 1 };
      },
      async asyncInc(payload, moduleState) {
        await delay();
        return { num: moduleState.num + 1 };
      }
    }
  },
});

now you can call reducer funtion in your component instead of setState

//  --------- for class component -----------
changeNum = () => this.setState({ num: 10 })
// ===> modify as below (attention that mr is alias of moduleReducer)
changeNum = () => this.ctx.mr.inc(10);// or this.ctx.mr.asynInc(10)

// of course you can call dispatch, but we think moduleReducer is better
//this.ctx.dispatch('inc', 10); // or this.ctx.dispatch('asynInc', 10)

//  --------- for function component -----------
const { state, mr } = useConcent("counter");// useConcent returns ref ctx
const changeNum = () => mr.inc(20); // or ctx.mr.asynInc(10)

infact concent allow user change with top api setState、dispatch and reducer.

with setState

import { getState, setState } from "concent";

console.log(getState('counter').num);// log: 1
setState('counter', {num:10});// change counter module's num state
console.log(getState('counter').num);// log: 10

with dispatch dispatch return a promise, so we should wrap the logic with async

import { getState, dispatch } from "concent";

(async ()=>{
  console.log(getState("counter").num);// log 1
  await dispatch("counter/inc");// call counter reducer inc method
  console.log(getState("counter").num);// log 2
  await dispatch("counter/asyncInc");// call counter reducer asyncInc method
  console.log(getState("counter").num);// log 3
})()

with reducer infact concent collect all module's reducer to its internal reducer map to let user call reducer method directly!

import { getState, reducer as ccReducer } from "concent";

(async ()=>{
  console.log(getState("counter").num);// log 1
  await ccReducer.counter.inc();
  console.log(getState("counter").num);// log 2
  await ccReducer.counter.asyncInc();
  console.log(getState("counter").num);// log 3
})()

Define computed

If you want to compute another state with module state, we recommend put them to computed

run({
  counter: { 
    state: { /** ... */},
    reducer: { /** ... */},
    computed: {
      numx2: ({num})=> num * 2,
      numBigx2: ({numBig})=> numBig * 2,
      numSumBig: ({num, numBig})=> num + numBig,
    }
  },
});


// get computed result in funtion component
const { moduleComputed } = useConcent('counter');

// get computed result in class component
const { moduleComputed } = this.ctx;

Attention that when you deconstruct the state for a computed function, you are also declare the dep keys for the function at the same time.

 // current function will only been execute when num or numBig changed.
 const numSumBig = ({num, numBig})=> num + numBig,

async comoputed is also supported, here see the online demo.

Some advanced Features

Concent allow user write code with its cool features, they are all optional, but once you learned it you will love it.

🎇Enjoy composition api🎊 🎉

with composition api, user can easily separate ui and logic.
view this demo

import { run, useConcent } from "concent";

run();// startup concent

const setup = ctx => {
  const { initState, computed, watch, setState, sync } = ctx;

  initState({ greeting: 'hello concent' });
  computed("reversedGreeting", n => n.greeting.split('').reverse());
  watch("greeting", (n, o) => alert(`from ${o.greeting} to ${n.greeting}`));

  return {
    changeGreeting: (e) => setState({ greeting: e.target.value }),
    changeGreeting2: sync('greeting'),
  };
};

function HelloConcent(){
  const { state, refComputed, settings } = useConcent({ setup });
  return (
    <>
      <h1>{state.greeting}</h1>
      <h1>{refComputed.reversedGreeting}</h1>
      <input value={state.greeting} onChange={settings.changeGreeting}/>
      <input value={state.greeting} onChange={settings.changeGreeting2}/>
    </>
  );
}

simple demo 1
simple demo 2

🎆Unified coding of class components and function components

setup can be used in both class and function component, that means user can easily share logic (even including life cycle logic) between the 2 kinds of component.

// for class
@register({setup})
class ClsComp extends React.Component{...}

// for function
function FnComp(){
  useConcent({setup});
}

view demo

Eco system

With middleware and plugin mechanism, you can easily cutomize your common handler for non logic code, or migrate redux eco lib.

Use with react router

Details see here react-router-concent，expose history，you can call it anywhere in your app to enjoy the imperative navigation jump.

react-router-concent online demo

Use with redux-dev-tool

Details see here concent-plugin-redux-devtool，track your state changing history。

Use with plugin-loading

Details see here concent-plugin-loading，control all your reducer function's loading status easily。

concent-plugin-loading online demo