Reactを使うとなぜjQueryが要らなくなるのか

  • 2551
    Like
  • 5
    Comment

はじめに

React (通称 React.js1) を全く知らない、あるいは幾つか記事を見たけどなんなのかピンと来ていない、という人のために、少し前にピンと来たばかり(のつもり)の人が書いています。

「jQueryくらいしか知らない」くらいの人に具体的に雰囲気を知ってもらうのが目的であり、すでにやる気がある人向けのチュートリアルではありません。やる気が出ればドキュメントを読んで手を動かせばあっという間なので、そこまでの興味が出ることを目標にしています。

厳密性や網羅性よりはイメージ優先なので、本来「DOM要素」と書くべき部分を「DOM」と略記しまくったりしていますが、ご了承ください。

以降では ES2015 (ES6) の文法(アロー関数とか)を普通に使います。Reactを使う以上、どうせ何らかのトランスパイラはほぼ必須ですし、だいたい今どきBabelかTypeScriptか使ってない人とかおらんやろ(煽り)。この部分が怪しい人は先にアロー関数だけでも知ってから先に進んでください。

Reactがやること

Reactがやることは非常にシンプルで、APIも数えるほどしかありません。「暗記力を使って覚えることの少なさ」に関してはピカイチです。そのわずかなAPIに、みんな慣れ親しんできたjQueryのメソッドの大部分を駆逐してしまうほどの威力があります

Reactがやれることを3行で説明すると、こうなります。

  1. 「ページ状態を保持しているプレーンなJSのオブジェクト」に、
  2. 「テンプレート的な関数」を作用させて、「仮想DOM」と呼ばれるDOMの設計図を取り出し、
  3. その設計図を使って本物のDOMを構築する。

ここでいう「プレーンなJSのオブジェクト」とは、JSONをパースしたりするだけで取得でき、タグとかの文字列を一切含まない、クリーンなデータを保持しているJSオブジェクトと思ってください。そこには、Web APIから読み取ってきた商品リストのデータであるとか、現在アクティブなタブのインデックスであるとか、入力中のフォームデータであるとかといった、「ページの状態」にあたるものがまとめて入っているイメージです(Fluxを聞いたことがあるならStoreに相当)。

Web APIなどからプレーンなオブジェクトを取り出し、そこから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);
    });
});

難しいことはしていませんが、見た目に直感的ではない感じはします。

同じことを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>
    </li>;
};

fetch('/api/items').then(res => res.json()).then(data => {
    ReactDOM.render(
        <ItemList items={data.items} />, // これを
        document.getElementById('container') // ここにレンダリングしろ
    );
});

え~ととりあえず、面妖な見た目のHTMLタグっぽいものを見て速攻逃げ帰りたくなった人がいますよね。なんとReactでは、このようにJavaScriptとHTML(?)が悪魔合体しているのが基本作法です。まあ少し我慢してお付き合いください。筆者もちょっと前までこの壮絶な外見を嫌悪して逃げていたクチですが、1日経たずにあっさり寝返りました。後でもう少し詳しく述べますが、とりあえずこの「タグ」は実際には単なる関数呼び出しであり、Babelなどに通すと機械的に関数呼び出しに変換されるので、これはあくまでJavaScriptです。$.getJSON() の代わりに使っている fetch についてはこれとかをご覧ください(もちろんお好みで superagent や axios を使っても構いません)。

まあともかく、DOMを直接切ったり貼ったりする部分はなくなり、代わりに2つのコンポーネント(というか関数)を定義しています。それぞれの関数はなにやら「HTMLタグっぽいもの」を返しており、その中でJavaScriptの変数が {} で埋め込まれています。このタグっぽいものが、巷で話題の仮想DOMと呼ばれているアレです。

ReactのAPIを露骨に呼び出しているのは最後の ReactDOM.render() だけ。しかもこれがこの記事に出てくる唯一のReactのAPIです。データを表示するだけならとりあえずこれさえあれば作れます。

:information_source: 2015年以前の記事で React.createClass という関数を使ってコンポーネントを定義している記事を見た人がいるかもしれませんが、現在は大部分のコンポーネントはこのように単なる関数か、あるいは後述するES6のクラスで記述するのが標準です。かなりスッキリしました。

