is reactDOMServer loaded on the browser?

[yinghaochan]

RenderReact imports reactDOMServer here: https://github.com/airbnb/hypernova-react/blob/master/src/index.js#L3

Your example bundles

var React = require('react');
var renderReact = require('hypernova-react').renderReact;

function MyComponent(props) {
  return React.createElement('div', {
    onClick: function () {
      alert('Click handlers work.');
    },
  }, 'Hello, ' + props.name + '!');
}

module.exports = renderReact('MyComponent.js', MyComponent);

into the rails application using sprockets.

Does this mean the client browser is always loading reactDOMServer?

[goatslacker]

@yinghaochan yes

[Inkdpixels]

@goatslacker @ljharb Is this something that is supposed to be changed at some point? Loading server centralized code on the client does not seem to be that productive.

[ljharb]

You can always alias out that import in your bundler.

I suppose we could lazy-require it?

[Inkdpixels]

Yep I guess lazy-requiring it would be a good solution, while aliasing it is also an option this pushes the work to the user IMO. I could submit a PR for it if you haven't started working on it yet :)

[goatslacker]

While lazy requiring it is better than the current approach it's still a half solution...the bytes will still end up in the user's browser. How about we figure out a way to not require it at all?

[ljharb]

Not if it was wrapped in a process.env check that could be uglified out.

That said, splitting the server and client code into separate entry points might be the better solution.

[wingleung]

getting it started, should we break current implementations? -> https://github.com/airbnb/hypernova-react/pull/45

[gempir]

If this problem was solved hypernova could also support loadable components, which require some custom chunk loading logic where you need to require a file on the server.

But you can't have "path" imports etc on the client. I'm not sure how that can be achieved. The file splitting is a start, but it doesn't solve the actual problem of code sharing.