Other discussions around auto-detecting Redux state usage about reactive-react-redux

[dai-shi]

Just a note: based on facebook/react#14110 (comment), I ended up with the normal Redux subscriptions.

I'd probably need to do some benchmarks how slow this proxy approach is compared to react-redux.

[theKashey]

Let me try to run some performance tests. Could you share your benchmark as is?

[theKashey]

:nods: so, by removing concatenation (as long as it's a lazy operation nowadays) you are skyrocketing it yet again. Pretty sure - that's enough :)

[theKashey]

Not so fast :) I am on offline vacations for a week.

…

On Thu, 10 Jan 2019 at 23:54, Daishi Kato ***@***.***> wrote: Results for benchmark tree-view-rher with the patch: ┌─────────┬───────────┬───────────┬──────────┬──────────────────────────────────────────────────────────────────────────┐ │ Avg FPS │ Scripting │ Rendering │ Painting │ FPS Values │ ├─────────┼───────────┼───────────┼──────────┼──────────────────────────────────────────────────────────────────────────┤ │ 13.12 │ 25649.44 │ 1240.48 │ 95.50 │ 1,11,15,14,16,17,19,10,13,11,16,7,15,16,19,16,15,2,17,16,13,7,12,14,10,7 │ └─────────┴───────────┴───────────┴──────────┴──────────────────────────────────────────────────────────────────────────┘ Pretty sure I did something wrong... Could you check it? diff2.txt <https://github.com/dai-shi/react-hooks-easy-redux/files/2745321/diff2.txt> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAjjCmhtiEYeFvgLvfjQcvcQNBKEl51Pks5vBzf4gaJpZM4YgQKm> .

[dai-shi]

@buzinas
Yes, it's tree-view-rher. It's up-to-date. The result is of v0.9.1.
Yes, v1.0.0 is supposed to be production ready.

---

It's interesting because I was just planning to do these before I got your comment.

• file a new issue for benchmark, and run it for v1.0.0 again.
• release v1.1.0 today and run the benchmark.

[smashercosmo]

@dai-shi nope, sorry, has zero experience in this field) Just thought it might be interesting for you.

[dai-shi]

@faceyspacey Thanks! I started this project with the mind that Redux should be easier for beginners, but you implied that it could be used in a broader way. That sounds exciting.

@theKashey already replied, but quoting his comment again, we are not yet ready for rest/spread.
I haven't thought much about it so far, but I will take some time to think about it as now it's clearer to me that rest/spread is important.

I don't know other unsupported edge cases at the moment, but I didn't obviously cover cases exhaustively.

[theKashey]

Meanwhile - rest was a problem for mapStateToProps realization, when you might want return/inject some slices from state as props.
With this approach, you are just "reading" from state inside component, as you wanted to do, and no need to rest.

const MyComponent = (props, state, actions) => ...
const MyComponentDestructured = (props, { foo } , actions) => ...

const RemixxComponent = (props) => {
  const state = useReduxState();
  const dispatch = useReduxDispatch();
  return MyComponent(props, state, dispatch);
};

🚀?

[theKashey]

I use selectors, I love selectors for memoization, "scoping" and testability. And preparing a small update for reselect with WeakMaps and Hooks in mind.

Selectors ARE the API.

[theKashey]

Sounds like we should have a series of experiments. Another, not bad, option would be - useMemo

const MyRemixxComponent = (props, state, actions) => {
  const val = state.mySelector(props)
  const render = useMemo(() => <div>{val}</div>, [val]);
  return render();
}

So - you will be able to bialout render by returning exactly the same return, and es-lint(not babel, not proxy!) would help properly pass down all the props you need.

The memoization quality could be easily tested by Remixx, but calling a function twice.

[theKashey]

const wrapSelector = selector => {
   const fn = (state, ...args) => selector(proxy(state), ...args);
   fn.getAffected = proxy.getAffected.....
   return fn;
}
const createSelector = (...args) => wrapSelector(realCreateSelector(...args));

@dai-shi - you may proxy proxied state. With some extension to your spread PR one could disable tracking on the parent proxy while selector is working to make result more pure.

[faceyspacey]

yes, my friend, it's a chance for your work to be way bigger than something for "beginners" as you initially imagined it. And at the very least, it allows you to solve the selectors issue, not just reducers. That makes your lib extremely powerful. Of course a redux fork must be used, but that's where the magic begins.

[dai-shi]

@markerikson Thanks! I'll look into those discussion.

[dai-shi]

@theKashey's proxyequal seems great. Let me try incorporating it.

[dai-shi]

Works like a charm. Thanks tons, @theKashey.

[theKashey]

😄 😃 😀

[dai-shi]

A deadly simple React bindings library for Redux with Hooks API
Just wrote a short introductory article.

[dai-shi]

I've been thinking a bit how this approach can be embeded in the official react-redux, but I'm not sure what would be appropriate.

but apparently there's a number of difficult edge cases.

Maybe, there's something I don't yet understand. There should be many edge cases, but what woud be the most critical ones?

[theKashey]

I would like to see some implementation details in the article.
Meanwhile:

1. Why you need bailOut hack? It would be great to utilise React.memo. Actually I am not sure this is easy doable with hooks.
2. You are not handling some edge cases, when you are reading not a POD type, an object for example, and passing it to another component. You have to “deproxify” all the props in the result (you can do it inside bailouthack).
   See https://github.com/theKashey/memoize-state/blob/master/src/call.js
3. You should pass a third argument to proxyState to maintain cross-render proxies-object red equality.
4. Selectors, like reselect would be able to work properly after .3, but their memoization would break your one. Like you have 3 selectors, all reading different keys of a object. 2 got memorised and assessing only object, but one is not, and assessing the inner key - only that key would be in affected. 2 would partially fix it. I have a ongoing task for this a wrapper for memoization lib, which will replay the used keys in case of memozation.

The rest is awesome.

[dai-shi]

article

I would like to write one when I got better understanding.

bailOutHack

The original motivation of mine is to avoid memoization (which I found is a rather hard concept for beginners).
After looking at facebook/react#14110, my hope is something like this library and I started experimenting it.

I may misunderstand something. What do you mean by utilising React.memo?

