Component not aware of state change? about reactive-react-redux

[mrGibi]

Ok, both examples are working now. Thanks!

[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".

[dai-shi]

OK, let me make a fix.

[dai-shi]

Here you go: db485e0
Would you try with this commit? @mrGibi

[mrGibi]

db485e0 didnt help 😔

Since you pushed to master, we can use it on Codesandbox by using:

"dependencies": {
    // ...
    "reactive-react-redux": "github:dai-shi/reactive-react-redux",
    // ...
  },

in package.json. Click here to open this codesandbox.

Its based on your example from README.md but with additional multiple button that triggers two dispatch() in Counter.tsx. As you can see, clicking multiple button doesnt trigger component update.

Additionaly you can use my example repo on localhost with this:

git clone https://github.com/mrGibi/reactive-react-redux-tests.git
cd reactive-react-redux-tests/
npm install
npm start

[dai-shi]

Oh... It wasn't about useLayoutEffect nor updating state.
It's about useForceUpdate. @theKashey
I didn't expect useReducer bails out for boolean.

Interestingly, if you add one more dispatch, it works. @mrGibi

const hc = () => {
  dispatch({ type: "increment" });
  dispatch({ type: "increment" });
  dispatch({ type: "increment" });
};

If you have another to make them four, it won't.

[mrGibi]

I dont get it...

I had two examples showing the issue:

• One example from my initial post: using reactive-react-redux 1.8.0 together with redux-saga that triggered:

yield put({ type: "TURN_ON" });
yield delay(10);
yield put({ type: "TURN_OFF" });

• and second example with multiple button: codesandbox here that triggered:

const hc = () => {
  dispatch({ type: "increment" });
  dispatch({ type: "increment" });
};

I thought that both examples are pretty much identical, but the second one was just simplified version of the first one. Its all about making two (or more) fast changes to the state and component not being aware of those changes, right?

Well it turns out that they are not as similar as I thought, becouse after your latest commit to master, the first example (now using latest reactive-react-redux from github/master) is working correctly. See here.

And the second example with:

const hc = () => {
  dispatch({ type: "increment" });
  dispatch({ type: "increment" });
};

now using latest reactive-react-redux from github/master (codesandbox) still doesnt work 🤷‍♂️

[dai-shi]

Please try the latest master.

[dai-shi]

So, the question remained to me is whether we really need useLayoutEffect. @theKashey

• state1 {a:1, b:1}, we are using only a.
• component render
• committed & inner state update
• state2 update {a:2, b:2} - change detected, force update
• component render, which uses b
• state3 update {a:2, b:3} - no change detected
• committed & inner state update
• no update (false negatives)

So, your approach totally depends on useLayoutEffect run 100% sync.

[theKashey]

Yes. As long as you might have multiple renders before single useEffect, and you have to track purely only one render - you have to useLayoutEffect. You have to "close" tracking just after render.

[dai-shi]

If we both revert useLayoutEffect and "close" tracking", it still works (no false negatives).
We have false positives (#20 (comment)), though it's different from what is happening to @mrGibi 's example.

If both are correct, oh and if we solve the concurrent mode issue in the future, we don't need useLayoutEffect.
I just feel like useLayoutEffect is a last resort we'd like to avoid unless we have a real problem.

[dai-shi]

@theKashey I also want your comment on this.

[theKashey]

If we both revert useLayoutEffect and "close" tracking", it still works (no false negatives).

🤷‍♂️ I am not sure why it works. Give me some time to play with it.

[dai-shi]

If both are correct, oh and if we solve the concurrent mode issue in the future, we don't need useLayoutEffect.

This "if we solve the concurrent mode issue" is kind of strong condition more than I thought on the previous day.
I saw useIsomorphicLayoutEffect in react-redux thread, which works around the warning issue, so I'd follow that.

[dai-shi]

https://www.npmjs.com/package/reactive-react-redux/v/2.0.0