ぱっと見、サーバサイド言語でもよく使われている、いわゆる「テンプレート」に似ている気がしませんか。ただしテンプレートがあくまで文字列ベースの処理なのに対し、Reactは 仮想DOMと呼ばれる「DOMの設計図」 をベースに処理をします。ItemListItemDetailといった関数が返している「タグっぽいもの」はDOM要素ではなく、あくまで設計図であり、つまりは非常に軽量なJavaScriptのオブジェクトです。

古典的なテンプレートエンジンでは、開発者はそのエンジン独自のテンプレート構文(ループとか)を覚え、テンプレートファイルを書いていきます。その代わりにReactでは、開発者はDOMの設計図をreturnする関数をJavaScriptで書いていきます。このHTMLタグっぽい記法と{}による任意の式の埋め込み以外に、独自規則はありません。ループや条件分岐は、見ての通り普段JavaScriptで使っている三項演算子や Array.prototype.map をそのまま使うだけです。

タグっぽい記述(の関数呼び出し)を通して仮想DOMを作ったら、ReactDOM.render が、それに対応する本物のDOM要素を指定した場所に構築してくれます。 これが、開発者が手でいちいち appendTo() とか removeClass() とか text() とか val() とかのjQuery的なDOM操作を書かなくて済む理由です

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' }, children: [ 'Hello ', { element: 'b', children: ['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') のようなJavaScriptコードに変換されます。この関数は実行されるとまさに上記のJSONに似たオブジェクトを出力し、それが仮想DOMの最終的な正体です。これだけなので、これを手書きする苦行を積みたい人はJSXを使わなくてもいいですが、本記事ではJSX使うべきということで通します。

逆にJSX記法さえあれば、古典的なテンプレートエンジンが頑張って実装してきたループ・条件分岐・子テンプレート呼び出し・テンプレート継承2・数値計算といった機能は、JavaScriptには全部元から備わっており、しかも超高速なのですから、使わない手はありません。

Babel や TypeScript は普通にJSXをサポートしています3ので、これらに馴染みがあれば導入のハードルは高くありません。JSX自体は汎用性の高い単なるシンタックスシュガーですから、他のライブラリでも採用されつつあるそうです。

慣れ親しんだテンプレートと比べると可読性はわずかに落ちますが、タグの対応ミスなどのシンプルな構文エラーはコンパイル時にチェックされ、エスケープ漏れなどでXSS脆弱性が入る余地もほぼありません。TypeScriptを使えば厳密な型チェックも入ります。

: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の記述方法こそが楽で合理的になります。

:information_source: 「JSXだと実装とデザインが分離できずデザイナーが辛いのでは」という点が気になる人がいるでしょうが、JSXでも規模に応じ、ビュー特化のコンポーネントとロジックが絡むコンポーネントを分けることはベストプラクティスです。詳細はこれとかこれを参照してください。

:information_source: セマンティックなHTMLを失うことによるアクセシビリティ低下が気になる人はARIAを学びましょう

理由: テンプレートより圧倒的に速い差分描画

何らかの理由(ユーザ操作など)でページの状態が変わり画面を書き直す場合、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に突然フル機能のカレンダー「タグ」や掲示板「タグ」が実装されたかのような感覚で扱えます。

// 1行でコンポーネントを定義
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)として与えられた情報のみで一意に決まるということです(数学的な意味での関数に近い)4。ステートレスコンポーネントは見てきたとおり、単なる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, consent: false };

const change = event => {
    const target = event.target;
    const value = target.type === 'checkbox' ? target.checked : target.value;
    user[target.name] = value; // 外部の状態を変更して…
    render(); // 新しいデータでざっくり再描画!
};

const submit = () => {
  /* userは最新版のフォームの状態を常に反映している! */
  alert(`${user.name}さん、登録ありがとう!`);
};

const isValidUser = () => (user.name.length > 0 && user.age >= 20 && user.consent);

