Suspense for lazy-loading reducers

[NotTheUsual]

This is a bit in the realm of “you’ve been asked not to do this for a reason” but, well, if you’re in the mood for something slightly inadvisable, read on.

We’ve set up our app to lazy load different pages with React.lazy, as you do. And, to match, we’re lazily adding Redux modules with the injectReducer function suggested on the Code Splitting page of the Redux docs.

The reducer injection happens in a few of these entry point hooks dotted around the app, which also cover loading extra translations, etc. We check if we’ve run the initialisation before, and if not set everything up in a useEffect block (if it’s done in the body of the component, we get the warnings that we’re trying to update another (Redux-y) component from the body of this one). Looks a bit like this

let setup = false;

export function useInitialise() {
  const store = useStore();
  const [isInitialised, setIsInitialised] = useState(setup);
  
  useEffect(() => {
    if (!setup) {
      store.injectReducer('count', countReducer);
      setIsInitialised(true);
      setup = true;
    }
  }, []);
  return isInitialised;
}

You then tend to end up with a component arrangement something like this

const Counter = React.lazy(() => import('./Counter'));
const Parent = () => (
  <Suspense fallback={<Loader />}>
    <Counter />
  </Suspense>
)

export default function CounterEntrypoint() => {
  const initialised = useInitialise();
  if (!initialised) return <Loader />;
  return <CounterBody />;
}

