Local update in the component that uses store causes an extra update from store

[mahmutyilmazcs]

Summary

Component receives an extra update from the store when its local state changed even though the field it uses from the store never changed.

This is observed in valtio + react usage case and reproducible for both react v16-17 and react v18. With one difference: React 18 optimizes the double update and blocks the one(I guess)

When following code block is used in the component, you see double commit and double render logs for react v.16.13(also applicable for v17) case and single commit and double render logs for react v18.2 case

useEffect(() => {
    console.log("commit");
  });
console.log("render");

Link to reproduction

Please open console and observe logs and profile the app to see an extra update store triggers for both cases.

react v16.13 + valtio v1.9.0

react v18.2.0 + valtio v1.9.0

Note that both examples above are NOT in Strict Mode.

[dai-shi]

This is expected behavior. If it renders from parent or state, in this case useState, we need to run the render and commit, because bool in this case may change the result.

The difference between react 18 and pre-18 is also expected. It's because react 18 comes with automatic batching. To get the same behavior in pre-18, one would need to use unstable_batchedUpdates.

[mahmutyilmazcs]

Yeah, or put bool in valtio state and eliminate useState. The whole problem is having two different states.

This resolves all problems :) But is not doable. Because, I use a library and it triggers an update inside. Then my component again renders itself because it uses valtio store.

However, let's talk about my approach in the previous answer. In this case every field must be in its own object. This is because, when we add a timezone info to 'time' like this timeObject: {value: 1, timeZone: 3}, then, when timezone changes, the component that only uses time.value would get double render again. So, we have to change it to be timeObject: {value: {value: 1}, timeZone: {value: 3}} and subscribe whatever portion of the timeObject you need but it's not maintainable at all.

Morever, I said

Of course it couldn't know when there is previously unexecuted code blocks. I see...

in the previous answer but when previously unexecuted code block gets executed for the first time, doesn't it already get the latest value from the store(because it is reading for the first time) and while doing so, valtio can register its listener for that field for further updates?

[greenwish84]

Hmm, what an interesting problem😃

@dai-shi First of all, thanks for implementing this great library that extremely simplifies the global state management 👍

If I understand correctly, when 2 components (no parent-child relation) have the same snapshot call (useSnapshot(state)), although each uses separate fields of the state object (1st one "time", 2nd one "count"), any update to a field (ex: time field in the 1st component) will trigger a render for the other one (2nd component that only uses count field) as well?

If this is the expected behaviour, I think it should be mentioned "specifically" in the documents this way. Also, this may be considered as a little bit of a pitfall for the default valtio usage. I expected that the library would trigger a rerender for a component only for the updates to the fields it use.

As mentioned by @mahmutyilmazcs, object based field subscription (scoped subscription) may not be desirable for both usage and maintainability. I hope for a solution to this issue for the sake of this library's great reputation 😃

[dai-shi]

If I want to block this double render.

But, you don't need to. If double render causes real performance issue, you want to memoize heavy computation.

Morever, I said

Again, there are two different states. React returns the old state value unless you explicitly update it. In our case, count will be zero. Play with the example in #638 (reply in thread). This behavior has nothing to do with valtio. React works like that.

[mahmutyilmazcs]

I see why it can't register listener when first read happens, because that first read can be made from one of previous snapshot objects that valtio no longer keeps track of. I got it.

Yeah, or put bool in valtio state and eliminate useState. The whole problem is having two different states.

This resolves all problems :) But is not doable. Because, I use a library and it triggers an update inside. Then my component again renders itself because it uses valtio store.

However, let's talk about my approach in the previous answer. In this case every field must be in its own object. This is because, when we add a timezone info to 'time' like this timeObject: {value: 1, timeZone: 3}, then, when timezone changes, the component that only uses time.value would get double render again. So, we have to change it to be timeObject: {value: {value: 1}, timeZone: {value: 3}} and subscribe whatever portion of the timeObject you need but it's not maintainable at all.

Morever, I said

Of course it couldn't know when there is previously unexecuted code blocks. I see...

in the previous answer but when previously unexecuted code block gets executed for the first time, doesn't it already get the latest value from the store(because it is reading for the first time) and while doing so, valtio can register its listener for that field for further updates?

[dai-shi]

when 2 components (no parent-child relation) have the same snapshot call (useSnapshot(state)), although each uses separate fields of the state object (1st one "time", 2nd one "count"), any update to a field (ex: time field in the 1st component) will trigger a render for the other one (2nd component that only uses count field) as well?

No. This only applies when it's rendered by other state.

btw, the said behavior happens in some of my other libs, for example use-context-selector and use-valtio.
It's still intentional. While it can be improved, it's simple implementation with useReducer.
useReducer works interestingly in React 18: https://twitter.com/dai_shi/status/1534170089981100032

The rationale is double-render-with-single-commit is almost by design, and it's not a problem. The right solution is useMemo.