どうも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おじさんです。 昨今の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を取り除く事ができます。

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

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

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