どうもReactおじさんです。 過去の案件も含め、JavaScript(TypeScript)の等価演算子(==)、厳密等価演算子(===)がごちゃ混ぜになって使用されているのをよく見かけてきました。 今回は、等価演算子(==)と厳密等価演算子(===)を詳細に解説し、プロジェクトで統一できるようにします。 特に他言語からJavaScript(TypeScript)に移行してきた方は最後まで読んでみてください！ <h2 id="h3c979e4c18">等価演算子(==)と厳密等価演算子(===)の違い</h2>まず、等価演算子(==)と厳密等価演算子(===)を使用した場合の判定結果を見ていきます。 <h3 id="hbf435f6bb7">等価演算子(==)</h3><pre><code>// 等価演算子
console.log(1 == 1);
// Expected output: true

console.log('hello' == 'hello');
// Expected output: true

console.log('1' == 1);
// Expected output: true

console.log(0 == false);
// Expected output: true

console.log(null == undefined);
// Expected output: true</code></pre> <h3 id="hf42abc9437">厳密等価演算子(===)</h3><pre><code>// 厳密等価演算子
console.log(1 === 1);
// Expected output: true

console.log('hello' === 'hello');
// Expected output: true

console.log('1' === 1);
// Expected output: false

console.log(0 === false);
// Expected output: false

console.log(null === undefined);
// Expected output: false</code></pre> 上記は<a href="https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/Strict_equality" target="_blank" rel="noopener noreferrer">公式</a>を参考にしています。 等価演算子(==)と厳密等価演算子(===)の違いは、型まで等しく判定できる・できないかが大きな違いになってきます。 下記を確認してみましょう。<pre><code>// 等価
console.log('1' == 1);
// Expected output: true

// 厳密等価
console.log('1' === 1);
// Expected output: false</code></pre> string型の'1'とnumber型の1を比較しています。 等価演算子(==)の際、1というデータを比較するとtrueになります。 しかし厳密等価演算子(===)の場合だと、string型の'1'とnumber型の1かどうか型を比較してfalseになっていることがわかります。 これが、型まで等しいか確認しているかということになります。 他にもnullとundefinedを比較した際に、等価ではどちらもデータが無いという意味でtrueになりますが、厳密等価ではnull型とundefined型の比較になり型が等しく無いのでfalseになります。 次になぜ、等価演算子を使用することが非推奨なのか確認していきましょう。 <h2 id="h219becd0f0">なぜ等価演算子(==)がダメなのか</h2>結論から述べると、バグが発生する可能性があるからです。 下記で具体的な例を見てみましょう。 <pre><code>function validateInput(input) {
 if (input == 123) {
 console.log('input is valid');
 } else {
 console.log('input is invalid');
 }
}

validateInput('123');</code></pre> 例えば、ユーザーが入力した値を検証するためにnumber型の入力値とstring型の入力値を比較する場合を考えます。 この場合、厳密等価演算子(===)を使用せずに等価演算子(==)を使用しているためstring型の入力値'123'がnumber型の123に変換され、入力値が文字列であるにもかかわらずinput is invalidと表示されます。 このように、等価演算子(==)を使用することで意図しない型変換が行われ、バグの原因となる可能性があるため、厳密等価演算子(===)を使用することが重要です。 <h2 id="h7642621081">ESLintの「eqeqeq」ルールを使用する</h2>ここまで等価・厳密等価演算子について解説してきましたが、プロジェクトによってこの辺が曖昧に使用されていたりすることが多々あります。 そこで、等価演算子(==)を使用した際にエラーを出すESLintのルールeqeqeqを紹介します。 公式: <a href="https://eslint.org/docs/latest/rules/eqeqeq" target="_blank" rel="noopener noreferrer">eqeqeq</a> ESLint自体の詳細は割愛させていただきますが、eslint.json,yml,jsなどのrulesに1行追加するだけです。(eslintはnpm installする必要あり) eslint.json<pre><code>{
	 "parser": "@typescript-eslint/parser",
	 "plugins": ["import", "@typescript-eslint", "prettier"],
	 "ignorePatterns": ["*.config.js", "*.setup.js", "*.js"],
	 "extends": [
	 "eslint:recommended",
	 "next",
	 "plugin:@typescript-eslint/recommended",
	 "plugin:@typescript-eslint/recommended-requiring-type-checking",
	 "plugin:import/recommended",
	 "prettier"
	 ],
	 ...
	 "rules": {
	 ...
 "eqeqeq": "error", // 追加
	 ...
 	 }
}</code></pre> エディタでエラーが出ているか確認 <img src="https://images.microcms-assets.io/assets/92d5d05a58d743f0abd69ff4e6ea61a5/314c93c81c624ebb835f12579e6eb1e8/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202023-02-27%200.22.21.png" alt=""> 等価演算子を使用した際にエラーが出ていることを確認できました。 <h2 id="ha214098e44">まとめ</h2>等価演算子、厳密等価演算子について説明してきましたが、バグを未然に防ぐためにも厳密等価演算子(===)を使用しましょう。 もし、自分のプロジェクトで統一できていなければESLintのルール「eqeqeq」を使用して、エラーを出すなりしてコードの品質担保に力を入れてみてください。 間違っている部分やもっと良い方法があれば<a style="background-color:#ffffff" href="https://twitter.com/react_nextjs" target="_blank" rel="noopener noreferrer">Twitter</a>でDMお願いします。

