Concurrent Mode

[brunolemos]

Do you want to request a feature or report a bug?

Feature

What is the expected behavior?

Full compatibility with Concurrent Mode

Details

We should be close to a Concurrent Mode release, and people are already experimenting with it on their projects. I am not sure but it seems react-redux is not compatible yet, based on this tweet and this pr.

[markerikson]

There's still no ETA on when Concurrent Mode will be released, and there's also a general lack of clarity on what exactly it will include, what the impacts are, and what the points of incompatibility may be.

As Dan said in issue #1164:

We need to be clear that there are several “levels” of compatibility with new features of React. They’re not formalized anywhere yet but a rough sketch for a library or technique X could be:

• X breaks in sync mode
• X works in sync mode but breaks in concurrent mode
• X works in concurrent mode but limits its DX and UX benefits for the whole app
• X works in concurrent mode but limits its UX benefits for the whole app
• X works in concurrent mode but limits its DX and UX benefits for features written in X
• X works in concurrent mode but limits its UX benefits for features written in X
• X works in concurrent mode and lets its users take full advantage of its benefits

This is not a strict progression and there’s a spectrum of tradeoffs. (For example, maybe there is some temporary visual inconsistencies such as different like counts, but no crashes are guaranteed.)

But we need to be more precise about where React Redux is, and where it aims to be.

Until Concurrent Mode is actually out and completely documented, we can really only speculate on the potential interactions, and there's a lot of other stuff that I'd rather spend my time worrying about.

I'll leave this open as a placeholder, but it's not an immediate priority.

[dai-shi]

I don't mean any rush, but while it's not an immediate priority, let's do some experiment.
I made a small repo for reproduction of "tearing" (as far as I understand).
https://github.com/dai-shi/will-this-react-global-state-work-in-concurrent-mode

It would be nice if someone could review it as I might be biased.
Please file issues there about this tool or any related discussion, not to disturb this issue here.

[gcloeval]

Hello redux team,

We were just wondering if there are any updated guidelines or at least high-level predictions on building components libraries on top of react-redux and making sure, to the best knowledge available, they will play nicely with concurrent mode?

We have switched fully to hooks version with useSelector for reading data and useDispatch for writing. We are also making sure that we do not do any side effects during rendering, i.e. all the dispatches are done inside useEffect. To be honest - just this - to only dispatch inside useEffect - has resulted in complete refactoring of entire codebase. Since its been a few months that this issue was opened, it would be great to get some more feedback from the team about the future.

Thanks for your hard work!

[markerikson]

@gcloeval: nope, no further updates, because there's no new info available on Concurrent Mode.

Realistically, I expect React-Redux won't be "compatible", in the sense that folks expect store updates to be readable immediately. That said, it may not be a blocker from using Concurrent Mode.

[Guria]

@markerikson now we have updates on concurrent mode could we see a future of this?

[markerikson]

The short version is that it's going to be up to the community to experiment and see exactly where the incompatibilities are. I don't currently have time to look into it myself, and I don't have enough experience doing data fetching to work with most of the concepts that are described.

As an example, Dan told me that Suspense transitions would likely be problematic, because you'd end up with cases where the Redux store is already updated from a dispatched action and thus trying to display "new" UI, whereas Suspense would want to still be displaying "old" UI.

Dan gave some short related answers on Redux + Suspense/CM in this SO answer.

The other major issue is "tearing", where new Redux actions might be dispatched during the pauses in rendering, and thus cause different parts of the tree to read different versions of the store state during the same render pass. (The v6 implementation was intended to avoid this by passing the current store state via context for consistency, but we had to drop that approach and go back to direct subscriptions due to perf problems.)

Dan has strongly recommended trying to duplicate some of the Suspense/CM demos with Redux. Someone on Reactiflux was trying to do a bit of that the other day, and I'll see if I can paste in their comments.

But yeah, I'm gonna have to ask folks to go experiment with this and report their findings here. My own focus for the foreseeable future is on rewriting the Redux core docs and encouraging people to use Redux Starter Kit.

[salvoravida]

