Just Reselect. Granted, we can assume that the vast majority of Reselect usage is with Redux state (and likely React-Redux as well), but I'm not planning to add any special APIs or behavior to React-Redux or Redux Toolkit that would be specific to Reselect.

So, the goal for this discussion is: given Reselect v4 as a starting point, and this list of pain points and other ecosystem libs, what improvements to Reselect's API and implementation should we be aiming for?

Great thoughts from all of you! :)

I think at this point we've described the problem space pretty well. So, what I'm really interested in is some concrete suggestions for changes to the API and feature set, including thoughts on what could go into a 4.x release and what should go into a new 5.0 major.

Per the "Reselect dev tools" bit, thereis actually such a thing:https://github.com/skortchmark9/reselect-tools , which I linked above in the "Debugging" section. I haven't actually used it myself yet, but it seems pretty neat, and perhaps it would be worth trying to coordinate with the author to get that added in to the core somehow.

reselect-tools looks initially useful but being I tend to normalize and use re-reselect for entity data I would be hard-pressed to use something that doesn't cover all the selectors I am using. reselect-tools does have anopen request to add re-reselect support.

Before the integration of dev tools into the core, I would want to understand the performance impact of the said tools. An easy way to turn it on and off would be nice since I don't want it always affecting perceived performance as I build.

Re-reselect in particular solved the biggest gripe I had with reselect's API which was the factory functions, especially the one required for the componentmapState. With 'createCashedSelectormy component'smapState` can stay consistent when moving from one to many cache sizes. IMO caching should be narrowed to the selector so the component doesn't care.

I think one drawback of the current API is that we don't take advantage of our knowledge of the inputs. We currently don't distinguish them when creating the selector which leads to more boilerplate after the fact such as with re-reselect's resolver function.

For myself, there are 3 types of selectors, inputs, that cover a majority of my use cases and could possibly automate much of the cashing I require without the need for a cache resolver function. Wild idea but what if we used arrays to identify these types?

For example:

constselectFiles=state=>state.files// shouldn't affect cache size, let's call it a "standard input"constselectCurrentUserId=createSelector(selectCurrentUser,// in state, not from propuser=>user.id)// here we want cache based on the result, let's call it a "cache result input"constselectPropsFileId=(state,props)=>props.fileId// prop selector, another example of "cache result input"constselectFileId=(state,fileId)=>fileId// straight up input but not from prop, let's call it a "cache input"// although personally I would make this like the prop selector for composition, let's call it a "cache input"// what if an API could allow us to identify these types and cache appropriately?constselectFileAuth=createSelector(// use array args to identify caching strategy?[selectFiles],// array of standard inputs (selectors)[selectCurrentUserId],// array of cache result inputs (selectors)[selectFileId],// array of cache inputs (selectors)// order in the result function remains unchanged(files,fileId,currentUserId)=>files[fileId][currentUserId])// generates and uses`${fileId}-${currentUserId}` as cache key,// multiple input/result cache selectors are simply concat with dashes?// Error when not string/number signaling you need to use cache resolver function instead?// same example but with the prop selector for fileIdconstselectFileAuth2=createSelector([selectFiles],[selectPropsFileId,selectCurrentUserId],(files,fileId,currentUserId)=>files[filed][currentUserId])// generates and uses`${fileId}-${currentUserId}` as cache key// with prop selectorsconstselectFileAuth3=createSelector([selectFiles][selectPropsFileId,selectPropsUserId],(files,fileId,userId)=>files[fileId][userId])// generates and uses`${fileId}-${userId}` as cache key// or when you want to break it up because more than one selector can take advantage of the file entity caching such as being fed into different selectors for different viewsconstselectFile=createSelector([selectFiles],[selectPropsFileId],(files,fileId)=>files[fileId])// fileId as cache keyconstselectFileAuth=createSelector([selectFile],[selectPropsUserId],(file,userId)=>file[userId])// userId as cache key

This would remove a lot of the repeated work I do with re-reselect's resolver function API. Granted we would still need access to create a cache resolver function if the caching couldn't be determined by a number/string input/result of a selector.

I would strongly encourage not to follow re-reselect API because it creates memory leaks as there is no "clean" condition.
For React there is only one "stable" way of making per-something memoization and it's "useMemo". In "quotes" because it's just about storing result in a component's fiber and cleaning up with the fiber as well. Here is anarticle to read.

In other words, re-select functionalityhas to be implemented on auseSelector level.
Technically speaking@josepot'sredux-views are working on this principle via placingselector.use intouseEffect

