どうも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を取り除く事ができます。

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

どうもReactおじさんです。 最近フリーランスになって1年2ヶ月が経過していることに気づきました。 せっかくなので、1年間活動してきた記録をまとめていこうと思います。 フリーランスエンジニアのリアルな実態が気になる方はぜひ最後まで目を通してみてください。 <h2 id="h72712eb594">フリーランスになる前のスキル</h2>自分はエンジニア歴1年6ヶ月でフリーランスエンジニアになりました。 当時はSES企業に勤めていましたが、その際のスキルが下記になります。 <h3 id="hd851974331">言語・フレームワーク</h3>HTML CSS jQuery JavaScript TypeScript Java React Angular Express フロントエンドではReact、Angularをメインに画面の開発、バックエンドではJavaを使って簡単なAPIやバッチを作れるレベルでした。 1年が経過したあたりから基本1人称で開発を行なっていました。 何となくコードは書けているけど言語化して人に教えれるレベルではなかった気がします。。 <h3 id="h1fc02ea273">インフラ</h3>AWS(CloudFront S3 Lambda API Gateway Athena EventBridge Cognito EC2) 9ヶ月くらいAWSを触る案件に入っていたのでメジャーどころは一通り触って基礎は身につきました。 マネコンで環境構築をスムーズにできるようにはなっていました。 AthenaでSQLを書いてS3からログ解析を行なっていた日々がつい昨日のことのように感じます。 <h2 id="h9787623747">なぜフリーランスになろうと思ったか</h2>興味自体は元々ありましたが、大きな理由は二つあります。 <h3 id="h2d101311d3">自分の得意な分野を極めたかった</h3>SES時代、開発スキルが幅広く付いたのは良かったですが「あなたの一番得意な分野は何ですか？」と聞かれた時に自信を持って答えれる分野がありませんでした。 この時に浅く広くやってきたけど、1から自分が責任を持って担当できる分野がないことに気づき少し焦ったのを覚えています。 フリーランスについて調べていく中でコードを書くことに専念できるという意見や技術レベルが向上するという意見が多く、バックエンドよりフロントエンドの方が実装していて楽しく感じたこともあり、1年ほどフロントエンドのスキルを向上させようと決心しました。 <h3 id="h6192f36b50">フリーランスで受かった会社のレベルが高い現場だった</h3>会社員転職と並行してフリーランスの案件面談も受けていました。 その中でもオファーを頂いた現場が国内でトップ３に入るくらいフロントエンドが強い会社でした。 すぐクビになるんじゃないかと不安でしたが、レベルの高い人達と一緒に働いてみたい気持ちが強くなり、結果フリーランスとして頑張っていこうと決意しました。 <h2 id="h9dd9f14d8f">初現場で死にかけた話</h2>フリーランスとして活動する前日は中々寝付けなかったのを覚えています。 そして、そのまま寝付けない日々が2ヶ月程続きました。 理由は2つあります。 <h3 id="hab58dec071">強エンジニアにボコられる日々</h3>１つ目は、参画したフロントエンドチームのベテランエンジニアから技術マウントを取られボコられていたことです。(以降、この人をマウントエンジニアと呼ぶ) チーム内では明らかに技術レベルがずば抜けていたマウントエンジニアさんですが、レビュー時に「なんでこんなコード書いてんの？」とPRのコメントに記載したり、全体ミーティングでキレだしたり手に負えない存在でした。 もちろんマウントエンジニアさんは、自分以外にもそのような対応をしていて、当時のチームの雰囲気は今まで経験した現場の中でも1番最悪だったのを覚えています。 クソコードを書いたらまた何か言われるんじゃないかと考えたり、発言しても否定されてしまうんじゃないかと思ったりストレスの溜まる日々が続き、生産性がとても低くかったと思います。 2ヶ月後、マウントエンジニアさんは現場から居なくなり、そこからコード書く楽しさも戻ってきたり、発言も積極的にできるようになりました。 <h3 id="h8800790892">周りのレベルが高すぎる問題</h3>2つ目は、周りのレベルが高すぎてついていくのに必死だったことです。 そもそも実力不足だったこともあり、現場のソースは良いものの読み解くのに時間がかかりました。 レビューで何度も指摘されまくって稼働時間がめちゃくちゃ増え、寝不足でしんどかったです。 印象に残っているのは、React・TypeScriptを半年も触ってない人が、経験1年くらいある自分よりゴリゴリコードを書いているのを目の当たりにしたことです。 この時、自分のメンタルがぶっ壊され、少し涙が出ました笑。 <h2 id="h2a93b6bdb7">実際にどのくらい勉強していたのか</h2>エンジニアになって1年くらいはついていくのに必死だったので業務外で勉強はあまりしていませんでした。 ただ、わからないことは業務中に全て解決するように心がけていました。 本格的に業務外で勉強を始めたのは、フリーランスになる2ヶ月前からでした。 ReactとNext.jsを使って画面を作ったり、Node.jsを使ってAPIを作ったりしていました。 最近の実務経験1年くらいの人と比べて、自分は全然勉強していなかった方だと思います。 <h2 id="hecefc93c45">外のエンジニアとの繋がり</h2>会社員時代、社内のメンバーの交流は積極的に行なっていましたが、社外のメンバーとの交流は皆無でした。 フリーランスになってからは現場の人と雑談や飲み会に行く機会がほとんどなく、社外のエンジニアと情報交換をしてレベルアップしていかないといけないという焦りを感じました。 ある日、Twitterを眺めているとTypeScriptのオンライン勉強会の募集を見つけたので、勇気を持って参加してみました。 そこから社外の色んな属性のエンジニアと交流ができて、情報交換や切磋琢磨できる人が増えてモチベーションや技術力の向上に繋がっていきました。 貴重な機会を設けてくださった<a href="https://twitter.com/WEBERYOTA" target="_blank" rel="noopener noreferrer">Ryotaさん</a>には本当に感謝しています。 <h2 id="hde1a67be31">月単価は1年間でどこまで上がったのか</h2>最初の案件は経験が1年6ヶ月だったこともあり、相場よりは低かったと思います。 そこから案件が変わるタイミングで月単価が15万くらい上がり、また半年後に7万程上がりました。 今の案件では、しっかり結果を出してきたこともあり、契約更新のタイミングでスムーズに単価交渉ができたと思います。 結果、1年で月単価23万円UPすることができました。 <h2 id="h8c21f8f812">フリーランスになって良かったこと</h2>よかったことは色々ありますが、金銭面の心理的安全性が担保されたことが一番大きかったと思います。 社会人になるタイミングで上京しましたが、都心での一人暮らしは自分が思ったよりも貯蓄できず、頭の片隅には常にお金への不安がありました。 フリーランスになってからは、金銭の不安は無くなり、自分がやりたいことに自己投資ができるようになってQOLが格段に上がったと思います。 <h2 id="ha214098e44">まとめ</h2>結論、フリーランスになってよかったと思います。 序盤はボコられたりもしましたが、他の人には同じことをしたくないと思えたのでよかったです。 また、気持ちにも余裕ができてストレスなく生活できていると思います。 ただ、今後続けていくかは別なのでまた記事にしようと思います。 聞きたいことある方は<a href="https://twitter.com/react_nextjs" target="_blank" rel="noopener noreferrer">Twitter</a>のDMや<a href="https://forms.gle/Dvt3wWcXDzENR97CA" target="_blank" rel="noopener noreferrer">お問合せ</a>からご連絡ください。 最後まで読んでいただきありがとうございました。

