Component not aware of state change?

[mrGibi]

I've been fighting this all day today.
Im new to Java/TypeScript world, React world and Redux world and I was pretty sure that I messed something up... until I tried doing the same with React-Redux (7.0.0.beta-1) and it turned out it works there!

Im writing a authorization flow with redux-saga - so this example that Im going to show you is just massively simplified code similar to mine. CodeSandboxes below.

Description: TOGGLE button dispatches an action that is caught by redux-saga. The Saga dispatches an action to toggle a value to true, wait 10ms, and then dispatches another action to toggle value back to false. Meanwhile the button is disabled if value === true, and there is a value ? 'ON' : 'OFF' text. Interestingly if you increase delay() value to (for example) 50ms it works!

How does it look like:

• using react-redux 7.0.0-beta.1 (good!)
  

• using reactive-react-redux 1.8.0 (bad!)
  

This was shot on MacOs 10.14.4 and Safari 12.1.
I have tested this also on:

• iOS: latest Safari, latest Chrome and latest Firefox. Results are the same, although on Firefox sometimes I had to click "toggle button" couple of times to "achieve" this issue.
• MacOs: latest Chrome, latest Firefox. On Firefox and Chrome sometimes it needs couple of clicks to get there.

Check out these codesandboxes:

• using react-redux 7.0.0-beta.1
• using reactive-react-redux 1.8.0

I dropped on this issue by accident. In my original code the delay function is just a Api call. This Api call had a wrong port number set so it got Connection refused and returned immediately. TURN_ON and TURN_OFF was just a isLoading indicator that disabled a Login button.

@dai-shi Im totally blown away by Your work on reactive-react-redux and @theKashey 's proxyequal. I follow every discussion, every benchmark test and commits to this repo and wish I would understand enough of it to be able to help...

[theKashey]

Just give an example to fight with! (ok, there is a sandboxes)

[theKashey]

Working on Chrome, not working on Safari or FF

[theKashey]

In short - this is due to batchedUpdates. But it's not clear why it does not work as expected.

[mrGibi]

@theKashey latest Chrome? On mine its not working on at most second/third click.
Another example, much simpler, based on @dai-shi codesandboxes from README.md: my codesandbox fork. There's a "multiple" button which triggers two dispatch(), one after the other. Component is not updating until you click "+1" or "-1" buttons.

[dai-shi]

Thanks for the example. You are already helping very much with it. @mrGibi

I think this might be related with my thoughts on #15.
Could you try this commit 10c9574 in store-state-for-updates branch?
(I'm trying it too, but codesandbox doesn't accept installing a npm package with commit???)

[theKashey]

So - by the time second update hits comparison - the last state is not yet stored in lastProxyfied.current.state

• store update
• force update
• component rerender with a new store
• use effect to save a new store
• store update
• comparison with an old store
• no update
• lastProxyfied.current.state update

[theKashey]

@dai-shi - useProxyfied should use useLayoutEffect

[theKashey]

In short - a new store update got triggered while an old update is not fully "commited".

• or use layoutEffect - it's almost sync after the render
• or update lastProxyfied.current.state after successful comparison (you have "used" it)

[dai-shi]

useProxyfied should use useLayoutEffect

Oh... I thought about that before, but yeah.
Does this #20 (comment) also help?? (maybe not. it's a different problem.)

(I've got to leave now... 🚗 )

[theKashey]

Yeah, concurrent mode. Actually, we have got tearing here, when different pieces are using states from different times.
So

• use layoutEffect to close rendering, or else you may record proxy results from more than one render.
• update lastProxyfied.current.state in the comparison function just after comparison, cos you dont need to defer it to record used keys, and you have to update it, as long as comparison with a "real" state was just made, and you dont want to redo it again, which would be the case, if state got changed one more time before a real render take a place.

[mrGibi]

Could you try this commit 10c9574 in store-state-for-updates branch?

Unfortunately this doesnt resolve the issue 😔

[dai-shi]

Good to know. I will make a useLayoutEffect version. I’m not sure if I understand the second bullet, yet.

[theKashey]

• state1 {a:1, b:1}, we are using only a.
• component render
• inner state update
• state2 update {a:2, b:2} - change detected, force update
• state3 update {a:2, b:3} - change detected, force update

Internal state was not yet updated, as a result the second comparison with an old state and a quick state update is a false positive, and might took more time than a comparison with state2.

So - once you compare a and b - set a=b

[dai-shi]

Got it. It’s false positives. I wonder if that would cause other false negatives in some edge cases?

[theKashey]

Should not. You already triggered redraw, and it would commit the "used" state in a proper time.
So - even if by any reason (Concurrent) render did happen with older state - useLayoutEffect would update the record as it should - "state used by fact".