DEV Community: 南小北

react-live-island, Dynamic Island for React

南小北 — Mon, 18 Sep 2023 16:06:36 +0000

Product Hunt: https://www.producthunt.com/posts/react-live-island

GitHub: https://github.com/nanxiaobei/react-live-island

import LiveIsland from 'react-live-island';

const Demo = () => {
  return (
    <LiveIsland>
      {(isSmall) => (isSmall ? 'small' : 'large')}
    </LiveIsland>
  );
};

I searched the entire internet but couldn’t find a suitable ⚛️ React Dynamic Island 🏝 component, so I decided to create one myself.

It is a very simple component that doesn’t introduce any external libraries. Simply importing it can add a dynamic island at the top of the page.

Considering that both the dynamic-island and react-dynamic-island NPM packages have been preempted, I named it react-live-island 🎉.

I hope you will like it, It is really very simple, directly importing and then you can see a dynamic island! ✌️ while also providing rich customization props.

Introducing react-live-island by 🐤 Kee (https://kee.so)

Introducing kee.so: Link in bio refresh, a home screen look

南小北 — Tue, 01 Aug 2023 10:37:37 +0000

https://kee.so/

https://www.producthunt.com/posts/kee-so

🐣 Initial Inspiration

We originally wanted to develop kee.so, starting in August 2021.

At that time, we saw the release of iOS widgets, the videos released by the new UI of Windows 11 and Android 12, and we liked the different system styles very much.

So we decided to develop a service for creating a “personal page” based on these different UI tastes.

🎙️ Original Idea of kee.so

Linktree provides a display of “horizontal bars”, a one-dimensional space, from top to bottom, very simple.

kee.so wants to create a differentiated experience, so “grids” came to mind, changes from one dimension to two dimensions, can be arranged horizontally and vertically.

With the inspiration of apps and widgets, the personal page experience is enriched and more possibilities are created.

📺 Launched Official Welcome Page

In August 2021, we registered the kee.so domain and Twitter account @_keeso.

In September 2021, the welcome page was launched, and the slogan was “Your home screen on internet”. This is the first tweet.

A personal page that can freely combine apps and widgets, so we gave it the concept: “home screen”.

🍱 Met Halfway Through … Bento

But kee.so did not have the right time to start formal development. In December 2022, Bento went online.

Although the idea is earlier than Bento, but developed late, so it is hard to avoid being called a Bento-like service.

But still, kee.so is only similar in “grids”, it is completely different in other aspects.

🪩 How kee.so Differs from Bento

The core of kee.so is not built on the concept of “bento 🍱”, but on the concept of “home screen”.

So in essence, the underlying concepts of kee.so and Bento are different.

What kee.so wishes to provide is a “home screen”.

📱 “Home Screen” x Web

A personal page that is identical in concept and design like a home screen of a phone.

It’s one page, one link, one “home screen” for everyone.

With the form of app + widgets, everyone can easily create a home screen on internet, which can be freely customized just like the home screen of a phone.

🍧 Unlimited Personal Page

This page focuses on displaying your various social links, URLs, pictures, and text.

This page link, uniquely defined by you, can be placed on any social platform, Instagram, Twitter, TikTok...

The design of the page is up to you to create freely, emoji icon, widget background color, home screen “wallpaper”, blurring, adding noise, you will not encounter any problems.

🐥 Your Home Screen on Internet

The degree of freedom and personalization of kee.so is far beyond that of Bento.

On mobile, its interface is completely responsive and does not require additional design, which is exactly the meaning of the web.

Be consistent on any screen and insist on consistent performance.

Make the only home screen, Perfect in everywhere. ⚡️

🧿 Turn React into SolidJS, update on demand, no more re-render

南小北 — Wed, 06 Apr 2022 19:32:51 +0000

1. What is SolidJS?

We all know SolidJS, if not, why are you reading this article!

We all know SolidJS, here is its doc: https://www.solidjs.com

Put it simply, SolidJS is the real "react" version of React, which is completely updated on demand, and where data changes are updated.

For example, a component:

function App() {
  const [value, setValue] = useState(0);
  return <div>{value}</div>;
}

React calls the entire function of App to death (i.e. re-render), while SolidJS only updates the small piece of value.

Of course, SolidJS is like this:

function App() {
  const [value, setValue] = createSignal(0);
  return <div>{value()}</div>;
}

In SolidJS, App is called only once during initialization, and is not executed after that.

So JSX in SolidJS is equivalent to "static template", which is only used to describe the UI and will not be called again, and there is no diff.

That is to say, any function executed in App or any function executed in JSX will only be triggered once.

2. First declare

How to turn React into SolidJS?

Certainly not rename solid-js to react, nor manually use DOM API to update it without React logic.

It must be stated here:

The following implementation is completely based on the React API, rather than hacking with the DOM API or jQuery, which would be meaningless.

3. How to implement it?

1. How to update only the small piece of `value()`?

This is the core of the implementation idea, let's just say it - that is to turn value() into a component.

Yes, it displays data, but it's actually a component. It's a component that just returns data.

2. Why `value()` instead of `value`?

Because we need to know that there is a data here, and it has to be updated later, how do we know?

According to JS syntax, there is no other way than state.value (use getter) or value() (call function).

This is why SolidJS must be written as value(). If it is written as value, God don't know how to update it, because in the implementation of "static template", the function will not run again.

3. Implement a `useSignal` similar to `createSignal`

We want to implement a useSignal, similar to SolidJS' createSignal, which returns two functions, a getter and a setter.

At the same time, the return of the getter is a component.

function useSignal(val) {
  const valRef = useRef(val);
  const update = useRef();

  const Render = () => {
    const [value, setValue] = useState(valRef.current);
    update.current = setValue;
    return value;
  };

  const getter = () => {
    try {
      useState(); // Use this hack to know whether the data is in JSX or read normally elsewhere
      return <Render />;
    } catch (e) {
      return valRef.current;
    }
  };

  const setter = (newVal) => {
    valRef.current = newVal;
    update.current(newVal);
  };

  return [getter, setter];
}

The above is a minimal implementation, but it is problematic because the data may be used in multiple places, and the above can only update the data in the last place.

4. Data synchronization update version `useSignal`

Collect the update functions with an array of listeners and that's it. In fact, this is also the implementation idea of React state managers.

function useSignal(val) {
  const valRef = useRef(val);
  const listeners = useRef([]);

  const Render = () => {
    const [value, setValue] = useState(valRef.current);

    useEffect(() => {
      listeners.current.push(setValue);
      return () => {
        listeners.current.splice(listeners.current.indexOf(setValue), 1);
      };
    }, []);

    return value;
  };

  return [
    () => {
      try {
        useState();
        return <Render />;
      } catch (e) {
        return valRef.current;
      }
    },
    (payload) => {
      listeners.current.forEach((listener) => {
        listener((prev) => {
          valRef.current =
            typeof payload === 'function' ? payload(prev) : payload;
          return valRef.current;
        });
      });
    },
  ];
}

The above is already a working implementation.

At this point, the core of the story has actually been told.

But if it is to be really used for development needs, there is still a lot of unfinished business.

4. What else is there to do?

If it's really "available", it should at least implement:

createEffect (for listening for data updates)
createMemo (for creating computed data)
onMount (for sending requests)
onCleanup (for unsubscribing)
What if the data is an object or an array? (This is the most complicated, the above actually only considers primitive data types)
How to implement conditional operator or function calls in JSX? (The conditional operator or function is only executed once during initialization and cannot respond to change)
How to respond to HMR? What if the data doesn't appear in JSX for the first time? How to unsubscribe after component unmount...

5. Introducing solid-react

There are a bunch of questions written on it, and naturally the answer is ready... This answer is called solid-react.

All the problems mentioned above have been solved. If you have a deeper understanding, you can look at the source code.

☞ GitHub: https://github.com/nanxiaobei/solid-react

Here is the API for solid-react:

useSignal (corresponding to createSignal, used to create data)
useUpdate (corresponding to createEffect, used to monitor data updates)
useAuto (corresponding to createMemo, used to create computed data)
useMount (corresponding to onMount, used to send requests)
useCleanup (corresponding to onCleanup, used to unsubscribe)
the data is an object or an array (use a proxy to handle this tricky case)
Run (for conditional operator or functions in JSX, Run(() => fn(value()))

Please pay attention to the naming of the API, which is also said: try not to conflict with existing APIs (such as not directly naming useState useMemo, which will confuse the code), while keeping it concise enough (easy to write) and intuitive (easy to understand).

For specific API introduction, please check README: https://github.com/nanxiaobei/solid-react

In this way, most common development scenarios can already be covered, that is, it can be used for "production".

6. Try solid-react

Demo: https://codesandbox.io/s/solid-react-rymhr6?fontsize=14&hidenavigation=1&theme=dark&file=/src/App.js

Here is a demo, you can open the console, click the button to try, and you will find:

Components don't re-render anymore, React is completely SolidJS-style on-demand updates!

useUpdate useAuto does not need anything like deps, its dependencies are automatically learned. And only when dependencies change, they execute again.

Yes, that is to say, you can get rid of Hooks, useCallback useMemo deps memo, will it trigger re-render, it's all unnecessary.

A function is a function, an object is an object, and it will not be created again if it is written there.

7. What else?

solid-react is an experimental project, just to implement an idea, and in fact it is not bad.

solid-react tries its best to make it "completely capable", whether it is sending requests or monitoring data, sparrows are small (but delicious) and have all the internal organs.

solid-react is a small thing, it may have flaws, of course it can't compare with the maturity of developing directly with React, and it is impossible to compare.

solid-react is definitely fine for small demo projects, but I haven't practiced it in big projects, it's good to play with it first, if you're interested.

solid-react is more like a concept. It is impossible for React officials to take this road, but thanks to the open source, you can experiment on this road yourself.

solid-react works hard to "suffer from Hooks", a general confusion in the industry that has not disappeared for several years (although I feel Hooks are fine)

solid-react welcomes those who are interested to try it together and create more possibilities.

Turn React into SolidJS, say goodbye to Hooks, say goodbye to re-render ↓↓↓

https://github.com/nanxiaobei/solid-react

Some people may want to say, isn't the API of solid-react are Hooks? How to say goodbye to Hooks! In fact, the above is to be compatible with the mixed use of React and solid-react ... Yes, I even considered this situation 🙈

resso, world's simplest React state manager

南小北 — Thu, 17 Feb 2022 15:51:32 +0000

1. resso, React state management has never been so easy

resso is a brand-new state manager for React, aims to provide the world's easiest way to use.

resso also implements on-demand updating. If the unused data changed, it will never trigger the component updating.

GitHub: https://github.com/nanxiaobei/resso

import resso from 'resso';

const store = resso({ count: 0, text: 'hello' });

function App() {
  const { count } = store; deconstruct first, then use
  return (
    <>
      {count}
      <button onClick={() => store.count++}>+<button>
    <>
  );
}

Only one API resso, just wrap the store object, nothing else.

To update, just re-assign the key of the store.

2. How does React state manager works?

Suppose there is a store, injected into different components:

let store = {
  count: 0,
  text: 'hello',
};

// Component A
const { count } = store;
const [, setA] = useState();

// Component B
const { text } = store;
const [, setB] = useState();

// Component C
const { text } = store;
const [, setC] = useState();

// init
const listeners = [setA, setB, setC];

// update
store = { ...store, count: 1 };
listeners.forEach((setState) => setState(store));

Put the setState of each component into an array, when updating the store, run listeners to call all setState, so that the update of all components can be triggered.

How to monitor the store data changing? A public update function (such as Redux's dispatch) can be provided, which is updated if called. You can also use the proxy's setter to listen.

Yes, almost all state managers work this way, it's that simple. For example, the source code of Redux: https://github.com/reduxjs/redux/blob/master/src/createStore.ts#L265-L268

3. How to optimize the update performance?

All setState in listeners is called every time the store is updated, which can cause performance issues.

For example, when updating count, theoretically only A is expected to update, at this time B and C are also updated, but they do not use count at all.

How to update on demand? You can use a selector (such as Redux's useSelector, or zustand's implementation):

// Component A
const { count } = store;
const [, rawSetA] = useState();

const selector = (store) => store.count;
const setA = (newStore) => {
  if (count !== selector(newStore)) {
    rawSetA(newStore);
  }
};

The same way for other components, subscribing new setA to listeners can achieve "on-demand update" of components.

Above functions can also be implemented using proxy's getter, and the data "used" by the component can be known through the getter.

4. How is resso implemented internally?

In the above implementation, one setState is collected in each component. When updating the store, determine whether to update the component through data comparison.

resso uses a new idea, which is actually more in line with the primitive concept of Hooks:

let store = {
  count: 0,
  text: 'hello',
};

// Component A
const [count, setACount] = useState(store.count);

// Component B
const [text, setBText] = useState(store.text);

// Component C
const [text, setCText] = useState(store.text);

// init
const listenerMap = {
  count: [setACount],
  text: [setBText, setCText],
};

// update
store = { ...store, count: 1 };
listenerMap.count.forEach((setCount) => setCount(store.count));

Use useState to inject each data from store used in the component, while maintaining a list of updaters for each key in the store.

The number of setStates collected in each component corresponds to the store data used. Instead of just collecting one setState for the component updating.

When updating, there is no need to do data comparison, because the update unit is based on the "data" level, not based on the "component" level.

To update a certain data is to call the updater list of this data, not the updater list of the component. Primitive the entire store.

5. How the API of resso is designed?

The secret to designing an API: write the usage you want first, and then figure out how to implement it. What comes out of this must be the most intuitive.

resso also thought about the following API design at the beginning:

1. Similar to valtio

const store = resso({ count: 0, text: 'hello' });

const snap = useStore(store);
const { count, text } = snap; // get
store.count++; // set

This is the standard usage of Hooks, with the disadvantage of adding an extra API useStore. And using snap when getting, using store when setting, makes people split. This is definitely not the "simplest" way.

2. Similar to valtio/macro

const store = resso({ count: 0, text: 'hello' });

useStore(store);
const { count, text } = store; // get
store.count++; // set

This is also achievable and is the standard usage of Hooks. At this time, the main body of get and set is unified, but it is still necessary to add a useStore API. This thing is only for calling Hooks, what if the user forgets to write it?

And in practice, it is found that when using store in each component, you have to import two things, store and useStore, which is definitely not as simple as importing only one store, especially when it is used in many components, will be very troublesome.

3. In order to import only one store

const store = resso({ count: 0, text: 'hello' });

store.useStore();
const { count, text } = store; // get
store.count++; // set

This is the last hope of a "legal" use of Hooks, just importing a store, but it still looks weird and unacceptable anyway.

If you try to design this API, you will find that if you want to directly update the store (requires import store), and want to deconstruct store data from Hooks (need to import one more Hook, get and set are from different sources), no matter what, the design will looks awkward.

For the ultimate simplicity, for the easiest way to use, resso finally embarked on this API design:

const store = resso({ count: 0, text: 'hello' });

const { count } = store; // get
store.count++; // set

6. How to use resso?

Get store

Because the store data is injected into the component using useState, it needs to be destructure first (destructure means calling useState), destructure at the top level of the component (Hooks rules, cannot be written after if), and then use, otherwise there will be a React warning.

Set store

Assignment to the first level of the store data will trigger the update, and only the assignment of the first level will trigger the update.

store.obj = { ...store.obj, num: 10 }; // ✅ trigger update

store.obj.num = 10; // ❌ does not trigger update (valtio supports this way)

resso does not support the writing method like valtio, mainly due to the following considerations:

It is need to traverse all the data deeply to proxy, and when updating the data, it needs to be proxy first, which will cause a certain performance loss. (resso only proxy store once at the initialization.)
Because all data are proxy, it is not friendly when printed in the Chrome console, which is a big problem. (resso does not because only the store is a proxy, and generally prints the data in the store.)
If the sub-data is destructured, such as obj, obj.num = 10 can also trigger the update, which will cause the data source to be opaque, and it is uncertain whether it comes from the store and whether the assignment triggers the update. (The main body of resso is always from the store, and the source is clear.)

7. Simple. Not chaos

The above is the design concept of resso and some implementations of a React state manager.

At the end of the day, the React state manager is a tool, React is a tool, JS is a tool, programming is a tool, and the job itself is a tool.

The purpose of tools is to create, to create works that act on the real world, not the tools themselves.

So, why not make it simpler?

jQuery is to simplify the development of native JS, React is to simplify the development of jQuery, development is to simplify the process in the real world, the Internet is to simplify people's communication path, work path, consumption path, the meaning of development is to simplify, the meaning of the Internet itself is simplification, and the value of the Internet lies in simplification.

So, why not make it simpler?

Chic. Not geek.

Simplicity is everything.

try try resso: https://github.com/nanxiaobei/resso

React State Management in 2022

南小北 — Thu, 10 Feb 2022 18:53:02 +0000

1. What is "state"?

In the era of jQuery, JS code is mixed with DOM structure. When various processes are complex and intertwined, it forms spaghetti code. When using publish/subscribe model, debugging will be messy.

jQuery is imperative programming for "process", and so many commands are ultimately to update the "data" in the UI. Why not change the data directly?

Beijing → Shanghai, just change city="Beijing" into city="Shanghai". No matter whether the plane or train breaks down on foot, or whether you will meet Wang Baoqiang on the pipeline.

The significance of modern front-end framework is the innovation of problem-solving ideas, which changes various commands of "process" into the description of "state".

What is state? State is the dynamic data in the UI.

2. State in React

React was born in May 2013. But before 2015, it was probably the world of jQuery. React 0.13.0 was released in March 2015, bringing the writing method of class components.

In the era of React class components, the state is this.state, use this.setState to update.

In order to avoid a mess, React introduces the concepts of "component" and "unidirectional data flow". With state and components, there is naturally the transfer of state between components, which is generally called "communication".

Parent-child communication is relatively simple, while the communication of deep-level and long-distance components depends on "lifting state up" + pass props layer by layer.
Therefore, React introduced Context, an official solution to solve the "cross level" communication of components.

However, Context is actually equivalent to "lifting state up". There is no additional performance optimization, and it is wordy.

In order to optimize performance, multiple contexts are usually added, which is more verbose. When the project is not so complex, it is better to pass props layer by layer.

3. What is "state management"?

In terms of pragmatism, "state management" is to solve the "cross level" communication between components.

Of course, when using state management library, it will bring some derived thinking patterns, such as how to organize state, how to split public logic, business logic, component logic, etc. but in the final analysis, these are not the core reasons.

The core is to solve practical problems — communication. Other concepts and philosophies are not necessary.

Context is not so easy to use, and React officials have no best practices, so community libraries were born.

4. State management in class era

The era of React class components is the story of Redux (and its related derivative libraries) and MobX.

Redux is an implementation in line with the concept of React. MobX’s "monitoring" mode is characterized by "not enough React", but it is simple to use.

The pros and cons of Redux have been discussed too much. In short, developers are concerned about "use", while Redux is concerned about "philosophy".

Previously, I joked that in fact, Redux can express it in one line of code, but wrote a sleepy document with paper specifications:

createStore = (reducer, state) => ({ dispatch: (action) => (state = reducer(state, action)) });

The principle of almost all React state managers are actually very simple. An implementation of "observer mode":

Subscribe a listener in each component. When the state is updated, call the listeners again to trigger the component update.

5. Why hooks?

React class component has the following problems:

this.state is an object. Each time a part of state is updated, a new field can also be added, which makes the whole state chaotic.
When using modes such as HOC, the data source in this.props will be opaque and chaotic.
Because of the existence of the magic pointer this, it is easy to hang a lot of things on it and call each other at will, which will entangle the logic.

In order to solve the above problems, React introduces Hooks:

Break up the chaotic state into primitive.
Provide logical sharing to replace HOC.
this no longer exists in the component.

This is an innovation of development concept and organization concept. Hooks has 3 strong characteristics: primitive, decentralization and algebraic effects.

Primitive. Built from the bottom, makes the data structure clearer. At the same time, it is also an engineering trend. e.g. Tailwind CSS is to primitive CSS.
Decentralization. There is a common concept of "top-level distribution" in the class era, but Hooks brings a strong concept of "component autonomy" (for example, Provider is no longer required, the component requests are processed by itself). At the same time, decentralization is also a popular concept in other fields.
Algebraic effects. In the final analysis, Hooks can be understood as a pipeline that connects to the core capabilities of React, and exposes internal machines to developers.

6. State management in Hooks Era

After the emergence of Hooks, the community has not had a state manager that once unified like Redux.

Redux has added some capabilities such as useSelector, useDispatch and useStore, and Facebook also opened a library Recoil.

However, Redux is old-fashioned after all, and the shadow left by it in the early stage is too big. Many people’s thinking is formatted. Writing it casually is in the clouds, just to realize a simple function,

Recoil’s writing rules seem awkward and wordy, and its development is not warm.

// Recoil
atom({ key: 'textState', default: '' });
useRecoilState(textState);

In the Hooks era, a mysterious organization emerged and contributed three state management libraries at one go.

It’s pmndrs, pmndrs for poimandres. pmnd.rs

When it comes to "organization", in fact, the main developer should be one person, the master, Daishi Kato. github.com/dai-shi

The three libraries are zustand, jotai and valtio. Interestingly, these three words actually mean "state".

zustand 🇩🇪 German "state", jotai 🇯🇵 Japanese "status", valtio 🇫🇮 Finnish "state".

Take a brief look at the usage:

// zustand 🇩🇪 - Redux spirit, old times, centralized
const useStore = create((set) => ({
  bears: 0,
  removeBears: () => set({ bears: 0 }),
}));
const bears = useStore((state) => state.bears);

// jotai 🇯🇵 - primitive concept, a little wordy, Hooks spirit
const countAtom = atom(0);
const [count, setCount] = useAtom(countAtom);

// valtio 🇫🇮 - proxy concept, "not very react", simple to use
const state = proxy({ count: 0, text: 'hello' });
const snap = useSnapshot(state);

7. Greedy update vs lazy update?

As mentioned earlier when referring to MobX, the scheme of proxy "monitoring" is not React, but it is practical, simple and most intuitive.

In essence, React is a "greedy update" strategy, full re-render then diff.

Proxy is a "lazy update" strategy, which can accurately know which variable is updated. Therefore, using proxy, we can optimize the performance of re-render.

React Forget introduced on React conf represents that React itself does not exclude some optimization in the idea of "lazy update".

Note that the above words "greedy update" and "lazy update" are my own words, referring to the concepts of greedy and lazy in regular expression.

8. Change of React state management ideas

All state in a large object → split into primitive
Opaque data → transparent data
Top level request, issue data → the component request by itself
State promotion → component autonomy
Provider & container components → just Hooks
Chaotic set → transparent decoupling
Greedy update → lazy update
Big and complete, strong concept, DX ❌ → clearer, simpler, DX ✅
Less concept, more intuition
Less rules, more automation

Generally speaking, although this is a change in state management, it is also a change in React community development, a continuous exploration of best practices:

Centralization → decentralization
Data collection → primitive
Build a structure, completely from the ground up

9. Introducing resso, the simplest React state manager

I have been thinking about what kind of React state manager is the simplest to use, and constantly explore a tool that is the most comfortable to use.

Retalk (Redux best practice) and flooks (hooks state management) have been developed before, but with the emergence of new ideas, some of the latest inspiration is now concentrated in the state management library of resso.

Here is resso:

import resso from 'resso';

const store = resso({ count: 0, text: 'hello' });

function App() {
  const { count } = store;
  return (
    <>
      {count}
      <button onClick={() => store.count++}>+</button>
    </>
  );
}

GitHub: github.com/nanxiaobei/resso

Note that it is easier to write than the very simple valtio. It should not be simpler. If so, please let me know.

More importantly, resso will automatically optimize re-render, and never trigger additional re-render just because the data is in the same object.

In fact, state management is a very simple thing, but Redux and other tools add too much complexity. The original purpose of people using a tool is to solve problems.

So, simple and clear, let the tool return to the tool. The way we know a hammer is to pick it up and use it.

I hope resso will be liked by those who need it.

10. Invest the future

But what’s the use of all this?

When new things keep coming, people will inevitably ask: class components are not unusable, Redux is not unusable, or more thoroughly, jQuery is not unusable. Why do you have to chase these new things?

An abstract explanation: we should constantly invest in the future.

This is not only in the development, in the work, but also in any field — "in the form of continuous subdivision in the new track, exchange the first identity for resources."
The track of the old world is crowded with hard-working travelers. Although the new world is a mirage, only the new world will jump everything.

The above content comes from the share of React State Management in 2022.

→ PDF download
→ Keynote download (more animation~)

React Split Components: A new way of Function Components without Hooks

南小北 — Sun, 07 Nov 2021 22:30:53 +0000

1. The Problem of Function Components and Hooks

1. Why Function Components?

Why does React officially promote Functional Components? Class Components isn't "unusable".

Because Functional Components are more in line with React's philosophy UI = f(state).

So Hooks came, bringing "internal variables" and "side effects" to Function Components, making them fully functional. it's also a "logical sharing" solution.

2. The problem of Function Components

Because every time the function is called, all the internal variables are created again, which is a bit wrong in the development intuition.

UI = f(state) looks like a pure function, pass state and return UI.

Like rice = electricCooker(rice), but if the electricCooker rebuilds its "circuit system" every time it cooks, it's counter-intuitive.

We hope that f is simply "cooking", and other functions are already "carried" instead of "create" every time.

3. The problem of Hooks

To solve the problem of re-creating variables, React provides useState, useCallback, useMemo, useRef.

State needs to be created with useState. For complex data types (function, array, object) passed to sub-components, use useCallback, useMemo to wrap (for large calculations, use useMemo too). To keep a variable, wrap it with useRef.

In the implementation of useEffect, useCallback and useMemo, there must be a thing called deps.

All the above makes Hooks very counter-intuitive to write. Don't I just use a variable or a function, why do I have to wrap it?

Can't be like Svelte?

2. Solve the Problem

1. The most intuitive UI = f(state):

function Demo(state) {
  return <div>{state.count}</div>;
}

2. This is how React works:

function Demo(props) {
  return <div>{props.count}</div>;
}

3. If the component needs to "carry" state and functions, instead of creating new ones each time, it cannot be written in the component:

let count = 0;
const onClick = () => {
  count += 1;
};

function Demo() {
  return <div onClick={onClick}>{count}</div>;
}

Writing separately destroys the unity, which is not good. Can the component not only hold external variables, but also write them in one function?

4. Naturally, we thought of closure (note that the component are returned internally):

function createDemo() {
  let count = 0;

  const onClick = () => {
    count += 1;
  };

  return function Demo() {
    return <div onClick={onClick}>{count}</div>;
  };
}

const Demo = createDemo();

Now the onClick function will never be re-created, so no need to wrap it with useCallback. With closure, we successfully lifted the dependency on useCallback.

But closure has one problem: all component instances share one piece of data. Of course this is incorrect.

5. Solve the data sharing problem of closure, generate its own data for each component instance dynamically:

const create = (fn) => (props) => {
  const [ins] = useState(() => fn());
  return ins(props);
};

function demo() {
  return () => <div />;
}

const Demo = create(demo);

So far, I'm actually finished... Huh? How to use this component?!

3. Make Abilities Complete

1. Solve useState and component update:

const create = (fn) => (props) => {
  const [, setState] = useState(false);

  const [ins] = useState(() => {
    const atom = (initState) => {
      return new Proxy(initState, {
        get: (target, key) => target[key],
        set: (target, key, val) => {
          target[key] = val;
          setState((s) => !s);
          return true;
        },
      });
    };
    return fn({ atom });
  });

  return ins(props);
};

function demo({ atom }) {
  const state = atom({
    count: 0,
  });

  const onClick = () => {
    state.count += 1;
  };

  return () => {
    const { count } = state;
    return (
      <>
        <h1>{count}</h1>
        <button onClick={onClick}>Click me</button>
      </>
    );
  };
}

const Demo = create(demo);

Use create function to pass in the responsive data generation function atom from the parameters, which can be used to generate the responsive state.

As a result, we successfully lifted the dependency on useState.

Above is already a usable component, try it here: codesandbox.io/s/react-split-components-1-ycw80

2. Solve useMemo, useRef, solve props:

function demo({ props, atom }) {
  const state = atom({
    count: 0,
    power: () => state.count * state.count,
  });

  const countRef = { current: null };

  const onClick = () => {
    const { setTheme } = props;
    setTheme();

    state.count += 1;
    console.log('countRef', countRef.current);
  };

  return () => {
    const { theme } = props;
    const { count, power } = state;

    return (
      <>
        <h1>{theme}</h1>
        <h1 ref={countRef}>{count}</h1>
        <h1>{power}</h1>
        <button onClick={onClick}>Click me</button>
      </>
    );
  };
}

const Demo = create(demo);

Pass props implemented by Proxy from the function parameters.

Because variables are re-created every time, so wrap them with useMemo and useRef before, with closure, it is no longer needed, variables will never be re-created, and the component naturally hold the updated values of variables.

And the similar monitoring mechanism of useMemo, Proxycan be used to support computed data type inatom.

Therefore, we successfully lifted the dependence on useMemo and useRef.

Try the above code here: codesandbox.io/s/react-split-components-2-wl46b

3. Solve useEffect:

function demo({ atom, onMount, onEffect }) {
  const state = atom({
    loading: true,
    data: null,
  });

  const getData = () => {
    request().then((res) => {
      state.data = res.data;
      state.loading = false;
    });
  };

  const onReload = () => {
    state.loading = true;
    getData();
  };

  onMount(() => {
    console.log('mounted!');
    getData();
  });

  onEffect(state.data, (val, prevVal) => {
    console.log('state.data', val, prevVal);
  });

  return () => {
    const { loading, data } = state;

    return (
      <>
        <h1>{loading ? 'loading...' : JSON.stringify(data)}</h1>
        <button onClick={onReload}>Reload data</button>
      </>
    );
  };
}

const Demo = create(demo);

Pass onMount and onEffect from the function parameters.

onMount is called during mount with only one callback function parameter. onEffect has two parameters. The first is the data to be monitored. When the data changes, the callback function of the second parameter will be called.

Both onMount and onEffect support similar to useEffect to clean-up side effects (such as unsubscription) in the returned function.

onEffect only supports monitoring one single props.xxx or state.xxx, because props and state are responsive data, and the data in all callback functions can always be up-to-date, so there is no need to put in deps to receive update. Monitoring one single data change can clearly indicate the source of the data change that "logical processing" relies on, thereby making the code clearer.

As a result, we successfully lifted the dependency on useEffect.

Try it here: codesandbox.io/s/react-split-components-3-zw6tk

Example of using onEffect to implement subscription: codesandbox.io/s/react-split-components-4-y8hn8

4. Other Hooks

So far, we have solved useState, useEffect, useCallback, useMemo, useRef, these are the most commonly used in development. There are 5 remaining official Hooks: useContext, useReducer, useImperativeHandle, useLayoutEffect, useDebugValue, I won't deal with them one by one.

4. Introducing React Split Components (RiC)

Just like Higher-Order Components, this design pattern needs a name.

Considering that closure splits "variables + logics" and "component code", learning the naming style of React Server Components, I named it React Split Components, which can be abbreviated as RiC, the small i here is a good expression of the "split" feature (Mainly after searching, I found that RSC, RPC, RLC, RTC are all occupied. Oh, the "split" has only 5 letters.).

Features of React Split Components:

1. Remove the dependence on Hooks, but not purely Functional Components

Through closure, no Hooks are required to wrap. This allows React developers to free themselves from the "counter-intuition of Functional Components" and "cumbersomeness of Hooks" and write pure JS intuitive code similar with Svelte.

After all, closure is a natural feature of JS.

2. Only at the writing level, no need for ESLint support

In fact, when designing the implementation of useEffect, I thought of a way to use existing code: change useEffect(fn, deps) to watch(deps, fn). But if like this, the deps of watch will need an ESLint plugin to support (because Hooks deps needs plugin support, otherwise it will easy to make mistake).

If not necessary, do not add entity. We want to achieve as natural as possible, as simple as possible, as intuitive as possible.

3. Like High-Order Components, it's a "design pattern", not API, no lib needed

It's not an official React API, doesn't need to be support by building tools (such as React Server Components), doesn't need 3rd-party lib support (create can be encapsulated to a npm package, but considering that everyone has different habits and needs, you can implement the helper function yourself, the above code can be a reference).

React Split Components final code demo: codesandbox.io/s/react-split-components-final-9ftjx

5. Hello, RiC

Look at React Split Components (RiC) example again:

function demo({ atom }) {
  const state = atom({
    count: 0,
  });

  const onClick = () => {
    state.count += 1;
  };

  return () => {
    const { count } = state;
    return (
      <>
        <h1>{count}</h1>
        <button onClick={onClick}>Click me</button>
      </>
    );
  };
}

const Demo = create(demo);

GitHub: github.com/nanxiaobei/react-split-components