Cleaner server-side dependency injection into `getInitialProps`?

[fionawhim]

Just wanted to raise something that I’ve noticed using the beta.

During server-side rendering (using the custom routing and renderToHTML), there are some server-side dependencies I want to make available (for example, a means of injecting requests directly into my Hapi app so that the server-side data fetching doesn’t go through a network interface). In some cases I also have data to seed an initial Redux store based on the request.

Currently I’m getting this data in by attaching custom properties to the Node Request object that’s passed in to the context.

This is fine, though a little awkward. I was raising this up in case you want to make it easier to add server-specific properties to the getInitialProps context.

[sedubois]

If I understood right, sounds like a similar need to #978

[fionawhim]

My issue is more about getting server-specific inputs into getInitialProps. I'm actually not concerned that creating the Redux store twice on the server is much of a performance hit given that the second time it's hydrated with an initial state, but I also don't know much about redux's internals.

[reel]

@finneganh It's easy to add an interface with HOC to handle that. The problem is with prefetch as it might not be hydrated properly. It will only go through getInitialProps without server context. So, you will have to duplicate the server code to your getInitialProps. It gets messy. You can have a look at https://github.com/simplehub/henri/blob/master/src/client/withAuth.js and withClient.js

[fionawhim]

Using a HOC to pull things off of the req is a little cleaner. I’m just wondering if adding things to req is the best way forward or if there should be another server-side mechanism for getting stuff into ctx.

[sedubois]

@reel prefetch doesn't execute code, it only downloads it.

[thangngoc89]

I want to give a +1 for this. Currently, I'm setting up the GraphQL server in the same express instance with next.js . (I know it's bad practice but for a side project it's more than enough). Since Heroku disable local network, I had to perform some weird trick to proxy the request back to my server when doing server side rendering.

Apollo Server document stated that I should use https://github.com/af/apollo-local-query to avoid going through the HTTP stack. But doing that mean I need to bundle postgres, my schema and everything in the client bundle.

[reel]

I found a solution for this... If you're using apollo or any other query that can be done server-side and client side, export your data fetching function from your React component file. Then, once you hit that route on the server, require the dist file and try to execute that function. Then, inject the result in req.data or anywhere else and render.

Reference: https://github.com/simplehub/henri/#withdata
Implementation: https://github.com/simplehub/henri/blob/master/src/henri.js#L107

I know it's not bulletproof but it works!

[unregistered]

I know this thread is old but it seems like one way to do this is to allow passing custom data in the render() set of methods (including renderHTML()) to be given to getInitialProps(), maybe a field called serverData.

That call seems to be done here: https://github.com/zeit/next.js/blob/v3-beta/server/render.js#L63-L64

Would be a relatively simple fix if there's interest in a PR for this.

[thangngoc89]

@unregistered You can use eval

if (!process.browser) {
  const serverData = eval("require("postgrest")
}

Webpack can't resolve eval so it won't end up in client bundle

[atainter]

@thangngoc89 The idea is that data should be fetched server-side and passed though the component on render for a truly isomorphic SSR. The current method seems to be passing data through the req object in an additional data key. It's a bit roundabout and can have some implications if you're using flow types, etc.

@unregistered is suggesting that a simple code change could make this more explicit by adding a serverData key to the render method.

[unregistered]

@thangngoc89 For those who already have a bunch of server-side data fetching being done in routes in their express apps, being able to pass the data through the nextApp.render() method would be very natural I think.

Also surely recommending consumers of your library to use eval to hack around webpack is a bit inelegant?

[thangngoc89]

@unregistered it's just my workaround for my usecase (see above). It works great for me. But you can do it another way if you like. IMHO, going through the HTTP stack is the easiest way of doing this. Same logic for client and server

[timneutkens]

@unregistered I'm not highly opposed to your idea of adding another parameter. @arunoda what do you think? 😄