I made a small example with useMemo at https://github.com/dai-shi/react-hooks-global-state/blob/master/examples/11_deep/Person.tsx#L31-L43
Is it related at all? (BTW, this is another probject of mine with the similar motivation, but since it doesn't use Redux, there's nothing to do with this project.)

deproxify

Will look into it.

the third argument & reselect

Thanks. I'll try that.

[theKashey]

Probably the best way is not use use proxyState directly, but via memoize-state, which will handle most of edge cases.
For you - just replace one line by another. See https://github.com/theKashey/beautiful-react-redux/blob/master/src/index.js#L64

[dai-shi]

Thanks for your suggestion.

beautiful-react-redux

Wonderful. Solves the general problem I have in mind.

memoize-state

Starting reading the code.

third argument to proxyState

I got this one.
I woner if "deproxify" is needed if this ProxyMap is kept the same across rendering.

Like you have 3 selectors, all reading different keys of a object. 2 got memorised and assessing only object, but one is not, and assessing the inner key - only that key would be in affected.

Probably because I don't get this one yet. Maybe, I'd write a failing test to better understand the issue.

[theKashey]

const state = {
 a: { 
   value: 1,
   b: {
     value1: 1
  }
}
....
affected - a.value, b.value.
... memoize
affected - a, as long it maintain eq-ref all good. 
... change a.value(changes also a), b is the same
affected - a.value, b

... you know - it would always fallback to the "root node", value of which would be changed due to immutability principles, and never miss the update. Just would be not as precise, as could.

So lets don't call it a problem, while it is not proven.

[dai-shi]

Got that. Not a problem, but not as precise as it could be. Thanks.

[dai-shi]

Well, I was trying twitter-lite benchmark (I don't think it's a good one for this comparison, though),
and found it just doesn't work probably because __proxyequal_scanEnd: "this is secure guard" is enumerable. I need to learn more about this.

[theKashey]

secure guards is a complex thing, and probably a mistake. And probably I should replace them by Symbols, to create a key non-enumerable by loops, but enumerable by spread.

The idea behind is to detect a full object spread and inform dev about deoptimization, or not to track all keys, as long one is tracking a whole object (this never was done).

For now you can disable it (globally) by calling spreadGuardsEnabled(false)

[dai-shi]

@theKashey Thanks so much! It works.

[dai-shi]

I run a benchmark using tree-view.

react-redux 5.0.7

┌─────────┬───────────┬───────────┬──────────┬─────────────────────────────────────────────────────────────────────────────────┐
│ Avg FPS │ Scripting │ Rendering │ Painting │ FPS Values                                                                      │
├─────────┼───────────┼───────────┼──────────┼─────────────────────────────────────────────────────────────────────────────────┤
│ 50.73   │ 9262.02   │ 7520.57   │ 576.89   │ 1,52,51,54,52,43,49,47,48,56,53,50,47,57,49,51,50,57,49,53,54,47,52,54,52,50,42 │
└─────────┴───────────┴───────────┴──────────┴─────────────────────────────────────────────────────────────────────────────────┘

react-hooks-easy-redux 0.8.0

┌─────────┬───────────┬───────────┬──────────┬─────────────────────────────────────────────────┐
│ Avg FPS │ Scripting │ Rendering │ Painting │ FPS Values                                      │
├─────────┼───────────┼───────────┼──────────┼─────────────────────────────────────────────────┤
│ 8.37    │ 28016.50  │ 693.61    │ 51.04    │ 4,5,11,7,6,12,13,6,10,11,10,4,0,7,9,11,5,8,16,8 │
└─────────┴───────────┴───────────┴──────────┴─────────────────────────────────────────────────┘

[dai-shi]

As a comparison, this is a dumb implementation without any bindings, but just use useEffect to subscribe the store and update for any changes.

┌─────────┬───────────┬───────────┬──────────┬──────────────────────────────────────────────────────────────────────────────────┐
│ Avg FPS │ Scripting │ Rendering │ Painting │ FPS Values                                                                       │
├─────────┼───────────┼───────────┼──────────┼──────────────────────────────────────────────────────────────────────────────────┤
│ 29.62   │ 22724.41  │ 3248.64   │ 224.59   │ 22,28,27,30,26,29,31,34,27,26,25,29,23,29,30,27,38,35,33,34,24,27,36,31,22,36,33 │
└─────────┴───────────┴───────────┴──────────┴──────────────────────────────────────────────────────────────────────────────────┘

[theKashey]

:noooooooooooo:

[dai-shi]

No, something is wrong. When I run the dumb version in dev mode, it's almost freezing.

But in prod mode, it's faster. I'm not yet sure what's happening.

[dai-shi]

I don't know why, but the dumb version in production mode is fast contradictory to the intuition. I'm curious about its optimization.

So far, what I found about proxyequal is that proxyState() takes several milliseconds when an object is big. This can be seen to be fair because tree-view is an extreme example. ...What's bothering is that the dumb version actually beats the proxy version.

[theKashey]

Probably I know that's the problem, and I know the way to solve it.

The Problem

You could not establish proxy upon frozen object. That's why it clones it via Object.assign(it's slow).
https://github.com/theKashey/proxyequal/blob/master/src/index.js#L43

if (state.constructor.name === 'Object') {
    const clone = Object.assign({}, state);
   /// ^^ replace this by `const clone = {}`
    Object.setPrototypeOf(clone, Object.getPrototypeOf(state));
    return clone;
}

The solution

Set a prototype for an empty object, and override getOwnKeys to emulate key existence. Just enable spreadGuardsBack, or activate these 3 lines in another way.

Another solution

Detect frozen object, and skip everything for plain ones.

@dai-shi - please monkey patch your version of proxyequal, and if it will help I'll ship a new version.

[dai-shi]

I hope I don't misunderstand anything.
What I did: const clone = {}; if (true || shouldHookOwnKeys) { ... }

