Separate build code from runtime code

[jhnns]

Following up #794

---

Currently, the react-server-cli generates code that is dependent on data that is provided on build time (like the routes file) or the clientBootstrapFile.

Since this code is part of the react-server runtime, it should imho be located in the react-server package. All the dynamic stuff like logging options and routes should be provided by static objects that are generated on build time (and are not actually written to disk).

This way, it's easier to reason about the actual code since code generation can quickly become messy. The clientBootstrapFile, for instance, would look like this:

if (typeof window !== "undefined") {
	window.__setReactServerBase = function(path) {
		__webpack_public_path__ = path;
		window.__reactServerBase = path;
	}
}
var reactServer = require("react-server");

// dynamic modules generated on build time
var options = require("react-server/options");
var routes = require("react-server/routes");

window.rfBootstrap = function() {
	reactServer.logging.setLevel('main', options.logLevel);
	reactServer.logging.setLevel('time', options.timingLogLevel);
	reactServer.logging.setLevel('gauge', options.gaugeLogLevel);
	new reactServer.ClientController({routes: routes}).init();
}

It also provides a cleaner separation of react-server and react-server-cli which means that I could use my own react-server-cli if the cli is too invasive for my taste. Ideally, it would even be possible to use another bundler but that is beyond my personal scope.

[roblg]

All the dynamic stuff like logging options and routes should be provided by static objects that are generated on build time (and are not actually written to disk).

Does this mean that require('react-server/options') and react-server/routes would be "intercepted" by webpack, and would be filled in with content at build time, but would never be written to disk?

So I think what I'm hearing is:

• clientBootstrap.js would be a static file, provided by react-server. (e.g., the webpack config might have react-server/clientBootstrap, or similar in each entrypoint.
• we'd have a webpack plugin (or alias?) in the webpack config that identified react-server/routes, and react-server/options requires, and replaced them with JSON representations of routes/options objects from memory.

If that's what you're suggesting, I'm on board, with the possible addition that clients should have a way to provide a path to their own clientBootstrap.js file. From the perspective of a new user of react-server, the change s/b transparent, and I think it makes things simpler for a more advanced user.

[jhnns]

Does this mean that require('react-server/options') and react-server/routes would be "intercepted" by webpack, and would be filled in with content at build time, but would never be written to disk?

Yes

clientBootstrap.js would be a static file, provided by react-server. (e.g., the webpack config might have react-server/clientBootstrap, or similar in each entrypoint.

Exactly.

In fact, my suggestion is not that different than the current implementation. I would just push dynamic stuff into dedicated modules instead of assembling code.

we'd have a webpack plugin (or alias?) in the webpack config that identified react-server/routes, and react-server/options requires, and replaced them with JSON representations of routes/options objects from memory.

You just need a loader for that. Loader generate code on build time, that's it.

If that's what you're suggesting, I'm on board, with the possible addition that clients should have a way to provide a path to their own clientBootstrap.js file. From the perspective of a new user of react-server, the change s/b transparent, and I think it makes things simpler for a more advanced user.

I don't think that option is necessary. If you want to use react-server outside the react-server-cli, you need to instruct your bundler of choice to replace react-server/routes and react-server/options with the result of a given generateRoutes() or generateOptions() function. browserify can do that.

[roblg]

I don't think that option is necessary.

It's possible that it's not required, and I think I'm OK with this change moving forward without it, it just feels a little strange to me to require magic in whatever bundler you choose in order to use react-server. That being said, I'm also OK leaving out the option to specify a different clientBootstrap file initially to see if anybody asks for it. Seems like it wouldn't be that hard to add if we decide we need it later.

[jhnns]

it just feels a little strange to me to require magic in whatever bundler you choose in order to use react-server

It does not necessarily require "bundler magic". You could also write that file to disk before calling webpack, pretty similar to the current implementation. The third option is to put this information on window and read it on runtime, but that wouldn't be my choice 😉

[roblg]

For sure. My "magic" comment was referring to the webpack-generated file being located in react-server/options in your example (var options = require("react-server/options");) -- I wouldn't be comfortable generating a file and putting inside my-app/node_modules/react-server in order to make that default clientBootstrap file work, so I'd either have to use a bundler like webpack or browserify, or I'd need to override the default clientBootstrap to make it work. Not a huge deal in the immediate term though.