This PR:

• Is a first prototype to see if we can use the WIP React "concurrent stores" API as a replacement foruseSyncExternalStore
  • Added a Yalc-built version ofhttps://github.com/thejustinwalsh/react-concurrent-store that exposes a couple additional types to satisfy TS
  • Adds a copy of thereactStoreEnhancer from the polyfill tests
  • Updates<Provider> andReactReduxContext to render the polyfill's<StoreProvider> component and thereactStore instance in context
  • RewritesuseSelector to call the newuseStoreSelector hook instead ofuseSyncExternalStore, and adds wrapper logic that tries to backfill support for equality checks and unstable selector references (hopefully to be handled by the hook itself later on)
  • Adds acreateTestStore util that configures the store with the React store enhancer
  • UpdatesuseSelector.spec.tsx to use thatcreateTestStore util for all of its stores
  • UpdatesuseSelector.spec.tsx tomostly pass:
    • commented out now-broken assertions that accessed the React-Redux internal subscription counts, as the current implementation is now relying on the polyfill'sStoreManager class to manage subscriptions
    • Disabled the "O(1) subscription removal" test, asStoreManager is using an array and not a linked list like ourSubscription class
    • Updated all places where we get different selector call counts, which increased noticeably (1 -> 3, 2 -> 4, 4 -> 8, 3 -> 5, etc). Clearly the new implementation is calling selectors a lot more.

Background

@captbaritone and@thejustinwalsh have been working inhttps://github.com/thejustinwalsh/react-concurrent-store to prototype the upcoming React "concurrent stores" API. As a loose description, what we're hoping for is "useSyncExternalStore, minus theSync" - aka a concurrent/transition-compatible way to integrate external state into React.

They've got a first POC polyfill up on NPM asreact-concurrent-store, and the repo has a couple tiny demo integrations for Relay and Redux.

This is my attempt to do an experimental integration and rewrite React-Redux to use it and see how far we get, a la the alpha integration ofuseSyncExternalStore in#1808 .

Results

Impressively, especially for just a couple hours of hacking:

All but 3useSelector tests pass!

The caveat is that I did change pretty much all places where we assert the number of selector calls (which all went up 2+ calls), and disabled a couple places where we asserted that we had N active internal subscriptions (as this mechanism bypasses our own Subscription implementation).

The test failures are:

• A test that asserts we always use the latest selector
• 2 tests that expect we handle errors thrown from selectors in a specific way

 FAIL  test/hooks/useSelector.spec.tsx > React > hooks > useSelector > uses the latest selectorAssertionError: expected [ +0, +0 ] to deeply equal [ +0, 1 ]- Expected+ Received  Array [    0,-   1,+   0,  ] ❯ test/hooks/useSelector.spec.tsx:481:31    479|           forceRender()    480|         })    481|         expect(renderedItems).toEqual([0, 1])       |                               ^    482|    483|         rtl.act(() => {⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯[1/3]⎯ FAIL  test/hooks/useSelector.spec.tsx > React > hooks > useSelector > edge cases > ignores transient errors in selector (e.g. due to stale props)AssertionError: expected [Function doDispatch] to not throw an error but 'Error' was thrown- Expected:undefined+ Received:"Error" ❯ test/hooks/useSelector.spec.tsx:528:34    526|             })    527|           }    528|           expect(doDispatch).not.toThrowError()       |                                  ^    529|    530|           spy.mockRestore()⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯[2/3]⎯ FAIL  test/hooks/useSelector.spec.tsx > React > hooks > useSelector > edge cases > re-throws errors from the selector that only occur during renderingAssertionError: expected [Function] to throw an error ❯ test/hooks/useSelector.spec.tsx:602:14    600|               normalStore.dispatch({ type: '' })    601|             })    602|           }).toThrowError()       |              ^    603|    604|           spy.mockRestore()

Analysis

I believe our own v7useSelector implementation would catch errors, swallow them, and force a re-render (under the assumption that if you had a stale props / "zombie child" scenario, then the problems would all go away by the time the component was done re-rendering). I don't know what the currentuSES semantics are, but hereuseStoreSelector is clearly doing something different.

The selector stability test is obviously failing due to some combo of the actualuseStoreSelector implementation not actually supporting unstable selector references and the attempt to make them work in userland here.

Overall, though, this is a pretty solid indication that we're on the right track already. Those are all pretty edge-case-y things, and the core functionality is working.

connect?

Thisdoes bring up a big question about if and how we'd be able to convertconnect over. Personally I'd rathernot :)connect has always been a big ugly beast of an implementation, and as it is I'm pretty sure the hacks I've got in place right now are an abuse ofuSES's semantics. I don't even want to think about making that work withuseStoreSelector. I'd be perfectly fine saying "NOPE,connect works as-is, with all its limitations, No Concurrent Behavior For You, go migrate touseSelector if you want that".

Store Enhancers?

You'll note this POC requires adding a Redux store enhancer to let us capture the action create the "React-compatible store":

exportconstaddReactStore:StoreEnhancer<{reactStore:ReactStore}>=(createStore)=>{return(reducer,preloadedState)=>{conststore=createStore(reducer,preloadedState)// Create concurrent-safe store wrapperconstreactStore=createStoreFromSource({getState:store.getState,reducer:reducer,})// Intercept dispatch to notify reactStoreconstoriginalDispatch=store.dispatchstore.dispatch=(action:any)=>{constresult=originalDispatch(action)reactStore.handleUpdate(action)returnresult}// Attach reactStore to Redux storereturnObject.assign(store,{ reactStore})}}

It's hypothetically possible we might be able to find a different solution as we go, but as a first attempt this seems like the right integration point to me. This is something that would presumably be addedafter the middleware enhancer (and before the DevTools?), so that it only sees actions that are about to reach the reducer. (Actually, now that I say that... I don't know what happens when you try time-traveling in the DevTools, so that's something we should investigate.)

Subscriptions?

I realized this bypasses our ownSubscription class entirely. That class has historically served 3 purposes:

• It enforced React batching pre-React-18
• It allowed us to do cascading updates in the commit phase, which was necessary to enforceconnect's invariants that "mapState always sees the latest props from its parent"
• By using a linked list for subscribers instead of an array, we get O(1) performance for removing a subscriber (Optimize createListenerCollection #1523 ,Switch back to Subscription in useSelector to fix unsubscribe perf #1870 ). The polyfill'sStoreManager class is using an array, so it presumably has that same perf problem. (I looked atuSES, and technicallyI don't think it actually tracks any subscribers itself?

Some of the tests failed because they asserted there were N active subscriptions, and now we don't have any subscriptions ourselves at all.

I'm not sure what happens if you were to mix-and-match at this point. I assume that aconnect in the tree would still get triggered fromSubscription.

To some extentStoreManageris an alternative toSubscription. Probably ought to use a linked list there if it's going to track subscribers, though.

Next Steps

useStoreSelector Changes

Perthejustinwalsh/react-concurrent-store#13 we really need this to allow unstable selector references, because this is a standard ecosystem pattern:

consttodo=useSelector(state=>selectTodoById(state,id))

We also need to handle customizable equality checks. Currently we rely onuseSyncExternalStoreWithSelector supporting that:

• useSyncExternalStoreWithSelector.js:isEqual

useStoreSelector will probably need to do something similar.

There's also the error-handling semantics question.

Testing Scenarios

Beyond that, though, we'd want to start adding some tests with transition behaviors and see what happens.

We'd also want to do some testing with Redux middleware and the Redux DevTools and see what happens and what expectations might break - certainly in normal sync mode, then with transitions added in.