JavaScript(TypeScript)の等価演算子(==)、厳密等価演算子(===)について解説していきます。厳密等価演算子(==)を使用するとバグが発生する可能性があるので厳密等価演算子(===)を使用するようにします。また、ESLintのルール「eqeqeq」を使用することで、プロジェクトで厳密等価演算子(===)に統一することができ、ソースコードの品質担保に繋がります。

JavaScript(TypeScript)の等価演算子(==)、厳密等価演算子(===)をプロジェクトで統一しよう！

どうもReactおじさんです。 今回はJavaScript/TypeScriptで使用するDefault exportとNamed exportの違いと使い分けをReactベースでまとめてみました。 あくまでも私が調べた中での結果なので、その辺を理解した上で読んでいただけると幸いです。 さっそく両者の違いについて確認していきましょう。 <h2 id="heb509af4ee">Default export</h2><pre><code>/* export */
const Button = () =&gt; {
 return &lt;button&gt;テスト&lt;/button&gt;;
};

export default Button;

---------------------------------------------------------------

/* import */
 // 命名する
import Button from '@/components/Button'; </code></pre> <h3 id="h76fd8ea3f6">importする側で対象を命名する必要がある</h3>上記の例で参考にすると、Buttonを自分で命名する必要があります。 これはButtonコンポーネントに対して、Buttonと命名し何をimportしているのか明確にわかるようになっていますが、下記の場合どうでしょう。 <pre><code>/* import */
import ScrollButton from '@/components/Button';
import SubmitButton from '@/components/Button';</code></pre>対象を自分で命名できるのは便利ではあります。 しかし、同じコンポーネントを使用しているのにあるページではScrollButton、あるページではSubmitButtonとなっているとコンポーネント名が統一されず、Buttonコンポーネント自体がどのようなものか不明確になり良くありません。 また、moduleの命名を変更し、import先で修正ミスがあった場合、動かしてみるまでエラーが見つからないことは欠点です。 Default exportを使用するなら命名はプロジェクトでしっかり管理することが重要になってくるでしょう。 <h3 id="hda47f5b166">React.lazyを使用する時はDefault exportしか使えない</h3>ここではReact.lazyについてあまり触れませんが、簡潔に説明するとファイルを分割して遅延読み込みができる機能です。 こんな感じ↓<pre><code>const ButtonComponent = lazy(() =&gt; import('../components/Button'));</code></pre>ButtonコンポーネントをNamed exportにするとエラーが発生します。 公式を確認してみた所、Named exportには対応していないようです。 気になる方は公式を確認してみてください。 公式: <a href="https://reactjs.org/docs/code-splitting.html#reactlazy" target="_blank" rel="noopener noreferrer">React.lazy</a> <h2 id="h7c575df7d2">Named export</h2><pre><code>/* export */
export const Button = () =&gt; {
 return &lt;button&gt;テスト&lt;/button&gt;;
};

---------------------------------------------------------------

/* import */
import { Button } from '@/components/Button'</code></pre> <h3 id="he464f7da91">import、exportで命名が統一できる</h3>export側で命名を変更した際に、import側でエラーが出る。<pre><code>/* export */
// TestButtonに変更
export const TestButton = () =&gt; {
 return &lt;button&gt;テスト&lt;/button&gt;;
};

---------------------------------------------------------------