before (twice):
┌─────────┬───────────┬───────────┬──────────┬──────────────────────────────────────┐
│ Avg FPS │ Scripting │ Rendering │ Painting │ FPS Values                           │
├─────────┼───────────┼───────────┼──────────┼──────────────────────────────────────┤
│ 6.63    │ 28119.50  │ 606.36    │ 44.71    │ 3,5,6,8,10,12,6,7,10,6,2,0,7,6,7,9,5 │
└─────────┴───────────┴───────────┴──────────┴──────────────────────────────────────┘
┌─────────┬───────────┬───────────┬──────────┬────────────────────────────────────────────┐
│ Avg FPS │ Scripting │ Rendering │ Painting │ FPS Values                                 │
├─────────┼───────────┼───────────┼──────────┼────────────────────────────────────────────┤
│ 7.00    │ 28459.22  │ 763.89    │ 48.56    │ 3,5,6,7,13,9,8,9,8,11,1,3,0,7,8,6,8,5,6,13 │
└─────────┴───────────┴───────────┴──────────┴────────────────────────────────────────────┘

after (twice):
┌─────────┬───────────┬───────────┬──────────┬─────────────────────────────────────────────────────┐
│ Avg FPS │ Scripting │ Rendering │ Painting │ FPS Values                                          │
├─────────┼───────────┼───────────┼──────────┼─────────────────────────────────────────────────────┤
│ 8.00    │ 27645.82  │ 877.30    │ 70.92    │ 1,6,9,13,11,7,9,8,3,5,9,7,4,10,8,5,10,9,10,7,5,9,12 │
└─────────┴───────────┴───────────┴──────────┴─────────────────────────────────────────────────────┘
┌─────────┬───────────┬───────────┬──────────┬───────────────────────────────────────────────┐
│ Avg FPS │ Scripting │ Rendering │ Painting │ FPS Values                                    │
├─────────┼───────────┼───────────┼──────────┼───────────────────────────────────────────────┤
│ 7.15    │ 27425.04  │ 902.62    │ 63.44    │ 1,4,9,7,8,11,4,8,6,9,10,2,3,6,5,8,6,11,8,10,8 │
└─────────┴───────────┴───────────┴──────────┴───────────────────────────────────────────────┘

Although my laptop may not be very stable while running, I see only a slight change.

---

Let me try a bit differently.

with spread guards:
┌─────────┬───────────┬───────────┬──────────┬────────────────────────────────────────┐
│ Avg FPS │ Scripting │ Rendering │ Painting │ FPS Values                             │
├─────────┼───────────┼───────────┼──────────┼────────────────────────────────────────┤
│ 6.47    │ 28246.59  │ 628.99    │ 47.14    │ 3,6,8,7,4,10,9,3,9,10,4,3,0,8,7,6,10,6 │
└─────────┴───────────┴───────────┴──────────┴────────────────────────────────────────┘

with spread guards + `const clone = {};`:
┌─────────┬───────────┬───────────┬──────────┬─────────────────────────────────────────────────┐
│ Avg FPS │ Scripting │ Rendering │ Painting │ FPS Values                                      │
├─────────┼───────────┼───────────┼──────────┼─────────────────────────────────────────────────┤
│ 6.71    │ 27706.79  │ 905.02    │ 70.12    │ 1,4,3,8,7,4,9,10,5,9,4,10,1,3,8,7,8,6,5,10,11,9 │
└─────────┴───────────┴───────────┴──────────┴─────────────────────────────────────────────────┘

Not much difference? Hope these may help...

[dai-shi]

Here you go:

git clone https://github.com/dai-shi/react-redux-benchmarks.git
cd react-redux-benchmarks
npm install
npm run initialize
REDUX=5.0.7 BENCHMARKS=tree-view:tree-view-rher:tree-view-dumb npm start

[theKashey]

Initial:

┌─────────┬─────────┬───────────┬───────────┬──────────┬───────────────────────────────────────────┐
│ Version │ Avg FPS │ Scripting │ Rendering │ Painting │ FPS Values                                │
├─────────┼─────────┼───────────┼───────────┼──────────┼───────────────────────────────────────────┤
│ 5.0.7   │ 6.44    │ 28581.75  │ 604.55    │ 42.48    │ 4,10,8,7,13,8,5,8,7,10,1,2,0,6,7,4,5,10,5 │
└─────────┴─────────┴───────────┴───────────┴──────────┴───────────────────────────────────────────┘

The problem was not in change tracking, but in the change comparison, to be more concrete in the building a list of keys to compare - collectValuables, which uses search-trie underneath.

I've run some perf tests and found a bit quicker solution to build trie(FPS 14), and get data I need from it(20)

┌─────────┬─────────┬───────────┬───────────┬──────────┬────────────────────────────────────────────────────────────────────────────┐
│ Version │ Avg FPS │ Scripting │ Rendering │ Painting │ FPS Values                                                                 │
├─────────┼─────────┼───────────┼───────────┼──────────┼────────────────────────────────────────────────────────────────────────────┤
│ 5.0.7   │ 19.20   │ 22173.94  │ 2957.29   │ 223.88   │ 4,8,17,22,19,15,10,14,22,24,21,18,28,22,10,21,18,22,9,17,24,25,19,24,18,33 │
└─────────┴─────────┴───────────┴───────────┴──────────┴────────────────────────────────────────────────────────────────────────────┘

Still not awesome, but much better than before, as similar as dumb tree:

┌─────────┬─────────┬───────────┬───────────┬──────────┬─────────────────────────────────────────────────────────────────────────────────┐
│ Version │ Avg FPS │ Scripting │ Rendering │ Painting │ FPS Values                                                                      │
├─────────┼─────────┼───────────┼───────────┼──────────┼─────────────────────────────────────────────────────────────────────────────────┤
│ 5.0.7   │ 20.77   │ 23343.37  │ 3144.17   │ 227.37   │ 9,23,27,24,17,22,25,30,27,28,23,21,18,21,24,17,19,23,17,14,15,21,19,18,24,10,13 │
└─────────┴─────────┴───────────┴───────────┴──────────┴─────────────────────────────────────────────────────────────────────────────────┘

New version is published as 2.0.2. You may try on your machine.

PS: without proxyequal, with an update on every change, it gives 12FPS on my machine (MBP mid 2015)

[dai-shi]

Great work. Let me try on my end.

with proxyequal v2.0.1:

┌─────────┬─────────┬───────────┬───────────┬──────────┬──────────────────────────────────────┐
│ Version │ Avg FPS │ Scripting │ Rendering │ Painting │ FPS Values                           │
├─────────┼─────────┼───────────┼───────────┼──────────┼──────────────────────────────────────┤
│ 5.0.7   │ 7.69    │ 27448.93  │ 674.92    │ 47.62    │ 3,7,9,10,8,13,7,8,13,8,3,0,7,8,7,9,6 │
└─────────┴─────────┴───────────┴───────────┴──────────┴──────────────────────────────────────┘

