ようこそ、React.js Advent Calendar 2018へ！
カレンダーを作ったトップバッターということで、React.jsの特徴を、他のフレームワークとも比較しつつ書き連ねていきます。
仮想DOMフレームワーク
仮想DOMについて詳しいことはちょうど4年前のカレンダー記事に譲りますが、3行でまとめるなら、
- シンプルなJavaScriptのオブジェクトとして、DOM構造を表現する「仮想DOM」を構築する
- 実際のDOMへの反映の際は、現在のDOMと仮想DOMを比較して、差分だけ適宜反映する
- 画面描画ごとに仮想DOMを構築しても、実用十分な性能が出る
ということで、jQueryでやっていた「ここをこう変化させる」と要素ごとに操作する必要性がなくなります。
仮想DOMオブジェクトを直接変数に入れられる
RiotはHTMLをHTMLとして表現する方式だったのですが、そのために<table>など、タグの組み合わせが決まっているところでうまく組めないという事態に陥ることがありました。Reactでは純粋なJavaScriptのオブジェクトとして仮想DOMを組むので、複雑なテーブルでもJavaScript的に組み上げてしまうことができました。
コンポーネント化
picodom→ultradom→superfine1という仮想DOMライブラリを使っていたこともありましたが、これには状態をもたせたコンポーネントがなかったので、本来であれば親が知る必要もないような細かな状態についても、まとめて管理せざるを得ず、コードが密結合になってしまっていました。
Reactでは状態を持ったコンポーネントを作れるので、上位層から知る必要のないようなstateは子コンポーネントに封じきってしまうことができます。
Controlledな要素
これは自分自身が以前に書きましたが、フォーム要素に値を記憶させるというデフォルトの機能をあえて殺して、「ユーザーからの入力」と「値の表示」を切り離すことで、入力値の管理をシンプルにしています。素のJavaScript、jQuery、Riotでも、「イベントと書換と読出しのタイミング」で悩まされてきたので、全部をJavaScript側のデータで管理できるというのも便利に感じました。
バックエンドの自由度（ブラウザ以外への発展）
まだ使ったことはないのですが、同じ仕組みでReact Nativeというものがあって、DOM APIではなくプラットフォームごとのGUI用APIを呼ぶことで、ネイティブアプリもReactで作れるようになる、とのことです。仮想DOMのルーチン自体はDOMに依存するものではないので、バックエンドさえ作れば多様な環境に対応が可能となりますし、その実例があるというのもいいものです。
始めるまでのハードル
Reactは慣れてしまえば快適なのですが、始めるコストはある程度ある気もします。
- 最先端のJavaScript文法（Object Spread、
classでのプロパティ宣言など）を多用する書き方 - JSXという、仮想DOMを直接JavaScriptで書けるようにするための文法拡張
- これらを処理する環境構築
とはいえ、環境構築はcreate-react-appで済ませてしまうなど、どうにかする手段はあります。
-
何度も名前が変わるくらいに改変が入り続けたのも、このライブラリから離れた要因の1つです。 ↩