/* import */
import { Button } from '@/components/TestButton'
// errorが出て正常にimportできない</code></pre> Default exportだとエラーが出ないので動かしてみるまで変更点に気づきにくい部分がありますが、Named exportだと変更したタイミングでエディタ上にエラーが表示され、バグを未然に防止できます。(VSCodeを想定) また、importする際に補完が効くのでタイポ防止にもなります。 <h3 id="h82d4f50b55">TypeScriptを使用している場合、import側で型定義できる</h3><pre><code>/* Type Ailias export */
export type ApiResponse = {
 name: string;
 age: number;
};

/* interface export */
export interface ApiResponse {
 name: string;
 age: number;
};

---------------------------------------------------------------

/* import */
import { ApiResponse } from './types' // Named import
import type { ApiResponse } from './types' // Type-Only Imports
import { type ApiResponse } from './types' // Type&nbsp;Modifiers on Import Names&nbsp;</code></pre> 型をimportする際にいくつか方法があるので順番に見ていきましょう。 ■Named import Named exportした際にimportしてくる構文になります。 そのまま型を付与すればOKです。 ■Type-Only Imports and Export こちらは<a href="https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-8.html" target="_blank" rel="noopener noreferrer">TypeScript3.8</a>から追加された機能で、moduleから型をimportする際に、typeを使用して型のみをimportできる構文です。 しかし、この構文には制限があり値のimportと同時に使用することはできず、一つのモジュールから型情報と値どちらもimportする場合にはそれぞれimportを別に書かなくてはいけません。 こんな感じ↓<pre><code>/* export */
export type Props = {
 children: string
}

export const Button = ({ children }) =&gt; {
 return &lt;button&gt;{children}&lt;/button&gt;;
};

---------------------------------------------------------------

/* import */
import { Button } from '@/components/Button' // コンポーネントをimport
import type { Props } from '@/components/Button' // 型をimport</code></pre> ■type Modifiers on Import Names&nbsp; この機能は<a href="https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-5.html#type-modifiers-on-import-names" target="_blank" rel="noopener noreferrer">TypeScript4.5</a>で追加された機能で、今回の記事を執筆している時に初めて知りましたw 簡単に説明すると、Type-Only Imports and Exportで値と型のimportが同時に出来なかったものができるようになりました。 こんな感じ↓<pre><code>/* export */
export type Props = {
 children: string
}

export const Button = ({ children }) =&gt; {
 return &lt;button&gt;{children}&lt;/button&gt;;
};

---------------------------------------------------------------

/* import */
import { Button, type Props } from '@/components/Button' </code></pre> この利点は同じmoduleから値と型の情報がimportできるようになるので、Type-Only Imports and Exportで値と型を分けていた部分が解消されました。 <h2 id="ha214098e44">まとめ</h2>Default exportとNamed exportについてまとめてきましたが、Next.jsなどDefault exportを使用しないといけない箇所以外はNamed exportを中心に使っていく方が良いと判断しました。 やはり命名でバグを未然に防ぐことができるのが開発を進めていく上で生産性が高くなるので一番の利点だと思っています。 他にもTypeScriptの機能が豊富なのが魅力です。 この辺は宗教的な話になるので正解はありませんが、もっと良い意見や考え方があれば<a href="https://twitter.com/react_nextjs" target="_blank" rel="noopener noreferrer">Twitter</a>でDMください。

フロントエンドだけでなくバックエンドでもJavaScriptのdefault exportsとname exportsどっちを使用すれば良いか悩んでいる人は多いと思います。今回はReactをベースにして両者の違いに触れ、ケースバイケースで使用できるように解説していきます。

ReactでDefault exportとNamed exportどちらを使用すれば良いのか??

どうもReactおじさんです。 先日、三項演算子についてツイートした際に反響があったので詳しく深掘りしていこうと思います。 <blockquote class="twitter-tweet">たまに三項演算子の中に三項演算子を書く人がいるけど可読性悪すぎてNGな気がする。 基本、１つの三項演算子で解決できないのであればif文使って書いた方が良い。&mdash; Reactおじさん (@react_nextjs) <a href="https://twitter.com/react_nextjs/status/1589819315716788224?ref_src=twsrc%5Etfw">November 8, 2022</a></blockquote><script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>特に初学者の方には刺さる内容だと思うので最後まで読んで、現場で今回解説する出来事があればこの記事の内容を元にドヤってみてください。 <h2 id="h407456acd2">三項演算子とは</h2>三項演算子が分からない方向けに軽く解説します。 めちゃくちゃ噛み砕いて説明すると、if 〜 else 〜 と書きたい時に一文で済ませる演算子のことです。 if文の場合<pre><code>const num = 4

if (num === 4) {
 // 真の処理
} else {
 // 偽の処理
}</code></pre> 三項演算子の場合<pre><code>const num = 4