with proxyequal v2.0.2:

┌─────────┬─────────┬───────────┬───────────┬──────────┬─────────────────────────────────────────────────────────────────────────────────┐
│ Version │ Avg FPS │ Scripting │ Rendering │ Painting │ FPS Values                                                                      │
├─────────┼─────────┼───────────┼───────────┼──────────┼─────────────────────────────────────────────────────────────────────────────────┤
│ 5.0.7   │ 15.59   │ 24285.89  │ 2009.59   │ 148.65   │ 1,10,22,25,20,23,6,15,17,13,12,18,16,12,22,23,20,7,12,14,18,17,10,15,7,15,13,19 │
└─────────┴─────────┴───────────┴───────────┴──────────┴─────────────────────────────────────────────────────────────────────────────────┘

Much better. (but, your perf test looks a bit better.)

---

PS: without proxyequal, with an update on every change, it gives 12FPS on my machine (MBP mid 2015)

How is this different from tree-view-dumb?

[theKashey]

How is this different from tree-view-dumb?

19 vs 20 FPS

[dai-shi]

Hm, my previous result was not really stable. Let me again run several times on my machine (MBP 2017).

tree-view-rher: 21 FPS
tree-view-dumb: 31 FPS

[dai-shi]

@theKashey I happened to find // IE11 case is faster on my machine in tree-view-rher.

(A)