+1 on the devtools point. I would really like to see Reselect be integrated with Redux DevTools and have selectors shown alongside state. Not being able to see my derived state through debug tools is a big pain point for me when using Redux compared to Overmind and MST.

There is an issue here about this with many upvotes but discussion died out in 2018.
reduxjs/redux-devtools#352

perhaps it would be worth trying to coordinate with the author to get that added in to the core somehow.

@markerikson

The author left a comment in that issue above saying that they would love to work on integrating into redux devtools and that was their plan all along. Not sure if they still have the bandwidth or interest but maybe you can reply and revive the discussion.

I haven't actually used it myself yet

I'm curious then what is your debug process when you see unexpected behavior related to app state and want to confirm that your derived state looks as expected? Seeing selector values feels like an important debug step to me

Also probably worth considering dev tool support forproxy-memoize if that's being recommended as a Reselect alternative in the official docs.

@adamerose : I usually just look at the output value in a debugger or console log.

I think this would be a useful idea to explore, although the first question would be how to expose debugging info from the selectors. This would likely require looking athttps://github.com/skortchmark9/reselect-tools and figuring out how to port that functionality into Reselect itself.

I've got enough stuff going on I don't think I could tackle that personally, but if you or someone else would like to look into it that would be great!

Hmm, I'm not sure if my descriptions give you the right understanding. Or, maybe I'm confused. Didn't even know reatom is proxy based. or, not...?

Great feedback!

Yes, I'm fully intending that v5 should be in TS at this point. No reason not to.

I'd also be inclined to pull the trigger on dropping variadic arguments and requiring the array format for input selectors. I think that might make it easier to add some kind of an options object as the last argument. In fact, if would be nice if the options object could be used for things like supplying memoization parameters, and we could avoid having a dozen variations ofcreateSelector. Like, hypothetically:

constselectSomething=createSelector([inputSelector1,inputSelector2],outputSelector,{cacheSize:10,cacheKey:(arg1,arg2)=>arg1.id,outputComparison:shallowArrayMemoizer})

FWIW, I see that@josepot has already created a codemod that would convert uses ofcreateSelector to the array format:

https://github.com/josepot/redux-views/blob/master/transforms/to-array-dependencies.js

With "updated" typescript definitions, variadic support isn't really problematic. I do think a decision should just be made and go in one direction over the other. Supporting both isn't really necessary.

Array support is probably the cleaner approach. If I had to pick one, that would be my vote. I really like the suggestion you provided. The options object as a third argument would be cleaner than curried functions and would support aton of features simultaneously.

Hey, thanks for the comment. I think there's a few misunderstandings here - let me see if I can clarify things.

First, it's important to understand that React-Redux, Reselect, and Redux Toolkit are three entirely different libraries with different responsibilities:

• React-Redux is the bindings layer between a Redux store and React components, and provides theuseSelector anduseDispatch hooks.useSelector acceptsany selector function, regardless of how it's implemented - a plain function, memoized with Reselect, or written using something else like Ramda.
• Redux Toolkit is primarily a UI-agnostic wrapper around the Redux core, and includes additional APIs likecreateSlice andcreateAsyncThunk. As of RTK 1.6, it now also includes the RTK Query data caching API. RTKQ in turn has both a UI-agnostic core set of functionality,and a React-specific layer that can generate hooks. That extra React layer requires use of React-Redux to supplyuseSelector/useDispatch as part of the query hooks.
• Reselect is a small UI-agnostic vanilla JS lib to generate memoized selector functions. While it's advertised as being "for use with Redux", it's not even Redux-specific - you could use it anywhere, including with React or a pure vanilla JS app.

Because of that, it doesn't make sense conceptually to talk about "Reselect owninguseSelector" - that's not possible from either a lib API perspective or a division-of-responsibilities perspective.

Also, the phrase "the majority of hooks are in Redux Toolkit" isn't correct - RTK doesn't haveany hooks except for the RTKQ query hooks.

Wehave vaguely tossed around the idea of adding additional React-specific functionality to RTK at some point, and now that we have the RTKQ query hooks as an additional entry point, we at least have a conceptual pattern that would let us implement that while keeping the bulk of the package UI-agnostic for use outside of React.

As for theuseDerivedSelector suggestion specifically, I'm not quite sure what the specific intent is there. It kind of looks like an equivalent ofcreateSelector but written purely using React's built-in hooks. I could at least imagine some kind of hook that made it easier to create unique selector instances per component or something, but that would be different than what I think you're describing there.