num === 4 ? /* 真の処理 */ : /* 偽の処理 */</code></pre>三項演算子の場合、if文と比べて一文で記載できるので可読性が良くなりましたね！ では、次に三項演算子の入れ子について見ていきましょう。 <h2 id="ha7d379640e">なぜ入れ子になった三項演算子がダメなのか</h2>まずは入れ子になった三項演算子とはどのようなものかサンプルを作りました。 入れ子の三項演算子<pre><code>const num = 4;
const num1 = 5;

num === 4
 ? console.log('4です')
 : num1 === 5
 ? console.log('5です')
 : console.log('4でも5でもないです');</code></pre>一つずつ確認していきましょう。 まず、numが4の時は「4です」がログに表示されます。 numが4じゃない時は、num1が5であれば「5です」が表示され、num1が5でない時は「4でも5でもないです」がログに表示される三項演算子になります。 めちゃくちゃ読みづらいですよね、、 自分でサンプル作ってても可読性悪すぎて頭が混乱してきましたw この程度の簡単な処理であれば最悪読めなくもないのですが、これがReactのJSX内で記述されていた時には中々読み取るのに時間もストレスもかかってしまうでしょう、、 Twitterでも記載しましたが、入れ子になる場合はif文を使用して可読性を高めましょう。 入れ子になった三項演算子をif文で書いた場合<pre><code>const num = 4;
const num1 = 5;

if (num === 4) {
 console.log('4です');
} else if (num1 === 5) {
 console.log('5です');
} else {
 console.log('4でも5でもないです');
}</code></pre>入れ子になっていた時よりもソース量は若干増えますが、パッと見た時になんの処理を書いているのかすぐにわかるようになりました。 <h2 id="hd8969f652e">ESLintのno-nested-ternaryルールを使用する</h2>ここで三項演算子の入れ子をした時にエラーを出すESLintのルールno-nested-ternaryを紹介します。 公式: <a href="https://eslint.org/docs/latest/rules/no-nested-ternary" target="_blank" rel="noopener noreferrer">no-nested-ternary</a> ESLint自体の詳細は割愛させていただきますが、eslint.json,yml,jsなどのrulesに1行追加するだけです。(eslintはnpm installする必要あり) eslint.json<pre><code>{
	 "parser": "@typescript-eslint/parser",
	 "plugins": ["import", "@typescript-eslint", "prettier"],
	 "ignorePatterns": ["*.config.js", "*.setup.js", "*.js"],
	 "extends": [
	 "eslint:recommended",
	 "next",
	 "plugin:@typescript-eslint/recommended",
	 "plugin:@typescript-eslint/recommended-requiring-type-checking",
	 "plugin:import/recommended",
	 "prettier"
	 ],
	 ...
	 "rules": {
	 ...
 "no-nested-ternary": "error", // 追加
	 ...
 	 }
}</code></pre> エディタでエラーが出ているか確認 <img src="https://images.microcms-assets.io/assets/92d5d05a58d743f0abd69ff4e6ea61a5/3ac8a14acf454241adff120f4eb61037/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202022-11-11%2016.28.20.png" alt=""> 入れ子になった場合はエラーが出てますね！ <h2 id="ha214098e44">まとめ</h2>三項演算子について色々書いてきましたが、基本if 〜 else 〜 の場合は使用した方がよく、入れ子になる際はif文を使用しましょう。 プロジェクトによっては、そもそも三項演算子を禁止して全部if文で書くところもあるそうです。 大事なのはケースバイケースで使い分けれることだと思います。 プロジェクトでメンバーのスキルがバラバラな場合は、no-nested-ternaryを使用し、ルールを統一してソースコードの品質を担保していきましょう。 これはJavaScriptのみにならず、三項演算子が使用される言語全てに共通していることなので是非参考にしてみてください。 間違っている部分やもっと良い方法があれば<a href="https://twitter.com/react_nextjs" target="_blank" rel="noopener noreferrer">Twitter</a>でDMお願いします。

ESLintのルールno-nested-ternaryについて言及していきます。このルールは三項演算子の入れ子を禁止するルールです。三項演算子の入れ子は可読性が悪いのでプロジェクトで見かけたらこのルールを入れてソースコードの可読性を担保しましょう。

ESLintのno-nested-ternaryを使用して三項演算子の可読性を担保しよう!!

