Document that you can't rely on React 16 SSR patching up differences

[Tarnadas]

With SSR being loaded on client side, there are various wrong behaviors if the server's HTML differs from the client's HTML.

For a minimal example, I created this repository.
Here is a code snippet:

class AppView extends React.Component {
  render () {
    const isServer = this.props.isServer
    const styles = {
      server: {
        backgroundColor: 'red'
      },
      client: {
        backgroundColor: 'green'
      }
    }
    return (
      <div>
        {
          isServer ?
            <div style={styles.server}>isServer</div> :
            <div style={styles.client}>isClient</div>
        }
      </div>
    )
  }
}

In the example I render a CSS background color of red for the server and green for the client. I force a difference by the server's and client's HTML with the isServer property.

With React 15, everything works as expected: the server renders a red background, but the client corrects it to green. With React 16 however the background stays the same, but the text changes as expected.

There are probably other similar behaviors. For example I found out about this bug, because I was conditionally rendering a complete component like so:

return someCondition && <MyComponent />

It becomes even more weird, because if there is additional JSX after that conditional rendering, it would render that additional JSX as if it is inside that MyComponent

return (
  <div>
    { someCondition && <MyComponent /> }
    <SomeOtherComponent />
  </div>
)

becomes

return (
  <div>
    <MyComponent>
      <SomeOtherComponent />
    </MyComponent>
  </div>
)

if someCondition === true on server side and someCondition === false on client side.

You can see this behavior on my website: http://smmdb.ddns.net/courses
Open Chrome Dev Tools and lower the width until you get the mobile view, then reload the page and see how the list is wrapped inside another Component.

[sebmarkbage]

The styles not being patched up is expected. That's an intentional breaking change. The idea behind that is that most sites stabilize once they have a solid SSR infra in place and therefore these things don't happen, yet they would have to spend all that time validating unnecessarily when they know it's not going to change. So it's an optimization.

The second part here should not happen though. It should not be inserted inside another parent. Do you think you'd be able to provide a smaller reduced example e.g. in a JSFiddle? It's a bit difficult to debug on a fully deployed site.

[sebmarkbage]

In development mode you should see a warning, btw. Are you not seeing the warning?

[Tarnadas]

I updated the repo with an example of what I mean.

Here is a code snippet:

import React from 'react'

export default function renderer (isServer, render) {
  return render(<AppView isServer={isServer} />, !isServer && document.getElementById('root'))
}

class AppView extends React.Component {
  render () {
    const isServer = this.props.isServer
    return (
      <div>
        {
          isServer && <ServerComponent />
        }
        <ListComponent />
      </div>
    )
  }
}

class ServerComponent extends React.Component {
  render () {
    const styles = {
      server: {
        backgroundColor: 'red'
      }
    }
    return <div style={styles.server} />
  }
}

class ListComponent extends React.Component {
  constructor (props) {
    super(props)
    this.getList = this.getList.bind(this)
  }
  getList () {
    const styles = {
      el: {
        width: '200px',
        height: '200px',
        margin: '20px',
        backgroundColor: 'blue'
      }
    }
    return Array.from((function * () {
      for (let i = 0; i < 10; i++) {
        yield <div style={styles.el} key={i} />
      }
    })())
  }
  render () {
    const styles = {
      client: {
        backgroundColor: 'green',
        display: 'flex',
        flexWrap: 'wrap'
      }
    }
    return (
      <div style={styles.client}>
        { this.getList() }
      </div>
    )
  }
}

And this will happen:

ServerComponent should get removed, but it won't. Instead it stays and the ListComponent's list elements get transferred to the <div> from ServerComponent. The surrounding <div> from ListComponent will be removed/replaced by the <div> from ServerComponent.

So you said the styles won't be patched, which is an optimization, but in this case I replace an entire div so shouldn't this update the style or is it WAI?

The problem on my website is that I make assumptions about screen size, which might not be true. Is there a stable method to get screen size on initial server rendering? Can I use the newly introduced SSR streaming method to get this working?

[sebmarkbage]

Ah. The reason this happens is because we try to reuse the structure as much as possible. Because the first item is a div in both cases we try to reuse it. That's why it retains its styles. If it was a different tag name it would patch it up but it's risky to rely on this.