フリーランスエンジニアとして1年が経過しました。実務経験1年6ヶ月でフリーランスに転身し実態を良い面、悪い面も含めてまとめた記事になります。今後フリーランスとして活動していきたい方、現フリーランスの方に少しでも参考になれば幸いです。

フリーランスエンジニアになって1年が経過したので実態をまとめてみた

初めまして！ Reactおじさんです。 7月から取り組んでいた技術ブログがようやくリリースできる形になったので、 最低限の機能だけ作ってリリースしました笑(バテたので最低限になってしまった…) <h2 id="h2ba0511ec3">なぜ技術ブログを作ろうと思ったのか</h2>理由はたくさんありますが、厳選して下記3点にまとめてみました！ <ul><li>アウトプットできる環境が欲しかった</li><li>転職やカジュアル面談時にアピールできるものが欲しかった</li><li>0から自分のサービスを作ってみたかった</li></ul> <h3 id="h7216114e93">アプトプットできる環境が欲しかった</h3>結論から言うと、アウトプットした方が知識の定着度が段違いだったことです。 今までは個人のGithubなどで、ソースを書くくらいしか行ってなかったのですが、 人に教えたりする際に、全然言語化できませんでした、、 言語化をして、分かりやすく人に伝えれて初めて理解したと言えるので、 このブログを機に言語化能力を高めようかと思います。 <h3 id="hc6025208ab">転職やカジュアル面談時にアピールできるものがほしかった</h3>ここ数ヶ月、カジュアル面談に励んでいましたが、 「個人開発でブログ作ってます！！」、「勉強会で講師やってます！！」 など話すと、面接官がとても喜んでくれました笑 さらに、ブログの内容次第では自分の技術力もアピールできるので、一石二鳥ですね！ <h3 id="hcee798f356">0から自分のサービスを作ってみたかった</h3>これは、エンジニアになった時から目標にしていた事なんですが、 自分でサイトを作って世に公開するという目標が地味にありました。 2年半程かかってしまいましたが、、笑 <h2 id="he235b92c3c">ブログの技術スタック</h2>今回は運用費用を0円にしたかったので、 下記のような構成にしました！ <ul><li>Next.js</li><li>CSS Module</li><li>microcms </li><li>Storybook</li><li>Netflify </li></ul> 使った事ない技術が半分くらいあったので、中々手こずりました。。 <h2 id="h3bfc3925d3">今後の方針について</h2>とりあえずブログの機能追加をしつつ、記事を量産してければなと思っています。 最初の方は、フロントエンド向けの記事を増やしつつ、バックエンド・インフラの記事も 公開していく予定です！ 年内に10記事は投稿できるようにしたい。。。

Reactおじさんがエンジニアとして学習した事をアウトプットしていくブログです。ブログを作った背景、今後の展望を記載します。

サイトマップ