どうもReactおじさんです。 昨今のReact、Next.jsの進化の早さにはとても驚いています。 それはReactに追従するライブラリも同様です。 特にReactの状態管理ライブラリは戦国時代を迎え、様々な状態管理ライブラリが台頭してきました。 今回はライブラリの紹介、これから使用されていくであろう物にフォーカスして自分なりにまとめてみようと思います。 ※2022年版に更新しました。 <h2 id="h79b411f1c1">結局、状態管理ライブラリは何が人気なのか？？</h2>JavaScript Rising StartsのState Management部門(2022)とnpm trendsを見ていきましょう。 <h3 id="hb15961a87d">JavaScript Rising Starts</h3><img src="https://images.microcms-assets.io/assets/92d5d05a58d743f0abd69ff4e6ea61a5/d255fe29668645fa816337fa365156fd/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202023-01-04%2016.34.51.png" alt=""> ※ <a href="https://risingstars.js.org/2021/en#section-statemanagement" target="_blank" rel="noopener noreferrer">JavaScript Rising Starts</a>とはGithubのスター数でのランキングをまとめたもの(2022/1/4現在) <h3 id="ha421048148">npm trends</h3><img src="https://images.microcms-assets.io/assets/92d5d05a58d743f0abd69ff4e6ea61a5/6f482c67016f458db6892ccd0bac23d4/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202022-11-02%2019.36.09.png" alt=""> ※<a href="https://npmtrends.com/jotai-vs-recoil-vs-redux-vs-valtio-vs-zustand" target="_blank" rel="noopener noreferrer"> npm trends</a>とはnpmからダウンロードされたパッケージの数をグラフ表示出来るもの(2022/11/2時点) 2022年版JavaScript Rising StartsではZustandが圧倒的な人気で一位を獲得しています。 自分が予想していた通り、JotaiがRecoilを抜かして堂々の3位になりましたね。 そして僕が推しているValtioもReduxを抜いて6位まで上がってきました。 今年度中にはRecoilを抜くと思われます。 一転、npm trendsでは70万ダウンロードされているReduxが圧勝。 Zustandなどはまだまだこれからって感じですね、、 Reduxは10年前くらいからあったのでダウンロード数が多いが、最近では他のライブラリの勢いが増してきて人気が落ちてきていますね。 では、次にStore・Atomベースについて解説し、各ライブラリの情報を見ていきたいと思います。 <h2 id="h4d05cf9f01">Storeベースの状態管理ライブラリ</h2>まず最初にStoreベースとは何か図で解説していきます。 <img src="https://images.microcms-assets.io/assets/92d5d05a58d743f0abd69ff4e6ea61a5/2a7de941b18f451d9a69243632a6af31/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202022-11-02%2023.23.28.png" alt=""> 青丸はコンポーネントになります。 Storeベースとは状態をStoreという一つのオブジェクトとして管理し、各コンポーネントから参照できることを言います。 よく使われるライブラリとしてRedux、Zustandなどがあります。 <h3 id="h227615658d">Redux</h3>公式: <a href="https://redux.js.org/" target="_blank" rel="noopener noreferrer">https://redux.js.org/</a> <ul><li>Facebook(現Meta)社が提唱している、Fluxアーキテクチャを採用している</li><li>単一方向にデータが流れていくので、データの流れを追従しやすくなる</li><li>大規模なアプリではより堅牢化できるので力を発揮できる</li><li>Action、Dispatch、Reducer、Storeなどファイルを分割して管理するのが一般的でファイル数が増加するのが問題</li><li>恐らく一番最古残でシェア率が高い状態管理ライブラリ</li><li>Reduxで非同期処理を実現させるには、別でmiddllewareライブラリ(redux-thunk、redux-saga)を導入した方がいい。</li><li>どうしても初学者には学習コストが高くなってしまう。</li><li><a href="https://chrome.google.com/webstore/detail/redux-devtools/lmhkpmbekcpmknklioeibfkpmmfibljd" target="_blank" rel="noopener noreferrer">Redux DevTools</a>というChromeの拡張機能があり、状態の変更を画面で確認できる</li></ul> オススメ度: ★★☆☆☆ 状態管理の流れを単一方向の流に絞れるのでバグが発生する可能性を大幅に削減できます。 しかし、ファイル数の増加や、複雑になってくることが多いため個人的にはあまり使用したくないです。 最近は、新規開発で導入するところはあまり見なくなってきて、脱Reduxが進んでいます。 Storeに全データをぶち込む人とは仲良くできそうにありません。笑 <h3 id="h7526918382">Zustand</h3>公式: <a href="https://zustand-demo.pmnd.rs/" target="_blank" rel="noopener noreferrer">https://zustand-demo.pmnd.rs/</a> <ul><li>公式のクマさん(?)が可愛いです</li><li>Reduxのようなボイラーテンプレートを作成する必要がなく簡潔に記述できる(Redux-Toolkitをさらに簡潔にした感じ)</li><li><a style="background-color:#ffffff" href="https://chrome.google.com/webstore/detail/redux-devtools/lmhkpmbekcpmknklioeibfkpmmfibljd" target="_blank" rel="noopener noreferrer">Redux DevTools</a>にも対応している</li><li>Reduxを理解している人だと、学習コストがほぼかからない</li><li>サイズがめちゃくちゃ軽い</li><li>一応Storeが複数作れるらしい</li></ul> オススメ度: ★★★★☆ 個人的には結構オススメな状態管理ライブラリ。 公式のクマさんが可愛過ぎて推しているところもあります。 Storeが複数作れるので完全なStoreベースとは言えませんが一応括りはここに入れておくことに。 StoreベースとAtomベースの中間地点だと認識してもらえると幸いです。 Reduxをさらにコンパクトにしたもので、Reduxから置き換える時に学習コストがほぼかからないのでオススメの一品。 読み方はドイツ語で「チュースタンド」と読むらしいです。 <h2 id="h3e55398a54">Atomベースの状態管理ライブラリ</h2>次にAtomベースについて解説していきます。 <img src="https://images.microcms-assets.io/assets/92d5d05a58d743f0abd69ff4e6ea61a5/00004adda2254de994f0ac396c194830/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202022-11-02%2023.33.12.png" alt=""> Atomベースとは、Storeベースとは異なり複数のAtomで状態管理を行うことを言います。 各コンポーネントから複数のAtomを参照できる形になります。 必要であれば間にSelectorを挟み、Atomのデータを加工してそちらからも参照可能です。 よく使われるライブラリとしてRecoil、Jotaiなどがあります。 <h3 id="hc41e2fe005">Recoil</h3>公式: <a href="https://recoiljs.org/" target="_blank" rel="noopener noreferrer">https://recoiljs.org/</a> <ul><li>Meta社が開発した状態管理ライブラリ</li><li>大きく分けてAtom、Selectorという概念がある</li><li>基本はAtomのみで状態管理は完結できる</li><li>Atomが状態管理を行う部分、SelectorはAtomから派生させたい値を作りたい時とかに利用できる</li><li>Atomを一つにまとめてReduxのStoreのように扱うこともできる</li><li><a href="https://chrome.google.com/webstore/detail/recoil-dev-tools/dhjcdlmklldodggmleehadpjephfgflc" target="_blank" rel="noopener noreferrer">Recoil Dev Tools</a>があり、Atomの状態を確認できる</li><li>hooksのuseStateの様な形式でAtomから状態を参照できる</li></ul> オススメ度: ★★★☆☆ Meta社が開発した状態管理ライブラリ。 まだ正式リリースではないので今後破壊的変更が入る可能性があるが、最近は開発現場でよく使用されている印象があります。 状態を一意のkeyを使って管理するので、uuidなどを使用しkeyが被らないようにするのが良いです。 (勉強会で教えてもらった) パッケージサイズがやたらと重いので複雑な状態管理が必要でなければこの後出てくるJotaiでも良い気がします。 バックグラウンドがMeta社なので将来性は期待できそうです！ <h3 id="he797c16ec4">Jotai</h3>公式: <a href="https://jotai.org/" target="_blank" rel="noopener noreferrer">https://jotai.org/</a> <ul><li>ほぼRecoilと一緒(Recoilより簡潔に記述できる)</li><li>基本Atomが状態管理を行う部分。Selector的なものはないがRecoilと同じでSelectorとほぼ同等のものが作れる</li><li><a style="background-color:#ffffff" href="https://chrome.google.com/webstore/detail/redux-devtools/lmhkpmbekcpmknklioeibfkpmmfibljd" target="_blank" rel="noopener noreferrer">Redux DevTools</a>が使用できる</li><li>Twitterでのサポートが熱い(<a href="https://twitter.com/jotaifriends" target="_blank" rel="noopener noreferrer">Jotai Friends</a>)</li></ul> オススメ度: ★★★★☆ 作者は日本人なので日本語の情報が豊富で公式ドキュメントも詳細に記載されている。 JotaiはRecoilの思想に強く影響を受けており、ほぼRecoilと同じ書き方ができる。 個人的にはパッケージサイズも小さく、React Hooksを学んでいる人であれば学習コストがほぼかからないのでオススメです。 <h2 id="ha214098e44">まとめ</h2>ここまで人気が高い状態管理ライブラリを紹介してきました。 色々調査した中で、個人的な所感も含め記載してきましたが、Atomベースは状態管理を複数のAtomで行うためしっかり管理しないとカオスなコードが生まれそうな予感がしました。 どちらにしろ状態管理ライブラリを扱うには設計が命になってくるので、個人のプロジェクトにあったものをできるだけ正確に選定する力が必要になってくるなと思います。 ちなみに筆者は紹介したライブラリ全て使用した経験がありますが、一番使いやすいなと思ったのはJotaiでした。 他にもSWRやReact Queryなどで状態管理する方法もありますが今回は省いています。 今後はRedux、Zustandなどの記事も書いていこうと思います。 あくまで個人の所感なので間違っている部分があればTwitterなどでDMください。 <a href="https://valtio.pmnd.rs/docs/introduction/getting-started" target="_blank" rel="noopener noreferrer">Valtio</a>使ってみたい、、