if (false && trie.edges.values) {

┌─────────┬─────────┬───────────┬───────────┬──────────┬────────────────────────────────────────────────────────────────────────────────────┐
│ Version │ Avg FPS │ Scripting │ Rendering │ Painting │ FPS Values                                                                         │
├─────────┼─────────┼───────────┼───────────┼──────────┼────────────────────────────────────────────────────────────────────────────────────┤
│ 5.0.7   │ 48.78   │ 19296.74  │ 21.64     │ 16.24    │ 1,48,54,46,47,48,54,49,45,43,46,49,43,54,47,52,49,41,52,56,43,54,48,53,45,55,45,51 │
└─────────┴─────────┴───────────┴───────────┴──────────┴────────────────────────────────────────────────────────────────────────────────────┘

Does it make sense?

(edit) This gives an error when running, so there's probably something wrong.

---

(B)
I further tried to use an iterator returned by values() directly, which results in like:

┌─────────┬─────────┬───────────┬───────────┬──────────┬──────────────────────────────────────────────────────────────────────────────────────────┐
│ Version │ Avg FPS │ Scripting │ Rendering │ Painting │ FPS Values                                                                               │
├─────────┼─────────┼───────────┼───────────┼──────────┼──────────────────────────────────────────────────────────────────────────────────────────┤
│ 5.0.7   │ 30.38   │ 22001.59  │ 3016.81   │ 209.17   │ 1,24,38,36,14,28,34,37,23,42,22,27,36,25,17,28,34,24,34,41,30,38,25,23,43,28,19,30,38,43 │
└─────────┴─────────┴───────────┴───────────┴──────────┴──────────────────────────────────────────────────────────────────────────────────────────┘

(C)
Another trial is to use string.charCodeAt and [[c, node], ...] instead of Object.create() in search-trie:

┌─────────┬─────────┬───────────┬───────────┬──────────┬────────────────────────────────────────────────────────────────────────────────────┐
│ Version │ Avg FPS │ Scripting │ Rendering │ Painting │ FPS Values                                                                         │
├─────────┼─────────┼───────────┼───────────┼──────────┼────────────────────────────────────────────────────────────────────────────────────┤
│ 5.0.7   │ 45.37   │ 18529.40  │ 2281.47   │ 95.50    │ 1,41,46,43,48,33,51,55,41,46,39,55,47,46,40,51,40,55,37,42,51,50,35,43,45,51,48,46 │
└─────────┴─────────┴───────────┴───────────┴──────────┴────────────────────────────────────────────────────────────────────────────────────┘

However, this seems slower in dev mode.

combination of (B) and (C)

┌─────────┬─────────┬───────────┬───────────┬──────────┬───────────────────────────────────────────────────────────────────────────────────────┐
│ Version │ Avg FPS │ Scripting │ Rendering │ Painting │ FPS Values                                                                            │
├─────────┼─────────┼───────────┼───────────┼──────────┼───────────────────────────────────────────────────────────────────────────────────────┤
│ 5.0.7   │ 51.21   │ 15174.46  │ 2653.37   │ 113.78   │ 1,50,45,40,52,53,49,51,36,55,53,54,53,52,56,50,54,52,35,47,52,56,54,56,54,59,54,57,55 │
└─────────┴─────────┴───────────┴───────────┴──────────┴───────────────────────────────────────────────────────────────────────────────────────┘

[theKashey]

🤯could you share the final solution?
I was thinking about removing trie completely, like

const buildTrie = lines => {
const values = new Set();
lines.forEach( line => {
 const chunks = line.split('.');
 chunks.pop(); // remove "last part"
 chunks.reduce( (acc, name) => {
   if(acc) {
     acc = acc+'.'+name;
   } else acc = name;
   
   values.add(acc);
   return acc;
 }, '');
});

// return lines, which does not exists in the values
return lines.filter(line => !values.has(line))
}

[dai-shi]

Here's the patch file against node_modules of the current final solution.

diff.txt

However, this seems slower in dev mode

Ah, it's also slow in prod mode in chrome. I wonder why the benchmark result seems good.
Anyway, this is not good. Let me see...
It was already slow in chrome even without this patch.

Could you try npx http-server runs/tree-view-rher and npx http-server runs/tree-view-dumb and see the difference by clicking "+" please?

[theKashey]

:nods:, I was thinking about flat arrays yesterday. Cool that you already spiked it and got so amazing results.

Meanwhile will try to see the difference

[theKashey]

According to this tests - https://jsperf.com/ltree-test/1 - the code with Set, I posted above, is 2-3 times faster that your one.
Your one(arrays) is 25% faster than initial one, and the same with the "current" one for long strings, but faster on short ones.

[dai-shi]

Good, jsperf is easier to test. (It's been a while since I last used it. It's now totally changed. Requiring GitHub oauth, and no fork?)

Played around a bit based on yours. https://jsperf.com/ltree-test-2/1
We might need the using part after putting for further experiments.

(BTW, I generally prefer array prototypes to for-loops, and I would avoid for-loops whenever possible in my application code...)

[theKashey]

😿 Maps/Sets sucks. Arrays rule.
Probably hash mapping is far more expensive for short data, and in this case it always would be "short".

[dai-shi]

Yeah, we might expect more optimizations by JS engines for maps and sets in the future, though.

[theKashey]

https://jsperf.com/ltree-test-2/5 - Set degrades quickly with more and more data filled in.
Your variant just smashing it in Chrome. In Safari difference is just 10%.

[dai-shi]

https://jsperf.com/ltree-test-2/9
Another trial, but it's not that compelling.

---

Well, more trial. This one is the best so far. https://jsperf.com/ltree-test-3

[dai-shi]

Ah, it's also slow in prod mode in chrome. I wonder why the benchmark result seems good.
Anyway, this is not good. Let me see...

It seems fine now. I probably misunderstood something then.

[dai-shi]

Re-running benchmarks with some variants.

Results for benchmark tree-view:
┌─────────┬───────────┬───────────┬──────────┬───────────────────────────────────────────────────────────────────────────┐
│ Avg FPS │ Scripting │ Rendering │ Painting │ FPS Values                                                                │
├─────────┼───────────┼───────────┼──────────┼───────────────────────────────────────────────────────────────────────────┤
│ 51.71   │ 9230.89   │ 7516.19   │ 569.54   │ 1,55,48,53,51,47,48,51,52,53,44,55,52,53,52,48,54,56,57,47,53,55,54,53,50 │
└─────────┴───────────┴───────────┴──────────┴───────────────────────────────────────────────────────────────────────────┘

Results for benchmark tree-view-rher:
┌─────────┬───────────┬───────────┬──────────┬──────────────────────────────────────────────────────────────────────────────────────┐
│ Avg FPS │ Scripting │ Rendering │ Painting │ FPS Values                                                                           │
├─────────┼───────────┼───────────┼──────────┼──────────────────────────────────────────────────────────────────────────────────────┤
│ 19.71   │ 24399.94  │ 2165.48   │ 152.65   │ 1,15,22,28,23,16,12,21,20,22,23,17,31,25,18,15,18,19,20,17,9,18,27,17,12,13,33,14,27 │
└─────────┴───────────┴───────────┴──────────┴──────────────────────────────────────────────────────────────────────────────────────┘

Results for benchmark tree-view-rher-simple:
┌─────────┬───────────┬───────────┬──────────┬─────────────────────────────────────────────────────────────────────────────────┐
│ Avg FPS │ Scripting │ Rendering │ Painting │ FPS Values                                                                      │
├─────────┼───────────┼───────────┼──────────┼─────────────────────────────────────────────────────────────────────────────────┤
│ 50.88   │ 9568.31   │ 7441.53   │ 556.23   │ 1,54,46,52,55,49,45,46,49,53,52,51,48,49,54,46,53,48,52,58,52,54,51,53,54,48,51 │
└─────────┴───────────┴───────────┴──────────┴─────────────────────────────────────────────────────────────────────────────────┘

Results for benchmark tree-view-memo:
┌─────────┬───────────┬───────────┬──────────┬───────────────────────────────────────────────────────────────────────────────────────┐
│ Avg FPS │ Scripting │ Rendering │ Painting │ FPS Values                                                                            │
├─────────┼───────────┼───────────┼──────────┼───────────────────────────────────────────────────────────────────────────────────────┤
│ 49.14   │ 15433.03  │ 6133.68   │ 432.18   │ 1,45,54,37,52,55,44,43,51,46,51,54,41,52,53,45,50,49,51,47,43,53,42,54,55,49,53,57,50 │
└─────────┴───────────┴───────────┴──────────┴───────────────────────────────────────────────────────────────────────────────────────┘

tree-view: the original one, react-redux 5.0.7
tree-view-rher: useReduxState with proxyequal 2.0.2
tree-view-rher-simple: useReduxStateSimple with shallow (limited) proxy
tree-view-memo: pure useContext + useMemo approach

[theKashey]

So - the only bearable result is tree-view-rher-simple. Is it usable in real applications, or too shallow?

[dai-shi]

But, there's still room for improvements in proxyequal 2.0.2, no? I mean based on our trials in jsperf.

The shallow approach can be usable if developers carefully design the redux state with the shallow comparison in mind. This is probably too limited for the majority of redux use cases.
I'd still hope proxyequal to become comparable.

[dai-shi]

Oh, I may mislead you that proxyequal 2.0.2 above includes the modification? Let me try that.

[dai-shi]

Results for benchmark tree-view-rher with the patch:
┌─────────┬───────────┬───────────┬──────────┬──────────────────────────────────────────────────────────────────────────┐
│ Avg FPS │ Scripting │ Rendering │ Painting │ FPS Values                                                               │
├─────────┼───────────┼───────────┼──────────┼──────────────────────────────────────────────────────────────────────────┤
│ 13.12   │ 25649.44  │ 1240.48   │ 95.50    │ 1,11,15,14,16,17,19,10,13,11,16,7,15,16,19,16,15,2,17,16,13,7,12,14,10,7 │
└─────────┴───────────┴───────────┴──────────┴──────────────────────────────────────────────────────────────────────────┘

Pretty sure I did something wrong... Could you check it?
diff2.txt

[dai-shi]

It has to be the other way around like this. (I need your review @theKashey )
return lines.filter(function(x) { return values.indexOf(x) === -1; });

The new patch is: diff3.txt

Results for benchmark tree-view-rher with this new patch:
┌─────────┬───────────┬───────────┬──────────┬──────────────────────────────────────────────────────────────────────────────────────────┐
│ Avg FPS │ Scripting │ Rendering │ Painting │ FPS Values                                                                               │
├─────────┼───────────┼───────────┼──────────┼──────────────────────────────────────────────────────────────────────────────────────────┤
│ 40.07   │ 17956.07  │ 4275.31   │ 303.62   │ 1,35,50,30,39,44,41,47,30,42,34,24,44,40,42,48,41,40,44,46,26,44,48,41,38,43,36,37,43,45 │
└─────────┴───────────┴───────────┴──────────┴──────────────────────────────────────────────────────────────────────────────────────────┘

(which may mean we can optimize more???)

[dai-shi]

Just tried once again with diff.txt:

┌─────────┬───────────┬───────────┬──────────┬────────────────────────────────────────────────────────────────────────────────────┐
│ Avg FPS │ Scripting │ Rendering │ Painting │ FPS Values                                                                         │
├─────────┼───────────┼───────────┼──────────┼────────────────────────────────────────────────────────────────────────────────────┤
│ 50.11   │ 15180.51  │ 2630.19   │ 113.08   │ 1,52,51,41,55,50,49,47,34,57,49,51,50,47,56,48,55,56,35,45,52,54,56,54,57,48,55,49 │
└─────────┴───────────┴───────────┴──────────┴────────────────────────────────────────────────────────────────────────────────────┘

So, search-trie + patch still works better.

(edit) This patch (diff.txt) doesn't seem to make it work correctly, so the above result is void.
(edit2) I found a bug I created in diff.txt.

[theKashey]

:beautiful:

[dai-shi]

@theKashey Are you available to update proxyequal some time soon like in a week or two?
Please let me know if you want me to work on a PR.

[theKashey]

I am back and active. Feel free to draft a PR in any time.

[dai-shi]

Updated packages and run all benchmarks:

$ git clone https://github.com/dai-shi/react-redux-benchmarks.git
$ cd react-redux-benchmarks
$ npm install
$ npm run initialize
$ REDUX=5.0.7 BENCHMARKS=tree-view:tree-view-rher:tree-view-rher-simple:tree-view-memo:tree-view-dumb npm start

Running benchmark tree-view
  react-redux version: 5.0.7
    Checking max FPS... (30 seconds)
    Running trace...    (30 seconds)

Results for benchmark tree-view:
┌─────────┬─────────┬───────────┬───────────┬──────────┬───────────────────────────────────────────────────────────────────────────────────────┐
│ Version │ Avg FPS │ Scripting │ Rendering │ Painting │ FPS Values                                                                            │
├─────────┼─────────┼───────────┼───────────┼──────────┼───────────────────────────────────────────────────────────────────────────────────────┤
│ 5.0.7   │ 51.61   │ 9555.77   │ 7210.61   │ 548.58   │ 1,51,53,50,52,46,47,48,47,56,51,55,46,54,51,53,50,52,53,57,53,55,52,50,54,53,54,53,49 │
└─────────┴─────────┴───────────┴───────────┴──────────┴───────────────────────────────────────────────────────────────────────────────────────┘
Running benchmark tree-view-rher
  react-redux version: 5.0.7
    Checking max FPS... (30 seconds)
    Running trace...    (30 seconds)

Results for benchmark tree-view-rher:
┌─────────┬─────────┬───────────┬───────────┬──────────┬───────────────────────────────────────────────────────────────────────────────────────┐
│ Version │ Avg FPS │ Scripting │ Rendering │ Painting │ FPS Values                                                                            │
├─────────┼─────────┼───────────┼───────────┼──────────┼───────────────────────────────────────────────────────────────────────────────────────┤
│ 5.0.7   │ 38.96   │ 17988.73  │ 4321.41   │ 303.09   │ 2,36,47,30,40,42,40,50,33,41,31,22,43,37,41,48,45,37,43,39,27,45,37,39,43,37,33,45,40 │
└─────────┴─────────┴───────────┴───────────┴──────────┴───────────────────────────────────────────────────────────────────────────────────────┘
Running benchmark tree-view-rher-simple
  react-redux version: 5.0.7
    Checking max FPS... (30 seconds)
    Running trace...    (30 seconds)

Results for benchmark tree-view-rher-simple:
┌─────────┬─────────┬───────────┬───────────┬──────────┬───────────────────────────────────────────────────────────────────────────────────────┐
│ Version │ Avg FPS │ Scripting │ Rendering │ Painting │ FPS Values                                                                            │
├─────────┼─────────┼───────────┼───────────┼──────────┼───────────────────────────────────────────────────────────────────────────────────────┤
│ 5.0.7   │ 51.61   │ 9521.76   │ 7253.08   │ 549.60   │ 1,52,43,51,56,49,48,45,52,53,58,53,48,44,55,52,50,56,54,56,53,54,53,49,53,55,52,53,48 │
└─────────┴─────────┴───────────┴───────────┴──────────┴───────────────────────────────────────────────────────────────────────────────────────┘
Running benchmark tree-view-memo
  react-redux version: 5.0.7
    Checking max FPS... (30 seconds)
    Running trace...    (30 seconds)

Results for benchmark tree-view-memo:
┌─────────┬─────────┬───────────┬───────────┬──────────┬─────────────────────────────────────────────────────────────────────────────────────┐
│ Version │ Avg FPS │ Scripting │ Rendering │ Painting │ FPS Values                                                                          │
├─────────┼─────────┼───────────┼───────────┼──────────┼─────────────────────────────────────────────────────────────────────────────────────┤
│ 5.0.7   │ 50.04   │ 15134.43  │ 5632.15   │ 412.14   │ 42,55,43,53,54,47,45,43,51,44,53,52,50,49,46,56,47,49,48,47,53,49,55,57,47,53,55,50 │
└─────────┴─────────┴───────────┴───────────┴──────────┴─────────────────────────────────────────────────────────────────────────────────────┘
Running benchmark tree-view-dumb
  react-redux version: 5.0.7
    Checking max FPS... (30 seconds)
    Running trace...    (30 seconds)

Results for benchmark tree-view-dumb:
┌─────────┬─────────┬───────────┬───────────┬──────────┬───────────────────────────────────────────────────────────────────────────┐
│ Version │ Avg FPS │ Scripting │ Rendering │ Painting │ FPS Values                                                                │
├─────────┼─────────┼───────────┼───────────┼──────────┼───────────────────────────────────────────────────────────────────────────┤
│ 5.0.7   │ 28.71   │ 22775.51  │ 3256.32   │ 228.11   │ 1,23,34,29,34,32,38,27,25,23,28,24,32,25,26,32,28,32,26,23,28,37,27,21,35 │
└─────────┴─────────┴───────────┴───────────┴──────────┴───────────────────────────────────────────────────────────────────────────┘

[markerikson]

@dai-shi : I'm a bit confused by the output there. It doesn't look like you're using the benchmarks repo the way I intended it to be used, which was to add multiple React-Redux builds into the react-redux-versions folder, and run each of them against the same benchmark apps.

What are those results there actually comparing?

[dai-shi]

@markerikson Sorry for the confusion. The first Version column is meaningless. react-redux 5.0.7 is only used in the tree-view benchmark and not in other tree-view-* benchmarks. So, I'm comparing the original tree-view with its variants tree-view-* which I beleive provide the same functionality.

[markerikson]

That's what I was wondering, yeah.

Since I've only been seeing some of the comments in here, can you summarize what the actual changes have been, and what the perf results are?

[dai-shi]

@markerikson

Well, originally I started this project because I wanted to pass down redux state directly in the context like react-redux v6, but as it's not yet possible with hooks, I ended up with putting redux store in the context like react-redux v5, for now.

Anyway, my interest then is to compare the proxy approach with react-redux v5 to see how proxy impacts on the performance. Just one benchmark case is not enough, but as a start, I picked tree-view in your benchmarks.

There were lots of discussions and trials in the comments here (some of them are void because of my misunderstanding), but in the end we improved proxyequal and the final results at the moment are the following.

tree-view: ~51FPS (the original benchmark with react-redux 5.0.7)
tree-view-rher: ~38FPS (react-hooks-easy-redux with proxyequal a.k.a deep proxy)

There are some other variants for comparison:

tree-view-rher-simple: ~51FPS (react-hooks-easy-redux without proxyequal a.k.a shallow proxy)
tree-view-memo: ~50FPS (just with hooks useContext, useEffect, useState and useMemo, no bindings library)
tree-view-dumb: ~28FPS (with useContext, useEffect and useState, updating all components)

---

BTW, I'm not sure if I understand other columns in the benchmark results: Scripting │ Rendering │ Painting │ FPS Values. Could you elaborate a bit on them? Or just if I should care them?

[markerikson]

The first three are the values that are recorded by the Chrome DevTools when you capture a performance trace. I'm not an expert on them, but to my understanding:

• "Scripting" is total time spent running JS
• "Rendering" is time spent doing page layout
• "Painting" is time spent actually drawing the updated layout on screen and/or GPU

The "FPS values" is what my benchmark script is recording, ie, what's used to calculate the average in the first column. The lib I'm using records any change in FPS. It's not perfect, because if you did a capture for 30 seconds, the first 20 seconds were 60 FPS, and the last 10 seconds were 30 FPS, then I think the current benchmark logic would count that as 45 FPS (just averaging the two values) rather than ( (20 * 60) + (10 * 30)) / 30 or whatever's needed to get a true average over time. But, it's sufficient for now.

[dai-shi]

Thanks a lot!

[buzinas]

@dai-shi Two quick questions:

• If I install this package from npm, which of these examples above is it using now? I expect it to be tree-view-rher, but I only want to make sure if I'm correct. Are all performance improvements already up-to-date in npm?
• Is this package ready for production?

[dai-shi]

Let us continue the discusson about benchmarks in #3.

[smashercosmo]

Want to chip in this thread and mention that there is a new kid on the block https://github.com/cerebral/overmind/tree/next/packages/node_modules/proxy-state-tree
May be worth trying or borrow some ideas from it

[dai-shi]

Hi @smashercosmo!
Looks interesting. How are you familiar with the library?

[theKashey]

That means one tree stops tracking when an other starts tracking. Since all component libraries produces their UI description synchronously, this gives a predictable behaviour.

That's something we talked about once. Having one tracker per state and switching it to different consumers. Probably it's not so dangerous. It's actually not a problem to trigger an error on track out of expected locations (ie async access), thus help customer detect a problem and wrap it with some method you may provide.

[dai-shi]

It may not be dangerous if synchronous, but I’m not sure how to implement it in a hook.

Haven’t yet read proxy-state-tree in detail, but I don’t get how to compare previous state and new one.

[theKashey]

Yeah, It's a bit complicated (and reactive) library. I am not sure it's interface would work for you.

[theKashey]

Meanwhile - @faceyspacey - you probably have something to say.

[faceyspacey]

there's a lot going on in this thread...i just wanna say im super impressed and very happy someone finally brought this to fruition. great work @dai-shi !!

The benchmarks are obviously of prime concern when it comes to this thing. If they can rival the old react-redux benchmarks, there's no reason this shouldn't become the de-facto way to use Redux.

---

An important goal for me in the past was the ability to continue to do deep key access checking when using the rest operator:

rest operator

const { someKey, ...rest } = someObject
<div>rest.someValue</div>

If you guys checked out Remixx from the Respond Framework you might have seen why this is important. Essentially the idea is that all component functions receive a 2nd argument for state, which inevitably will be destructured most of the time, eg:

const MyComponent = (props, state, actions) => ...
const MyComponentDestructured = (props, { foo } , actions) => ...

NOTE: in Remixx, the goal is no visible usage of hooks nor connect; store access is completely built-in and transparent; it can be accomplished via several ways: fork of React or babel plugin that wraps all standard React components.

Not having rest is akin to the controversy around hooks requiring linting rules for the scenarios it doesn't support--i.e. "solutions" having such failed edge cases should be avoided at all costs.

@theKashey had mentioned the hurdles to this in the past. How are u guys viewing rest operator support now: a solid possibility that just needs to be pursued? or a road better not followed as the costs are too high? What are those costs? Any other edge cases that are currently not supported??

[theKashey]

So - still there is no solution for the rest spread, except...
We may actually create a super simple Babel plugin, which would transform rest opartor to the something digestible by us. One line before and one line after to toggle proxies on and off.

[faceyspacey]

I'm obviously not opposed to that. Are you 100% sure that's the only route?

[faceyspacey]

it's very nice to see you remembered the strategy; it's even nicer to see react-hooks-easy-redux playing it's part perfectly (as in your sample implementation).

yea, on our side destructuring rest isn't a problem. it's only a problem for users that would expect to do so, as destructuring is so common with arguments.

both this and its "broader" use cases are exciting 🚀. now we just gotta lockdown:

• something for selectors: https://github.com/respond-framework/remixx/blob/master/docs/initial-plan.md#connect-implementation-5-selectors

• something for redux modules: https://github.com/respond-framework/remixx/blob/master/docs/initial-plan.md#remixx-modules

...leaving modules out of the discussion for now, @theKashey what's your take on selectors? Do we need them, or is the work traditionally done in selectors now done in component functions like any other standard work? My initial idea was essentially preparing a complete and independent "UI Database" in the form of the combination of reducers + selectors. I've been away from Reactlandia for some time--what's your take?

[faceyspacey]

@theKashey , which is why I wanna make sure we pay special attention to selectors and truly get them right for the new proxy-based Redux world.

So, here's an example where the selectors API in this setup fails us:

const MyRemixxComponent = (props, state, actions) => {
  const val = mySelector(state, props)
  return <div>{val}</div>
}

const mySelector = memoize((state, props) => {
  return state.temp === 'high' // low | medium | high
    ? state.highs    // low and medium always returns mediums, therefore:
    : state.mediums // POTENTIAL FOR UNNECESSARY RENDER
})

So react-hooks-easy-redux is only checking state. It's not making use of the intelligence within selectors, like react-redux does with HOCs.

How can we make the above not trigger unnecessary renders when state.temp changes between medium and low??

My original idea for Remixx was to make the state arg passed to your remixx components also have selectors built in, e.g:

const MyRemixxComponent = (props, state, actions) => {
  const val = state.mySelector(props)
  return <div>{val}</div>
}

on store creation, you pass reducers and selectors now, eg: createStore(reducer, selectors)

And then somehow internally we produce a state object that addresses this issue. Thoughts on how we might implement this??

[theKashey]

• redux like mapStateToProps. A black box. But we could track what was used as inputs (property access), and what was returned. Like we know everything, and could bailout on shallow equal. But - we could return an array or an object, not just a POD type, and it may matter

• inline state access. We might track only the first part - property access, but not to bailout if you got the same result from different values. But! Usually, you will use POD types to create elements...

• selectors. We might track what's happening inside selector, and we might track what it will return (that should be "our" selectors). This might create something like hierarchical cache - the first level (state access) determine should MyRemixxComponent be called, while the second(selector result) may determine should MyRemixxComponent return be rejected.

Plus - we have to hook into React.createElement, and track the factual usage. Including wrapping POD variables by object with defined [toPrimitive], thus track not the property access, but property read (only for numbers and strings :( )

[faceyspacey]

But we could track what was used as inputs (property access), and what was returned. Like we know everything, and could bailout on shallow equal.

that's what I was thinking.

And by having state.mySelectors, during createStore we have an opportunity to wire up the shallowEqual comparison of selector return values in order prevent component re-rendering.

In other words, we couple this to how re-rendering is currently prevented by react-hooks-easy-redux. It works to our advantage to have all our selectors up front. In fact, it's necessary (though we will to offer an API to add more via code-splitting).

This might create something like hierarchical cache - the first level (state access) determine should MyRemixxComponent be called, while the second(selector result) may determine should MyRemixxComponent return be rejected.

I guess this begins to more closely describe the implementation.

Plus - we have to hook into React.createElement, and track the factual usage

I guess here's where things get out of control--ur saying the most optimum version of selector tracking includes tracking usage of return values, not just shallowEqual of return value, correct?

---

Sounds like we have a roadmap??

[faceyspacey]

Es-lint can automatically discover all the values that go in the array like [val]? I'm not sure what u r referring to that we get from es-lint??

But I love this idea! I guess we must parse all functions called on state, and then take the return values and place them as deps to useMemo. Is this what u have in mind?

It sounds like step 3 of the roadmap is maybe the easiest...perhaps this even addresses steps 1+2 (i.e. comparing return values to block additional rendering)!!

...actually, im wrong, it solves steps 1+2. But there's still a chance a value could be marked as a dep, but isn't in fact used in the jsx. So on top of this, we need to track access of selector-created objects.

I wonder if that much more tracking has potential to be less performant.

Either way, this is a great start! And in my opinion worthy of an initial release for the selectors feature. It's probably under 20% of the time that a dep is passed that isnt accessed. Maybe as low as 5%, what do u think??

[theKashey]

Es-lint can automatically discover all the values that go in the array like [val]? I'm not sure what u r referring to that we get from es-lint??

Cmon - React team created ESLint plugin to help you provide all the stuff you need for useEffect and useMemo. And also watches if you are using something you are NOT using :)

What about usage rate of selectors - it depends on code style. Sometimes it's 😭.

[faceyspacey]

Lol, have only been studying hooks, havent used em yet. ..In our case, it's kind of annoying that its an es-lint plugin, as we likely need our babel plugin to do the same work. Maybe you have a way to streamline building this I'm not aware of. I think we only wanna require our users to install a babel plugin.

Does it just provide warnings, or does it actually make the changes for you with eslint --fix?

Unless somehow we get this for free as part of a standard babel plugin integration, i think we either gotta copy it or implement it ourselves, eg:

const MyRemixxComponent = (props, state, actions) => {
  const val = state.mySelector('MyRemixComponent', props) // component name injected by babel plugin
  return <div>{val}</div>
}

And then the hierarchical cache compares cached values for this precise component and makes final decision of whether to trigger re-rendering.

Also, since their could be multiple MyRemixComponent, i guess we have to use useRef or something like this to get a handle on particular component instances. Eg:

const MyRemixxComponent = (props, state, actions) => {
  const ref = useRef(null)
  const val1 = state.mySelector1(ref, props)
  const val2 = state.mySelector2(ref, props)
  return <div>{val1}, {val2}</div>
}

Then our algo operates on a structure like:

const refs = {
   [ref]: [returnVal1, returnVal2], // compare these to return values in next potential rendering
   [ref2]: [returnVal2_1, returnVal2_2]
}

I feel like in the end it will be best to use our own internal infrastructure, i.e. the infrastructure that react-hooks-easy-redux is using. It's often better to reduce the # of dependencies on outside things.

[theKashey]

yep, something like this.

[dai-shi]

(I'm getting to understand what you guys are trying to do.)

[dai-shi]

We had very nice discussions here. I appreciate for all who participated. Sine it got long, let me close this issue now. Please discuss in more specific existing issues or file a new issue.