Use Proxy-based selectors

[theKashey]

Based on:

• Investigate adding a proxy-based selector API
• useTrackedState from reactive-react-redux
• proxy-memoize
• why-did-you-update-redux

---

Proxy based solutions were floating around for a while, and actually actively used inside(MobX) and outside of React ecosystem(especially in Vue and Immer). I am opening this discussion to resolve status quo and add some momentum to Redux + Proxies investigations.

Overall proxies are capable to solve 3 objective:

• selector memoization. Proxies can be provide more efficient memoization(comparing to reselect) in some cases, where just some pieces of state matters, as seen in proxy-memoize or redux-tracked

import memoize from 'proxy-memoize';

// reading only `.a` and `.b`
const fn = memoize(x => ({ sum: x.a + x.b, diff: x.a - x.b }));

fn({ a: 2, b: 1, c: 1 }); // ---> { sum: 3, diff: 1 }
fn({ a: 3, b: 1, c: 1 }); // ---> { sum: 4, diff: 2 }
fn({ a: 3, b: 1, c: 9 }); // ---> { sum: 4, diff: 2 } (returning old value)
//                        ^ "c" does not matter

• testing. While the use case above is a little synthetic and such memoization is not really needed unless a developer willing not to use any memoization at all, it can be used to check selector quality, and report all selectors which react to the state change while they should not

technically running selector twice in dev mode might solve majority of the problems, like returning new array/object every time, proxy based memoization is capable to detect more complicated situations and provide some guidance around the problem. As seen in why-did-you-update

• slice isolation. One named issue of redux is it's "global" store, and the fact that all listeners would be notified on state update. Knowing which slices were updated, and which selectors are listening for them, might provide an optimisation for selectors. This is actually a very old idea - Use React.createContext() with observed bits #1021 - but still valuable.

---

What proxies can solve:

• speed. Proxy based memoization works "more often" and might result a better experience
• less dev pain. Proxies "just works". At least, in the test mode, they can point on the problem instantly, not asking to invest some hours in debugging.
• TBD

---

What proxies cannot solve:

• per-component memoization. It's just absolutely orthogonal problem.
• TBD

---

What proxies can break:

• As long as one has to wrap state with a Proxy - one will use Proxy in all "frontend" code. In the same time at reducers/middleware side it will be just state. (Only once) I had a problem with "equal reference" memoization working differently in useSelector and saga. It's very edge-case-y, but having state sometimes wrapped, and sometimes not can break stuff.

---

Actionable items:

• decide about proxy-memoized selector
• decide about proxy-based selector pureness / quality checking
• decide about slice isolation or/and proxy-based tracking/DevTools integration. It's really possible to know which components reading which slice or/and react to a some piece of information and this knowledge can transform DevTools.

cc @markerikson , @dai-shi

[dai-shi]

Does useTrackedState in #1503 fall into any of the three?

[theKashey]

@dai-shi - it is the first one.
However I am trying not to focus on selection part as we did it already before, and it was not that easy to sell the it. The main problem with proxy-memoized selector is that you might not need it, as it not really solves memoization problem (due to cache size). For last 2 years I am using proxies to "check" my selectors in dev mode, and then use weakmap based memoization to band-aid the problem.
I really don't have a case when you have to use proxies for memoization. Atoms (hello jotai), as well as normalized state, can do it better. The only difference - atomic "strings" and "numbers" has to be wrapped with weakmap-able objects.

[markerikson]

Thanks for putting this writeup together.

Lemme try to come at the question for a different angle:

What pain points of Reselect can be addressed by using a proxy-based selector approach, if any?

My thought process here is that perhaps the right place to start is by finding some scenarios where Reselect is a pain to work with, and proxy-based selectors solve those pain points. We can then look at maybe including something in RTK as a stepping stone away from Reselect, as well as revisiting the useTrackedSelector idea.

[theKashey]

Pain points of Reselect

