Other discussions around auto-detecting Redux state usage

[markerikson]

There's been some other experimentation and discussion around auto-detecting which pieces of Redux state are used. In particular, @theKashey has done a lot of work around trying to use proxies, but apparently there's a number of difficult edge cases.

Please see respond-framework/remixx#1 and reduxjs/react-redux#1018 for related discussion.

If you've got ideas for how we can leverage this kind of functionality in a future version of React-Redux, I'd appreciate any help you can provide!

[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]

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.

[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.