React.js meetup #1
React 概論
Naoya Ito
Kaizen Platform, Inc.
4/24 2015

React 記事書きました

後編も鋭意執筆
中です!

React

React
• Facebook, 2013
• PHP フレームワークの XHP の移植として開発
されたのがきっかけ
– XHP ･･･ 2010 年くらい
• HTML の中に PHP コードを埋め込むのではなく PHP の
中に XML fragments をリテラルで書けるようにした
(like JSX)
• 独自タグを定義可能 reusable components

React とは
• UI 開発用の JavaScript ライブラリ
• React が提供するのは View のみ
• "Its goal is to be simple, declarative and
composable." (wikipedia)

React Developer Tools
で Facebook を見ると、
確かにプロダクションで
使われている

発想
• PHP では毎回ページを書き換えてた。簡単だっ
た
• JavaScript で UI 開発するようになって
DOM 操作で複雑になった
• XHP を JavaScript に移植して、同じパラダ
イムで開発できないか?

• 従来とはまったく異なる方法で DOM を扱う
• 手動で DOM を更新して状態を管理するといった旧態依
然とした開発方法はスケーラビリティの点で劣っている
• ユーザーインタフェースをより宣言的に記述できる。そ
して仮想DOMにより DOM の更新は最小に抑えられる

どういうことだ!

≒ サーバーサイド脳で書ける
• View は常に全更新
– モデルが更新されたら View を全部更新
– View を更新したかったら全部レンダリング
しなおす
– 富豪的プログラミング
• View は宣言的に定義 (HTML だし)

つまり

従来のやり方
命令的なDOM操
作コード群

従来の手法の難しさ
• DOM 操作の難しさ
いつ、どこから書き
– DOM が状態を持っている
換えられるかわから
ない状態を間違いな
–
く管理しなければな
グローバル
らない
– 非同期

React では

setState() すると
render() で View が
まるごと更新
View は宣言的に
定義

データが変わったら
Viewは全更新
(サーバーサイドと同じ考え方)

State と JSX
• State
– 変化する値 (状態) を扱う機構
– 1方向データバインディング
– setState() で変えると、View の再描画が走る
• JSX
– リテラルで XML ぽいのを書ける
– 宣言的な記述
厳密には JSX のおかげで宣言
的、というわけではないです。
(JSX は必須ではない)

全部丸ごと更新では、効率が悪い?
そこで Virtual DOM

VirtualDOM
• React のバックエンドにある
DOM構造を抽象化したデータ
構造
• データモデルの状態変化に合わ
せて VirtualDOM の前後の
diff を算出
• 生 DOM 再描画を差分のあった
箇所だけ行う
source: React’s diff algorithm
h4p://calendar.perfplanet.com/2013/diff/

React の責務
1. DOM の更新
2. イベントへの反応
HTTPリクエスト (Ajax)、ルー
ティング、モデル、永続データな
どは感知しない。他のもの使って
ね

重要なこと
• サーバーサイド脳でいける
– State によるデータバインディング、宣言的な View 構築
(JSX)、Virtual DOM
• コンポーネント指向
– DOMへの作用をコンポーネントに局所化
• データフローが明確
– ステートレスコンポーネント
– コンポーネントのI/F: Props と State
この辺を意識せずに
使っていては長所を
活かせない

TodoApp コンポーネントは
TodoInput コンポーネントと
TodoList コンポーネントで
構成 (Composition)

TodoApp
<TodoInput />
<TodoList />
コンポーネン
トは JSX で
実は ul や li も
参照
React コンポー
ネント

コンポーネントへの
値の受け渡しは
TodoApp
Props (属性) が I/F
onAdd={this.onAdd}
todos={this.state.todos}
TodoInput
TodoList
input
ul
li

コンポーネント化
イベントや入出力は、そ
のコンポーネントクラス
内に局所化される

データフロー
TodoApp
State は親に持たせて、
子には Props で渡す。

State
Props は不変にし、子は
State を持たない = ス
テートレスコンポーネン
ト
TodoInput
TodoList

つまり
• シンプルなパラダイムで書ける
– サーバーサイド脳
– ステートレス: 状態を気にしなくていい
• データフローが明確なので実装箇所に迷いが少
ない
• そのコンポーネントにまつわるコードはそのコ
ンポーネント内にあるので見通しが良い

生産性より信頼性
• 生産性を高めるライブラリというより
• 可読性、保守性など長期的な信頼性に重
きを置いている
コードは書く時間より読
む時間の方が長いだろ?
(by Facebook)

FAQ
• JSX ビルドどうするの
– トランスパイラ使う (react-tools, Browserify , Babel など)
• jQuery 併用できる?
– できるはできるけど DOM 操作はパラダイムが違うので、よく
わかんないでやるべきではない ($ajax とかは構わない)
• リアクティブプログラミング (RP) なの?
– データフローに着目 & 宣言的あたりが「リアクティブ」
– ただし「リアクティブ」の言葉の意味が広すぎるので要注意
• React だけでRPを把握しようとすると地雷、かも
• Functional Reactive Programming 方面へどうぞ

おまけ: Immutable.js
• facebook/immutable-js
• Immutable なデータ構造を提供するライブラ
リ
– var map2 = map1.set('key', value);
– 非破壊的に操作できるデータ構造
– List, Map, Set, Seq ...
• State で扱うデータ構造用に使うと る

React: 命令的 → 宣言的
• 命令的であったViewの組み立て(DOM操作)を、
宣言的なパラダイムに
• 「データモデルに変更があったら DOM を丸ご
と更新」
– 非効率な部分は VirtualDOM が解決
フロントエンドUI開発を、
サーバーサイドと同じ富
豪的プログラミングスタ
イルに戻す

PR: 採用してます
「Kaizen 採用」で検索。興
味あるだけでも可。その場
合は Wandtedly で。