Memoizing rapidly changing state

[alex-trofimov]

Hello!
I would like to ask for an advice on what's the best way to handle memoization of a state that changes very regularly (and whether this is actually a proper use-case for reselect).

Context:
I'm working on a React application that has multiple redux store slices, each managing own set of entities. There's usually a dozen or a couple of dozen of items in each one. They can be roughly described like:

type EntityA = {
  id: string
  regularProperty: string
  otherRegularProperty: number
  relatedBEntityId: string
  // ...
  oftenChangingProperty: string
}

type EntityB = {
  id: string
  commonProperty: string
  otherCommonProperty: number
  // ...
  rapidlyChangingProperty: object
}

type EntityC = {
  id: string
  boringProperty: string
  otherBoringProperty: number
  // ...
  sometimesChangingProperty: string[]
}

There's id-based relation between entities. Application displays them in multiple lists (the UI is somewhat heavy), filtering them basing both on relations and user-defined filters. Again, roughly:

const selectFoo = createSelector([selectA, selectB], (itemsA, itemsB) => {
  return itemsA.filter(itemA => itemsB.find(itemB => itemB.id === itemA.relatedBEntityId))
})

const selectBar = createSelector([selectA, selectB, selectC, selectFilters], (itemsA, itemsB, itemsC, filters) => {
  return itemsB.filter(...).sort(...).map(item => {
    id: string
    commonProperty: string
  })
})

// and many other similar selectors

The problem is that EntityB["rapidlyChangingProperty"] changes often - on average there's at least one update for at least one entity every second (planning to throttle update actions through RTK's batching functionality but data needs to be updated at < 1-2s interval anyway), which results in all selectors that use EntityB being invalidated - causing recalculation and generation of a new result reference. There's noticeable impact on performance.

What bothers me is that EntityB["rapidlyChangingProperty"] is responsible for 80% of recomputations but it's actually irrelevant for 2/3's of selectors and for half of lists that render EntityB. If deep comparison was used over shallow - one would notice that many selector outputs don't change that often.

For a while I thought about splitting EntityB slice into two - one of them storing EntityB without this property and the other storing a map of that property - in theory it seems like it would prevent a lot of recomputations, but this solution just feels a bit weird.

Are there any other common approaches to this? Or it's better to give up on memoizing data and instead focus on preventing unnecessary renders using React means? Any help is very welcomed 🙂

[markerikson]

You might want to look into using https://github.com/dai-shi/proxy-memoize , which uses proxies to track which specific fields are being accessed. Not sure if it'll help in this case, but worth a shot.

That said, yeah, it does sound like these EntityB items are changing, which means new references, which means recalculations. That's pretty much inherent in the React/Redux model - immutable updates, reference comparisons to determine what's changed. Given that, splitting out that value may be worth looking into.