How to use library with code splitting with React.lazy and use declarative routing?

[fedulovivan]

Say with have several modules, one for each page. Each of them is pretty heavy, and its not an option to load them all in advance to prepare static routes map as demonstrated in example (const routes = [{ path: '/foo', component: Page1 },...];)

Each module contains async-connected page component + appropriate reducer.

first create lazy wrappers for each page:

const Page1 = lazy(async () => {
    const moduleBundle = await import(/* webpackChunkName: "Page1" */'src/pages/Page1');
    injectAsyncReducer(store, moduleBundle.constants.NAME, moduleBundle.reducer);
    return moduleBundle;
});
const Page2 = lazy(async () => {
    const moduleBundle = await import(/* webpackChunkName: "Page2" */'src/pages/Page3');
    injectAsyncReducer(store, moduleBundle.constants.NAME, moduleBundle.reducer);
    return moduleBundle;
});

injectAsyncReducer function re-configures store and injects reducer for certain page using replaceReducer redux utility.

now init provider, router, suspense-wrapper, define routes and mount tree:

ReactDOM.render(
    <Provider store={store}>
        <BrowserRouter>
            <GenericContainer>
                <App>
                    <Suspense fallback={<div>Loading...</div>}>
                        <Switch>
                            <Route path="/page1">
                                <Page1 />
                            </Route>
                            <Route path="/page2">
                                <Page2 />
                            </Route>
                        </Switch>
                    </Suspense>
                </App>
            </GenericContainer>
        </BrowserRouter>
    </Provider>,
    renderTarget,
);

so the question, where is the place for <ReduxAsyncConnect> component here?

[alaycock]

@fedulovivan did you end up finding a solution for declarative routing? A fork or another package?

[fedulovivan]

@alaycock Yes, finally I have managed to launch our legacy code with latest version of redux-connect, but this approach required to use some monkey-patching and final solution appeared to be not that elegant (I even cannot remember what particulary was changed).
Being honest, now we are trying to eliminate usage of async connect in our code and switch to following architecture for the root component for the page:

const PageComponent: React.FC<PageComponentProps> = (): JSX.Element => {
    // state
    const [startInitialLoadTriggered, setStartInitialLoadTriggered] = useState(false);
    // selectors
    const isPendingInitialLoad = useSelector(selectors.isPendingInitialLoad);
    // actions
    const startInitialLoad = useAction(actions.startInitialLoad);
    // effects
    // trigger initial load
    useEffect(() => {
        setStartInitialLoadTriggered(true);
        startInitialLoad();
        // eslint-disable-next-line react-hooks/exhaustive-deps
    }, []);
    // minor imperfection after elimination of redux-connect:
    // we need to skip first render
    // since effect with startInitialLoad is not yet executed
    if (!startInitialLoadTriggered) return null;
    return (
        <Page title={PAGE_TITLE} bodyClassName={style.root}>   
        </Page>
    );
}

action startInitialLoad is handled by folowing epic which triggers fetching of required data

    // fetch initial data on page load
    (action$, state$) => action$.pipe(
        ofType(actions.startInitialLoad.TYPE),
        mergeMap(() => {
           return of(
               actions.fetchEtities(),
               actions.fetchEtitityAttributes(),
            );
        })
    ),

isPendingInitialLoad selector returns true if any of async operations (fetch requests) are still in progress.

[alaycock]

Thanks, @fedulovivan for the response and the example! I was exploring something similar, but removing redux-connect also seems like a potential solution.

[abhagsain]

Thanks, @fedulovivan for the response and the example! I was exploring something similar, but removing redux-connect also seems like a potential solution.

@alaycock Were you able to remove redux-connect? If so what else did you choose?

[alaycock]

@abhagsain we're still running it. There's some pretty tight coupling between redux-connect and some of the other packages we depend upon which can make it hard to remove. We just found a proprietary solution for code splitting and are running that instead.

[abhagsain]

Got it. @alaycock could you please tell me which version of react, react-router/react-router-dom are you using with redux-connect? I'm trying to upgrade from react@15.3 to react@16.8 and react-router@v3 to react-router-dom@v4 but having a hard time.

[alaycock]

@abhagsain your best bet is to look at the package.json for the peer dependencies if you haven't already.

You should be able to upgrade to a more recent version of React without any issues while continuing to use react-router 3. That is a small step forward.

As for our versions, we're pretty far behind. We're on redux-connect@6.0.0 which requires react-router 3, so we're in a similar boat as you. Upgrading to a more recent version of react-router can be a pretty significant undertaking, which is why I'd aim to remove redux-connect before trying to do that upgrade. Trying to do both at the same time would make the project more complex than it needs to be, in my view.

I haven't actually looked into if that's reasonable or possible, so you'll have to do your own exploration.