Yep. I think my mental model of "what goes where & who's responsible for that API" was totally sideways. :) I'll trace back through my notes relearning RTK and see where I made the jump that the hooks came from RTK and not the react-redux layer. If I do find something off in docs, I'll go open a PR over there.

The motivation behind wanting something likeuseDerivedSelector came from there being a large gap betweenuseSelector & needingcreateSelector in a react app. It shows up most commonly when using parameterized selectors and trying to maintain code that utilizes other react hooks.

constselectItems=(s)=>s.items;constMyComponent=()=>{const[filter,setFilter]=useState();constitems=useSelector(selectItems);constfilteredItems="?";}

The docs I referenced when encountering this problem (and my thoughts as I looked at how to solve this):

• https://react-redux.js.org/api/hooks#useselector
  • Needs to be a pure function ok
  • It can parameterize using something likeconst todo = useSelector((state) => state.todos[props.id])
  • As long as its an inline selector and we're not usingcreateSelector we shouldn't have any issues.
  • My component needs to then know way too much about my redux state tree. That seems very bad. External functions would work, but parameterizing them adds some complexity
• https://react-redux.js.org/api/hooks#using-memoizing-selectors
  • createSelector looks like how you handle parameterized selectors
  • This looks really different than useSelector
  • Where are thecreateSelector docs?
  • Hm... this is the only instance ofcreateSelector in the RTK docs... It says this comes from reselect
• https://github.com/reduxjs/reselect#createselectorinputselectors--inputselectors-resultfunc
  • I'm in too deep. Here be dragons 🐉 🐉 🐉
  • https://github.com/reduxjs/reselect/blob/master/README.md#q-how-do-i-create-a-selector-that-takes-an-argument

    • The general consensus here and over at nuclear-js is that if a selector needs a dynamic argument, then that argument should probably be state in the store. If you decide that you do require a selector with a dynamic argument, then a selector that returns a memoized function may be suitable:

    • Oh... oh no. None of this can be right. That would undermine a lot of community hooks that maintain their own state. Let's just copy thecreateSelector example from RTK
• https://react-redux.js.org/api/hooks#using-memoizing-selectors
  • The second argument seems to be for "props" from the older non-hookmapStateToProps. We're just reusing that it seems
  • (working code) Great! But now I've got this weird one-off selector function that's added a lot of indirection

The thing is, I'm not entirely sure that this is on reselect as a library. What reselect is doing makes perfect sense, but our component has changed in a way that became difficult to follow:

