Help us understand the problem. What is going on with this article?

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

はじめに

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

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

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

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

:dragon: 以下の説明中、このアイコンで表すのは(2019年2月現在から見た)『昔話』です。新しく自分のコードを書く際には本来知らなくていいことですが、古い記事を見たときに混同しないための参考情報として書いてあります。この記事自体はReactの最新に追従するように定期的に更新し、表現を見直しています。

Reactがやること

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

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

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

ここでいう「プレーンなJSのオブジェクト」とは、JSONをパースしたりするだけで取得でき、タグとかの文字列を一切含まない、クリーンなデータを保持しているJSオブジェクトと思ってください。

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です。データを表示するだけならとりあえずこれさえあれば作れます。

:dragon: 2015年以前の記事で React.createClass というAPIを使ってコンポーネントを定義している記事を見た人がいるかもしれませんが、これは既にレガシーとなっています。今後書くコンポーネントはこのように単なる関数か、あるいは後述するES6のクラスで記述します。

ぱっと見、サーバサイド言語でもよく使われている、いわゆる「テンプレート」に似ている気がしませんか。ただしテンプレートがあくまで文字列ベースの処理であるのに対し、Reactは 仮想DOMと呼ばれる2「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やCoffeeScript(>=2.0)を通すと、機械的に以下のようになります。試したい方は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コードに変換されます3。この関数は実行されるとまさに上記のJSONに似たオブジェクトを出力し、それが仮想DOMの最終的な正体です。これだけなので、これを手書きしたい人はJSXを使わなくてもいいです(実際悟りを開いた開発者の中にはJSXが要らなくなる人もいるようです)が、本記事ではJSX使うべきということで通します。

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

Babel や TypeScript や CoffeeScript は普通にJSXをサポートしており、これらに馴染みがあれば導入のハードルは低いです。JSX自体は汎用性の高い単なるシンタックスシュガーですので、他の多くのライブラリでも採用されており、各種エディタでのサポートも非常に良好です。もはや事実上の標準といっても過言ではない状態になっています。

:dragon: 2015年ごろまではJSX構文周りのエコシステムが貧弱で、Reactの開発チームが専用のJSX変換ツールを配布したりしていました。その時の名残で「ReactはaltJSと相性が悪い」という記事がたまに残っています。

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

:dragon: JSXは最初は違和感が強いでしょうが、実はこれは、XMLが今よりずっとメジャーだった時代に提案され、Firefoxに実装もされていた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の記述方法こそが楽で合理的になります。styled-components を使えばCSSすらも1ファイルにまとめて、完全に自己完結したコンポーネントが作れます。

:information_source: 「JSXだと実装とデザインが分離できずデザイナーが辛いのでは」という点が気になる人がいるでしょうが、JSXでも規模に応じ、ビュー特化の(純粋にテンプレート的な)コンポーネントとロジックが絡むコンポーネントを分けられます。詳細はこれとかこれを参照してください。まあ分けないほうが楽なことも多いので規模や設計次第です。

:information_source: 「HTMLとJavaScript(とCSS)を1つにまとめてコンポーネントという単位で管理すべき」という思想自体は、React対抗としてよく名前が挙がるVueやRiotでも共通です。

: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はどうあるべきか」の定義に集中できます。「ロード中はこのボタンとこのボタンを一時的に無効化してここにインジケータを表示して…」みたいな面倒なコードが一掃され、勝手にページ全体の一貫性が保たれます

この威力は絶大です。さっきの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)として与えられた情報のみで一意に決まるということです(数学的な意味での関数に近い)5。この思想のお陰で、コンポーネントは単なる関数で書くことができます。

Reactを使うにあたって、jQueryから一番考え方を変えないといけないのがこの部分でしょう。jQueryのコンポーネント(カレンダーでも、スライダーでも)は内部状態(プロパティ/ステート)として「現在の入力値」とか「disabledかどうか」とかを持っているのが当たり前でしたし、それの初期化と出し入れで記述が長くなる傾向にありました。Reactのコンポーネントでは、大事な状態は外部から流し込まれます。コンポーネントとは外部からの情報をDOM設計図に変換するプリズムに過ぎません。そう心得て、可能な限りそのように作るべきです。

