v16について書いたブログの中の、サーバーサイドレンダリングについての部分に間違いがあったので修正しつつ、v16のサーバーサイドレンダリングについて補足します。http://blog.koba04.com/post/2017/09/27/react-v16-changes/Hydrationしたい場合は、renderToStringまたはrenderToNodeStreamで行う必要があります。renderToStringまたはrenderToNodeStreamには、data-reactroot以外にも変数部分を識別するためのコメントノードなどが挿入されていて、それが必要であるためです。それでは、v15とv16でのサーバーサイドレンダリングの違いを見てみます。以下、長いのでサーバーサイドレンダリングはSSRと略します。v15までReactでSSRしたコンテンツをクライアントでも再利用したい場合、これまではSSRしたHTMLを元に生成されたchecksumとクライアントサイドで構築したReactElementから生成したchecksumが一致する必要がありました。これはつまり、ReactDOMServer.renderToStringのエントリーポイントと、ReactDOM.renderのエントリーポイントが一致する必要があることを示します。HTML全体をReactで構築しようとするとこんな感じになります。document.getElementById('app'));上記のようにHtml.jsではdangerouslySetInnerHTMLを使い、アプリケーションのComponentをrenderToStringによりchecksumなどが付与されたHTML文字列として埋め込む必要があります。server.jsでは、HTML全体の部分はrenderToStaticMarkupで、アプリケーションの部分はrenderToStringでと、別々に生成する必要があります。これにより、renderToStringとReactDOM.renderで構築される内容が一致するため、SSRによって生成されたDOMが再利用されます。v16v16では、checksumによりチェックは行われず、可能な限りすでに構築されているDOMを再利用しようとします。ReactDOM.hydrateという明示的なAPIを使うことで、サーバー側とクライアント側でエントリーポイントを合わせる必要はありません。(ReactDOM.renderを使う場合は、data-reactrootの属性がDOMにあるかをチェックしているのでエントリーポイントを合わせる必要があります)そのためv15のように、エントリーポイントを一致させるために、アプリケーションのComponentを別途HTML文字列として生成する必要はありません。document.getElementById('app'));上記ではHtmlのComponent内で、アプリケーションのComponentを、ReactDOM.hydrateの対象となるDOMの子要素として渡しているだけです。HTML文字列として渡したりする必要はありません。全体もrenderToNodeStreamでまとめて構築できるため、コードもシンプルになります。いうわけで、v16ではSSRのコードもよりシンプルに書けるように効率的になっています。