Reference to a computed property seems to trigger unnecessary re-renders

Using v5.0.4, I’ve noticed that making a reference to computed store properties causes the component making the reference to re-render, even when unrelated properties are being updated. I’ve made a demo to illustrate:

https://codesandbox.io/s/interesting-morning-0qbd4u

Open the console and notice the following output (which is correct):

rendering FOO
rendering BAR
rendering BAZ

Now click on either of the two Increment counter buttons (one in the Bar component, and the other in the Baz component), which will increment the store’s counter property. Note that the Foo component is the only component to make reference to counter, and as such you’d only expect rendering FOO to be output. However, you’ll notice the following in the console output:

rendering FOO
rendering BAR

Commenting out the reference to completedTodos (a computed property) in the Bar component will result in it not being mistakenly re-rendered when counter is updated.

Baz component has a reference to todos (a standard, non-computed property) which does not result in a re-render when counter is updated.

In summary, having a reference to a computed property is causing the referring component to re-render, when I believe it shouldn’t. Making a similar reference to a non-computed property does NOT cause the re-render (even when the computed property refers only to the non-computed property). Is this expected behaviour? Is there something I’m missing?

[ctrlplusb]

Just released v5.0.5. 🎉

Thanks for championing this fix @jmyrland ♥️

And thanks for all the patience ya’ll!

[no-stack-dub-sack]

@jmyrland @ROTGP I’ve dug into the code a bit more and found out that unless you use state resolvers, the input to the computed property is the parent store’s state. Knowing this, it makes perfect sense that the component that references the computed prop re-renders any time that any state changes (not just the piece of state it references).

I think then, it’s just a misunderstanding of this from the docs:

In general it is recommended that you only use state resolvers if you need to resolve state from another part of your model. There are some performance benefits to be had by isolating local state, but in almost every case this would be insignificant.

This does call out that there are perf benefits by isolating local state, I guess it’s just what is considered “insignificant” that is open to interpretation here. It would depend on how heavy the component is that’s re-rendering due to referencing a computed prop, and how often state in the parent store is likely to change. IMHO, unless there are adverse performance implications to using state resolvers in basic use-cases, then it would seem prudent to default to using them always in order to avoid un-wanted re-renders of the components that consume them. It seems like this is not an actual bug and is in-fact intended behavior, but perhaps the docs could be a little clearer on this.

Also, to support more complex computed props, the types could be expanded to allow a greater number of resolvers. I’d be happy to open a PR for this if @ctrlplusb were interested.

Thanks again for helping to look into it!