Reactの状態管理ライブラリについて考察していきます。StoreベースのRedux・Zustand、AtomベースのRecoil・Jotaiについての特徴を解説します。この記事を読むことで要件にあったライブラリを選定できる参考になればと思います。

Reactの状態管理ライブラリを比較してベストな選択をしよう！

どうもReactおじさんです。 ブログをリリースして満足していましたが、記事を執筆しないと価値が無くなってしまうので、だらけずにアプトプットしていこうと思います。 今回は汎用コンポーネントの作り方です。 <h2 id="h22ff7066ae">一般的な汎用コンポーネントの作り方</h2>フロントエンドエンジニアであればコンポーネント作成は避けて通れない道ですよね、、 今回のメインに行く前に一般的に作られているコンポーネントの作り方をおさらいしましょう。 <h3 id="he0a8675f39">ボタンコンポーネントの場合</h3><pre><code>import type { FC, ReactNode } from "react";

type Props = {
 children: ReactNode;
 onClick: () =&gt; void;
};

export const Button: FC&lt;Props&gt; = ({ children, onClick }) =&gt; {
 return &lt;button onClick={onClick}&gt;{children}&lt;/button&gt;;
};</code></pre> <h3 id="h458ac61db2">テキストフィールドコンポーネントの場合</h3><pre><code>import type { ChangeEventHandler, FC } from "react";

