Multiple entry-points with React Router

[blittle]

@petehunt thank you for this explanatory repo! It has helped a lot! One question though related to React router, how do you split entry points based upon routes? I want hitting a particular router to load another set of code.

For example, to lazy load code inside the About.js module, would you just wrap it in a require.ensure statement? Or is there something more magical with react-router and webpack? @rpflorence

[blittle]

Or is this the recommended pattern? https://github.com/rackt/react-router/blob/master/examples/partial-app-loading/app.js

[aarongreenlee]

@blittle did you resolve this? Do you think this question should be asked in the React-Router community?

[sokra]

https://github.com/webpack/react-proxy-loader

[blittle]

@aarongreenlee I have moved on to other things at the moment, but plan to revisit this soon. Thanks @sokra for the link, I'll check it out!

[seanadkinson]

We adapted react-proxy-loader to load modules on willTransitionTo, and I just posted the code here: https://gist.github.com/seanadkinson/a1eb7d3a79b2036d0c5e

I didn't sanitize it to be the most reusable, but it could help others achieve what I was looking for, which is to asynchronously load page bundles when the page is requested. I have an unnecessary dependency on jquery, but that should be able to be removed easily if someone doesn't want it.

I may clean this up and put on npm soon.

UPDATE: Code published here: https://github.com/odysseyscience/react-router-proxy-loader

[catamphetamine]

Ok, I'll try your https://github.com/odysseyscience/react-router-proxy-loader

[jregeimbal]

I really like react-router-proxy-loader, however using it in an isomorphic app is giving me trouble, as the app cannot find "react-router-proxy" when processing on the server. I need a way for the serverside to understand, or ignore 'react-router-proxy' but webpack loader to still pick it up.

error: Sending 500 ("Server Error") response: Error: Cannot find module 'react-router-proxy?name=campaigns!./Campaigns.react'

This is the route def:

<Locations path={this.props.path}>
          <Location path="/" handler={MyEloqua} />
          <Location path="/campaigns/" handler={require('react-router-proxy?name=campaigns!./Campaigns.react')} />
</Locations>

[seanadkinson]

Was just commenting on server-side rendering here: https://github.com/odysseyscience/react-router-proxy-loader/issues/8

See comments there, but basically yes, we'd need to move the react-router-proxy! prefix into a place where node doesn't see it, but webpack does. The only place for this would seem to be in the configuration file, possibly using an alias, but I haven't tried this yet.

Not having built an isomorphic application yet, I'm curious what people do in situations with webpack-specific require statements (such as using the imports-loader). Is there a common strategy?

Need some help from the community on how best to support isomorphic applications in react-router-proxy-loader.

[jregeimbal]

Thanks for the response. I'd love to help work on a solution for this, and am happy to guide the development or help if needed. I've figured out two work arounds, one which came from you. The first work around I came up with is as follows:

handler={typeof require.ensure != 'undefined' ? require('react-router-proxy!./'+component) : require('./' + component)}

As you can see I am using require.ensure to figure out if the code is being reached through webpack or node (no require.ensure). Also note I am using webpack contexts, which allow dynamic requires.

This works but forces a re-draw on the client because the checksums do not match up, the error on the client is: Uncaught Error: Invariant Violation: You're trying to render a component to the document using server rendering but the checksum was invalid. This usually means you rendered a different component type or props on the client from the one on the server, or your render() methods are impure. React cannot handle this case due to cross-browser quirks by rendering at the document root. You should look for environment dependent code in your components and ensure the props are the same client and server side.

After reading your reply, I decided to try out moving the loader part to the webpack config. Turns out alias does not work but has the same client error above, but you can do this:

module: { loaders: [ { test: /Users.react$/, loader: "react-router-proxy!jsx" }, { test: /Contacts.react$/, loader: "react-router-proxy!jsx" }, { test: /.react$/, loader: "jsx-loader" } ], },

Then in the app, it's back to a simple require like require('./Users.react').

Also, dynamic contexts still work: handler={require('./' + component)}

Again same client error, this comes from the fact that react-router-proxy-loader must write something different to the HTML that is different from rendering without react-router-proxy-loader on the server.

I can try to dig in more.

[seanadkinson]

@jregeimbal Let's continue the conversation here: odysseyscience/react-router-proxy-loader#8

Not really a "Multiple entry-points with React Router" issue for react-router-proxy-loader to support server-side rendering.

[wzup]

@blittle Broken link

Or is this the recommended pattern? https://github.com/rackt/react-router/blob/master/examples/partial-app-loading/app.js

[AdrienLemaire]

Hi guys, it's 2020 and odysseyscience/react-router-proxy-loader hasn't been updated in 4 years. Do you know what's today's best practice to set webpack with entrypoints detected from react router v5 routes and react 16 ?