Large store performance

[Josef177]

Hi,

Imagine a store in which there are many properties and the functional components of the entire application use these properties using:

useStore(state => state.property1)
useStore(state => state.property2)
...

Imagine that there are roughly 200 components (mostly repeating) each using dozens of properties from this one store.

So my 1st question is: could it be a performance issue to figure out which components to render when one property changes? E.g. property1?
(I understand that only components that use this property1 are rendered, but in my opinion it must be difficult to figure out which ones they are when there are a lot of them and they all use dozens of properties from the same store.)

I think yes. So what if we split the store using the slices pattern: https://github.com/pmndrs/zustand/blob/main/docs/guides/slices-pattern.md
Or use an equally interesting solution using zustand-lens https://github.com/dhmk083/dhmk-zustand-lens
However, in my opinion, both solutions will not improve performance, since all functional components still use one store, e.g.:

useGlobalStore(state => state.property1) 
useGlobalStore(state => state.property2) 
...

Is it right?

So my 2nd and main question is: is physical separation into completely different stores the solution to this possible performance problem?
(These properties theoretically do not need to be in one Store, as they are mostly independent on each other.)

Thanks a lot for any answer.

[dai-shi]

Using multiple stores instead of one combined store can improve performance. (It's often called "scoped subscriptions")
But, whether it will be a bottleneck or not is questionable. Often the case, it's premature optimization. You want to measure it in a practical setup and compare.