Comparison with related projects

[dai-shi]

	Context value	Using subscriptions	Optimization for rendering big object	Dependencies	Package size
react-tracked	state-based object	Yes *1	Proxy-based tracking	No	1.5kB
constate	state-based object	No	No (should use multiple contexts)	No	329B
unstated-next	state-based object	No	No (should use multiple contexts)	No	362B
zustand	N/A	Yes	Selector function	No	742B
react-sweet-state	state-based object	Yes *3	Selector function	No	4.5kB
storeon	store	Yes	state names	No	337B
react-hooks-global-state	state object	No *2	state names	No	913B
react-redux (hooks)	store	Yes	Selector function	Redux	5.6kB
reactive-react-redux	state-based object	Yes *1	Proxy-based tracking	Redux	1.4kB
easy-peasy	store	Yes	Selector function	Redux, immer, and so on	9.5kB
mobx-react-lite	mutable state object	No *4	Proxy-based tracking	MobX	1.7kB
hookstate	N/A	Yes	Proxy-based tracking	No	2.6kB

• *1 Stops context propagation by calculateChangedBits=0
• *2 Uses observedBits
• *3 Hack with readContext
• *4 Mutation trapped by Proxy triggers re-render

[dai-shi]

state value/object

Hm, I think context value in constate and unstated-next is state-based object as well. More precisely, output of useValue hook.

Updated.

[dai-shi]

Benchmark results for react-tracked, reactive-react-redux and react-redux.
the forked repo

[theKashey]

Could you please add https://github.com/atlassian/react-sweet-state to the comparison

[dai-shi]

Added in the table. (Do you also mean to the benchmark?

[theKashey]

To be honest I am more concerned about API and edge cases, as long as the majority of the work I am doing is faaaaaaaaar from real time.
Performance should not be terrible. Performance should not degrade due to application size or developer mistakes.

[dai-shi]

I wonder how you would evaluate edge cases...

[theKashey]

All alternate state managers were created to solve some edge cases. You may try to figure out that problem (and in which way) some library was intended to solve, and try to apply the same case to another library)
Usually:

• cascade update progression
• componentization (aka isolation or microfrontends)
• verbosity
• working in a big team
• working with a big state
• frequent updates
• derived data generation
• stability and predictability
• learning curve
• more to come

[dai-shi]

There was a misunderstanding of mine about react-sweet-state. It uses readContext. Modified.
The README doesn't show the container. It can be used without Context.Provider because it reads the context default value.

Yeah, zustand by @drcmda is only a popular library with non-context solution. I've seen small/experimental libraries without context though.

[dai-shi]

I made a minimal example to compare actual bundle size with some libraries.

Build JS sizes