type Props = {
 value: string | number;
 onChange: ChangeEventHandler&lt;HTMLInputElement&gt;;
};

export const TextFiled: FC&lt;Props&gt; = ({ value, onChange }) =&gt; {
 return &lt;input type="text" value={value} onChange={onChange} /&gt;;
};</code></pre> ボタンコンポーネントはクリックが可能。 テキストフィールドコンポーネントは入力が可能な最低限の機能を備えています。 では次に、ボタンコンポーネントにボタンのタイプ、活性 or 非活性の機能を追加してみましょう。 <pre><code>import type { FC, ReactNode } from "react";

type Props = {
 children: ReactNode;
 onClick: () =&gt; void;
 disabled: boolean; // 追加
 type: "button" | "reset" | "submit"; // 追加
};

export const Button: FC&lt;Props&gt; = ({ children, onClick, type, disabled }) =&gt; {
 return (
 &lt;button type={type} onClick={onClick} disabled={disabled} &gt;
 {children}
 &lt;/button&gt;
 );
};</code></pre> disabledとtypeを追加しました。 上記の様に何か機能を追加したい時は、ボタンコンポーネントの修正・ボタンコンポーネントを呼び出している親コンポーネントの修正が必要になります。 一見普通に見えますが、テキストフィールドコンポーネントの場合id、onBulr、name、onKeyDown等の要素やイベントを必要になった時に追加していくのはメンテコストがかかるし受け取るPropsの型定義が冗長になっていきます。 そこで次に出てくるComponentProps型が救世主となります。 <h2 id="h49c99ca828">ComponentProps型を使用した汎用コンポーネントの作り方</h2>ComponentProps型とは、簡単に説明すると指定したコンポーネントのProps型を取得できる型です。 ↓こんな感じ<pre><code>type Props = ComponentProps&lt;typeof Button&gt;;</code></pre> <img src="https://images.microcms-assets.io/assets/92d5d05a58d743f0abd69ff4e6ea61a5/2cd2e5c370cc44659337313de7847da3/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202022-10-19%2020.31.43.png" alt=""> 例えば、先ほどのボタンコンポーネントをComponentProps型に指定すると、 ボタンコンコーネントのPropsの型を全て取得できます。 では、先ほどのボタン・テキストフィールドコンポーネントを修正していきます。 <h3 id="h75643da8d3">ボタンコンポーネントの場合(ComponentProps ver)</h3><pre><code>import type { FC, ReactNode, ComponentProps } from "react";