• cache size 1. So not truly component model compatible
• memoization itself. It's easy to create a selector that would be not very "stable".

Cache size

Proxies are not able to help here. There are ways to resolve the problem, but they are not bound to proxies.

Memoization

TrackedSelector can check that selector behaves in the same way as it should - be pure, and for the same "input data" produce the same "output".

It's again not bound to proxies or reselect, but only to how you write your code/selectors. There is always a way to produce a perfect memoization using reselect only.

---

In other words proxies are not going to magically solve all the problems, but they might lower the bar and improve dev experience and target product quality in many different ways.
For example once I've created a POC for tracking Component->Redux->Rest. Ie I can know precisely which pieces of state were used to produce the result component (as seen at FromJS )

[dai-shi]

In other words proxies are not going to magically solve all the problems, but they might lower the bar and improve dev experience and target product quality in many different ways.

So, proxy-memoize v0.2 supports nesting and should help lowering the bar. Are there any examples that I can tackle applying the method?

finding some scenarios where Reselect is a pain to work with

pretty much this.

[markerikson]

Here's a few libs that specifically try to deal with weaknesses in Reselect:

• https://github.com/heyimalex/reselect-map
• https://github.com/toomuchdesign/re-reselect
• https://github.com/josepot/redux-views

Related:

• https://medium.com/@josepot/we-need-better-redux-selectors-457a1ed10732
• Version 5.0.0 proposal reselect#401

I'd say those are good starting points for comparisons.

[dai-shi]

Thanks. So, I modified @josepot 's example in redux-views.

https://codesandbox.io/s/spring-star-1yrqm?file=/src/proxy-memoize.js

I noticed proxy-memoize would require useMemo/useCallback for parametric selectors.

[markerikson]

@dai-shi okay, yeah, the useCallback bit there is confusing both me and the linter :) I eventually figured out that the naming of that function collides with the React hook, so that's just a coincidence.

actual behavior-wise, is that ultimately just acting as a cache with size > 1?

tbh the redux-views example feels a bit more readable here.

[dai-shi]

the useCallback bit there is confusing both me and the linter

oops, I was trying to emulate the useCallback behavior in the example.

actual behavior-wise, is that ultimately just acting as a cache with size > 1?

uh, no. cache size = 1, but memoization is based on state and a prop (carId) separately.
proxy-memoize-with-size.js is the example with cache size > 1.

tbh the redux-views example feels a bit more readable here.

Ha ha, I guess we should create react-redux examples which are common to use useCallback.

[markerikson]

@dai-shi oooo, yeah, I forgot that there was another example file there.

Hey, neat, it's got a size option built in! That right there is a big improvement over Reselect, and I guess you could just do size: Infinity if you wanted to?

Out of curiosity, is the separate variable read like const cars = state.cars necessary for the memoization/tracking to work right? Could I just do return state.cars.filter()? (Also, I assume destructuring works here too?)

[dai-shi]

you could just do size: Infinity if you wanted to?

Yeah, but that means memory leaks, and it does not solve the issue technically.

Could I just do return state.cars.filter()? (Also, I assume destructuring works here too?)

Yes.

proxy-memoize has a mix of WeakMap cache and Array (with size) cache.

1. firstly check weakMap.has(obj) without tracking info (so, { state, carId } always misses.)
2. if it doesn't find, check the array cache with tracking info
3. otherwise, run the function and record tracking info

[markerikson]

Okay, so here's a use case I'm not clear on yet.

Let's say I've got:

const selectTodoDescriptions = createSelector(
  state => state.todos,
  todos => todos.map(todo => todo.text)
)

Now I dispatch(toggleTodo()). New todo object, new state.todos array. We call selectTodoDescriptions(state), todos has changed, output selector runs, and returns a new todoDescriptions array that is a new reference but shallow-equal because none of the todo.text values changed.

Is proxy-memoize going to do the same thing, because state.todos changed? Or is it smarter in that case in some way, because we only read todo.text and the new todo object only has a new todo.completed field?