JSで書かれたコードを「いつ、どこで、どこまでレンダリングするか」。|ユーザごとに表示内容が異なるページには適用不可SSRのメリットSEOの観点はもはやSSRのメリットにはならない。すべき、とされていました。選択肢に挙げる必要がなくなりました。これからも有効な手段であることに変わりありません。いうとユーザが最初に目にする初期表示を早くすること。Renderingについて知るべきこと。2017SSRのデメリット(フレームワークを使わないと)とてもめんどくさい。blog.koba04.comv15までReactでSSRしたコンテンツをクライアントでも再利用したい場合、これまではSSRしたHTMLを元に生成されたchecksumとクライアントサイドで構築したReactElementから生成したchecksumが一致する必要がありました。これはつまり、ReactDOMServer.renderToStringのエントリーポイントと、ReactDOM.renderのエントリーポイントが一致する必要があることを示します。v16v16では、checksumによりチェックは行われず、可能な限りすでに構築されているDOMを再利用しようとします。ReactDOM.hydrateという明示的なAPIを使うことで、サーバー側とクライアント側でエントリーポイントを合わせる必要はありません。要は、SSRしたものをCSR時に重複してレンダリングせずに再利用するのに悪戦苦闘している。v16から多少楽にはなっているものの、サーバ側もクライアント側も大変そう。Next.jsのようなフレームワークを使えば、特に意識しなくてもSSRが簡単にできるよ!!という話。#jsprimerエントリポイントとは、アプリケーションの中で一番最初に呼び出される部分のことです。アプリケーションを作成するにあたり、まずはエントリポイントを用意しなければなりません。Webアプリケーションにおいては、常にHTMLドキュメントがエントリポイントとなります。返すhtmlファイルに書かれているDOMが空のdiv要素1つとかなのがCSRで、ファーストビューの分までレンダリングしたhtmlファイルが返るのがSSR。大まかな流れは以下の通りサーバで、エントリポイントを起点にコンポーネントをレンダリングする(componentDidMountの前まで)。具体的にはReactDOM.renderToNodeStreamを使い、仮想DOMの構築をサーバ側で行い、仮想DOMの構造に合わせてHTMLファイルを出力してからクライアントへ返す。CSSOMツリー)が構築される。クライアント側でサーバと同じJSファイルが読み込まれ、ReactDOM.hydrateで仮想DOMが再度生成される。サーバ側で構築された分の仮想DOMはHTMLに反映済みなので、それ以降(componentDidMountから)の部分でイベントハンドラの設定などが適用される。大事なポイントとして、JS自体は2回実行され、仮想DOMの構築も2回行われる。2回実行されるが、SSRの場合操作対象のDOMツリーが完成した状態で2回目が実行され、仮想DOMとの差分が無いため、Layoutの処理は再度走らず重くならない。段階でJSファイルが読み込まれ、実行自体はツリー構築後になる。最初に走る処理であるが、サーバ側ではエントリポイントで呼ばれたときのみ、クライアント側ではhistoryAPIを叩いて遷移するときのみ呼ばれる。仮想DOMの構築は確かに2回行われるが、getInitialPropsでのAPIへのリクエストはちゃんと1回しか行われないようになっている。Reduxで状態管理をしている場合はサーバ側で保存した状態をクライアント側へ引き継ぐ必要がある。いうライブラリでhtmlへ埋め込んでクライアントへ渡したり。Interactive)までの時間は短くならない。Deckメモv15までのSSRの流れ詳細サーバで、エントリポイントを起点にコンポーネントをレンダリングする(render関数の実行まで)ReactDOM.renderToStringを使い、レンダリング内容を文字列としてhtmlへ埋め込みクライアントへ渡す。属性として値を埋め込んでおく。CSSOMツリー)が構築される。クライアント側でサーバと同じJSファイルが読み込まれ、ReactDOM.renderで仮想DOMが生成される。ReactDOM.render実行時にchecksumを参照して、差分がなければhtmlを更新しない。Qrunch.netサーバー提供フィードバックを送信する。