type Props = {
 children: ReactNode;
} &amp; ComponentProps&lt;"button"&gt;;

export const Button: FC&lt;Props&gt; = ({ children, ...props }) =&gt; {
 return &lt;button {...props}&gt;{children}&lt;/button&gt;;
};</code></pre> 親コンポーネント<pre><code>import { Button } from "../components/button";

const Index = () =&gt; {
 const onClickHandler = () =&gt; console.log("click");

 return (
 &lt;Button type="button" onClick={onClickHandler}&gt;
 テスト
 &lt;/Button&gt;
 );
};

export default Index;</code></pre> <h3 id="h2deda0682e">テキストフィールドコンポーネントの場合(ComponentProps ver)</h3><pre><code>import type { ComponentProps, FC } from "react";

type Props = ComponentProps&lt;"input"&gt;;

export const TextFiled: FC&lt;Props&gt; = ({ ...props }) =&gt; {
 return &lt;input {...props} /&gt;;
};</code></pre> 親コンコーネント<pre><code>import { ChangeEvent, useState } from "react";
import { TextFiled } from "../components/textFiled";

const Index = () =&gt; {
 const [value, setValue] = useState("");

 const onChangeHandler = (e: ChangeEvent&lt;HTMLInputElement&gt;) =&gt;
 setValue(e.target.value);

 return &lt;TextFiled value={value} onChange={onChangeHandler} /&gt;;
};

export default Index;</code></pre> 順番に見ていきましょう。 <ol><li>ボタン、テキストフィールドコンポーネント両方にComponentPropsを追加</li><li>受け取るPropsをスプレット構文で一括に受け取れるように修正</li><li>受け取ったPropsを各要素に追加</li></ol> まず1ですが、ComponentProps型を追加してボタンの要素(type,onClick,disabled等)、テキストフィールドの要素(type,onChange,value等)の型を全て受け取っています。 そして2と3で受け取ったPropsを展開していている形になっています。 これで親コンポーネントからPropsを渡してもボタン、テキストフィールドコンポーネントは修正せずに済むのでメンテコストがかからずコード量も削減できました。 ただし、Reactのinput要素はonChange、valueが必須なのでその場合は、下記の様にOmitでComponentPropsから必要な型は除外して、明示的にPropsの型定義を書くことでバグを回避するようにしましょう。 <pre><code>import type { ChangeEventHandler, ComponentProps, FC } from "react";

type Props = {
 value: string | number;
 onChange: ChangeEventHandler;
} &amp; Omit&lt;ComponentProps&lt;"input"&gt;, "value" | "onChange" &gt;;

export const TextFiled: FC&lt;Props&gt; = ({ value, onChange, ...props }) =&gt; {
 return &lt;input {...props} value={value} onChange={onChange} /&gt;;
};</code></pre> <h2 id="ha214098e44">まとめ</h2><ul><li>ComponentProps型は指定したコンポーネントの型を全て取得できる</li><li>普通のHTMLタグの振る舞いをしてほしい場合は、ComponentPropsで型定義した方がメンテコスト、ソース量が削減できる</li><li>コンポーネントに必須な型はOmit等でComponentPropsから除外し、明示的にPropsの型定義をしてバグを防ぐ</li></ul> 公式ドキュメントに載っていなかったので理解するのに時間がかかりました、、 間違っている部分、分かりにくい部分は<a href="https://twitter.com/react_nextjs" target="_blank" rel="noopener noreferrer">Twitter</a>でDMお願いします。

ReactのComponentProps型について解説してきます。一般的なコンポーネントの作り方から、ComponentProps型を使用したコンポーネントの作成を行い不要なPropsを取り除く事ができます。

JavaScript(TypeScript)の等価演算子(==)、厳密等価演算子(===)をプロジェクトで統一しよう！

ReactでDefault exportとNamed exportどちらを使用すれば良いのか??

ESLintのno-nested-ternaryを使用して三項演算子の可読性を担保しよう!!

Reactの状態管理ライブラリを比較してベストな選択をしよう！

ReactのComponentProps型を使って不要なPropsとお別れしよう！！