How to conditionally include packages on client but not server (and vice-versa)?

[evantahler]

Say you wanted to render some maps in your Next application. You chose the fairly popular react-leaflet project, which takes the very popular leaflet library... and React-izes it.

It turns out that Leaflet is in fact not ready for an isomorphic application, as it has things like window and navigator all over its codebase. This is turn causes Next to crash with a sad ReferenceError: window is not defined.

You can't use conditional logic in your map component because include statements need to happen at the top of the file, and at boot. You can change from include to require (and require conditionally), but that seems like a bad idea, and Next throws a warning (below). You can block rendering a map on the server, but not the inclusion of the react-leaflet => react libraries.

The warning Next throws when using a conditional required:

Warning: React attempted to reuse markup in a container but the checksum was invalid. This generally means that you are using server rendering and the markup generated on the server was not what the client was expecting. React injected new markup to compensate which works but you have lost many of the benefits of server rendering. Instead, figure out why the markup being generated is different on the client or server:
 (client) react-empty: 27 --><!-- react-empty: 28 
 (server) react-empty: 27 --><p data-reactid="28">

It's fairly easy to check if you are running on the sever or client:

export default function isNode(){
  // http://stackoverflow.com/questions/4224606/how-to-check-whether-a-script-is-running-under-node-js
  return (typeof process !== 'undefined') && (process.release) && (process.release.name === 'node');
};

How should we handle something like this? I could imagine a try/catch scenario when rendering on the server looking for specifically window, navigator, etc and rendering a small ./pages/_unrenderable.js in those components.... but that seems... hacky.

[mikecardwell]

Conditional require is probably the way to go. That's not a Next error, that's a React error. React warns if you do an initial render to an element that already contains react component markup inside it which doesn't match exactly. You want to make sure that the first render on both the server and the client creates the exact same structure. So if you want to render something like a map on the client but not the server, don't do it until after the initial render. You can do this by setting some state in componentDidMount which causes a re-render with the actual content you want displayed (componentDidMount only gets run on the client)

let mapLib;

export default class SomePage extends React.Component {
  constructor () {
    super();
    this.state = { showMap: false };
  }
  componentDidMount () {
    mapLib = require('some-map-library');
    this.setState({ showMap: true });
  }
  render () {
    return (
      <div>
        {
          this.state.showMap ? (some sort of map thing) : "Loading map"
        }
      </div>
    );
  }
}

On the above example, the first thing rendered on both the server and the client is <div>Loading map</div>

P.S. The above is untested and I am not a Next developer, just a random guy trying to use it.

[evantahler]

That's some good hackery! Thanks!

... I'm going to leave this issue open in case there's a better way, but this gets me where I need to go!

[sedubois]

@mikecardwell using setState in componentDidMount triggers a second render and can cause prop/layout thrashing (I noticed thanks to the eslint no-did-mount-set-state rule).

[frol]

@sedubois That is quite obvious, isn't it? The alternative is to either ignore React warnings or hack React to drop the checksums validations (I think, the minified version of React drops these checks for you)... The choice is yours.

[mikecardwell]

It does trigger a second render. That's why this fixes the problem being discussed. "prop/layout thrashing" sounds much worse than it is. It makes sense to generally avoid calling setState in componentDidMount if you can do it elsewhere, e.g. componentWillMount, but in this case, we want to trigger a second render, and the first render is so tiny that it's not going to hit performance.

He could even stick this at the top of his render function:

if (!this.state.showMap) return null;

I don't think we'll get much "thrashing" from rendering nothing to the page once.

[sedubois]

Yes it's obvious, but was less obvious that it's a "bad practice" as flagged by the eslint rule. Would just have been nice to render properly in one go. But yes, not a big deal, it's just hacky as mentioned.

[mikecardwell]

I don't think there's anything that could be done in the next framework to avoid this "hack". It's entirely a React issue. I've had to do stuff like this in the past when it comes to dates. Imagine the following component:

const component = () => <p>{ Date.now() }</p>;

That will trigger this exact same problem. The initial render on the server will show one date and the initial render on the client will almost certainly show a different one unless the server and client clocks match to the millisecond, taking latency between server/client render into account.

[arunoda]

@evantahler You could use react-no-ssr:

import React from 'react';
import NoSSR from 'react-no-ssr';
import Comments from './comments.jsx';

const MyPage = () => (
  <div>
    <h2>My Blog Post</h2>
    <hr />
    <NoSSR>
      <Comments />
    </NoSSR>
  </div>
);

In the above example, comment will only render on the client.

[evantahler]

@arunoda again, it's not a problem of controlling rendering, it's a problem of import

[arunoda]

@evantahler Okay. got it.
Then I agree with @mikecardwell solution and it's totally fine to have a another render on the client.

With SSR, it won't be another render.
First rendering of the component will take care by SSR and in the client it simply use the code comes with SSR.
Then it'll do another render to load the client only stuff.

For me this is totally how it should be done.
I don't see an anti-pattern here.

[nkzawa]

I think we can close this now.

Additionally, if you'd like to include a module only on server, you can conditionally require and exclude it from a bundle file for client like the following (v2 or later).

// pages/index.js
const isServer = typeof window === 'undefined'
const foo = isServer ? require('foo') : null

// next.config.js
module.exports = {
  webpack (config) {
    config.externals = config.externals || {}
    config.externals.foo = 'foo'
    return config
  }
}

[kaelhem]

I'm facing a similar issue as @evantahler with react-leaflet.

The fix proposal (mounting map only on client side) seems a good approach, but I cannot manage to make it work.

The error is :
Uncaught (in promise) TypeError: Cannot read property 'removeLayer' of undefined. at _fn.componentWillUnmount (eval at evalScript (eval-script.js?cb1dd48:22), <anonymous>:2255:24) at ReactCompositeComponent.js?7b94502:409 at measureLifeCyclePerf (ReactCompositeComponent.js?7b94502:75) at ReactCompositeComponentWrapper.unmountComponent (ReactCompositeComponent.js?7b94502:408) at Object.unmountComponent (ReactReconciler.js?cb1dd48:79) at Object.unmountChildren (ReactChildReconciler.js?7b94502:146) at ReactDOMComponent.unmountChildren (ReactMultiChild.js?e45aa37:373) at ReactDOMComponent.unmountComponent (ReactDOMComponent.js?7b94502:980) at Object.unmountComponent (ReactReconciler.js?cb1dd48:79) at ReactCompositeComponentWrapper.unmountComponent (ReactCompositeComponent.js?7b94502:418)

Did you encounter this error guys?
Any help will be greatly appreciated!

[mikecardwell]

I could probably diagnose your problem if I saw your code. Going on the error message alone, I haven't a clue.