Question about createSelector examples

[jtwigg]

https://redux.js.org/usage/deriving-data-selectors#passing-input-parameters

In this example, I can see no way that it will not constantly recalculate the output, given that state => state.items will always be referencing a new array every time the store is modified.
So if the redux store modified item.completed = true the this will get recalculated.

**Question 1: Am I correct in this assumption? If so what is the point of this example, given that its supposed to show me how to prevent redraws?

Question 2: What is the best way to get access to the whole state object in the output portion of the createSelector if not like this example?**

const selectItemsByCategory = createSelector(
  [
    // Usual first input - extract value from `state`
    state => state.items,
    // Take the second arg, `category`, and forward to the output selector
    (state, category) => category
  ],
  // Output selector gets (`items, category)` as args
  (items, category) => items.filter(item => item.category === category)
)

[markerikson]

Hiya. I think you may be reading too much into that example. For one thing, it's a standalone snippet that doesn't even show what state.items is in the first place :)

It's true that if something inside of state.items gets updated, then items will be a new array. That's the point - a new array value leads to recalculating the output. But, there could be many other state slices, and many other actions in this app that cause updates to those other slices, and in those cases state.items would be unchanged.

As a really bad example, imagine that we have an app that is simultaneously a "Todo List" and a "Counter". If I click the "Increment" button and dispatch {type: "counter/increment"}, that has nothing to do with the todos data, and state.todos will be unchanged as a result.

This example in particular is really intended show the technique for "extracting extra arguments" and passing them on to the output function: (firstArg, secondArg) => secondArg, which you might typically use for something like selectItemById(state, id), or selectItemsByCategory(state, "boots").

Beyond that: you do not want to have state (ie, the entire Redux root state) be one of the arguments to the output function! That will be a new reference after every action, and thus cause the selector to always have to recalculate. That's why we have input selectors that only extract specific pieces of data - the output function should only run if one of those extracted values has changed.

[jtwigg]

@markerikson I'm struggling to get my re-draw's down. I feel I must be missing something.

Let me show my model simplified.

state = {
   tracks: [{  // len: 5 
       title: string,
       id: string,
       notes: [{.  //len 16
                 enabled: boolean
            }]
     }]      
 }

I have my top most component <TrackList> which shows a list of <Track>

My problem is, touching one note[5].enabled in my reducer causes state.tracks array to change and then triggers redraw at <TrackList> level.

It seems apparent that createSelector is meant to reduce these redraws but I can't seem to construct.

const trackSelector = createSelector(
    (state) => {
        return state.tracks
    },
    (tracks) => {
        return tracks.map(track => {
            title: track.title,
            trackID:track.id
        }))
    })


const TrackList: React.FC = () => {

const allTrack = useAppState(trackSelector())
return { allTracks.map( track => <Track id={track.trackID}> }
}

Question: What would a good approach be to only redraw the list if say an item is inserted/deleted/swapped which seems like the re-draw use-case (maybe not even swapped)

Problems: Returning the state.tracks doesn't work because it always changes
Problem: Returning ANY array in the selector doesn't work because the arrays are different. How to get createSelector to handle arrays of data?

Thanks for your help in advance.

[markerikson]

Yeah, this is entirely expected behavior.

You are updating state.tracks. Therefore it is a new reference, and so extracting state => state.tracks will cause the output selector to rerun. That's the intended behavior.

The point of a memoized selector is that it should skip recalculating if other data changes, like state.todos or state.filters, etc. But if the input data changes... yes, it should recalculate the output.

Btw, it looks like you do have a typo in your last bit of sample code - it should be useAppSelector(trackSelector) (notice no parentheses to call trackSelector, but rather passing it as an argument). I assume that's just a typo in the example, not in the real code, because otherwise it would throw an error.

If you want to optimize rendering behavior further, the usual pattern is to have the parent component read just a list of item IDs, the child list item component should be wrapped in React.memo(), and it should also read its data from the store based on that ID:

• https://redux.js.org/tutorials/fundamentals/part-5-ui-react#selecting-data-in-list-items-by-id

I'd recommend reading my extensive post A (Mostly) Complete Guide to React Rendering Behavior to better understand how rendering works.

[jtwigg]

This seems to to help quite a bit.

 const todoIds = useSelector(selectTodoIds, shallowEqual)

@markerikson For createSelector is there any ways to get this behavior?
a) for the input stage, I'd like to return an array that uses the shallowEqual comparison to validate equality.
b) For the output stage I don't have access to state anymore, and I'm finding that limiting. Is there any way to get it forwarded without forwarding it from the input parameters, since obviously the state would always fail equality.

Here's a contrived example:

const trackSelector = createSelector(
    (state) => {
        return state.tracks.map( t => t.id} //Compared with shallowEqual
    },
    (state, tracks) => { //Somehow get state passed in afterwards?
        return state.tracks
    })

[markerikson]

@jtwigg I'm rather confused what you're trying to do here, tbh :(

You shouldn't be accessing the entire root state in the output function of a createSelector call. Ever. That will guarantee that the selector will never memoize correctly.

Instead, you should write more input selectors that only extract the specific pieces that you need:

createSelector(
  state => state.a,
  state => state.b,
  state => state.q,
  (a, b, q) => {
    // calculate return value here
  }
)

For this particular example, I'm afraid the usage is very wrong conceptually:

const trackSelector = createSelector(
    (state) => {
        return state.tracks.map( t => t.id} //Compared with shallowEqual
    },
    (state, tracks) => { //Somehow get state passed in afterwards?
        return state.tracks
    })

because the "input selector" is always returning a new reference, and thus will again always recalculate.

For the "select an array of IDs" use case specifically, you've got 3 options:

• Use the new "output comparison" option in Reselect 4.1, supply shallowEqual as the comparison function, and then do useSelector(selectTodoIds): https://github.com/reduxjs/reselect/releases/tag/v4.1.0
• Stick with what you've got - a selector that will end up recalculating the array when state.todos changes, but pass useSelector(selectTodoIds, shallowEqual)
• Use Redux Toolkit's createEntityAdapter to store the todos, because it keeps a stable array of item IDs in state: https://redux-toolkit.js.org/api/createEntityAdapter, https://redux.js.org/tutorials/essentials/part-6-performance-normalization