You can build a little infra that passes screen size to the server as a separate request but that might be overkill. If you don't have screen size on the server you will server render the wrong output which could lead to flashes on the content when it finally restores the JS on the client. If your app is resilient to that, then there is a way to model that on the client.

You can render the initial mount with the server render screen size. Then in componentDidMount you can read the real screen size and if it doesn't match up with your guess, then you rerender by setting state.

class App extends React.Component {
  state = { screenSize: DEFAULT_SIZE };
  componentDidMount() {
    this.setState({ screenSize: getRealScreenSize() });
  }
}

[rgrove]

I also have a use case in which I intentionally have the server render something slightly different than the client will render, and it's affected by this change in React 16 as well.

I have a component that renders a feed of items. On the server I render one page of items at a time, with conventional "Prev" and "Next" pagination links. On the client I render an infinitely scrollable virtualized list.

Rendering a conventional paginated list on the server helps improve SEO by giving search bots actual links to follow to subsequent pages and also ensures that clients with JS disabled can still paginate through the list.

There's no visible flash when a JS-capable client hydrates the list because the only visible difference (pagination links) will typically be below the fold, so this should work out well. However, React 16 reuses certain server-rendered elements without removing their classNames even though the client-rendered state doesn't use those classNames, and this breaks the design in weird and unexpected ways.

I understand that it's generally not advisable for server-rendered content to differ from client-rendered content, but this was a conscious choice made with full awareness of the disadvantages. I expected a slight performance penalty, but didn't expect broken output.

If this scenario really is considered unsupported in React 16 and there are no plans to allow developers to opt into full validation when hydrating server HTML, then it seems like the dev mode warning should be an outright error in order to prevent subtle breakage from slipping into production. This change should probably also be called out prominently in the release notes, since it could unexpectedly break existing code that relies on the old behavior.

[sebmarkbage]

But, yea this will definitely need to be prominent release note and maybe a separate blog post.

What's your mechanism for silencing the warning in 15? Maybe we can target that as a way to inform you?

We rely pretty heavily on console.error being considered an actual error, and can even rely on it between minor versions to change the behavior - since it was a true error to begin with. We don't throw because that causes even more potential problems when code paths differ between development and production. There are really unexpected ways. Yea, I know this is a weird Reactism.

Note that hydration isn't just a performance optimization but a way to preserve state in things like forms and animations.

I'm going to add a way to suppress the diff warning for individual nodes. At least for text content differences. We could potentially expand that to direct child elements of that node too. That way you could work around it by using different tag names on the container element.

[rgrove]

What's your mechanism for silencing the warning in 15? Maybe we can target that as a way to inform you?

Basically I close my eyes and put my fingers in my ears and yell "you're not my supervisor!" 🙈

I took another pass at my list component using the two-phase render approach you recommended above and it works well, so I think that'll be good enough to cover my use case. Thanks!

My guess is I'm not the only one who's gotten used to ignoring that warning, so I'll try to help get the word out about the change.

[Tom910]

My case of use. Our server does not know about authorization. And when transitions between applications, we quickly restore part of the data of the authorized zone. In this case, patch html and story. Thus, there is a fast switching between applications.

[sebmarkbage]

Btw, if you relied on React to clear out the DOM for you in 15 you can still do that explicitly in 16. Just do container.innerHTML = '' before ReactDOM.render. (In 17, ReactDOM.render will do that automatically but currently it doesn't for backwards compat.)

[flarnie]

It sounds like the action item here is to update docs/release notes and possibly write a blog post about this change, showing people how to migrate their code if they run into this issue.

[zombieJ]

hi @sebmarkbage,
We use react-hot-reload + webpack-hot-module-reload on ssr. This works find in 15.5 and front end always sync with latest version. But for v16, I have to keep the server side code update to date to avoid dom element over-reuse.
container.innerHTML = '' could help but something we finished a page and wish the warning in console of c-s diff. innerHTML = '' & render will break the warning.
I think it could be a hook of the react client side render listener for c-s diff. When trigger, just let me reload all the page by client side.(Maybe already have? Not sure)