Investigation: try React-Redux v7 / v8 with React 18 alpha

[markerikson]

React 18 is now available as preview alpha releases (per https://reactjs.org/blog/2021/06/08/the-plan-for-react-18.html ).

The React team has put together a Working Group discussion forum to describe the changes in React 18 in more detail: https://github.com/reactwg/react-18/discussions

Looking at that forum, there's several issues that may be relevant to React-Redux in some way:

• Overviews:
  • Introducing React 18
  • Upgrading to React 18 on the Client
  • Installing React 18 Alpha
• Behavior changes:
  • Automatic batching
  • Adding Strict Effects to StrictMode
  • How to support Strict Effects
  • Testing with Strict Effects
  • How to support Strict Effects

I'd like to have some folks start trying out React-Redux v7 with React 18 alpha, and report any interesting findings. We could potentially use some of the example apps from the Redux tutorials, and any of the example CodeSandboxes linked in our docs.

You would need to:

• Switch the React version to one of the React 18 alphas, and update the app to use React.createRoot() per instructions
• Try out the app
• Hand-inspect the behavior to see if anything seems unexpected

We're interested in seeing examples and comparisons with both connect and useSelector.

It would also be worth cloning the React-Redux repo, and updating our React devDep to run our tests against the alphas.

The React team has reported that a brief test of a couple Redux-based apps combined with createRoot + StrictMode did not appear to be working correctly - in particular, no re-rendering happening despite actions being dispatched.

It's very possible that Strict Effects running effects callbacks more than once is causing problems with subscriptions.

We'd appreciate any feedback reports!

Please provide this info:

• Details on the example app used
• Link to updated source code / CodeSandbox if possible
• Description of observed behavior, good or bad ("works okay", "clicking button X doesn't update the UI", etc)

[gaearon]

Note to folks trying — if you have StrictMode on, please test both with StrictMode and without it. This is to see if some issues only occur in StrictMode. (StrictMode has gotten “stricter.”)

[timdorr]

We actually have tests for StrictMode in our suite already, so it should be good to test at least the basics here.

[markerikson]

Okay. First issue here is that there's this new "Strict Effects" thing which is enabled if you're using createRoot() + <StrictMode>, which double-runs the effects in the same way that <StrictMode> has traditionally double-run renders. I could easily see that messing up subscriptions.

So, we'd need to figure out how to do a React 18 upgrade for our tests, which I assume would mean something with React Testing Library since that's doing the rendering?

[nickserv]

If you're asking about Testing Library compatibility, you may want to subscribe to testing-library/react-testing-library#925 (proposed as an alpha).

[ryota-murakami]

I have a side project that used to React-Redux v7.2.4, I'd like to try it if React 18 alpha working on CRA v4.0.3.

[markerikson]

Comment from the React team on plans for helping the community do updates:

reactwg/react-18#56 (comment)

The first step is to explain what work we see needs to be done at a high level, so we're working on a workgroup post that will be a "Concurrent rendering for library maintainers" guide, and documentation for new APIs libraries will use to support concurrent features. Those docs will be a "kick off" for starting library support. After they're published, we'll do a Q&A / support session, and use the working group to document questions, use cases, patterns, design, etc.

I know we're all really excited to start with the work of adding support to libraries, so I'm sorry it's taking so long. We've spent the last couple weeks kicking off the release (which focused on the gradual adoption strategy), and now we're transitioning to working with libraries to support the new concurrent features.

We expect this work to take months, not weeks, similar to how the hooks release went.

[markerikson]

Mobx has a PR going that's tracking some similar status checks for React 18. Worth keeping an eye on that:

mobxjs/mobx#3005

[artem-malko]

Hi @markerikson! I have something interesting for you)

I have a repository with react 18 + SSR + redux for UI state. There is an interactive demo — http://158.101.223.0:5000/

As you can see, there is a button "Patch query string". If you'll click this button, the UI state in a redux-store will be updated with new Date().toString() There is a source code. Top part of the page has a component, that has a subscription to the redux-store vis useSelector.

So, if you will open the demo with a query param strict=true, the whole app will be wrapped with component. If there is no strict query param — without it. Click to the button, that changes the query string works perfectly in strict mode and without it. But, it works in production build only.

If you will clone the repository, exec npm i && make dev and open http://localhost:4000?strict=true, you will see, that the UI won't be changed after the button click.

Actually, I can not understand, what is the difference between develop and production build in case of redux/react-redux. May be it is because of react?

I understand, the project is quite big. But I've tried to make it easy to repeat the problem. Other stuff from that repo is not so important, as think)

[gaearon]

Example of StrictMode + createRoot breaking it, per request from reactwg/react-18#19 (comment): https://codesandbox.io/s/serverless-wood-uouyy?file=/src/index.js

[markerikson]

And copying over some excellent detective work from @Andarist at reactwg/react-18#19 (reply in thread) :

The problem is not that dispatching doesn't work (although you probably didn't mean exactly that) and it's not even because components are not subscribed - because they are. The problem is that the hooked up listener is a "proxy" listener:

react-redux/src/utils/Subscription.ts

Lines 111 to 115 in d859c23

	function handleChangeWrapper() {
	if (subscription.onStateChange) {
	subscription.onStateChange()
	}
	}

which actually forwards notifications to another one that is put as a property on the subscription object. And that property gets "nullified" in the cleanup of the Provider:

react-redux/src/components/Provider.tsx

Line 43 in d859c23

subscription.onStateChange = undefined

while not being re-instantiated in the setup because it's only assigned within useMemo here:

react-redux/src/components/Provider.tsx

Line 25 in d859c23

subscription.onStateChange = subscription.notifyNestedSubs

So what happens is that Provider gets notified about a store change - it should notify nested subscriptions but it doesn't because of the mentioned issue. And useSelector (and probably any other inner subscribers like connect etc) are never notified about this because they are subscribed to that parent subscription that lives in the Provider here.

TLDR; lack of symmetry between setup/cleanup of an effect in the Provider led to the notification chain being broken.