Connect HOC misses store changes when "offscreen"

What version of React, ReactDOM/React Native, Redux, and React Redux are you using?

• React: 0.0.0-experimental-e7d0053e6-20220325
• ReactDOM: 0.0.0-experimental-e7d0053e6-20220325
• Redux: 4.2.0
• React Redux: 8.0.2

Here is a Replay recording of this bug with some annotations from me: http://app.replay.io/recording/replay-failing-reactdevtools-e2e-repro--3351989d-95d4-4035-80af-07d813a623aa

Here is a Loom (it’s long) where I use Replay to investigate the problem: https://www.loom.com/share/3d60c14466184b03acc9af7b80e9eff8

Also note that this issue is specific to an experimental React API, Offscreen. The React team has published some early documentation about this API but it has not been released in a stable form yet.

What is the current behavior?

A connected component misses updates that are fired while it is inside of a hidden Offscreen component.

I believe this is because the component unsubscribes when it is unmounting and does not check for missed updates when it is later remounted. (The selectors passed tot he map-state-to-props function were not executed.)

What is the expected behavior?

The expected behavior is perhaps up for debate. Should the component process Store updates (at a lower priority) while hidden or should it wait to render them only if it’s later re-shown? In a sense, this question isn’t worth debating yet because I don’t think React currently provides an API (even an experimental one) to stay subscribed while in a hidden state.

That being said, I think the currently expected behavior is that when then Offscreen tree is later re-shown, React Redux connect should check the Store for the latest values and re-render if they have changed since the component was last rendered.

Which browser and OS are affected by this issue?

Presumably all of them

Did this work in previous versions of React Redux?

• Yes

[Andarist]

I’m afraid that this should be reopened 😅 Based on the quote above I’ve found this to be an issue with the current version of React too. Repro: https://codesandbox.io/s/goofy-kapitsa-wkojvp?file=/src/App.js

Scenario:

1. render a potentially suspending component that uses a connected component somewhere in it
2. don’t suspend right away
3. suspend (it would probably work with resuspending too, in such a case at step 2 you could initially suspend too, but u’d have to resume before resuspending)
4. dispatch an action to change the store’s state
5. resume
6. ❌ the resumed component doesn’t see the updated value

I’ve also prepared two codesandboxes to demonstrate how layout & passive effects behave in basic scenarios.

If you suspend initially then both types of effects are only setup after the value gets resolved and when the actual content gets rendered (we switch from a fallback to the content here)

However, if you suspend an already committed tree then layout effects are being “disconnected”, we switch to a fallback, the content gets merely hidden (but not unmounted). When the value resolves we switch back to displaying the content and layout effects are set up again. Note that the same doesn’t happen for passive effects - they stay “active” in such a suspended tree.

[markerikson]

sigh yeah, thanks for investigating further 😃