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

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

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

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