$ cd examples/counter-react-tracked
$ wc build/static/js/*.js
       1    2263  123254 build/static/js/2.0c3afdb5.chunk.js
       1      16    1066 build/static/js/main.088f65ad.chunk.js
       1      37    1502 build/static/js/runtime~main.a8a9905a.js
       3    2316  125822 total

$ cd examples/counter-constate
$ wc build/static/js/*.js
       1    2190  120150 build/static/js/2.f7ca4f1e.chunk.js
       1      16    1109 build/static/js/main.e21dfac9.chunk.js
       1      37    1502 build/static/js/runtime~main.a8a9905a.js
       3    2243  122761 total

$ cd examples/counter-zustand
$ wc build/static/js/*.js                  
       1    2222  121214 build/static/js/2.20ef84af.chunk.js
       1      18    1079 build/static/js/main.44ecf751.chunk.js
       1      37    1502 build/static/js/runtime~main.a8a9905a.js
       3    2277  123795 total

$ cd examples/counter-reactive-react-redux
$ wc build/static/js/*.js
       1    2976  148172 build/static/js/2.40846575.chunk.js
       1      18    1117 build/static/js/main.e8a6d259.chunk.js
       1      37    1502 build/static/js/runtime~main.a8a9905a.js
       3    3031  150791 total

	JS file size (bytes)	Diff (bytes)
react-tracked	125,822	+3,061
constate	122,761	0
zustand	123,795	+1,034
reactive-react-redux	150,791	+28,030

[dai-shi]

https://github.com/reusablejs/reusable by @adamkleingit and @morsdyce
This is a bit different from others. In terms of its implementation, the context value is multiple stores. Looks to me like multiple constate instances + selector interface. Interesting.

[avkonst]

You may want to include https://github.com/avkonst/react-use-state-x to your research too. It is tiny, type-safe, feature-rich useState-like React hook to manage complex state (objects, arrays, nested data, forms) and global stores (alternative to Redux/Mobx). It's size is reported here: https://bundlephobia.com/[email protected] but it includes Typescript headers too.

[avkonst]

It would be interesting to see it's performance, but I have not done much about optimising the linear performance. I was more focused on reducing number and "size' of renders on state changes.

[theKashey]

react-powerplug in hooks form 👍

[dai-shi]

@avkonst If I understand your implementation correctly, Observer triggers re-render for any state change. That’s just like the normal context. So, I might be misunderstanding something. It would be nice if there were a minimal example in codesandbox for global state.

[dai-shi]

Where can I find react-powerplug hooks form?

[avkonst]

Yes, you are right. Observer is essentially a context provider. React knows nested components dependent on the context. The ones which call useStateLink in our case. You can use the same observer multiple times, in the deeply nested hierarchy of Dom tree. Change in the global state will trigger context change for all the observers of the linked / related store. You can also have multiple global stores. For example one about user state, another about apps settings,etc. In this case observers of the affected by a change store will trigger rerender, but not the other.

…

On Thu, 11 Jul 2019, 21:24 Daishi Kato, ***@***.***> wrote: @avkonst <https://github.com/avkonst> If I understand your implementation correctly, Observer triggers re-render for any state change. That’s just like the normal context. So, I might be misunderstanding something. It would be nice if there were a minimal example in codesandbox for global state. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1?email_source=notifications&email_token=AA6JSVJUDXN23CYELBX4YXTP6333DA5CNFSM4HZBGGMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZWDCBQ#issuecomment-510406918>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA6JSVKHZ2YTULALRANFMHLP6333DANCNFSM4HZBGGMA> .

[theKashey]

So not quite “tracked” ;)

[avkonst]

For your table for react-use-state-x.
Context value in the internals of the implementation is a reference to the global state object. ValueLink returned by useStateLink, knows how to trace and unpack this reference in order to return the actual state value.
There are no dependencies.
Size is 2kb zipped, includes typescript headers, which should not be counted.
Optimisations for big object are:
Cache of nested value in the ValueLink instance.
Use multiple independent stores.
Use multiple observers deeper in the hierarchy instead of a top level single one context provider.
Use derived state link to manage local component statendependent on the global. See docs with the example about it.

[avkonst]

The change to the value in the store is done via ValueLink set API, it is not js proxy and has got other functions, eg validate state according to user's validators.

[dai-shi]

So, If I were to add an item:

	Context value	Using subscriptions	Optimization for big state object	Dependencies	Pakage size
react-use-state-x	mutable reference to state object (which is basically equivalent to store)	Yes (observer pattern?)	Multiple stores	No	2.9kB

Don't worry too much about the bundle size. Mine also includes unused functions. If you are interested, create a simple counter example and compare.

As far as I understand, your library focuses on mutating state in a good way.
My comparison table is about re-renders for state updates. (no mutation in mind)

---

That said, I'm getting to understand your lib. useStateObject and useStateArray are easier to get.
Whereas useStateLink looks a bit complex to me, maybe because I'm not very used to observer.
BTW, if you are OK with using Proxy, link.value can do the same job of link.nested, something like immer but different. (Ah, is it like MobX?)

[avkonst]

The table addition looks good. You may expand optimisations column like 'multiple stores, multiple deeper placed observers/contexts, derived per component local state cache' useStateLink link is effectively useState which returns a ValueLink with value and set properties instead of an array of value and set function. If useStateLink is called to bind with global store, it returns ValueLink to mutate the global store. Observer is not influencing the design of the ValueLink, it is built on top of it. Main complexity of the ValueLink is due to strict typesafety for value access and mutation ops. I guess it could be implemented using proxy, but it would be a problem to support validation features this way. Also I like the idea of separate explicit 'set' action, which I know should be called in reactions but not during render. Hope it helps.

…

On Thu, 11 Jul 2019, 23:19 Daishi Kato, ***@***.***> wrote: So, If I were to add an item: Context value Using subscriptions Optimization for big state object Dependencies Pakage size react-use-state-x <https://github.com/avkonst/react-use-state-x> mutable reference to state object (which is basically equivalent to store) Yes (observer pattern?) Multiple stores No 2.9kB ***@***.***> Don't worry too much about the bundle size. Mine also includes unused functions. If you are interested, create a simple counter example and compare <#1 (comment)> . As far as I understand, your library focuses on mutating state in a good way. My comparison table is about re-renders for state updates. (no mutation in mind) ------------------------------ That said, I'm getting to understand your lib. useStateObject and useStateArray are easier to get. Whereas useStateLink looks a bit complex to me, maybe because I'm not very used to observer. BTW, if you are OK with using Proxy, link.value can do the same job of link.nested, something like immer but different. (Ah, is it like MobX?) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1?email_source=notifications&email_token=AA6JSVO5UA5ZOYDPD4LUNBTP64JM5A5CNFSM4HZBGGMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZWMJRQ#issuecomment-510444742>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA6JSVJVCCLYVNVCRQLBOCDP64JM5ANCNFSM4HZBGGMA> .

[avkonst]

In relation to your question about nested. It is not like mobx. Mobx required required a lot more boilerplate. Nested and inferred functions of ValueLink are described in the documentation. If it was not needed to develop strongly typesafe API, the ValueLink could combine all properties from nested and inferred, but I see it is a disadvantage to blur the type of the value and mutation ops allowed over this value.

…

On Thu, 11 Jul 2019, 23:53 Andrey Konstantinov, ***@***.***> wrote: The table addition looks good. You may expand optimisations column like 'multiple stores, multiple deeper placed observers/contexts, derived per component local state cache' useStateLink link is effectively useState which returns a ValueLink with value and set properties instead of an array of value and set function. If useStateLink is called to bind with global store, it returns ValueLink to mutate the global store. Observer is not influencing the design of the ValueLink, it is built on top of it. Main complexity of the ValueLink is due to strict typesafety for value access and mutation ops. I guess it could be implemented using proxy, but it would be a problem to support validation features this way. Also I like the idea of separate explicit 'set' action, which I know should be called in reactions but not during render. Hope it helps. On Thu, 11 Jul 2019, 23:19 Daishi Kato, ***@***.***> wrote: > So, If I were to add an item: > Context value Using subscriptions Optimization for big state object > Dependencies Pakage size > react-use-state-x <https://github.com/avkonst/react-use-state-x> mutable > reference to state object (which is basically equivalent to store) Yes > (observer pattern?) Multiple stores No 2.9kB > ***@***.***> > > Don't worry too much about the bundle size. Mine also includes unused > functions. If you are interested, create a simple counter example and > compare > <#1 (comment)> > . > > As far as I understand, your library focuses on mutating state in a good > way. > My comparison table is about re-renders for state updates. (no mutation > in mind) > ------------------------------ > > That said, I'm getting to understand your lib. useStateObject and > useStateArray are easier to get. > Whereas useStateLink looks a bit complex to me, maybe because I'm not > very used to observer. > BTW, if you are OK with using Proxy, link.value can do the same job of > link.nested, something like immer but different. (Ah, is it like MobX?) > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#1?email_source=notifications&email_token=AA6JSVO5UA5ZOYDPD4LUNBTP64JM5A5CNFSM4HZBGGMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZWMJRQ#issuecomment-510444742>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AA6JSVJVCCLYVNVCRQLBOCDP64JM5ANCNFSM4HZBGGMA> > . >

[dai-shi]

Will add it to the comparison table.
The optimization column is about rendering state (not clearly stated though),
so your point should be in another column, but I don't create a new column at the moment.
(Maybe, I should limit the table for Redux-inspired/reducer-oriented libraries.)

I think I understand your point. As you may know my another library react-hooks-global-state has type-safe mutation but just for a (shallow) object, so it's like your useStateObject. And, you are basically doing it recursively for a nested object. That could be tough for typing.

Speaking of types, I found typing in immer works well. I didn't realize Proxy helps typing mutation operations.
Speaking of immer, have you looked into easy-peasy? It might be close to your mind set. (But, it's action based, so slightly different.)

I have an interesting idea, If you expose a custom hook for local state, it can work with react-tracked nicely. Wait a minute, you already have one useLocalStateLink. Let me try creating an example.

[dai-shi]

https://codesandbox.io/s/react-tracked-example-trb02
There you go. Enjoy.

---

If you understand what's going on, here's my suggestion: if you focus on creating a custom hook for local state that has handy setter (with typing), you can turn into global state with react-tracked, constate or anything you like. As I guess typed setters are the strength of your library, let the job for global state out.

[avkonst]

Thanks. I will have a look. I do not understand now how usetracked hooks into ValueLink :)
Regarding optimisations, I tend to use multiple stores instead of multiple contexts. These are two different optimisations with different effect.

[avkonst]

I understand your lib uses undocumented internal API. I am a bit concerned that it maybe gone in the future... What do you think?

[dai-shi]

I'd expect when they obsolete the unstable API, a new proper API will be provided.
If that's not the case, still I could implement without context and only with subscriptions (like zustand), but not sure it will be concurrent mode friendly.

multiple stores / multiple contexts

If I understand correctly, if one uses multiple stores, they will use context provider for each store (in this case a Observer is a provider). I guess we are talking about the same thing. There are rendering optimization and mutation optimization. The comparison table is only about the former.

You could put multiple stores in a context (see reusable), but it doesn't seem to be so in your lib.

[avkonst]

OK. I see what you are doing in your library. Tracking of used within a component props matched with detected changes to force update for the affected subscribers. I think tracking has got the potential.

I have tried the approach with subscribers in the past (just subscribers, not the tracking) and got performance issues on the use case like this (it is artificial to demonstrate what happens when nested components rerender too):

const ComponentA = (props: { depth: number }) => {
    const state = useTrackedState();
    if (props.depth > 100) {
        return <></>;
    }
    return <><p>{props.depth}</p><ComponentA depth={props.depth + 1} /></>
}

I found that plain rerender all down to from the context provider works faster in this case.

I have tried observedBits feature of react to learn what it does. I see that observedBits do not make any effect, because the root level state change causes full tree rerender.

• Could you please help me to understand why observedBits do not make any effect? (playground is here: https://codesandbox.io/s/react-tracked-example-j4o93 - I think it does the same as yours react-hooks-global-state except no name tracking, just hard coded bits).
• How should I use context provider and useContext to trigger rerender of only components which use the context but not of the full tree?

[dai-shi]

It will not loose typing.

Oh, yes. You are totally right. That's my bad.

But it will have other disadvantages.

Would you look into MobX and see how they solve the issues, or not?

[avkonst]

I have used Mobx previously and seen that their Observer triggers rerender for every component where the state is used, regardless of what is being used. Maybe it changed recently. That is why I asked the link to the Mobx benchmark test to learn how they do it. Do you have this benchmark test code for Mobx or not? "Would you look into MobX and see how they solve the issues, or not?" What do you mean? What would you like me to look at?

…

On Fri, Aug 16, 2019 at 11:23 AM Daishi Kato ***@***.***> wrote: It will not loose typing. Oh, yes. You are totally right. That's my bad. But it will have other disadvantages. Would you look into MobX and see how they solve the issues, or not? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1?email_source=notifications&email_token=AA6JSVN4VOIBPQLFYZSQUT3QEXQORA5CNFSM4HZBGGMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4NIEWI#issuecomment-521831001>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA6JSVNE3VOYLWDHETGJUOLQEXQORANCNFSM4HZBGGMA> .

[dai-shi]

I personally didn't write any benchmark code for MobX.
I tried mobx-react-lite and knew it would only trigger render for the parts changed.

But, the point I'm raising is not about the render part, but the mutation part.

What do you mean? What would you like me to look at?

I didn't yet fully understand all "disadvantages" you mentioned.
Wondered if it's solved in MobX or not.
If it's solved, you learn from it. If not, that's the point your lib beats MobX, right?
(And, if you already have an answer, no need to look at.)

[avkonst]

"... all "disadvantages" you mentioned. Wondered if it's solved in MobX or not."
It is not solved in MobX, they just do not have some of the features of the Hookstate, it is not their scope, eg. valuelink pattern for state 'leaves', various features like validation, etc.. For example, I have no idea how to put Performance metrics counter with Mobx similar to the one I put for Large Table performance demo. This is maybe where Hookstate beats Mobx.
However, I guess the main point where Hookstate beats Mobx is the following. As far as I understand, Mobx optimizes the rendering only when it is used like this by multiple consuming components. That is all clear, implementation is based on components putting global state subscribers. As far as I understand Mobx does not provide the analogy of this one or this one. It will rerender the whole upper lever state consuming component. Maybe I am missing something and Mobx can do this too, but I have not found how to achieve the same with Mobx. So, I asked if you have got some benchmarks.

[dai-shi]

Thanks for the explanation.
Unfortunately again, I don't have any benchmarks.

[avkonst]

They tell here https://mobx-react.js.org/observer-hook:
Despite using useObserver hook in the middle of the component, it will re-render a whole component on change of the observable. If you want to micro-manage renders, feel free to use or useForceUpdate option (for advanced users).
But I can not understand how a client can achieve it and how not to mess up with optimization, which could result in missed rerendering.

[dai-shi]

The reason I thought the benchmark target of your lib is MobX, is about mutations not renders.
But, it seems that it's not the case, so you might not need to compare with MobX.

[avkonst]

I have thought about putting the same large table performance demo using Mobx to compare, but I have not figured out how to achieve it with Mobx :) It seems like each table cell should be a consumer of the global state to make sure only the affected cells are rerendered, or there is another way?

[dai-shi]

I'm willing to help to compare with react-tracked. 😄
Honestly, I'm not very familiar with MobX and I did have a misconception before, so I can't be of much help.

[avkonst]

"I'm willing to help to compare with react-tracked. 😄"
Yes, I will be glad to see the results! And the benchmark code base.

[avkonst]

Hi @dai-shi Hookstate now supports IE11 via @hookstate/proxy-polyfill plugin. Example project is here. Could you please let people know, who were interested in ES5 compatible state management system with usage tracking support. Thanks.

[dai-shi]

I don’t read the code as I’m on vacation now, but do you deal with non-get proxy handlers?
I don’t know anybody who would be interested in your lib with proxy-polyfill. Sorry about that.

[avkonst]

I provide custom proxy-polyfill which supports only get method needed for the Hookstate core. It is as simple as: ``` function ProxyImpl(target, handler) { this.target = target; if (Array.isArray(target)) { return target.map((e,i) => handler.get(target, i)); } else { const result = {}; Object.keys(target).map(k => { result[k] = handler.get(target, k) }) return result; } } ``` "I don’t know anybody who would be interested in your lib with proxy-polyfill" - you said you had requests for your library to work without Proxy, so I though you captured this interest and connections. If not it is ok. It was an exercise to see how much the hookstate needs to run in IE11.

…

On Tue, Aug 27, 2019 at 6:50 PM Daishi Kato ***@***.***> wrote: I don’t read the code as I’m on vacation now, but do you deal with non-get proxy handlers? I don’t know anybody who would be interested in your lib with proxy-polyfill. Sorry about that. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1?email_source=notifications&email_token=AA6JSVJRRHSP6FGYZG6K2FDQGTFDVA5CNFSM4HZBGGMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5GWCYI#issuecomment-525164897>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA6JSVN56EQ3BRNO6VHOIOLQGTFDVANCNFSM4HZBGGMA> .

[dai-shi]

Interesting. So, you don’t use/need google lab’s proxy-polyfill.

There was a general discussion whether proxy can be polyfilled for IE11 in the Redux community.

[avkonst]

Could you give me a link to this discussion?

…

On Tue, 27 Aug 2019, 20:18 Daishi Kato, ***@***.***> wrote: Interesting. So, you don’t use/need google lab’s proxy-polyfill. There was a general discussion whether proxy can be polyfilled for IE11 in the Redux community. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1?email_source=notifications&email_token=AA6JSVOK7QBL75ISX6SHWQTQGTPPDA5CNFSM4HZBGGMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5G5I5I#issuecomment-525194357>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA6JSVPPE5ETSOIC76YQRS3QGTPPDANCNFSM4HZBGGMA> .

[dai-shi]

I don’t have the link right now, but it’s the long discussion about hooks.

By the way, if you can implement your lib without proxies that easy, you wouldn’t need proxies from the start, would you? That might be simpler.

[dai-shi]

Let’s continue the discussion in avkonst/hookstate#6

I will close this issue later as it becomes very long mostly discussing about hookstate.

[dai-shi]

Copied the table in README.

[bySabi]

@dai-shi can you add hookleton and garfio to the comparison table?

author here.

[dai-shi]

@bySabi Thanks for coming here.
Unfortunately, if I were to add your libs, there would be so many other libs I would need to consider.

If there's a huge demand on a comparison table, I should probably start a new repo. Hm, that would not be a bad idea. I could add more columns to compare. Adding benchmarks would also be nice.

---

BTW, your implementation of

const forceUpdate = s => ~s;

might have an issue with batched updates.

[bySabi]

@dai-shi thanks for take the time for look at the code. Please ping me when the new comparison repo is done.

I also thought that s => ~ s might have problems with the batch update but in practice I haven't had any.
I have not looked at the React code to know how the algorithm works in detail.
In my case the state changes using the sequence "infinite" -1 0 -1 0 -1 ... I don't think React risks ignoring such a simple state change.
The other solutions out there like: !BOOLEAN and even increasing a counter could have the same problem of ignoring changes of state.
What solution do you propose?

[dai-shi]

I used to use s => !s but there was an issue reported. If you update twice in a single batch, React "bails out" rendering and users won't see the update. This issue is easily reproducible. Just update 2x times in a batched callback.

Now, I use s => s + 1 in my libs. This is not infinite as you may imply.
More precisely, it should be s => s === Number.MAX_SAFE_INTEGER ? Number.MIN_SAFE_INTEGER : s + 1, maybe?

[bySabi]

I imagine you don't have the link to the issue at hand :-)? ... I would like to try an issue repo

s => s === Number.MAX_SAFE_INTEGER? Number.MIN_SAFE_INTEGER: s + 1
It would be the most purist but the least performant :-)

Now that I am looking at how to add Typescript support, I will probably update forceUpdate

[dai-shi]

I imagine you don't have the link to the issue at hand :-)?

Let me see...

dai-shi/reactive-react-redux#20 (comment)
dai-shi/reactive-react-redux@c9132a9

Here you go.

[bySabi]

Thanks for the link, they have been useful to understand the problem.

Well, it seems that in my case the 'forceUpdater' s => ~ s is not a problem because it is called from a useMemo that "observes" the changes in the user's provided hook output so React is in charge of tracking, and Batching is desirable. https://github.com/bySabi/hookleton/blob/master/src/index.js#L51

Using s => s + 1 does not change anything, in my case. Just as in this example:

import React from 'react';

const App = () => {
  const [s, forceUpdate] = React.useReducer(s => ~s);
  //const [s, forceUpdate] = React.useReducer(s => s + 1, 0);

  console.log('render: ', s); // should be out: "render 0"

  React.useMemo(() => {
     forceUpdate(); // should be out: "render 1"  -- NOT RENDERED --
  }, []);
  React.useMemo(() => {
     forceUpdate(); //should be out: "render 2"
  }, []);

  return null;
}

export default App;

When I create hookleton I try to make it completely user's hook output transparent and let the React "hook" engine do all the work.

Although surely there is something that escapes me. The code needs other hawk eyes :-)

Thanks for your time.

[dai-shi]

@bySabi Hi, I created a new repo. https://github.com/dai-shi/lets-compare-global-state-with-react-hooks

[RayaneNekena]

@dai-shi It's a really interesting benchmark. I'm a React developer but I'm a beginner in terms of measuring performance. How did you make them ? How do you know which features to compute and how did you calculate them ? I want to know how to make a performance evaluation of a library or tools like that.

Benchmark results for react-tracked, reactive-react-redux and react-redux. the forked repo

[dai-shi]

It's https://github.com/krausest/js-framework-benchmark.