:information_source: …と書きましたが、必要に応じてステート付きのコンポーネントも書けます。以下の2通りの方法があります。

  • 関数コンポーネント内でフックを使う。(2019年2月リリースのReact 16.8から利用できる新機能)
  • ES6のクラス構文を使う。

新しいAPIだけあって前者の方が遙かに楽なので新規コードでは基本的にそちらをお勧めしますが、当面はクラスで書かれたコンポーネントを扱うことも多いと思います。ステートにするのは「親コンポーネントと一切やりとりする必要がないプライベートな内部状態」だけにしましょう。「ドロップダウンメニューが今ドロップダウンされているかどうか」とか。

「外部に状態がある」というのはカスタムコンポーネントだけの話ではありません。Reactでは <input> などの標準フォーム要素ですらその発想が徹底しており、ステートレスな振る舞いをするようになっています。以下の例では value が「外から」固定されているので、この input 要素はリードオンリーになり、中身を変更できません。

See the Pen React examples on CodePen.

編集可能にしたければどうするのかというと、例の「ページ状態を管理しているプレーンなJavaScriptオブジェクト」を経由します。テキストボックス内で入力操作が起きた場合、内部状態が変わってからイベントが発火して外部状態を更新するのではなく、コールバック関数経由で外部状態を先に変更してから画面を「再描画」するのです。こんなイメージ。

See the Pen paVbjx by naruto (@narutan) on CodePen.

回りくどいと思うでしょうが、綺麗な元データ ("single source of truth") が外部の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外の話とはいえ)この部分が混沌としていましたが、今はとりあえずreduxという軽量なライブラリが最も人気です。深く考えたくない人はとりあえずこれを使っておけばいいんじゃないでしょうか。

:information_source: よく誤解されていますが、reduxのようなものは必須ではありません。Reactのチュートリアルなどでも使われていません。小さなアプリでreduxのような専用の状態管理ツールをいきなり導入してもタイプ量が増えるばかりで実用上のメリットがよく分からないと感じると思います。既にユニットテストや依存性注入などの概念が骨身に染みついた上で大規模開発をする人以外は、まずreduxなしでReactの考え方に慣れることをお勧めします。

Reactが向かない場合

もちろんReactが常に万能なわけではありません(タイトルが釣りっぽいのはごめんなさい)。Reactの弱点、Reactが向かない場合もありますのでよく考えて使いましょう。

  • React自体の理解に加えて、Babel/TypeScriptのようなトランスパイラの知識は(絶対ではないけど)ほぼ必須で、Webpack/Browserifyのようなモジュールバンドルシステムの知識も(絶対ではないけど)ほぼ必須。そこまで至っていない人にとっては多少学習コストはあります。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で使えると便利なのは $.extend (Object.assignがIE11でも未サポート)と $.ajax 系くらいですが、そのくらいならもっとコンパクトな代替品があります。そう気づいてしまい、残ったjQuery依存を消し去りたいという衝動に駆られたら、はじめて、ああいう記事の出番なわけです。わずか数カ所の数文字のタイプ数増加で、100KB超のライブラリを捨て去れるなら、Webでのメリットは大きいです。

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


註: お陰様でよく読まれる記事になっていますので、ブクマコメント等を元に定期的に加筆修正やアップデートを行っています。最後の更新は2019年2月です。いま見当違いのように見えるコメントは、大抵は私が加筆したせいです。



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

  2. 「仮想DOM」は、ドキュメントなどでは「React要素」と呼ばれています。これはReactの応用先が今やブラウザ上のDOMのみに限られないからです。この記事では有名かつ直感的な名称である「仮想DOM」を使用します。 

  3. この React.createElement はトランスパイラの設定などで変更できるので、React 以外のライブラリも JSX を利用できます。 

  4. テンプレート継承にあたることはES6のクラス継承でも実現できますが、React開発者は継承の代わりに「Render Props」とか「高階コンポーネント」という手法を勧めています。詳細は他の記事に譲ります。 

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

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away