Component is partially re-rendering on client

[Stanko]

Description

It is a little bit hard to explain, but I'll do my best. I stumbled on a following issue, although example here is simplified for the sake of replication.

When you render following component, everything works fine in development mode (gatsby develop).

import React from "react"

const Test = () => {
  const isServer = typeof window === 'undefined';
  const env = isServer ? 'Server' : 'Client';

  return (
    <div className={ env }>
      { env }
    </div>
  );
}

export default Test;

After building it, server page is rendered as expected:

<div class="Server">Server</div>

But after client apps loads and hydrates, component is rerendered as

<div class="Server">Client</div>

If you log env it will properly say Client in the browser's console.

EDIT: It can be easily hacked by calling setState in componentDidMount, but I would like to figure out a cleaner solution. This is the old comment but even react team suggested just that in 2016.

Steps to reproduce

• Follow quick start guide to setup Gatsby Default Starter
• Take component I posted above and render it anywhere
• Run npm run build and npm run serve
• Visit http://localhost:9000/ and compare server returned html and client rendered one

Expected result

Once on the client, I would expect to get this output for this specific component

<div class="Client">Client</div>

Actual result

As described above, component's root element is reused and not updated.

<div class="Server">Client</div>

Environment

  System:
    OS: macOS 10.14.3
    CPU: (8) x64 Intel(R) Core(TM) i7-7920HQ CPU @ 3.10GHz
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 11.10.0 - ~/.nvm/versions/node/v11.10.0/bin/node
    npm: 6.8.0 - ~/.nvm/versions/node/v11.10.0/bin/npm
  Languages:
    Python: 2.7.15 - /usr/local/bin/python
  Browsers:
    Chrome: 72.0.3626.121
    Firefox: 65.0.1
    Safari: 12.0.3
  npmPackages:
    gatsby: ^2.1.27 => 2.1.27
    gatsby-image: ^2.0.31 => 2.0.31
    gatsby-plugin-manifest: ^2.0.22 => 2.0.22
    gatsby-plugin-offline: ^2.0.24 => 2.0.24
    gatsby-plugin-react-helmet: ^3.0.8 => 3.0.8
    gatsby-plugin-sharp: ^2.0.25 => 2.0.25
    gatsby-source-filesystem: ^2.0.23 => 2.0.23
    gatsby-transformer-sharp: ^2.1.15 => 2.1.15

[DSchau]

Hey! Thanks for this question!

This is how our SSR at build-time works. That logic will be parsed once when the component renders (in a Node.js environment) and then will be rendered to HTML. Once the client-side code picks up (e.g. when run in a browser) that logic won't be re-evaluated because there's nothing that will trigger re-evaulating that code. If you want some type of re-evaluation, you'd need to do a dynamic, stateful check, something like the below should work:

import React, { Component } from 'react'

export default class ClientServer extends Component {
  state = {
    env: 'server'
  }

  componentDidMount() {
    this.setState({
      env: `client`
    })
  }

  render() {
    const { env } = this.state
    return (
      <React.Fragment>
        {/* This will render (As static HTML) I am rendered on the server, and will update client-side with I am rendered on the client */}
        <h1>I am rendered on the {env}</h1>
      </React.Fragment>
    )
  }
}

Hopefully I've adequately explained this. Is there anything else I can help with?

[Stanko]

Got it, I was hoping there is a way to avoid it. Do you think it deserves a mention in the documentation?

Thank you very much and keep up the good work!

[DSchau]

Not sure. I don't think we'd necessarily want to encourage this pattern. We'd moreso recommend to write your code in a way that doesn't necessarily have to care whether rendered on the client or server. If you want access to window globals, treat those as enhancements on top of the initial base--not necessarily serving differing behavior or content which doesn't make a ton of sense.

Could you describe your use-case in more detail? Maybe I'm missing something!

[Stanko]

Hey, sorry for the delayed response.

In the application I'm currently working on, we have a very complicated layout which changes based on window size (breakpoint) and scroll position. Usually we solve this by rendering two components and hide one on small breakpoints and other on large, using CSS. In this case it is a page layout, and we would have to render the whole page twice. Breakpoint and scroll position values are both null on the server, but layout is not rerendered properly on the client.

It is a niche usecase.

[wodCZ]

Please mention this in the documentation. I've spent too much time finding this info.

In my use case, I use localstorage to persist user's selection on previous page (or in previous session) and change the className based on that. Pretty similar to how Author's original component.

Maybe a quick mention here: https://www.gatsbyjs.org/docs/debugging-html-builds/ ?

It's confusing that the behaviour is different in develop mode vs in html build.

