Use ReactDOM.hydrate() for hydrating a SSR component if available

[theJoeBiz]

Looks like this was originally addressed in #1013, but was closed by accident and never reopened. My project is using React 16 and I can confirm that this patch prevents the deprecation warning.

---

This change is 

[coveralls]

Coverage remained the same at ?% when pulling 9e86b75 on theJoeBiz:fix-react-render-deprecation-warning into eb4438a on shakacode:master.

[justin808]

@theJoeBiz Any way to test or verify this for both older React and new react?

[theJoeBiz]

@justin808 I don't think so. There aren't any existing tests for clientStartup.js and I've never had to deal with tests for two separate versions of react. That being said, the change made here is fairly transparent and visibly falls through to the old behavior for any version (older than 16) where ReactDOM.hydrate is undefined.

[theJoeBiz]

Also, only one test needs to be updated for a react 16 upgrade
theJoeBiz@468338c#diff-85a5145721dbc772cfb6de2e6102717c

[justin808]

@alexfedoseev can you please confirm this React syntax looks good.

[alex35mil]

Looks like you mix things here you shouldn't mix. E.g. !!ReactDOM.hydrate is enough for shouldHydrate decision, but if something is wrong w/ dom node then it's out of scope ReactDOM.hydrate vs ReactDOM.render problem.

Also, facebook/react#10971

[theJoeBiz]

@alexfedoseev Good call, updated to just check for truthiness of ReactDOM.hydrate.

[justin808]

@alexfedoseev let me know if I should merge.

[alex35mil]

LGTM 👍

[theJoeBiz]

We just moved our app into production with this warning, which is fine, but I was just revisiting this on a page that has a combination of server/client rendered components and found a flaw. Turns out, the data-reactroot check I removed in a previous iteration of this was there to check to see if the component was server rendered. In react 16, ReactDOM.hydrate is only supposed to be used on components that were previously rendered on the server. So, now that data-reactroot is unreliable, I replaced that check with !!domNode.innerHTML so the hydrate check is now:

const shouldHydrate = !!ReactDOM.hydrate && !!domNode.innerHTML;

I tested this most recent commit locally on a page using React 16 and a combination of server/client rendered components. Here is the output from the console:

(index):68 [SERVER] RENDERED SearchForm to dom node with id: SearchForm-react-component with railsContext: {...,"serverSide":true}
(index):98 [SERVER] RENDERED Explore to dom node with id: Explore-react-component with railsContext: {...,"serverSide":true}
createReactElement.js:41 HYDRATED SearchForm in dom node with id: SearchForm-react-component using props, railsContext: {} {…,"serverSide":false}
createReactElement.js:41 HYDRATED Explore in dom node with id: Explore-react-component using props, railsContext: {} {…,"serverSide":false}
createReactElement.js:43 RENDERED FreeReport to dom node with id: FreeReport-react-component with props, railsContext: {} {…,"serverSide":false}
createReactElement.js:43 RENDERED ClientOnlyTest to dom node with id: ClientOnlyTest-react-component with props, railsContext: {} {…,"serverSide":false}

[justin808]

@alexfedoseev Please look at the latest change. I know we want to use this as well.

[justin808]

@theJoeBiz can you please rebase on top of master and add an entry to the CHANGELOG.md

[theJoeBiz]

@justin808 added an entry to CHANGELOG.md and squashed the commits

[alex35mil]

LGTM

[justin808]

Shipped! 10.1.2

[theJoeBiz]

Any estimate on getting this onto npm as 10.1.2?

[justin808]

@theJoeBiz it should have published. I'm looking into it.