勉強の為に引用しました。
http://qiita.com/naruto/items/fdb61bc743395f8d8faf
1473695736
naruto
2016年11月25日に更新
12
ストック
はじめに
React (通称 React.js1) を全く知らない、あるいは幾つか記事を見たけどなんなのかピンと来ていない、という人のために、少し前にピンと来たばかり（のつもり）の人が書いています。
「jQueryくらいしか知らないけど、それで十分やっていけてるし…」くらいの人が対象であり、すでにやる気がある人向けのチュートリアルではありません。やる気が出ればドキュメントを読んで手を動かせばあっという間ですので、そこまでの興味が出ることを目標にしています。
厳密性や網羅性よりはイメージ優先なので、最近（2016年以降）の記法をあたかも昔からそうであるかのように語ったり、本来「DOM要素」と書くべき部分を「DOM」と略記しまくったりしていますが、ご了承ください。
以降では ES2015 (ES6) の文法（アロー関数とか）は普通に使います。Reactを使う以上、どうせ何らかのトランスパイラはほぼ必須ですし、だいたい今どきBabelかTypeScriptか使ってない人とかおらんやろ（煽り）。この部分が怪しい人は先に
アロー関数だけでも知ってから先に進んでください。
Reactがやること
Reactがやることは非常にシンプルで、APIも数えるほどしかありません。「記憶力を使って覚えることの少なさ」に関してはピカイチだと思います。そのわずかなAPIに、みんな慣れ親しんできたjQueryのメソッドの大部分を駆逐してしまうほどの威力があります。
Reactがやれることを3行で説明すると、こうなります。
「ページ状態を保持しているプレーンなJSのオブジェクト」に、
「テンプレート的な関数」を作用させて、「仮想DOM」と呼ばれるDOMの設計図を取り出し、
その設計図を使って本物のDOMを構築する。
ここでいう「プレーンなJSのオブジェクト」とは、JSONをパースしたりするだけで取得でき、タグとかの文字列を一切含まない、クリーンなデータを保持しているJSオブジェクトと思ってください。そこには、Web APIから読み取ってきた商品リストのデータであるとか、現在アクティブなタブのインデックスであるとか、入力中のフォームデータであるとかといった、「ページの状態」にあたるものがまとめて入っているイメージです（Fluxを聞いたことがあるならStoreに相当）。
Web APIなどからプレーンなJSオブジェクトを取り出し、そこからDOMを作り出すことはjQueryでよくやる作業です。例えば「商品データを一覧表示」なら、愚直にやるとこんな感じ。
$.getJSON('/api/items').then(data => {
const ul = $('ul.item-list').empty();
data.items.forEach(item => {
const li = $('<li>').addClass('item').appendTo(ul);
if (item.stock === 0) li.addClass('soldout');
$('<div>').addClass('item-name').text(item.name).appendTo(li);
$('<div>').addClass('item-price').text(item.price).appendTo(li);
$('<button>').text('注文').addClass('btn').appendTo(li)
.on('click', orderClickHandler);
});
});
難しいことはしていませんが、見た目に直感的ではない感じはします。
同じことをReactで書くと、こういう全く違う見た目になります（行数が増えているのは関数を分割したりしているから）。
// ItemListのコンポーネント定義（実体は関数）
const ItemList = props => {
return <ul className="item-list">
{props.items.map(item => <ItemDetail item={item} />)}
</ul>;
};
// ItemDetailのコンポーネント定義
const ItemDetail = props => {
const item = props.item;
return <li className={'item' + item.stock === 0 ? ' soldout' : ''}>
<div className="item-name">{item.name}</div>
<div className="item-price">{item.price}</div>
<OrderButton onClick={orderClickHandler.bind(null, item.id)} />
</li>;
};
// OrderButtonのコンポーネント定義（ワンライナー）
const OrderButton = props => <button className="btn" onClick={props.onClick}>注文</button>;
$.getJSON('/api/items').then(data => {
ReactDOM.render(
<ItemList items={data.items} />, // これを
document.getElementById('container') // ここにレンダリングしろ
);
});
え～ととりあえず、面妖な見た目のHTMLタグっぽいものを見て速攻逃げ帰りたくなった人がいますよね。なんとReactでは、このようにJavaScriptとHTML(?)が悪魔合体しているのが基本作法です。太古の黒歴史である onClick が華麗に復活しているのも誤植ではありません。まあ少し我慢してお付き合いください。後でもう少し詳しく述べますが、とりあえずこの「タグ」は実際には単なる関数呼び出しであり、Babelなどに通すと機械的に関数呼び出しに変換されるので、これはあくまでJavaScriptです。あと $.getJSON() の部分にjQueryが残っているのに気づいた人は鋭いですね、Reactにこの機能の代替はありません。代用品は後の方で提示します。
:information_source: 筆者もちょっと前までこの壮絶な外見を嫌悪して逃げていたクチですが、1日経たずにあっさり寝返りました。後述します。特に気になるであろうonClickの類にも、Reactの設計思想的には実害はありません。こういう新しい記法なのだと思ってください。実際は内部でイベントバブリングを使った最適化がちゃんとされています。
まあともかく、DOMを直接切ったり貼ったりする部分はなくなり、代わりに3つのコンポーネント（というか関数）を定義しています。それぞれの関数はなにやら「HTMLタグっぽいもの」を返しており、その中でJavaScriptの変数が埋め込まれています。このタグっぽいものが、巷で話題の仮想DOMとか呼ばれているアレです。
ReactのAPIを露骨に呼び出しているのは最後の ReactDOM.render() だけ。しかもこれがこの記事に出てくる唯一のReactのAPIです。データを表示するだけならとりあえずこれさえあれば作れます。
:information_source: 2015年以前の記事で React.createClass という関数を使ってコンポーネントを定義している記事を見て、不格好でタイプ量が多すぎと感じた人がいるかもしれませんが、いまや大部分のコンポーネントはこのように単純な関数で記述するのが基本です。
ぱっと見、サーバサイド言語でもよく使われている、いわゆる「テンプレート」に似ている気がしませんか。ただしテンプレートがあくまで文字列ベースの処理なのに対し、Reactは 仮想DOMと呼ばれる「DOMの設計図」 をベースに処理をします。ItemListやItemDetailといった関数が返している「タグっぽいもの」はDOM要素ではなく、あくまで設計図であり、つまりは非常に軽量なJavaScriptのオブジェクトです。
古典的なテンプレートエンジンでは、開発者はそのエンジン独自のテンプレート構文（ループとか）を覚え、テンプレートファイルを書いていきます。その代わりにReactでは、開発者はDOMの設計図をreturnする関数をJavaScriptで書いていきます。このHTMLタグっぽい記法と{}による任意の式の埋め込み以外に、独自規則はありません。ループや条件分岐は、見ての通り普段JavaScriptで使っている三項演算子や Array.prototype.map をそのまま使うだけです。
タグっぽい記述（の関数呼び出し）を通して仮想DOMを作ったら、ReactDOM.render が、それに対応する本物のDOM要素を構築していきます。 これが、開発者が手でいちいち appendTo() とか removeClass() とか text() とか val() とかのjQuery的なDOM操作を書かなくて済む理由です 2。
Reactとは基本これだけをするライブラリです。んー、大したことない気がしませんか。というか、これってサーバサイド言語（PHPとかJSPとか）で使ってきたテンプレートを、ちょっと面倒くさくしただけではないでしょうか。テンプレートと比べて何が嬉しいのでしょう。
なぜこれだけのライブラリが、一部界隈で、まるで世界を革命する力であるかのように言われているのでしょう？ 以下で述べていきます。
理由: JSXが便利で見やすい
既に見たとおり、Reactでは JSX と呼ばれる新しい記法をJavaScriptに導入しています。これが必要な理由は単純で、普通のJavaScriptの構文だけを使って「DOMの設計図」を読み書きするのは人間には辛いからです。JSON的なデータを記述するにはJavaScriptの構文は最強ですが、「要素や属性があって、子にはテキストノードや別の要素があって」というHTML/XML的なデータ構造を、素のJavaScriptは効率的に表現できません。
JSX/XML/HTMLの記法で <div title="message">Hello <b>World</b></div> で直感的に表現できる構造は、もしJSONで書くと { element: 'div', attributes: { title: 'message' }, content: [ 'Hello ', { element: 'b', content: ['World'] } ] } のようになります。イヤですね。
上記の「タグ」はBabelやTypeScriptを通すと、機械的に以下のようになります（試したい方は
BabelのREPLにいろいろ入れてみましょう。reactのプリセットをONにするのだけは忘れずに）。
React.createElement(
"div",
{ title: "message" },
"Hello ",
React.createElement("b", null, "World")
);
要するに <Element a="b" c={d}>Text</Element> は React.createElement(Element, {a: 'b', c: d}, 'Text') に変換されます。これだけなので、これを手書きする苦行を積みたい人はJSXを使わなくてもいいのですが、本記事では使うべきということで通します。
逆にJSX記法さえあれば、古典的なテンプレートエンジンが頑張って実装してきたループ・条件分岐・子テンプレート呼び出し・テンプレート継承3・数値計算といった機能は、JavaScriptには全部元から備わっており、しかも超高速なのですから、使わない手はありません。
Babel や TypeScript は既に普通にJSXをサポートしています4ので、これらに馴染みがあれば導入のハードルは高くありません。JSX自体は汎用性の高い記法なので（単なる関数呼び出しのシンタックスシュガー）、他のライブラリでも採用されつつあるそうです。
慣れ親しんだテンプレートと比べると可読性はわずかに落ちますが、タグの対応がとれていないなどのシンプルな構文ミスはコンパイル時にチェックされ、エスケープ漏れなどでXSS脆弱性が入る余地もほぼありません。TypeScriptを使えば厳密な型チェックも入ります。文字列ベースのテンプレートと違い、見た目だけ構築して後でjQueryで別にイベントハンドラをくっつけるといった2段階作業も不要になります。
:information_source: JSXは最初は違和感が強いでしょうが、実はこれは、XMLが今よりずっとメジャーだった時代に提案され、一部実装もされていた
E4X記法とそっくりです。まだJSONがなかった昔、今のJSONの位置にXMLを使う未来が想像されていた時代があり、その時代には文字列リテラルを""で囲むのと同じ感覚で、XMLリテラルを<hoge></hoge>で囲んでJavaScriptで書くのが自然と思われていたのです。それを知っていれば、JSXはJavaScriptのごく自然な拡張に見えてくるかも。
そして、このようにHTMLとJavaScriptが悪魔合体していることは、禁忌どころか、大事なメリットなのだと考えましょう。「HTMLとJavaScriptは分離せよ」は長い間の鋼の掟でしたが、それは、HTMLこそが単独でも成立する主役ドキュメントであり、サーバサイドでHTML内に実データを頑張って埋め込んでおり、JavaScriptがおまけだった時代の話です。SPAで殆どの実データがAPI経由でやってきて、あらゆるものが動的に構築されるようになると、HTML部分は「中身のない<ul>」「カレンダーやスライダに変身させられるのを待っているだけの<div>」「<form action=...>と結びつかないフォーム要素」「見出し行だけのテーブル」「クリックしてもどこにも飛ばない<a>や<button>」等々、JavaScriptなしには意味を持たない“抜け殻”が静的に陳列されるだけの場と化していきます。CSSの表現力向上によってHTMLタグでごにょごにょする必要性は下がり続けています（少し前まで角丸ボーダーにテーブルレイアウトが必要でした）。ある一線を越えたらもう、抜け殻のHTMLタグだけを遠くの別ファイルで独立してメンテし、遠距離狙撃で .datepicker() や .val() を撃ちまくることは、重要でも効率的でもないのです。むしろ機能的に関連するタグと動作を、名前付きでまとめて短く記述できるReactの記述方法こそが楽で合理的になります。
■ 「JSXだと実装とデザインが分離できずデザイナーが辛いのでは」という点が気になる人がいるでしょうが、JSXでも規模に応じ、ビュー特化のコンポーネントとロジックが絡むコンポーネントを分けることはベストプラクティスの一部です。詳細はこれとかこれを参照してください。
■上記の記事でも強調されていますが、常に小さな粒度の関数（コンポーネント）を作ることを心がければ、JSXはそれほど酷い見た目にはなりません。普通のJavaScriptが綺麗に書ける人なら問題ないはずです。見た目がなんぼ激しくても、この「タグ」は単なる関数呼び出しに過ぎないということは改めて強調しておきます。
■セマンティックなHTMLを失うことによるアクセシビリティ低下が気になる人は
ARIAを学びましょう。
■それでも絶対JSXが合わないという人はRiotなど類似技術は検討に値します。少々の独自構文・ルールやタグのプリコンパイルの手間はありますが。
理由: テンプレートより圧倒的に速い差分描画
何らかの理由（ユーザ操作など）でページの状態が変わり画面を書き直す場合、ReactはゼロからDOMを毎回作り直すのではありません。画面を更新する際、Reactは新旧の設計図を見比べて差分を計算し、パッチ的にDOM操作を適用します。
開発者がやることは、新しい状態が含まれた新しいプレーンなJavaScriptオブジェクトを準備して、さっきの ReactDOM.render() で再描画するだけです。あとはReactが以前の設計図と見比べ、勝手にjQueryでいうところの remove() や val() や prop() や addClass() などなどに対応する操作に置き換えて実行します。これらを人間が手で書かなくても大丈夫。
この差分描画はとても高速なため、ウェブページ全体をReact化して適用してしまうことが普通に可能です。1キーストロークごとに、アプリケーション丸ごとの状態が含まれたプレーンなJavaScriptオブジェクトでアプリケーション全体を「再描画」しても、割と快適に動作します（とても複雑なページだと最適化が必要）。これは文字列ベースのテンプレートでは遅すぎて到底できない芸当です。仮想DOMの比較はJavaScript内のみで完結する軽い演算なので、本物のDOM操作と比べると圧倒的に速いわけです。
Reactを使えば、「状態がこう変わったらDOMをどう変更すべきか」を忘れてしまい、「ある状態に対応するDOMはどうあるべきか」の定義に集中できます。「ロード中はこのボタンとこのボタンを一時的に無効化してここにインジケータを表示して…」とか「このモードに入ったらこのDIVが非表示でこの要素にこのクラスが設定され…」みたいな面倒なコードが一掃され、勝手にページ全体の一貫性が保たれます。
この威力は絶大です。さっきのjQueryの例も、あれだけだったら別に大したことなかったですが、ユーザ操作に応じて在庫有無やユーザ評価やカラバリ選択ボックスやポップアップメニューを動的に付与したり、同じアイテムを2カ所に表示しつつ同期したり、商品をフィルタリングしたりソートしたり…といった様々な動きをつけていくと混沌の扉が開きはじめます。サンプルレベルではReactの威力は実感しづらいのですが、実用的なアプリならめっちゃ楽で、バグの心配が激減します。
更に、ページ全体の情報が1箇所に集まっているため、「ブラウザをリロードされても状態を復元する」「ユーザ操作を元に戻す/やり直す」といったことの実装も比較的容易です。
理由: 超軽量なコンポーネント
Reactでは「部品」「独自タグ」的なものがアホみたいに簡単に書けます。それを組み合わせるのも非常に簡単です。コンポーネントの定義といっても何しろ単なる関数ですから、ワンライナーでもよい。コンポーネントの利用の際も、標準のHTML要素と独自タグの境界はほとんどなく、まるでHTMLに突然フル機能のカレンダー「タグ」や掲示板「タグ」が実装されたかのような感覚で扱えます。
// コンポーネントの定義
const Heading = props => <h1>{props.title} <em>{props.subtitle}</em></h1>;
// コンポーネントの使用
const virtualDOM = <Heading title="Hello" subtitle="React" />;
これは極端にシンプルな例ではありますが、実際にアプリケーションを作るにあたって、大部分のコンポーネントはこのように極力単純な関数で書き、それを組み合わせてアプリにしていくことが推奨されます。数行で済む「ヘッダーコンポーネント」「目次コンポーネント」とかを何十個も書いて、最終的に1個のアプリを作り上げていくイメージ。この手軽さは、ちょっとjQuery UIとかのコンポーネントには真似できません。SubversionのブランチがGitのブランチに変わったくらいのインパクトがあります。
ただしこんな芸当が可能であるために、「コンポーネントが原則として内部状態を持たない（ステートレス）」であることがとても重要です。というわけで次の話。
理由: 原則的にステートレスなコンポーネント
コンポーネントがステートレスである、とは、返すDOMの設計図が、外部から「タグ」の属性(props)として与えられた情報のみで一意に決まるということです（数学的な意味での関数に近い）5。ステートレスコンポーネントは見てきたとおり、単なるJavaScriptの関数で書けます。
Reactを使うにあたって、jQueryから一番考え方を変えないといけないのがこの部分でしょう。jQueryのコンポーネント（カレンダーでも、スライダーでも）は内部状態（プロパティ／ステート）として「現在の入力値」とか「disabledかどうか」とかを持っているのが当たり前でしたし、それの初期化と出し入れで記述が長くなる傾向にありました。Reactでは大事な状態は外部に置かれます。コンポーネントとは外部からの情報をDOM設計図に変換する一方向のプリズムに過ぎません。そう心得て、可能な限りそのように作るべきです。
:information_source: …と書きましたが、必要に応じてステート付きのコンポーネントも書けます。関数に状態がくっついたものというと「クラス」ですね、ということで、今は
ES6のクラス構文を使うのが標準となっています（もちろん必要に応じてトランスパイラを組み合わせて）。基本的に「外部と絶対やりとりしないプライベートな内部状態」はステートにしてもよいでしょう。「ドロップダウンメニューが今ドロップダウンされているかどうか」とか。
「外部に状態がある」というのはカスタムコンポーネントだけの話ではありません。Reactでは<input>などの標準フォーム要素ですらその発想が徹底しており、ステートレスな振る舞いをするようになっています（JSFiddleでのデモ）。
編集できないinput要素
// valueが固定なので、このinput要素はリードオンリーになり、中身を変更できない！！
ReactDOM.render(
<input type="text" value="Can you edit this?" />,
document.getElementById('container')
);
編集可能にしたければどうするのかというと、例の「ページ状態を管理しているプレーンなJavaScriptオブジェクト」を使います。テキストボックス内で入力操作が起きた場合、内部状態が変わってからイベントが発火して外部状態を更新するのではなく、コールバック関数経由で外部状態を先に変更してから画面を「再描画」します。こんなイメージ（
JSFiddleでのデモ）。
編集可能なフォーム
// 外部にある唯一の状態オブジェクト
const user = { name: '', age: 25, checked: false };
const change = (key, newValue) => {
user[key] = newValue; // 外部の状態を変更して、
render(); // 新しいデータでざっくり再描画
}
const submit = () => {
alert(JSON.stringify(user));
/* userは最新版のフォームの状態を常に反映している！ */
};
const isValidUser = () => (user.name.length > 0 && user.age >= 20 && user.checked);
// コンポーネント定義
const UserForm = props => <div>
<p>名前<input type="text" value={user.name} onChange={ev => change('name', ev.target.value)} /></p>
<p>年齢<input type="number" value={user.age} onChange={ev => change('age', ev.target.value)} /></p>
<p><input type="checkbox" checked={user.checked} onClick={() => change('checked', !user.checked)} /> 規約読みました</p>
<button onClick={submit} disabled={!isValidUser()}>20歳以上なので登録</button>
</div>;
const render = () => {
ReactDOM.render(<UserForm user={user} />, document.getElementById('container'));
};
render();
回りくどいと思うでしょうが、綺麗な元データが外部の1カ所にしかなく、DOMは必ずそれを反映しているので、複雑なフォーム・アプリになればなるほど楽さが際立ちます。jQueryで設定画面などのフォームを書いていると、val() や text() を駆使して、「生データの状態をDOMに反映させる」のと、逆の「DOMの状態から生データを再構築する」のを両方書かないといけません。この構造ならそういう作業は要りません。（One-way data flow という標語を聞いたことがある人は、それが指しているのはこれのことです。）
例えばこのくらいの複雑さのフォームになると、ReactならjQuery UIの半分の行数で実装できる感じ（6個のステートレスコンポーネントの組み合わせ。ステート付きコンポーネントは自力では書いていませんが、
React-Bootstrap を使用しています。他にも
便利なUIライブラリがたくさんあります）。
condition-image
さて、React自体は単機能の描画ライブラリであり、「外部の状態」をどこにどうやってどんな粒度で保存すべきかについて一切関知しません。小さなアプリなら上記サンプルコードに毛が生えた程度のものでページ全体をまるっと更新するので何の問題もありません。が、規模が大きくなってきた場合は、この「外部の状態」を管理するための別ライブラリを混ぜて使う人が多いです。Fluxがどうってやつですね。過去には（厳密にはReact外の話とはいえ）この部分が混沌としていて、Reactの使用自体ためらうほどだったのですが、今はとりあえずreduxという軽量なライブラリで集約されつつあります。深く考えたくない人はとりあえずこれを使っておけばいいんじゃないでしょうか。
Reactが向かない場合
Reactが常に万能なわけではありません。Reactの弱点、Reactが向かない場合もあります。
React自体の理解は難しくないけど、Babel/TypeScriptのようなトランスパイラの知識は（絶対ではないけど）ほぼ必須で、Webpack/Browserifyのようなモジュールバンドルシステムの知識も（絶対ではないけど）ほぼ必須。そこまで至っていない人にとっては学習コストが高い。さっさと『
旧石器時代のJavaScript』から抜け出しましょう。
Webpack等の細かい勉強をしたくない場合は
React公式のスターターを使って5分でReactアプリを作る方法もありますが、まあこれらが何をやっているのかは知っておいた方が良いでしょう。
複雑で動的なアプリほど向いているけど、HTMLが主役で動的な要素が少ないサイトや1日でコーディングが終わるようなサイトは、jQueryで特に困ることはない。
作ろうとしているものが「記事（HTMLが9でJavaScriptが1）」なのか「アプリ（HTMLが1でJavaScriptが9）」なのかで分ける、というのは大雑把な指針としてはいいと思います。もちろんReactが向いているのは後者。
あくまでJavaScriptベースのライブラリなので、デザイナ系の人の理解と協力が必要（とはいえそんなに難しくないはずであることは前述しました）。
大抵の場合はサーバ側の協力も必要（基本的にはサーバ側は楽になる方向だけど）。純なReactアプリではHTMLは数行くらいの固定ファイルになり、あらゆる実データはJSONのAPI経由などで来る。サーバサイドに必要なのはAPIであり、テンプレートでHTMLにデータを埋め込むことではない。
React最新版ではIE8以下は切り捨て。も、もういいよね…
ちゃんと最適化したjQueryよりは若干遅いので、本当にパフォーマンスが必要なゲームなどでは要検討。まああくまで「ちゃんと最適化した」jQueryとの比較ですよ？
ReactにとってDOMとはあくまで外部状態を反映した映像に過ぎないので、逆にDOMからデータを取ってくるような作業は一切行えない（スクレイピングはできない）。
結論:
You Don't Need jQuery?
最近
You Don't Need jQueryという記事が話題になっていましたが、はてブとかの反応を見る限り、「むしろjQueryの使いやすさが良く分かった」という人が予想外に多い感じでした。
でもその記事の冒頭部分にある通り、その記事は「DOMを直接操作することはアンチパターンとなりました」という大前提で書かれています。「（頑張れば標準APIでもjQueryと同じことを書けるから）もうjQueryは必要ない」ではなく、もっと根本的に「（jQuery的なDOM操作なんか人間がやることじゃないから）もうjQueryは必要ない」です。jQueryを使うことで標準APIより数文字節約できるような作業の大部分は、そもそも1行も書かなくてよくなったのです。
DOM操作系が軒並み不要で、$.proxy とか $.each とかの「昔は便利だった」jQueryのユーティリティメソッドも、今はほぼ標準で代替可能です。となると、jQueryが真に有用な場面はかなり少ないです。今でもjQueryがないと多少辛いのは $.extend (Object.assignがIE11でも未サポート）と $.ajax 系くらいですが、そのくらいならもっとコンパクトな代替品を探せます6。そう気づいてしまい、残ったjQuery依存を消し去りたいという衝動に駆られたら、はじめて、ああいう記事の出番なわけです。わずか数カ所の数文字のタイプ数増加で、100KB超のライブラリを捨て去れるなら、Webでのメリットは大きいです。
元記事にもリンクされていますが、個人的には
You Might Not Need jQueryというサイトがまとまっていてお勧め。
註: お陰様でよく読まれる記事になっていますので、ブクマコメント等を元に定期的に加筆修正やアップデートを行っています。いま見当違いのように見えるコメントを見ても、大半は私が加筆したせいです。React使わない人を煽るような表現は当初から全くないつもりなのですが（想定読者様ですし…）、「仕様になったES6の文法や、モジュール分割の方法を一生学ばない」という選択肢はない7と信じているので、そこの部分で煽るのは止めないよ！
一応 "React.js" だの "ReactJS" だのというのは俗称です。ちなみにAngularもバージョン2からは後ろにJSが付かないのが正式名称です。 ↩
ただし裏で、イベントの標準化であるとかブラウザ間の差の吸収であるとかをやって、開発者が細かいことを気にしないような処理をいろいろしているようです。この辺はjQueryと一緒。 ↩
テンプレート呼びだしとは単なる関数呼び出しですから、ES6のクラス継承による多態性でも、依存性注入でも、好きな方法を使うだけ。 ↩
2015年頃にReactの世界に起きたありがたい変化のひとつです。以前は「専用のJSX変換ツールを使え」というツラい世界であり、「ReactはaltJSと相性が悪い」とまで言われていました。 ↩
厳密には「ピュアレンダ」と「ステートレス」とを別の概念として区別する必要がありますが、この記事では割愛します。 ↩
$.extend の代用品は個人的にはこれ、 $.ajax/$.getJSON 等の代用品としてはsuperagent（定番）かaxios（新しくてPromise対応）を使っています。 ↩
仮にその選択肢があるとしたら、恐らくその時点でReactの要らないプロジェクトです、安心してjQueryを使いましょう（←ダメ押しの煽り）。 ↩
naruto
2488Contribution
フォロー
人気の投稿
Reactを使うとなぜjQueryが要らなくなるのか
ECMAScript6にシンボルができた理由
はじめに
Reactがやること
理由: JSXが便利で見やすい
理由: テンプレートより圧倒的に速い差分描画
理由: 超軽量なコンポーネント
理由: 原則的にステートレスなコンポーネント
Reactが向かない場合
結論: You Don't Need jQuery?
いいね
2212
ykks2uai
masakielastic
gonzui
fisherman08
milkmeta
flny
sugitk
nullpoo
matsuoshi
sndr
ストック
編集リクエスト
この記事は以下の記事からリンクされています
過去の2件を表示する
Om(React)でsvgを描画するからリンク3ヶ月前
Reactチュートリアルをcreate-react-appの形式に合わせて焼きなおすからリンク2ヶ月前
ここからはじめるReactの基礎の基礎からリンク約2ヶ月前
React.jsを使う前に公式を見ずQiitaなどを流し見してさらっと考えたからリンク約2ヶ月前
レトロエンジニアのための近代Webフロントエンド事情からリンク18日前
PR 社内メールでの情報共有をなくそう - Qiita:Team
sugerara
0contribution
2016-05-20 00:47
いいね
1
すみませんが、教えて下さい。
「太古の黒歴史である onClick」とありますが、寡聞にして知りませんでした。
参考になる資料などあれば、教えてもらえないでしょうか。
よろしくお願いします。
naruto
2488contribution
2016-05-20 07:37
いいね
0
@sugerara ご質問の意図を正しく理解できているか分からないのですが、「HTMLファイル内にはドキュメントの構造だけ書き、 onclick="func()" のようなインラインのJavaScriptコードは書くな」というのは、jQueryが支配的であった時代のごく一般的な推奨事項だったと思います。もしご存じなければ「HTML JavaScript 分離」とか「控えめなJavaScript」などで検索すると、そういうガイドが沢山でてきます。onclickが完全廃止されたわけではないです。本文で書いたとおり、最近のフレームワーク（Reactに限らず）では、書き方に違いはあれ、概ね「1つの機能を実現するHTML要素とJavaScript（と、場合によってはCSS）をまとめてしまえ」という考え方が多い気がします。
naruto
2488contribution
2016-05-20 10:53
いいね
2
ちなみにjQueryのオリジナル作者であるJohn Resig氏も、最近はもうReact派のようです。
https://twitter.com/jeresig/status/726058698989277185
（訳：「驚くほどのことでもないだろうけど、今は自分のコーディングのほとんどでReactを使ってるよ」）
sugerara
0contribution
2016-05-23 00:35
いいね
0
@naruto コメントありがとうございます。
HTMLとJavaScriptを書くなというのは、私も理解しているつもりです。
ただ、formをsubmitする前にクライアント側でチェックしたい場合、onclick="check()"などとして、
別のjsファイルに定義したチェック関数をコールするのを私は良くやっています。
onclickに直接記述するのではなく、イベントリスナーに登録する方がよいってことですね。
確かに、onclickに書いてしまうと他のイベントリスナーとの順番とか考えないといけないので
面倒ですね。参考になりました。