[Stanko]

I agree, even if it is gatsby anti-pattern, it should be mentioned.

For now, (components that are not important for SEO) we are not rendering on server at all, by using this high order component:

import React, { Component } from 'react';

/*
Unfortunately gatsby assumes server and first client render are identical.
Therefore it doesn't rerender components on client side even their props have changed.

Check this issue for more information:
https://github.com/gatsbyjs/gatsby/issues/12413#issuecomment-470987990
*/
const renderOnClient = ComposedComponent => class RenderOnClient extends Component {
  state = {
    isClient: false,
  }

  componentDidMount() {
    this.setState({
      isClient: true,
    });
  }

  render() {
    const {
      isClient,
    } = this.state;

    return isClient ? <ComposedComponent { ...this.props } /> : null;
  }
};

export default renderOnClient;

[aychtang]

This should be mentioned in documentation. I've also experienced some strange behaviour where a component partially updates its HTML output on hydration.

[derykmarl]

Yes please on the documentation! I just wasted almost 3 working days puzzling over this.

What I had was a youtube component that I only wanted to render if I know the user has accepted cookies (oh the joys of GDPR), and to render an alert instead if they haven't. For the life of me I couldn't work out why, when building and deploying the production site, once cookies were accepted, if I reloaded the page the component rendered the Youtube embed INSIDE the alert, like it was some sort of Schrodinger's Youtube Component, in two states at once. I was tearing my hair out :)

Well it appears it's because during SSR it draws the alert, then on hydration it only updates what it "knows" has changed and leaves the "outer" alert intact, causing this visual glitch. Thanks to the info in here and in a stackoverflow thread I eventually figured out that I need to build state into the component and trigger a state change via componentDidMount to force it to do a full re-render on hydration. My implementation is a bit convoluted but I use connect(mapStateToProps) from redux to update the component's props, and then componentDidMount and componentDidUpdate (with "if" statement to make sure it's actually changed, to avoid an infinite loop error) to feed this prop back into the component's local state which causes it to re-render.

So my "acceptCookies" variable gets passed around a lot... it goes from redux context to a prop and then to component state. But it works at long last.

[codebravotech]

Agreed about adding this to the documentation. In my case, I needed to use dangerouslySetInnerHTML which behaves slightly differently in CSR and SSR (server side, it wraps the contents of the __html property in an extra div), so the server render and client render weren't identical, causing an odd behavior where gatsby was rendering the resulting component partly in English (the default language that's rendered during SSR) and partly in the intended localized language.

I think it was reusing the server-side div (on which the property dangerouslySetInnerHTML was set) and since that property was originally the english text (on the server side), it was never updating.

[dcramer]

@codebravotech I believe we're hitting a similar issue - how'd you address it?

We've got something akin to:

const Content = ({html}) => <div dangerouslySetInnerHTML={{ __html: html }} />;

In a production build on initial load it reads in some state/props, sets that html, and wont always update it correctly. If i use the 'html' fragment in anything else (e.g. <div>JSON.stringify()</div>) it works fine.

Seems very related to the above, but a sightly different case.

[codebravotech]

@dcramer Yep, so since the server-side tag is getting reused (not the contents, just the tag), the prop dangerouslySetInnerHtml (which is part of the tag) is not getting the updated value of the new props. I'm not totally clear on what is causing that behavior in ReactSSR and gatsby, but the good news is it's an easy fix. (The approach is outlined in some of the comments above- friendly reminder to always make sure you really understand the whole comment chain before asking the same question again. If you have questions or don't understand, its always cool to clarify, but it's helpful that others know you've familiarized yourself with all the information on the chain.)

So- Make html a state value that gets set to the value of the props after first render. This will force a re-render that replaces the server-generated tag entirely with one generated client-side. Looks like you're using a functional component the useState and useEffect hooks, so follow the example below (untested but should be a good enough starting point):

const Content = ({html}) => {
  const [innerHtml, setInnerHtml] = useState()
  
  useEffect(() => {
     setInnerHtml(html)
  }, [])

  return (<div dangerouslySetInnerHTML={{ __html: innerHtml }} />);
}

I would recommend wrapping this behavior in a HOC so you can re-use it elsewhere that you might run into this edge case (for example, i've noticed it not update the "placeholder" property of an input tag)

[dcramer]

Ah I get the above examples now. This is super helpful, and agree with the general sentiment in this thread on the confusion. It was difficult enough to just Google for the issue we were seeing.

Thanks!

[kilinkis]

Lost three hours in this 😿

[presencewebdesign]

Gatsby is a bag of crap. Stick with create react app