Hi folks.
My idea is to change forceRender into useSelector hook, let instead set a state, and return that state.
This should transform redux state changes into react useState changes that should batched and eventually paused form react concurrent mode useTransition.

[markerikson]

@salvoravida : if you've got ideas, please feel free to prototype them and see how they work out.

That said, I'm not sure how what you're describing is actually different than what we do right now internally, and it doesn't change the issue that there's going to be differences between what the Redux store says is the "current" state value, and what React is currently wanting to display based on Suspense changes.

[eddyw]

The "tearing" issue is .. expected. At least within Suspense.

• Suspense just tells to display a fallback UI if some component is waiting for some data to be "ready"
• useTransition (startTransition), tells Suspense to keep the old UI visible for a specific time (setup with { timeoutMs })

If the old UI needs to display "current" data, then it's a blocking-update and React will warn about it with or without using Redux. So the point is to "bake" useTransition within your components (as suggested in docs). Within a transition, it basically tells React to update the new UI (that is in memory and not displayed yet).

The mechanism is pretty simple actually. This is what tells Suspense to .. suspend the UI:

const MyComponent = () => throw { then(tellSuspenseThatWeAreReadyForNewUI, fail) {} }
const App = () => {
  return (
    <Suspense fallback="New UI not ready">
       <MyComponent />
    </Suspense>
  )
}

So, the main issue I think is .. what to throw 🙈 and how/if react-redux can help with that or if it needs to be implemented on user side.

This is a very naive implementation:

const promise = { // throw this instead
  then(tellSuspenceToContinue, throwAnError) {
    const unsubscribe = store.subscribe(() => {
      if (store.getState() !== STATUS.PENDING) {
        ubsubscribe();
        tellSuspenceToContinue();
      }
    });
  }
};

Here is a sandbox which describes what I mentioned above:
https://codesandbox.io/s/peaceful-spence-yh8w7
It shows the differences with/without useTransition (check console)

A complete separate issue is tearing that is not related to "intentional transition/suspense tearing" that could happen when nested components render too slow. However, I don't know if this is a bug or not. I found out that some slow renders are never committed to the DOM, so I'm just waiting for a more .. stable - experimental release 🙈 to know if it's really a thing to worry about or not. Currently happens because of nested Providers with react-redux. However, I haven't tried using react-redux hooks. I suspect that the issue shouldn't be if there are no connected components and just hooks but I haven't really had the time to test that.

[markerikson]

Related issue: JustSift/ReSift#32

[salvoravida]

@eddyw i can't see any unexpected behavior in your demo.

on StoreState changes -> useState.setState
within startTransition setState delay 5000ms so you will see correctly old UI until "Loading".
that's the correct behavior.

if after startTransition, storeState changes many times it will enqueue setState many times.
after transition end due to 5000ms timeout or promiseResolve (Suspense end transition on promise resolve) all pending setStates will be batched/executed and you will see on screen only last
"reduxStore" update.

that's fine.

Am i missing something?

[markerikson]

We're having a good discussion with Dan atm on Twitter about whether it would be helpful for the React team to try porting a couple of the Suspense demos to Redux to show what's broken, and and how we might be able to understand the issues involved.

A few entry points into the subthreads (read up and down from these links):

https://twitter.com/dan_abramov/status/1192569023529140231
https://twitter.com/dan_abramov/status/1192570534543933441
https://twitter.com/EphemeralCircle/status/1192574816815108096
https://twitter.com/dan_abramov/status/1192579208423378946

[dai-shi]

Oh, there's so much going on here.

In my perspective, the tearing issue is relatively easy. We just take the approach either by use-subscription or reactive-react-redux. (Both have slight issues, but let's put aside.)

What's hard is the new pattern with Suspense and CM. Transitions and Render-as-You-Fetch pattern. This is not because of the core libraries redux and react-redux, but rather async middleware and best practices. In my blog post, I used "action hooks". My optimistic expectation is reactive-react-redux with no async middleware may work in CM. The question is if you call it a "React Redux" app, I mean what value do we get from Redux.