// コンポーネント定義
const UserForm = props => <div>
    <p>名前: <input name="name" type="text" value={user.name} onChange={change} /></p>
    <p>年齢: <input name="age" type="number" value={user.age} onChange={change} /></p>
    <p><input name="consent" type="checkbox" checked={user.consent} onChange={change} /> 規約読みました</p>
    <button onClick={submit} disabled={!isValidUser()}>20歳以上なので登録</button>
    <pre>{JSON.stringify(user)}</pre>
</div>;

const render = () => {
    ReactDOM.render(<UserForm user={user} />, document.getElementById('container'));
};

render();

回りくどいと思うでしょうが、綺麗な元データが外部の1カ所にしかなく、DOMは必ずそれを反映しているので、複雑なフォーム・アプリほど楽さが際立ちます。jQueryで設定画面などのフォームを書くと、val()text() を駆使して、「生データの状態をDOMに反映させる」のと、逆の「DOMの状態から生データを再構築する」のを両方を書くことになりますが、この構造ならそういう作業は要りません。(One-way data flow という標語を聞いたことがある人は、それが指しているのはこれのことです。)

:information_source: 上記の例で、太古の黒歴史とされてきた onChangeonClick 属性が華麗に復活しているのを見て驚いた人がいるかもしれませんが、Reactの設計思想的には何も問題ありませんので、こういう新しい記法だと思いましょう。内部ではちゃんといろいろ最適化されているそうです。

例えばこのくらいの複雑さのフォームは、ReactだとjQuery UIの半分の行数と1/5の時間で実装できる感じ(6個のステートレスコンポーネントの組み合わせ。ステート付きコンポーネントは自力では書いていませんが、React-Bootstrap を使用しています。他にも便利なUIライブラリがたくさんあります)。

condition-image

さて、React自体は単機能の描画ライブラリであり、「外部の状態」をどこにどうやってどんな粒度で保存すべきかについて一切関知しません。小さなアプリなら上記サンプルコードに毛が生えた程度のものでページ全体をまるっと更新するので何の問題もありません。が、規模が大きくなってきた場合は、この「外部の状態」を管理するための別ライブラリを混ぜて使う人が多いです。FluxがどうとかStoreがどうってやつです。過去には(厳密には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が向いているのは後者。普段の仕事内容によって「もう一生jQuery要らない」って人もいれば「一生jQueryしか要らない」って人もいていいと思います。
  • あくまで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 系くらいですが、そのくらいならもっとコンパクトな代替品があります。そう気づいてしまい、残ったjQuery依存を消し去りたいという衝動に駆られたら、はじめて、ああいう記事の出番なわけです。わずか数カ所の数文字のタイプ数増加で、100KB超のライブラリを捨て去れるなら、Webでのメリットは大きいです。

元記事にもリンクされていますが、個人的にはYou Might Not Need jQueryというサイトがまとまっていてお勧め。


註: お陰様でよく読まれる記事になっていますので、ブクマコメント等を元に定期的に加筆修正やアップデートを行っています。最後の更新は2017年4月です。いま見当違いのように見えるコメントは、大抵は私が加筆したせいです。React使わない人を煽るような表現は当初から全くないつもりなのですが(想定読者様ですし…)、「仕様になったES6の文法や、モジュール分割の方法を一生学ばない」という選択肢はない5と信じているので、そこの部分で煽るのは止めないよ!



  1. 一応 "React.js" だの "ReactJS" だのというのは俗称です。ちなみにAngularもバージョン2からは後ろにJSが付かないのが正式名称です。 

  2. テンプレート呼びだしとは単なる関数呼び出しなので、ES6のクラス継承による多態性でも、依存性注入でも、好きな方法を使うだけです。React開発者たちのお勧めは「高階コンポーネント」というコンポーネントをラッピングする手法です。 

  3. 2015年半ばまではそうではなかったので、「ReactはaltJSと相性が悪い」という記事がたまに残っています。気をつけましょう。 

  4. 厳密には「ピュアレンダ」と「ステートレス」とを別の概念として区別する必要がありますが、この記事では割愛します。 

  5. 仮にその選択肢があるとしたら、恐らくその時点でReactの要らないプロジェクトです、安心してjQueryを使いましょう(←ダメ押しの煽り)。