宮水の日記

宮水の日記

主に書評や資格取得について記事を書いています。

react-dom【JSライブラリ1日1個】

JSライブラリ紹介

JSライブラリを1日1つ紹介する

1日1つJSのライブラリを調べます。

① ライブラリに関するドキュメントを最初から最後まで読む
② 実際に使ってみる or 使い方を調べる
③ ライブラリを3行で説明する


本日は、react-domのドキュメントを読んで実際に業務で使っているところを調べました。

ドキュメント

今回読んだドキュメントはこちらです。
github.com

実際に使ってみる

This package serves as the entry point to the DOM and server renderers for React. It is intended to be paired with the generic React package, which is shipped as react to npm.

READMEによると、reactと一緒に使うことが前提のようです。DOMをレンダーするときのエントリーポイントになります。

var React = require('react');
var ReactDOM = require('react-dom');

class MyComponent extends React.Component {
  render() {
    return <div>Hello World</div>;
  }
}

ReactDOM.render(<MyComponent />, node);

ところで、React.Componentのrenderとは何が違うのでしょうか？

こんなQiitaをみつけました。
https://qiita.com/tatane616/items/9808f8861586fb2b2926

React.DOMのrender()が実際のDOM要素にレンダリングを行なっているのに対し、
React.Componentのrender()はthis.propsとthis.stateを調べた後React要素などを返しているだけとなります。

React.DOMのrenderとReact.Componentのrenderが違うことがわかりました。（そういえば意識したことなかったです）

続いて、公式ドキュメントにおけるReactDOMの説明を読みました。
https://ja.reactjs.org/docs/react-dom.html

気になった文がこちら

サーバで描画されたコンテナをクライアントで再利用するために ReactDOM.render() を使用することは非推奨となり、React 17 では削除されます。代わりに hydrate() を使用してください。

どうやら、サーバーでレンダリングする場合とクライアントでレンダリングする内容が異なるバグが発生するため、そうならないhydrateを使うべきだと書いてあるみたいです。たた、hydrateにするとパフォーマンスが落ちる（サーバーとクライアントでレンダリングした内容を合わせるために再レンダリングするので重くなるという意味だと思いました）らしいので、気をつけて使わないといけませんね。

わからなかったところ

でも一緒に使うことが前提なら、どうしてわざわざreact-domというライブラリにわけたのでしょうか？リポジトリが大きくなりすぎてしまうから...？

また、このライブラリを調べてSSRとCSRというものをはじめて知りました。

SSRはサーバーサイドでDOMをレンダリングしますが、CSRはクライアント側でDOMをレンダリングします。
最初のレンダリングはSSRで、その後の非同期の動きは全部CSRなのでしょうか？
意識して使い分けたことがないのであまりよくわかりませんでした。

3行でまとめる

react-domは、

  • Reactとセットで使う
  • 本当のDOMをrenderするメソッドが生えている

フィードバック

SSR(Server Side Rendering)とはなんなのか

SSRはその名の通り、サーバサイドでHTMLをレンダリングしてレスポンスとして返す技術。
より正確にいうと、クライアントサイドでHTMLをレンダリングするのと同じ方法でサーバーサイドでHTMLを生成してレスポンスとして返す技術。（RailsにViewを書いて、HTMLでレスポンスを返すのとはまた違って、クライアントサイドと同じ方法というところがポイント。）

https://engineer.recruit-lifestyle.co.jp/techblog/2016-11-16-isomorphic-javascript/
→宮水「SPAの問題点と、それを解決してくれるSSRの話がとてもわかりやすかったです！」

https://speakerdeck.com/yosuke_furukawa/you-need-to-know-ssr

https://www.publickey1.jp/blog/17/server_side_renderingserver_side_rendering_ng-japan_2017.html
→ 宮水「SSRを使うと検索エンジンに優しいのは初耳でした！初期表示のHTML生成でCPUを使ってしまう...など意識したことがなかったです。フロントのパフォーマンス向上について”こんな風に考えながら改善するんだー”ということがわかりました」

Universal/Isomorphic JavaScript

クライアントもサーバサイドもJavaScriptにすること。実は歴史が長い。

BFF（Backends For Frontends）

サーバーサイドは別の言語でバックエンドある時にFrontend用のBackendのみJavaScriptで構築する、という手法。
https://www.atmarkit.co.jp/ait/series/9324/

なぜSSRにするのか

First Viewのレンダリングが速くなり最初のユーザインタラクションまでの時間が短縮できることがメリット。
https://jakearchibald.com/2017/netflix-and-react/
https://techblog.yahoo.co.jp/entry/20191203785540/

with hydration

最初にSSRでHTMLを返し、その後は普通のSPAのようにクライアント側でHTMLを生成しながら動くものを特に SSR with hydration という。ReactDOM.hydrate はまさにそのためのメソッド。
https://ja.reactjs.org/docs/react-dom.html#hydrate

なぜreactとreact-domは別ライブラリなのか

分けることによって複数のプラットフォームに対応できるから。
実はこの二つはライブラリとして役割が明確にわかれていて、
react: PropsやStateをいい感じにしつつ最終的に仮想DOM（ReactNode）を生成するところまでが責務
react-dom: reactで生成したReactNodeを受け取ってDOM（=HTML）を生成するところまでが責務
になっている。

ここで例えばHTMLが必要なくてネイティブアプリ上でViewを生成したいときに、react-domの部分をreact-nativeに差し替える、みたいなことができるというメリットがある。（Dependency Injection ぽい感じ）

React Native

ちなみに React Native の内部の詳細は以下の記事が詳しくて面白い。
https://tadeuzagallo.com/blog/react-native-bridge/
https://www.reactnative.guide/3-react-native-internals/3.1-react-native-internals.html
個人でアプリを作りたいときには有力な選択肢になるかも。

以上です！