constselectItems=(s)=>s.items;constmakeSelectFilteredItems=()=>createSelector(selectItems,// same as our useSelector from before(_,filter)=>filter,// https://github.com/reduxjs/reselect#api a "props" argument, I think?(items,filter)=>// complex filtering of items goes here// but now it's also decoupled from the component)constMyComponent=()=>{const[filter,setFilter]=useState();constselectFilteredItems=useMemo(makeSelectFilteredItems,[]);constfilteredItems=useSelector((state)=>selectFilteredItems(state,filter));}

We memoize the factory method, then use ouruseSelector hook, but pass in a custom selector that is contingent on the current redux state and the localized filter state. This feels like a long winded way to end up at

constselectItems=(s)=>s.items;constMyComponent=()=>{const[filter,setFilter]=useState();constitems=useSelector(selectItems);constfilteredItems=useMemo(()=>{// complex filtering of items goes here},[filter,items]);}

And again, coming back to the earlier point, I'm not actually sure this is a reselect API issue. It's just thatcreateSelector is all-powerful and there's not really a simpler way to express "this state, plus these external values".

Yeah, there's some scattered references to selectors throughout the React-Redux and RTK docs. That said, I just recently wrote a newDeriving Data with Selectors page in the Redux docs that's intended to consolidate and explain a lot of the usage patterns - I'd suggest taking the time to read through that.

I definitely agree that themakeSomeUniqueSelectorInstance pattern is annoying... and that's actually one of the primary reasons why I opened up this entire discussion issue in the first place :) The core problem is that Reselect's default cache size is only 1, and if you reuse the same selector instance in multiple components, you end up always blowing the cache because every component passes in different arguments. Hence my questions up top about "how can we rework the API to make this easier to use?"

The other issue you're seeing is thatuseSelector by definitionalways calls its given selector function withone argument: the current Reduxstate.useSelector has no way of knowing youmight want to pass in other arguments. That's why the shown pattern isuseSelector(state => selectSomeThing(state, otherArgumentsHere)), because you need to capture those other args from the surrounding environment and pass them through.

Ultimately, yes, there is a lot of overlap between trying to memoize filtered results via acreateSelector memoized selector, and doing it withuseMemo. The names are similar because they do a similar job.createSelector is more flexible overall, both because Reselect offers more customization of selector behavior and configuration, and because it can also be used entirely independently of React.

• What are the biggest pain points with using selectors today?

Not knowing when it works, when it don't, and how to fix it

• What would an ideal selector API look like?

The current API is quite declarative and simple - you are just connecting the dots and that is all you should be thinking about.

• What changes would you want to see made to Reselect?

There are options:

1. make Reselect more strict and punch you every time something is not working properly.
2. make Reselectmagically disappearing and swallow your mistake driving a better outcome automatically.

The first option is our immutable past, the second is our future already possible in other (👋@dai-shi ) solutions.

Hey!

First of all, thank you for all your work on Redux, it really is a great library! I have been thinking a lot about how to design selectors in a scalable way, and I am currently using my own custom selector library as I found Reselect (and any other selector library out there) rather inadequate for my needs, so I will describe here the latest iteration of the API I am using to show some of the issues I faced, in the hope that it can inspire a future version of Reselect.

TL;DR

Sorry for the very long post, here is a short list of the key takeaways, described in more details below.

• Parameterized selectors should be currified functions instead of being functions with additional arguments. Using functions with additional arguments is the main design decision of Reselect I completely disagree with.
• Caching is tricky, but maybe there is a way to tie it to Redux' global life cycle, cleaning up unused selectors automatically
• Caching should be optional, as the same API can be used for reducing boilerplate in selectors that have no reason to be cached
• Reselect's optionresultEqualityCheck is great (but I think that usingequalityCheck just means that the input selectors are broken)
• The "output selector" is a quite different kind of function compared to regular selectors, so I don’t think the term "selector" should be used for it
• proxy-memoize was way too slow when I tried it, so I prefer a more explicit Reselect-like API
• Calling all selectors twice in development to ensure they do not return new references would be great
• Some more debugging tools for selectors, for instance concerning how many times a given selector is called or how long it takes, would be great

Context

I have been working for the last two years on an internal tool at my current company. It's a graphical editor for creating complex animations (think something like Figma but for animations, with a UI heavily inspired by After Effects), and it's entirely implemented as a React + Redux web app. I have a very complex state structure, as in a given project you have many animations, each animation has many layers, each layer has many keyframes, and so on, and there is a lot of different places the data needs to be queried by components. The state is partially normalized, in the sense that I use the{allIds, byId} pattern everywhere possible (with my custom version ofcreateEntityAdapter), but I also do use nesting: each animation contains its own layers, each layer contains its own keyframes, etc. In particular, to refer to a particular keyframe you need to give theanimationId, thelayerId, and thekeyframeId. Performance is very much a concern as in many places you can click and drag on stuff, which dispatches actions for everymousemove event, and it causes all selectors to rerun every time.

The main issue I faced was how to design parameterized selectors (i.e. selector with arguments) in a way that makes them easy to define, easy to use, and performant. The main function in my library is calledcombineSelectors and is similar to Reselect'screateSelector. It takes as input several parameterized selectors, one combining function, and creates a resulting parameterized selector. Let me now get into more details about exactly what I mean, as well as clearing up some terminology.

Simple selectors

A (simple)selector is any pure function that can be used as an argument to theuseSelector hook. In particular it has exactly one argument, the whole state, and returns some data.

In addition to being pure, it is very important for selectors not to return new references needlessly, likefilter ormap do, otherwise the components using that selector will rerender at every single state change which can impact performance dramatically. I know that theuseSelector hook can be passed an equality comparison function as its second argument, but in my opinion this is the wrong place to put this equality test: it really is the responsibility of the selector to not return new references, not the responsibility of the component to know which selectors require shallow equality tests and which do not. The newly addedresultEqualityCheck option in Reselect is a much better solution.

In my library, I also added a debugging feature that calls all selectors twice (in development mode) and logs an error message if the two results are not referentially equal, because that means something is wrong with the selector. I found this invaluable in order to find selectors that may be improperly memoized.

Simple selectors are fine for simple global state, but in my case the vast majority of selectors need to select data corresponding to a particular animation, or to a particular layer in a particular animation, and to handle that we need parameterized selectors.

Parameterized selectors

Aparameterized selector is a currified function that takes some arguments and returns a simple selector, for instance:

selectAnimationById:({animationId:string})=>(state:State)=>Animation

Note that this differs from Reselect's notion of parameterized selectors, which is a function with several arguments in addition to the state:

selectAnimationById2:(state:State,animationId:string)=>Animation

I must say I really don't understand the point of such selectors with several arguments, because they cannot easily be used inuseSelector (except by writing anonymous functions everywhere, but who wants to do that?). Compare:

constanimation=useSelector(selectAnimationById({animationId}));constanimation=useSelector(state=>selectAnimationById2(state,animationId));

I always want to use the first version, so that's what I tailored my library towards. I don't support selectors with several arguments, and I don't even call them selectors.

Combining functions

The "output selector" of Reselect is what I call acombining function. I don't think the word "selector" should be used here at all because it is a completely different kind of function:

• It takes several arguments, none of them being the whole state, whereas selectors only take one argument which is the whole state.
• Unlike selectors, it is perfectly fine for the combining function to return new references, that's actually exactly where you are supposed to do that.

So I think it makes sense to clearly distinguish between (parameterized) selectors and combining functions because they correspond to different concepts.

Another related point is that I don’t really see the point of Reselect'sequalityCheck option. The input selectors should be proper selectors themselves and should therefore never need anything else than a reference equality check. If an input selector returns new references, then it should be fixed to not do that, rather than requiring every derived selector to useequalityCheck.

Caching

If the combining function is computationally expensive/returns new references, then caching can/must be used. Like in Reselect, caching means that we first run all input selectors, and if it turns out that we get the exact same values than last time, then we do not rerun the combining function, but instead simply return whatever it returned last time. A very important thing to look out for (which is what re-reselect was designed to fix), is that calling the same selector but with different arguments should not invalidate the cache, otherwise it completely destroys all memoization as soon as you have two different uses of the same selector at the same time:

// No memoization at all with Reselect's default behavior!conststuff=useSelector(selectComputationallyExpensiveStuff(animationId));constotherStuff=useSelector(selectComputationallyExpensiveStuff(otherAnimationId));

Figuring out how to properly cache thing is pretty tricky, though.

The simplest solution is to have a infinite cache, but it can of course create memory leaks. But a fixed cache size (as in Reselect'scacheSize option) doesn’t make a lot more sense to me either, as

• it requires the programmer to choose a somewhat arbitrary number
• if it turns out that this number is too small, it completely destroys all memoization and replaces it by useless bookkeeping: if you have a cache size of 10 but you use 11 different instances of a given parameterized selector, then at every render eachuseSelector will remove from the cache the value that is about to be used by the next selector...

Ideally I think that there should be an unlimited cache but which gets cleaned up after each render, so that we only cache instances of selectors that are currently in use. I think this is where 99.9% of the benefits of caching come from: to optimize successive renders and making sure that when we change one part of the app, the rest of the app that is untouched doesn’t rerender/runs computationally expensive functions. So every time an action is dispatched and Redux has run all the selectors again, it should remove from the cache all cached selectors that did not rerun in this cycle. I haven’t implemented that in my library yet, but I think that would be the best solution.

In addition, re-reselect allows you to provide a custom function to compute a cache key based on the arguments. In my case, I feel likeJSON.stringify on the arguments is enough, but I guess it might be occasionally useful to have a custom cache key (although it still feels a bit too low-level to me).

Globalizing selectors and reducing boilerplate

One of the main problem I wanted to solve was actually reducing boilerplate when globalizing selectors. For instance a keyframe has a timestamp, so there should be aselectKeyframeTimestamp parameterized selector. In "raw Redux" you could write it like this:

constselectKeyframeTimestamp=(props:{animationId:string,layerId:string,keyframeId:string})=>(state:State)=>state.animations.byId[props.animationId].layers.byId[props.layerId].keyframes.byId[props.keyframeId].timestamp

but this is clearly not sustainable, especially when you need many such selectors. Instead I can now write it as follows, whereselectKeyframeByIds is defined once somewhere else.

// selectKeyframeByIds has type// ({animationId: string, layerId: string, keyframeId: string}) => (state: State) => KeyframeconstselectKeyframeTimestamp=combineSelectors([selectKeyframeByIds],keyframe=>keyframe.timestamp);// with type// ({animationId: string, layerId: string, keyframeId: string}) => (state: State) => number// Usage in a componentconsttimestamp=useSelector(selectKeyframeTimestamp({animationId, layerId, keyframeId}));

which is a lot better. The thing to note in particular is that I am not usingcombineSelectors here for its caching capabilities, but only for reducing boilerplate. Caching is not desirable here as it would just increase memory usage for no good reason. Given that most of my selectors are of this form, I actually have caching off by default, and I turn it on only for the selectors that do need it.

The API

Finally, here is how my API looks like on a general example.

Given several parameterized selectors:

selector1:(props:Arguments1)=>(state:State)=>Result1selector2:(props:Arguments2)=>(state:State)=>Result2selector3:(props:Arguments3)=>(state:State)=>Result3

and a combining function

combiner:(value1:Result1,value2:Result2,value3:Result3)=>Result

it produces a new parameterized selector

combineSelectors([selector1,selector2,selector3],combiner):(props:Arguments1&Arguments2&Arguments3)=>(state:State)=>Result

which callsselector1,selector2 andselector3 onprops andstate, and then callscombiner on the three results. There is support for optional caching and result equality check via a third argument tocombineSelectors. I currently only support (and need) parameterized selectors with one argument, and the type of the argument of the resulting selector is the intersection of all the types of the arguments of the input selectors. This allows the input selectors to share arguments, which can be very useful in practice.

For instance let's say I want the timestamp of a keyframe but expressed in frames (which requires knowing the fps of the animation), I can write it like this:

// Assume we have// selectAnimationById: ({animationId: string}) => (state: State) => Animation// selectKeyframeByIds: ({animationId: string, layerId: string, keyframeId: string}) => (state: State) => KeyframeconstselectAnimationFps=combineSelectors([selectAnimationById],(animation)=>animation.fps,);// of type ({animationId: string}) => (state: State) => numberconstselectKeyframeTimestampInFrames=combineSelectors([selectKeyframeByIds,selectAnimationFps],(keyframe,fps)=>keyframe.timestamp*fps,);// of type ({animationId: string, layerId: string, keyframeId: string}) => (state: State) => number

and then I can simply use it as follows

consttimestampInFrames=useSelector(selectKeyframeTimestampInFrames({animationId, layerId, keyframeId}));

It will call bothselectKeyframeByIds andselectAnimationFps with the argument{animationId, layerId, keyframeId} and the state, which will return the keyframe we're interested in and the fps of the corresponding animation, which are then passed to the combining function which computes the final result.

The other API I am using is the following function, which allows you to add arguments to a selector:

constselectArgument=<Kextendsstring>(key: K) =><T>(props: Record<K,T>) =>(_:State)=>props[key];

It is a function returning a parameterized selector that ignores the state and simply returns one of the parameters. It can be used to add additional arguments to a selector, for instance if you want the fps to be provided as an argument to the selector rather than taking it from the animation:

constselectKeyframeTimestampInFrames=combineSelectors([selectKeyframeByIds,selectArgument("customFps")<number>],(keyframe,fps)=>keyframe.timestamp*fps,);// of type ({animationId: string, layerId: string, keyframeId: string, customFps: number}) => (state: State) => number

Additional thoughts

I tried to useproxy-memoize at some point (maybe one year ago or so), but performance was pretty bad and it made my app essentially unusable, so I quickly moved away from it. It is fully possible that I was not using it properly or that it improved since then, but on the other hand selectors run way more often than reducers, so it might be an inherent problem to proxy-based selectors. I do use Immer for reducers, but it is acceptable there as there is typically at most one reducer running per mousemove event, as opposed to several hundreds of selectors.

Another thing I implemented in my library is a debugging tool that counts how often selectors are called and how much time they take to run, to find computationally expensive selectors. I have found that this gives great insights and allows one to know whether some selectors need to be optimized.

@guillaumebrunerie thank youvery much for taking the time to write up this extensive comment! I genuinely appreciate it.

Unfortunately my own brain is kinda fried and overloaded atm (a combination of not quite enough sleep the last couple days, and juggling too many other tasks at work and on the Redux side atm).

I've skimmed your comment, and there's clearly a lot of great info here. Iwill come back to this later and give it the deeper read and better response that it deserves, but it will probably be some time before I'm ready to turn my attention back to working on Reselect.

My couple immediate thoughts I can toss out are:

• Yes, wedo specifically show theuseSelector(state => selectAnimationById2(state, animationId)) approach in the docs as the typical way to use multi-param selectors, because it's clearer what's going on as opposed to a curried selector being generated
• I'd love to see more details on the API and implementation of yourcombineSelectors lib if you get a chance
• Agreed that fixed-size caches are of debatable use. Ihave seen an interesting technique inReact's experimentalcache() API implementation that usesWeakMaps to store cache data as a tree based on the arguments - something that's on my list to go investigate further.

So every time an action is dispatched and Redux has run all the selectors again, it should remove from the cache all cached selectors that did not rerun in this cycle.

Brilliant idea - automatic garbage collection for the cache. It is worth further investigation.
I was looking for a similar solution atmemoize-state (almost 5 years ago) and found it not to work with "magic memorization". In my case a small update to the state will preserve the majority of selectors and not trigger deeper computations, marking them as "not used".
Look like a bit more direct solution will be not affected by such "zerba tainting". Very interesting 👍

I have seen an interesting technique inReact's experimental cache() API implementation that uses WeakMaps to store cache data as a tree based on the arguments - something that's on my list to go investigate further.

It's been8 4 years -https://github.com/theKashey/useReselect

@markerikson I have now made a codesandbox showing my implementation, seehere. I've plugged it into some default Redux template to check that it works, but this is just an example application, way simpler than my real project.

• The main file to look at issrc/store/combineSelectors.ts (containing the implementation)
• You can also look atsrc/store/selectors.ts (containing some simple selector definitions) andsrc/component/Todo.tsx andsrc/components/TodoList.tsx (showing the usage of those selectors in components). I could try to come up with more complex examples if desired.
• There are some Typescript/ESLint parsing errors, but this seems to be because codesandbox uses an old version of Typescript. It works fine for me otherwise.
• Similarly, all theas const inselectors.ts can be instead replaced by a singleconst modifier incombineSelectors, but that also requires a more recent version of Typescript.
• I need to import theAppState type incombineSelectors.ts, which is of course suboptimal, but so far I haven’t managed to make it infer it automatically (I also haven’t tried very hard).
• I removed the debugging stuff because I couldn’t make it work with codesandbox: I need to extract the name of the selectors, and I do that in my real project in a very hacky way by fetching thebundle.js file created by Webpack and then parsing a(new Error()).stacktrace to extract the exact piece of code where the selector is defined, and then some more fiddling around with promises as it is asynchronous.
• The empty object in for instanceuseSelector(selectIncompleteTodoMessages({})); is just a flaw in my Typescript typings which makes every parameterized selectorrequire one argument, even if it is not used.

When it comes to anonymous functions likestate => […] being clearer than curried functions, I really have the opposite opinion:

• From the point of view of the consumer of the selector (the person writing a component), the fact that a selector is a simple function taking the state as an argument is an implementation detail.
• In other words, it is completely irrelevant what a selectoris, as long as you can feed it touseSelector and get in return the data you were promised.
• In addition, we could imagine the selectors created bycombineSelectors to be more than simple functions (for instance functions with some debugging or testing information attached to them, like therecomputations field in Reselect), and thenuseSelector could make use of that information when available, but this wouldn’t work at all when only passing anonymous functions touseSelector.
• Finally, (as a response to one of your comments below) note that that every call tocombineSelectors sets up its own local cache and then caches the (resulting) selector functions themselves, based on the arguments. This is necessary, as you point out, otherwise there is no way memoization could work. So when calling a selector created withcombineSelectors, it only creates a new function reference if that selector has never been called before with those arguments, otherwise it returns the cached selector. Having curried functions doesn’t make it especially more difficult to do, it’s just a matter of declaring the right variables in the right place.

There is another way to solve this which maintains the memoization capabilities,useSelector(selectUserById, id). I've started to use this in a recent app and was wondering if there is a downside with this approach as well. This is a custom store on top of Zustand with overrides their subscribe method to handle the above format.

@triptu Do you mean that you have a customuseSelector hook that basically does:

import{useSelectorasuseSelectorOriginal}from"react-redux";exportconstuseSelector=(selector,props)=>{returnuseSelectorOriginal(state=>selector(state,props));};

I like this syntax, and I've been thinking about introducing it to my own projects as well, although it's kinda weird to use the same name (useSelector) with a different API, it might be confusing to other people.

@guillaumebrunerie yes very similar, typed like this with typescript to ensure the IDE autocompletion works fine.

exporttypeStateSelector<T,R,Argsextendsany[]>=(state:T,  ...args:Args)=>R;exportconstuseStore=<R,Argsextendsany[]>(selector:StateSelector<T,R,Args>,  ...args:Args):R=>{returnuseSelector((state)=>selector(state, ...args));};// usageconstrooms=useStore(selectRooms);constroom=useStore(selectRoomById,roomId);constuserConfig=useStore(selectRoomUserConfig,roomId,userId);

same name with a different API

I useuseStore for the name usually with the app name in it as well(e.g.useGithubStore). In my case the store part is abstracted as its own small wrapper and doesn't export the original hook to keep things simple.

I have a lot of selectors which take arguments and really like having them defined at one common place. This especially becomes helpful when the selectors are doing more than just selecting one field. The DX is good.

@triptu Actually, I just realized that separating the selector function from the arguments makes it very easy to implement a custom hook for the"selector factory" pattern, which ... should solve essentially all cache problems?

exportconstuseParameterizedSelector=(selectorFactory, ...args)=>{constselector=useMemo(selectorFactory,[]);returnuseSelector(state=>selector(state, ...args));};

With this, each use ofuseParameterizedSelector creates a memoized selector with its own cache of size 1, which is perfect.
The selector simply needs to be defined as a selector factory, that is

constselectorFactory=()=>createSelector(...);

instead of

constselector=createSelector(...);

Have you tried something like that?

Cool idea. The main issue I see is that there will be duplicate memoization in contrast to using maxSize with the defaultMemoize function. Every place which needs sayselectUserById will create its own instance instead of one shared instance. This is probably fine for most applications though but might increase memory usage at scale.

We do have some plans in RTK 2.0 to try adding aselectors field inside ofcreateSlice:

There's a WIP PR here - take a look and give feedback?

reduxjs/redux-toolkit#3297

Thank you for the writeup! I have to head out in a minute, so I'll try to come back later and give it some more thought. My first reaction is that both React and Redux work best in the "80%" use case, where there's decent amounts of data being updated reasonably frequently, but when you start hitting these "real-time/thousands of updates per second" use cases that's not really what they're meant to handle. That's also true for Reselect.

In general, I'd love to come up withsome kind of mechanisms that help better optimize Redux updates and Reselect selectors, but I'm not sure thereare alternate approaches without fundamentally changing both libraries.

Yep, so similar conclusion. The 3 fixes I gave represent 3 different categories of problems:

1. Problems the data model can improve (e.g. atomic vs singleton state)
2. Problems the selection model can improve (e.g. offering more control over memoization details and evaluation frequency across the selector graph)
3. Problems that break down the reactive paradigm itself and can't reasonably be improved in React or React-based models (our lib falls short here too and can only help by offering an escape hatch and resources/guides to help people do it correctly).

As far as whether any of these are actionable for Reselect, I'm in the same boat: I don't think so. At least not for the specific problems we ran into. The current paradigm is good enough for most things (way more than 80% 😄) and any changes would require massive overhauls. Not worth it.

What I was more intending to communicate is that React itselfwas fast enough for us in every case but one. However, React's overheadcombined with Reselect's overhead was too much for us in lots of other cases too. Reducing our data layer overhead enabled React for us in all those other cases.

React's flavor of reactivity has amazing Dev X and I'm glad we didn't shun it just because our app type technically lies outside React's intended use case. IMO it's way better to use React for everything possible and bump down to imperative, brittle models only exactly where you need them than to use a view layer with worse Dev X for everything. React gives all the escape hatches necessary for this.

Anyway, I hope this was helpful or at least alittle interesting.

I wonder if you took a look at SolidJS? It's an alternative to React with pretty similar syntax but a quite different model of reactivity, and it's been praised for being a lot more performant. The reactivity model is based onsignals (single reactive values whose life cycle is not tied to components, similar to your atoms I think) andeffects (side effects that rerun whenever the signals it depends on change). You can create graphs of signals that depend on other signals (usingcreateMemo), and you can debounce/throttle parts of the graph to make sure some signals do not change too often (using for instancecreateDebouncedMemo fromsolid-primitives). So everytime a signal changes, the signals that depend on it rerun, and so on until reaching the individual DOM nodes that use a signal that just changed, which are then modified atomically. There is not "rerun every single selector at every change" phase like in Redux, nor "rerun the whole component code including every child at every change" like in React. It's really trying to do the minimal amount of work to update the UI.

I'd suggest watching the talk "The world beyond components" by Ryan Carniato, it's more about how SolidJS is a replacement for React rather than Redux and Reselect, but it's really an eye opening talk.

Note that I did add user-configurable cache sizes todefaultMemoize as of Reselect 4.1.

I'm also playing around with a couple new memoizers over in#605 - an "autotrack" memoizer based on ideas from Ember's Glimmer engine, and a "weakmap" memoizer based on React's internalcache() API. Both still early POCs.

I am keeping an eye on your activity, and it looks very promising 👍.
I just wanted to remind that not every problem need a solution in isolation, only as a part of a bigger whole. This probably would not affect what you are doing, as you working on a level above Reselect. But quite related to the discussion above, there another "level above" has been discussed as a potential solution.
This is why the question - is the goal to solve the problem for reselect, or reselect with redux (and react?). Experiments withcache() sounds that we are on the same page.