const CounterBody = () => {
  const count = useSelector(selectCount);
  // you get the idea...

Now, here’s the part where people start to frown at me. Towards the end of last week, slightly tired, I proposed trying to Suspend the component while we initialised the code. Upsides being that (1) we wouldn’t have to manage the loading state ourselves, (2) we could slot the entry point hooks at the top of any component, knowing that any code below it would only be run post-initialisation, (3) these files were almost always used in lazy-loaded components, so almost always sat inside Suspense boundaries anyway. The downsides, of course, being that it’s an undocumented, unsupported API that you’re absolutely not meant to use in production code, for sensible reasons.

Code then starts to look more like this

let setup = false;

const useInitialise = () => {
  const store = useStore();

  if (!setup) {
    const promise = new Promise((resolve) => {
      store.injectReducer('count', countReducer);
      setup = true;
      resolve();
    });
    throw promise;
  }
};

// Parent code as-was

export default function Counter() => {
  useInitialise();
  const count = useSelector(selectCount);
  /// etc
}

which does feel nicer! To my eyes, anyway. Shame it doesn't fully work outside of tiny demos.

The issue looks like this:

• to suspend a component at the moment, you have to throw a promise from its body - IE not in an effect
• to inject a reducer in a way that doesn’t irritate React, you have to inject it in an effect

And the code above falls foul of the second condition when you try to add it to a real app.

Now, again, the obvious answer is “just don’t use the unreleased API” but while I’m down in this rabbit hole, the questions I have are:

1. Is it possible to inject a reducer without triggering that warning? (Other than being very excellent about what’s memoised where)
2. Is this the kind of thing that fits with (a) the direction that suspense is going in, and (b) how we’d expect reducers to be lazily added?
3. You don’t happen to know of a more-secret more-forbidden “do this work outside of the render phase, but not via useEffect” API, do you?

Maybe worth discussion of how reducers “should” be lazily added in general? The docs talk about creating injectReducer (or alternatives), but less about calling them.

Anyway, thanks for indulging me by reading this far (if you have) - hope there’s something interesting here for you, too.

[markerikson]

Appreciate the writeup! I'm going to try to give some quick initial thoughts. this wasn't quick, was it.

First, a caveat: I haven't done any actual lazy-loading of reducers myself. I'm familiar with the theory and basic mechanics, of course, but I've never tried to implement it in any app I've worked on.

I think that the idea of leveraging Suspense in the lazy-loading process is actually a very viable approach, both in concept and in potential implementation. It just isn't something that had specifically occurred to me here.

Suspense is sorta-kinda documented-ish, at this point. There's plenty of libs using it, and the "throw a promise" mechanism is well known. It's also correct to be throwing that promise while rendering, because React immediately suspends rendering for that component. From its point of view, there's never any inconsistency - by the time it does get rendered for real, it has data available and just keeps on chugging.

The React team has documented a lot more of how Suspense will work in React 18 in the Working Group discussion threads in the last couple weeks:

• What changes are planned for Suspense in React 18?
• Behavioral changes for Suspense in React 18

There's a lot of precedent for lazy-loading happening in the render phase. In fact, I've been told that it was critical to do this in the constructors of class components, so that the store was updated before mapState would run and try to read those slice reducers. React-Redux v6 actually broke that approach, because we passed down a single consistent state value per render pass. See some prior discussion in these React-Redux issues:

• <Provider> misses state changes that occur between when its constructor runs and when it mounts react-redux#1126
• RFC - API for dynamically adding reducers react-redux#1150

What "warnings" are you seeing atm? Is it the one where React says "you can't update another component while this one is rendering"? If so, I actually wouldn't expect that to be happening here, if you have well-written selectors, because none of the other parts of the state have changed and they should still be returning identical references as the last call.

Given that you're looking at using Suspense, though, you ought to be able to do the store.replaceReducer() in a brief setTimeout(). Promise still gets thrown immediately, component still suspends, quick delay, store's updated, promise resolves, and that update happens outside the render phase.

So, to specifically answer your questions:

1. I don't think you should be seeing any warnings (such as "can't update other components while rendering") unless you've got some malformed selectors that are causing re-renders when they shouldn't be
2. I think this definitely fits into where React is going Suspense-wise
3. Nope, no hidden secrets here.

I'm going to ping @Ephem , who I know has done a lot of work around SSR and lazy-loading with Redux, and also see if anyone else has thoughts on this.

[Ephem]

No, we don't do SSR, so I hadn't considered that at all, sorry.

No need to apologize! This thread was about your specific case, I just wanted to add some context around the extra complexities that comes with SSR for anyone reading along. 😄 For the record, I think there might be extra issues with using Suspense for reducer injection in the SSR-case, but I didn't want to go into details there because that wasn't what the thread was about.

The Suspense version protects me from, well, myself on that front.

Maybe a little when it comes to that setTimeout avoiding triggering updates in render, but even if there is no warning for that (because the API itself is undocumented and unstable?) I think it's still bad triggering updates inside of a Suspend too, at least long term. The safest thing when doing this client side only, at least long term, would be to keep doing it in an useEffect. I appreciate how that can be a hassle both because of managing the loading state and since the following selectors will still run before injection though. I'd hoist it into a component instead, something like (you could also do a HoC like some libraries that solve this do):

function WithReducer({ children, reducerName, reducer, fallback }) {
  const store = useStore();
  const [initialised, setInitialised] = useState(false);

  useEffect(() => {
    if (!initialized) {
      store.injectReducer(reducerName, reducer);
      setInitialised(true);
    }
  }, [reducerName, reducer, store, initialised]);
  
  if (initialised) {
    return children;
  }

  return fallback;
}

// In a component:

function MyComponent() {
  const data = useSelector(getDataSelector);
  // ...
}

export default function ComponentWithReducer(props) {
  return (
    <WithReducer reducerName="name" reducer={reducer} fallback="...">
      <MyComponent {...props} />
    </WithReducer>
  );
}

On the other hand I think this probably works well enough with Suspense today and if you are the kind of person that is willing to experiment with unstable APIs, maybe you are also willing to accept the cost of changing this back to a useEffect if you run into problems in the future? 😄 One thing makes me wary though:

(see also: any other processes we might want to run in that initialisation step)

I don't think Suspense is meant to be safe for this. Suspense is not useEffect with built in render-blocking and a built in loading state, I'm pretty sure it's (going to be) a lot more constrained than that. It might work in some cases (idempotent/non-observed effects), especially when not using future concurrent features, but I'm pretty sure using it for "initialisation in general" is a footgun.

(If it's not, I'm going to celebrate heavily, because that would solve a whole bunch of other problems I'm thinking about.. 😁)

[markerikson]

FWIW, I think this is actually an entirely valid use case for Suspense, and here's why.

If you look at the demos the React team has shown previously, they usually look like:

function MyDataUsingComponent({id}) {
  const item = someDataResource.readById(id);
  
  // render logic
}

Under the hood, someDataResource.readById():

• Checks to see if there is a cached value representing data for that ID
• If there is, it's returned synchronously
• If not, it immediately starts a data fetch (a side effect! gasp!), creates a promise representing that data, and throws it

React suspends the component, waits for the promise to resolve, and then starts a new render. We readById() again, this time the data is there, and the component continues loading.

So, from the component's point of view, there's nothing "side effect"-y going on. Of course the read always succeeds! it has no idea that the request actually got triggered the first time, because there's no visible evidence that anything is getting thrown code-wise. It's an internal implementation detail of this resource.

To me, loading a reducer is exactly the same principle. We have a thing we want to load. If it's already loaded, great, we just keep right on going and use the actual data. If not, we start the process of loading it, throw a promise, and let it resolve some time later.

That's the distinction of the "algebraic effects" thing the React team keeps bringing up. I still don't understand what that means, exactly, but for this discussion, we can say that as long as the component sees no observable side effects happening, it's safe.

FWIW, I'll try to bring up this use case as part of the React 18 Working Group in the near future to get some additional feedback, but my summary takeaway here is that the "load a reducer with Suspense" concept is sound and the snippet is fine.

[Ephem]

but for this discussion, we can say that as long as the component sees no observable side effects happening, it's safe.

I totally agree! As I said in the first post, I think it's fine to do this with Suspense, but the same constraints as in render might apply and if so maybe you don't gain anything by it. So if what @NotTheUsual is after is "I'm not sure if the reducer injection will trigger a rerender somewhere, so I'll do it in a Suspend to be safe" I'm not sure that will hold true (at least in the future) and useEffect might be safer if that is what you want to guard for.

Btw, reducer injection is only safe in a Suspend if we treat it as a resource to be cached forever. If we care about reducers not being injected unless something is listening to them, it wouldn't be safe (think huge apps and memory problems maybe, or just very small amounts of memory available like in IoT perhaps?). But that's a very niche caveat.

[andreawyss]

I lazy load redux slices using this library:
https://vmware.github.io/slices-for-redux/docs/concepts/mutable-reducers

[Ephem]

I guess we should probably link to the dynamic reducer injection part of Marks excellent ecosystem links collection here for a whole bunch of library alternatives for this: https://github.com/markerikson/redux-ecosystem-links/blob/master/reducers.md#dynamic-reducer-injection 😀

[epeterson320]

@NotTheUsual I think two things may make this task much easier.

1. Add a hasReducer() method on the store instance.
2. Import the slices via normal (not dynamic) import in the components where they're used, and use the typical React.lazy() mechanism for code splitting.

So to implement:

1. Import base store in slices.
2. Export slice-enhanced hooks in slice files, e.g. useCheeseDispatch or useBreadState.
   For SSR, this may require writing it with a useStore() and if store.hasReducer(r) check.
3. Import slice-specific hooks in components (normal import, not dynamic import).
4. Continue to code split via components via React.lazy(). The redux slices will be imported as the components that use them are imported.

Code examples:

// @filename: store.ts
export function createStore(/* ... */) {
  return configureStore({
    // set up store so it has addReducer and hasReducer.
    // have a minimal or empty reducer, initially.
  });
}
export type BaseStore = ReturnType<typeof createStore>;

// @filename: cheeseSlice.ts
import { useDispatch, useStore, useSelector } from 'react-redux';
import { createSlice } from '@reduxjs/toolkit';
import type { BaseStore } from './store.ts';
const cheeseSlice = createSlice(/* ... */);
export const useCheeseDispatch = () => {
  const store = useStore();
  if (!store.hasReducer(cheeseSlice.reducer)) store.addReducer(cheeseSlice);
  return useDispatch();
};
export const useCheeseState = () => {
  if (!store.hasReducer(cheeseSlice.reducer)) store.addReducer(cheeseSlice); // DRY it how you want
  return useSelector(store => store.cheese);
}

// @filename: CheeseDashboardPage.tsx
import { useCheeseState } from './cheeseSlice.ts'
export const CheeseDashboard = props => {
  const cheeseState = useCheeseState();
  return <span>You have {cheeseState.quantity} slices of cheese pizza</span>;
}

// @filename AppRouter.tsx
import { lazy } from 'react';

const CheeseDashboardPage = lazy(() => import('./CheeseDashboardPage'));

export const AppRouter = () => (
  <Switch>
    <Route path="/cheese" element={<CheeseDashboardPage />} />
  </Switch>
);

This will keep your reducers out of the main bundle, and since you're putting <Suspense> at the page level, each page's slices will be loaded with the page.

[epeterson320]

Gotcha, I didn't realize that would dispatch during render. Never mind, then.

[phryneas]

Why not just inject the reducer immediately on file load?

[epeterson320]

I think it's because the store isn't available in module scope in some SSR scenarios, so you can't import store from .... That works for browser-only code, though.

[phryneas]

Why would you want to lazy-load code on the server though?

[Ephem]

Why would you want to lazy-load code on the server though?

I just chanced upon this on going through some old notifications, but I saw this was unanswered so I thought I'd leave a quick note. There are a couple of reasons, the main one being supporting serverless. In those cases, you usually need to load a quite small part of the code to answer the request and cold boot times are important, so code splitting makes sense. Even for more traditional server use, being able to not load and parse all code up front can make sense for bootup times for large applications.

In my experience, in a lot of cases devs not using frameworks that do this for them just don't though and mash everything together in a huge server.js file in the end.