Another works Developers Blog

<p>Another works CTOの塩原です。<br>
フロントエンドの設計は複業クラウドでもいろんなことを試しました。<br>
今回は、現在の複業クラウドのフロントエンド設計を紹介できればと思います。</p>
<h1>技術スタック</h1>
<ul>
<li>Next.js</li>
<li>React</li>
<li>Typescript</li>
</ul>
<h1>フロントエンド設計の考え方</h1>
<h2>1. 無理な共通化・抽象化を行わない</h2>
<p>これは過去の経験からですが、一時期フロントエンドの設計に対して、DDDの考え方や、クリーンアーキテクチャの考え方を取り入れようとしたことがありました。<br>
バックエンドではDDDやクリーンアーキテクチャを導入しているのでフロントエンドでもその考え方を取り入れてみようという考えでした。<br>
複業クラウドのコアな概念をドメインモデルとして定義したのですが、フロントエンドの場合<br>
表示する画面によってデータ構造が影響を受けてしまい、<br>
例えば複業クラウドでも「求人」という概念が一覧画面で見た時と、詳細ページで見た時、閲覧履歴や検索結果から見る時で表示される情報が変わるので共通化や抽象化に苦戦しました。<br>
画面も頻繁に書き変わることが多かったので開発コストと見合わなくなりました。<br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/00c6d221-daed-45ff-bf0f-d90f87d3b232%2F%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%882022-11-2114.05.26.png" alt="スクリーンショット2022-11-2114.05.26.png"></p>
<h2>2. 変更における影響範囲が広くならないことを意識する</h2>
<p>また上記に関連することですが、共通化などをしすぎると画面変更に伴い共通化したもの自体にかなり大きな変更が入り、結果として特定の箇所の画面変更にも関わらず他の画面にも影響が出てしまうといったことも発生しました。</p>
<p>特に複業クラウドでは大幅に画面仕様が変わることも多く、そういったフェーズでは特に抽象化したものがそもそも0から書き直さなければならないといったことが発生しました。</p>
<h2>3. 仕組み化に頼りすぎずコミュニケーションを重要視する</h2>
<p>エンジニアには自動化や仕組み化といったことが得意かつ好きな人が多く、ついつい全てを仕組み化してしまいたくなりますが、プロダクトチームで人数がまだ10人に満たない中、常に変化も大きいため、仕組み化や自動化は取り入れながらもコミュニケーションを取ることも重要視するようにしています。</p>
<h1>推奨利用しているライブラリ</h1>
<ul>
<li>styled-component
<ul>
<li>reactでcssを書くためのライブラリ</li>
<li>jsx, tsxファイル内で書くことができる
<ul>
<li>css in js</li>
</ul>
</li>
<li>値に応じて動的にCSSを変更するようなコードを書ける</li>
<li><a href="https://styled-components.com/">https://styled-components.com/</a></li>
</ul>
</li>
<li>SWR
<ul>
<li>stale-while-revalidateをうまくやってくれる
<ul>
<li>キャッシュから値を返したあと、裏側で再フェッチし最新データに置き換える</li>
</ul>
</li>
<li>利用する側がフェッチ処理などを意識することなく、データのように利用することができる</li>
<li><a href="https://swr.vercel.app/">https://swr.vercel.app/</a></li>
</ul>
</li>
<li>react-hook-form
<ul>
<li>フォーム管理ライブラリ</li>
<li>バリデーションの機能も持っている
<ul>
<li>Yupを使わずに書くことができる</li>
</ul>
</li>
<li>以前はformikを使っていたが、内部でrefをうまく活用することで再レンダリングする箇所を最小限に抑えていたりなどパフォーマンス面に優れている</li>
<li><a href="https://react-hook-form.com/">https://react-hook-form.com/</a></li>
</ul>
</li>
</ul>
<h1>ディレクトリー構成</h1>
<h2>ディレクトリーの説明</h2>
<pre><code class="language-markdown">-- src
 |-- adapter
   |-- fcCoreApi
   |-- localstorage
 |-- assets
 |-- exception
 |-- hooks
 |-- features
   |-- projectSearch
   |-- mypage
 |-- lib
   |-- date
 |-- pages
 |-- styles
 |-- ui
   |-- homeland
   |-- origin
</code></pre>
<h2>adapter</h2>
<p>データ通信が発生する部分などの技術的な部分を扱うレイヤーを入れています</p>
<p>API通信についてという項目で詳細に説明しますが、useSWRを使うのはこの層になります</p>
<h2>features</h2>
<p>機能単位で分解しているモジュールです</p>
<p>こちらもfeatureディレクトリーについてという項目で詳細に説明します</p>
<h2>lib</h2>
<p>日付の共通処理や数字の変換処理など普遍的なクラスをこの中に入れています</p>
<p>utilではなくlibとした理由は、複業クラウド以外のプロジェクトで利用されても問題ないものが入るという意味を表すためにlibという名前を使いました</p>
<p>カスタムhook系の処理はhooksディレクトリーに入れるのでこの中には入りません</p>
<h2>hooks</h2>
<p>カスタムhooksの中でfeaturesを跨いで使うような共通処理を置くモジュールです</p>
<p>ファイル名は必ずuseXXXとなります</p>
<h1>Featureディレクトリーについて</h1>
<p>弊社ではfeatureというディレクトリーを使って単数もしくは複数のページをまとめています。</p>
<p>まとめた中に共通となるコンポーネントや、カスタムhooks、型定義や定数などを格納しています。</p>
<pre><code class="language-markdown">|-- features
 |-- projectSearch
   |-- ui
     |-- pages
     |-- origin
   |-- consts
     |-- projectConsts // 求人の型を入れておく
   |-- hooks
</code></pre>
<p>そうすることで、hooksやconstsなどの利用範囲が限定されているので</p>
<p>実際に表示で使う型に合わせて定義することができます。</p>
<p>featureディレクトリーというと、一ページ内での機能単位でディレクトリーを切る場合もありますが、機能単位に微妙に分解しづらいものなども存在するのとページ単位の場合、Next.jsでは <code>pages/</code> ディレクトリーをいじらなければ移行自体はやりやすいのでページ単位を採用しました。</p>
<h2>ESLint</h2>
<p>feature同士が依存するとせっかくディレクトリーを分けた意味がなくなるので、</p>
<p>その依存を防ぐためにeslintを使ってimportの依存関係を制御しています。<br>
https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/no-restricted-paths.md</p>
<pre><code class="language-json">module.exports = {
  extends: [
    'next',
    'next/core-web-vitals',
    'plugin:import/recommended',
    'plugin:import/typescript',
    'prettier',
  ],
  settings: {
    'import/resolver': {
      typescript: {},
    },
  },
  rules: {
    'import/no-restricted-paths': [
      'error',
      {
        zones: [
          {
            from: './src/features/!(accountDelete)/**/*', // 対象の依存パス
            target: './src/features/accountDelete', // 禁止するパス（正規表現可）
            message: 'features同士で依存することはできません', // エラーメッセージ
          },
        ],
      },
    ],
  },
};
</code></pre>
<h1>コンポーネント設計</h1>
<h2>landscape/homeland/origin</h2>
<p>複業クラウドでは三種類のコンポーネントを使いわけています。</p>
<p>以前はAtomicデザインを適用していたのですが、実際の運用を行う上で分けやすい分け方がいいと思いコンポーネントの種類を見直しました。</p>
<h3>landscape</h3>
<p>ボタンや、formなどの基本的なコンポーネント</p>
<p>複業クラウドでは企業側とタレント側などでフロントエンドリポジトリーが分かれているので</p>
<p>npmライブラリで実装して複数箇所で使えるようにしています。<br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/ae80688d-fdbb-4bb0-8d73-cbd958c1c370%2FUntitled.png" alt="Untitled.png"><br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/57b24c2a-3634-4037-8d9a-4bee936e00fe%2FUntitled(1).png" alt="Untitled(1).png"></p>
<h3>homeland</h3>
<p>このコンポーネントは上記のコンポーネントほど頻出ではないものの、</p>
<p>求人カードやタレントプロフィール画面などプロダクトのコアになりそうなデザインコンポーネントを定義しています。</p>
<p>そうすることで、変更が入った時にも一箇所を修正すれば変更が反映され、デザインする際にも一貫性が保たれます。</p>
<p>こちらはリポジトリーに直接定義するので、企業側・タレント側それぞれで定義されています。</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/76583943-7fa1-4df2-9d00-a8f8774a4ddf%2FUntitled(2).png" alt="Untitled(2).png"></p>
<table>
<thead>
<tr>
<th></th>
<th>landscape</th>
<th>homeland</th>
<th>origin</th>
</tr>
</thead>
<tbody>
<tr>
<td>デザイナーとのコミュニケーション</td>
<td>必要</td>
<td>必要</td>
<td>不要</td>
</tr>
<tr>
<td>ビジネスロジックを持てるかどうか</td>
<td>NG</td>
<td>OK</td>
<td>OK</td>
</tr>
<tr>
<td>実装方法</td>
<td>npmライブラリ</td>
<td>src/ui/homeland配下に実装</td>
<td>src/ui/originもしくは各features配下に定義</td>
</tr>
</tbody>
</table>
<h1>API通信について</h1>
<h2>SWRを使ったAPI通信</h2>
<p>弊社ではAPI通信にswrを利用しています。</p>
<p>swrにはいくつか利点がありますが、特に気に入っているポイントとして</p>
<ul>
<li>キャッシュを簡単に行なってくれる</li>
<li>useEffectとuseStateの乱立を防げる</li>
<li>楽観的更新・定期ポーリング・エラー時の再試行などを簡単に実装できる</li>
</ul>
<p>という点が挙げられます。</p>
<p>特にuseEffectとuseStateの乱立を防げるという点では下記のコードで比較をしてみます</p>
<p><strong>useSwrを使わない場合</strong></p>
<pre><code class="language-tsx">import useSWR from 'swr'

function Profile() {
  const [data, setData] = useState(undefined)
  useEffect(() =&gt; {
     const callback = async () =&gt; {
       const result = await fetcher()
       setData(result)
     }

     callback()
  }, [setData])

  if (!data) return &lt;div&gt;loading...&lt;/div&gt;
  return &lt;div&gt;hello {data.name}!&lt;/div&gt;
}
</code></pre>
<p><strong>useSwrを使う場合</strong></p>
<pre><code class="language-tsx">import useSWR from 'swr'

function Profile() {
  const { data } = useSWR('/api/user', fetcher)

  if (!data) return &lt;div&gt;loading...&lt;/div&gt;
  return &lt;div&gt;hello {data.name}!&lt;/div&gt;
}
</code></pre>
<p>とこのようにSWRを使わない場合、useEffectとuseStateを駆使しなければいけません。</p>
<p>APIが一つなのでまだシンプルですが複数必要になるとかなり複雑になってきます。</p>
<h2>SWRを使った設計</h2>
<p>上記のサンプルコードはSWRの公式ドキュメントを参考にしたものなので、</p>
<p>コンポーネント内に直接 <code>useSWR</code> を記載していますが、</p>
<p>このような書き方にはいくつか問題があると考えています。</p>
<ul>
<li>異なるデータのキャッシュの値が被ってしまう可能性がある
<ul>
<li>APIのパスにすれば被っても問題ない
<ul>
<li>postやgetのrequest情報もパスに含める想定なら
<ul>
<li>ただ理想としてはキャッシュ値は中央集権的に管理しておきたい</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
<li>第二引数のデータ構造をAPIのまま使うのではなく、加工したいときにコンポーネントに加工処理が漏れる</li>
<li>APIのレスポンスやリクエスト内容などはコンポーネントの関心ごとからは切り離したい
<ul>
<li>これはプロダクトの思想によっては異なる</li>
</ul>
</li>
</ul>
<p>そのため複業クラウドでは以下のような三層構造で設計をしています</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/8093264e-df13-4d23-a307-088e4c204ef6%2F%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%882022-12-0516.04.04(1).png" alt="スクリーンショット2022-12-0516.04.04(1).png"></p>
<p>Adapter層では、APIと直接通信し、APIのエンドポイントごとに通信するための関数を用意し、その中でSWRを実行しています。</p>
<p>feature内のhooksで、adapter層の関数を使って、見た目に必要な情報などを加工する処理などを記載します。</p>
<p>楽観的更新やポーリングなどもこのcustom hooksで実装するようにしています。</p>
<p>componentはAdapterを直接参照せずに、feature内のhooksから参照するようにすることで、componentがそこまでAPIの情報を意識することなく利用することができます。</p>
<p><code>adapter/useGetProfile.ts</code></p>
<pre><code class="language-tsx">export function useGetProfile(request: {id: string}) {
  const { data, error } = useSWR(['/api/user', request], fetcher)
  return data, error
}
</code></pre>
<p><code>feature/hooks/useProfile.ts</code></p>
<pre><code class="language-tsx">export function useProfile(params: {id: string}) {
  const {data, error} = useGetProfile(params)
  return {
    data: {
      ...data,
      fullname: data.lastName + data.firstName
    },
    loading: !error &amp;&amp; !data
  }
}
</code></pre>
<p><code>feature/ui/origin/profileBox.tsx</code></p>
<pre><code class="language-tsx">function ProfileBox() {
  const { data, loading } = useProfile()
  
  if (loading) return &lt;div&gt;loading...&lt;/div&gt;
  return &lt;div&gt;hello {data.fullname}!&lt;/div&gt;
}
</code></pre>
<h1>まとめ</h1>
<p>フロントエンドに限らず設計は日々最適解を見つけながら進化させていくべきだと考えています。<br>
なので今回の設計で満足せずに、会社の規模・チームの規模、技術の進歩に合わせて常に改善を続けていきたいと考えています。</p>


複業クラウドのフロントエンド設計を紹介します！

<p>オブジェクトの型を指定するインターフェースに関してですが、クラスに関しても使えるということで、特に抽象クラスの定義について色々と調べてみました。</p>
<h2>TypeScriptにおけるクラスとは</h2>
<p>実はTypeScriptでは、JSよりも前にクラスを備えていました。<br>
特徴として、TypeScriptのクラス構文では2つの異なる側面を併せ持ちます。</p>
<h3>インターフェースとしての型宣言となる</h3>
<p>型のコンテキストにおいてはインターフェースとして扱われます。</p>
<h3>コンストラクタ関数(通常のクラスとして)</h3>
<p>コンストラクタ関数とかくとややこしいですが<strong>要は普通のクラス構文</strong>として振る舞うということです。JavaScript, TypeScriptではクラスはシンタックスシュガーであり、その実態はプロトタイプオブジェクトを継承してオブジェクトインスタンスを生成するための独立した関数となっています。</p>
<h2>抽象クラスの定義</h2>
<p>クラスが宣言されたとき、インターフェースとしての側面と通常のクラスとしての側面を併せ持つと言いました。よって抽象クラスにも2つの定義の仕方が存在します。<br>
抽象クラスとはそれ自身がインスタンスを生成できず、継承されることを前提としたクラスです。</p>
<h3>abstract修飾子</h3>
<p>まずは通常のクラスの扱いとしての見慣れているやり方ですね。抽象クラスをabstract修飾子で定義し、それをextendsによって継承して実装するというものです。</p>
<pre><code class="language-typescript">abstract class Rectangle {
  sideA: number;
  sideB: number;

  constructor(sideA: number, sideB: number) {
    this.sideA = sideA;
    this.sideB = sideB;
  }

  getArea = (): number =&gt; this.sideA * this.sideB;
}

class Square extends Rectangle {
  side: number;
  constructor(side: number) {
    super(side, side);
  }
}
</code></pre>
<p>ポイント</p>
<ul>
<li>実装の詳細を抽象クラスでかけてしまう</li>
<li>継承先で再実装しなくてもエラーにならない</li>
</ul>
<h3>interface</h3>
<p>初めに、クラスを定義したときはそれは型のコンテキストではインターフェースの定義と同等となるという説明をしました。<br>
つまりクラスはinterfaceを継承することができます。<br>
implementsを使用します。</p>
<pre><code class="language-typescript">interface Shape {
  readonly name: string;
  sideA: number;
  sideB?: number;
  sideC?: number;
  sideD?: number;
  getArea: () =&gt; number;
}

class Rectangle implements Shape {
  readonly name = 'rectangle';

  sideA: number;

  sideB: number;

  constructor(sideA: number, sideB: number) {
    this.sideA = sideA;
    this.sideB = sideB;
  }

  getArea = (): number =&gt; this.sideA * this.sideB;
}

</code></pre>
<p>インターフェースはもともとオブジェクトの型定義に使用されるものですがJavaScriptのスーパーセットであるTypeScriptではJavaScript同様にクラスとオブジェクトの間に本質的な区別はないからです。<br>
クラスももとを辿ればオブジェクト。なのでインターフェースで型定義することができ、またそれを継承することができます。</p>
<p>ポイント</p>
<ul>
<li>型だけを定義し、実装漏れを確実に防ぐ</li>
<li>？によって柔軟性をもたせることができる</li>
<li>実装の詳細を継承元で書かなくて済む</li>
</ul>
<h2>抽象クラスの弱点と　interfaceの良さ</h2>
<p>abstract修飾子は、実は実装の詳細を含むことができてしまいます。本当は実装すべきメンバの型だけを定義したいのにも関わらずです。これが唯一のabstract修飾子による抽象クラス定義の弱点でしょうか。</p>
<p>DRYでコードを書くことはRubyでも口酸っぱく言われていますが、継承というのは親に強く依存してしまいバグの発見がしづらくなるという理由から「継承よりも合成を使う」という考え方のほうが主流になりつつあるようです。<br>
比較的新しい言語であるGoやRustでは実装を伴った継承がそもそも存在しません。</p>
<p>その点インターフェースでは実装を伴わない型のみの定義が可能であり、抽象クラスの定義として優れています。</p>
<h2>結論</h2>
<p>よほどのことがない限り、クラスの定義はinterfaceを使ったほうが良いのではないのでしょうか。<br>
その「よほどのこと」というのも現時点では私の中では出てきていないので、もしユースケースがあれば教えていただきたいです！</p>


TypeScriptのabstractとinterfaceを比べてみた

<p>こんにちは。フロントエンドエンジニアのhakemaruです。<br>
React開発におけるイミュータブルを意識した実装について書きます。</p>
<p>Reactではイミュータブルを意識して実装する必要があり、stateの更新前にオブジェクトのコピーを行うことが多々あるかと思います。<br>
しかし、深いネストを持つオブジェクトをイミュータブルを上記のコピーではネストを気にしないと行けないので面倒ですし、ミスが発生するかもしれません。<br>
そこで今回は、イミュータブルを意識した実装を容易にしてくれる「immer」についてご紹介したいと思います。</p>
<h2>イミュータブルについて</h2>
<p>イミュータブルとは「不変性」を意味します。つまり、値が変更されないことを指します。<br>
イミュータブルを意識することで意図しない値の変更を防ぐことができます。<br>
どこかで意図せず変更があるかもしれないと恐怖ですよね。</p>
<p>また、reactの公式ドキュメントでは以下のように記されています。</p>
<blockquote>
<p>ミュータブル (mutable) なオブジェクトは中身が直接書き換えられるため、変更があったかどうかの検出が困難です。ミュータブルなオブジェクト変更の検出のためには、以前のコピーと比較してオブジェクトツリーの全体を走査する必要があります。<br>
イミュータブルなオブジェクトでの変更の検出はとても簡単です。参照しているイミュータブルなオブジェクトが前と別のものであれば、変更があったということです。</p>
</blockquote>
<p>このように、Reactで実装していく上ではイミュータブルを意識することは重要になってきます。</p>
<h2>immerについて</h2>
<p>immerの公式ドキュメントには以下のように記されています。<br>
内容からもReactでの実装を意識して作成されていることがわかります。</p>
<blockquote>
<p>Immerは、不変の状態をより便利な方法で操作できる小さなパッケージです。Reactステート、ReactやReduxのリデューサー、構成管理などと組み合わせて使うことができます。イミュータブルなデータ構造は、（効率的な）変更検出を可能にします。オブジェクトへの参照が変更されていなければ、オブジェクト自体も変更されていないことになります。さらに、クローンを比較的安価に作成することができる。データツリーの変更されていない部分はコピーする必要がなく、同じ状態の古いバージョンとメモリ上で共有される。</p>
</blockquote>
<p>後ほど触れますが、最後の部分が特徴的ですね。</p>
<blockquote>
<p>クローンを比較的安価に作成することができる。データツリーの変更されていない部分はコピーする必要がなく、同じ状態の古いバージョンとメモリ上で共有される。</p>
</blockquote>
<p>実はReactの公式ドキュメントでも深くネストされたオブジェクトでイミュータブルを守る際の選択肢として推奨されています。</p>
<p><a href="https://reactjs.org/docs/optimizing-performance.html#the-power-of-not-mutating-data">The Power Of Not Mutating Data</a></p>
<h2>実際に使ってみる</h2>
<p>まずはスプレッド構文の例を見ていきます。<br>
深くネストされたオブジェクトをスプレッド構文でコピーし、値を変更します。</p>
<pre><code class="language-tsx">  const obj1 = {
    p1: &quot;p1&quot;,
    nest1: {
      p2: &quot;p2&quot;,
      nest2: {
        p3: &quot;p3&quot;
      }
    }
  }

  // この場合、shallowcopyになりコピー元が変更されてしまう
  const copyObj1 = { ...obj1 }
  copyObj1.nest1.nest2.p3 = &quot;spread test!&quot;

  console.log(obj1.nest1.nest2.p3)
  // spread test!
  // 元の値も変更されてしまう。
  console.log(copyObj1.nest1.nest2.p3)
  // spread test!

</code></pre>
<p>実際はスプレッド構文でもネストされている部分までコピーすればイミュータブルを実現することができますが、ネストが何重にもなるとかなり面倒です。</p>
<p>続いてimmerの例を見ていきます。<br>
immerではproduceという関数が提供されており、お手軽にイミュータブルを実現できます。<br>
produceは第1引数に変更したい値を受け取り、第2引数に状態を変更する関数を受け取ります。<br>
そして変更された値が返却されます。変更の際に値がコピーされているので、元の値に影響はありません。</p>
<pre><code class="language-tsx">  import produce from &quot;immer&quot;;

  const obj1: Obj = {
    p1: &quot;p1&quot;,
    nest1: {
      p2: &quot;p2&quot;,
      nest2: {
        p3: &quot;p3&quot;
      }
    }
  }

  const copyObj2 = produce(obj1, draft =&gt; {
    draft.nest1.nest2.p3 = &quot;immer test!&quot;
  })

  console.log(obj1.nest1.nest2.p3)
  // p3(元の値は変更されていない)
  console.log(copyObj2.nest1.nest2.p3)
  // immer test!
</code></pre>
<p>また、produceの第一引数に関数を渡すことで汎用的な関数を作成できます。<br>
いわゆるカリー化というものです。何度も変更がある場合に便利ですね！</p>
<pre><code class="language-tsx">  const changeP3 = produce((draft: Obj, value)=&gt; {
    draft.nest1.nest2.p3 = value
  })
  const copyObj2 = changeP3(obj1, &quot;immer test!&quot;)

</code></pre>
<h2>lodash cloneDeepとの比較</h2>
<p>今までネストが深いオブジェクトをコピーする際はcloneDeepで対応してしまっていたので、どのような違いがあるのか比較してみました。</p>
<h3>挙動の違い</h3>
<p>cloneDeepはすべてのオブジェクトツリーをコピーする一方で、冒頭で述べたようにimmerは変更される部分のみコピー（メモリを確保）してくれます。</p>
<p>先程のオブジェクトにnest3を加えて検証して行きます。</p>
<pre><code class="language-tsx">  import produce from &quot;immer&quot;;
  import {cloneDeep} from &quot;lodash&quot;

  const obj1: Obj = {
    p1: &quot;p1&quot;,
    nest1: {
      p2: &quot;p2&quot;,
      nest2: {
        p3: &quot;p3&quot;
      }, 
      nest3: {
        p4: &quot;p4&quot;
      }
    }
  }

  // immer 
  const changeP3 = produce((draft, value) =&gt; {
    draft.nest1.nest2.p3 = value
  })
  const copyObj2 = changeP3(obj1, &quot;immer test!&quot;)

  // cloneDeep
  const copyObj3 = cloneDeep(obj1)
  copyObj3.nest1.nest2.p3 = &quot;cloneDeep test!&quot;

  // 結果
  console.log(copyObj2.nest1.nest2.p3)
  // → immer test!
  console.log(copyObj3.nest1.nest2.p3)
  // → cloneDeep test!

  // メモリ空間が同じかどうか比較
  console.log(obj1.nest1.nest3 === copyObj2.nest1.nest3)
  // → true
  // immerは必要のないコピーを行わないので、p3とオブジェクトツリー上で関係のないnest3はコピーされない。
  console.log(obj1.nest1.nest3 === copyObj3.nest1.nest3)
  // → false
  // cloneDeepを使用すると、不要なコピーが生じてしまう。


</code></pre>
<h3>パフォーマンス</h3>
<p>簡易的にベンチマークを測定。<br>
要素数が少なければ大差はないが、10000件程度の配列になると倍くらい変わってくる。</p>
<pre><code class="language-tsx">    const obj1: Obj = {
      p1: &quot;p1&quot;,
      nest1: {
        p2: &quot;p2&quot;,
        nest2: {
          p3: &quot;p3&quot;
        }, 
        nest3: {
          p4: &quot;p4&quot;
        }
      }
    }
    const arr1: Obj[] = []
    for (let i = 0; i &lt; 10000; i++) {
      arr1.push(obj1)
    }

    // immer test
    const immerStartTime = performance.now(); 
    const changeP3 = produce((draft: Obj[], value: string) =&gt; {
      draft[0].nest1.nest2.p3 = value
    })
    const copyObj2 = changeP3(arr1, &quot;immer test!&quot;)
    const immerEndTime = performance.now(); 
    
    // cloneDeep test
    const cloneDeepStartTime = performance.now(); 
    const copyArr2= cloneDeep(arr1)
    copyArr2[0].nest1.nest2.p3 = &quot;cloneDeep test!&quot;
    const cloneDeepEndTime = performance.now(); 

    console.log(immerEndTime - immerStartTime); 
    // →　4.699999988079071（ms）
    console.log(cloneDeepEndTime - cloneDeepStartTime); 
    // →　9.5（ms）

</code></pre>
<h2>パッケージのサイズ比較</h2>
<table>
<thead>
<tr>
<th style="text-align:left"></th>
<th style="text-align:right">immer</th>
<th style="text-align:center">lodash</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align:left">bundle size</td>
<td style="text-align:right">5.6kb</td>
<td style="text-align:center">24.5kb</td>
</tr>
<tr>
<td style="text-align:left">download time</td>
<td style="text-align:right">6ms</td>
<td style="text-align:center">28ms</td>
</tr>
</tbody>
</table>
<h2>use-immer</h2>
<p>同時に提供されているuseImmerというライブラリを利用して、stateをを更新する際に簡単にイミュータブルを実現できます。<br>
produceでも実現できますが、より簡略化できます。</p>
<p>使い方としてはuseStateと非常に似ており、set関数で値をすると、内部でコピーを行ってくれます。</p>
<pre><code class="language-tsx">import { useImmer } from 'use-immer';

// ... 

const [obj, setObj] = useImmer&lt;Obj&gt;({
    p1: &quot;p1&quot;,
    nest1: {
      p2: &quot;p2&quot;,
      nest2: {
        p3: &quot;p3&quot;
      }, 
    }
  });

  const changeP3 = (value: string) =&gt; {
    // useStateを使用している場合はここにコピーの処理を書く必要がある。
    setObj((draft) =&gt; {
      draft.nest1.nest2.p3 = value
    })
  }
</code></pre>
<p>useReducer用のuseImmerReducerも提供されています。</p>
<h2>reduxでの活用</h2>
<p>produceの第一引数に渡し、switch文で変更したいstateを変更するだけです。<br>
reduxあるあるの多量のスプレッド構文が消え、スタイリッシュに書くことができます。</p>
<pre><code class="language-ts">import produce from &quot;immer&quot;

const initialState = {
  todos: []
}

const todosReducer = produce((draft = initialState, action) =&gt; {
    switch (action.type) {
        case &quot;toggle&quot;:
            const todo = draft.todos.find(todo =&gt; todo.id === action.payload)
            todo.done = !todo.done
            break
        case &quot;add&quot;:
            draft.todos.push({
                id: action.payload,
                title: &quot;new todo&quot;,
                done: false
            })
            break
        default:
            break
    }
})

</code></pre>
<h2>おまけ</h2>
<p>reduxについては正規化が推奨されており、なるべくネストは避けるべきとのこと。(優先度B)<br>
ネストの多いオブジェクトのイミュータブルを意識することも大切だが、ネストを減らした実装を意識することも必要かも。</p>
<p>https://redux.js.org/style-guide/style-guide#normalize-complex-nestedrelational-state</p>
<blockquote>
<p>多くのアプリケーションは、複雑なデータをストアにキャッシュする必要があります。そのデータはしばしばAPIからネストされた形で受け取られたり、データ内の異なるエンティティ間の関係を持っています（例えば、ユーザー、投稿、コメントを含むブログなど）。<br>
そのようなデータは、ストアに「正規化」された形で保存することをお勧めします。これにより、IDに基づいたアイテムの検索や、ストア内の単一のアイテムの更新が容易になり、最終的にはパフォーマンス・パターンの改善につながります。</p>
</blockquote>
<h2>最後に</h2>
<p>immerを使用することで、イミュータブルな実装が容易になりました。<br>
イミュータブルを実現するためのライブラリとして、「immutable.js」、「Ramda」、「immutability-helper」などが存在します。<br>
今回は、React公式が推奨している「immer」をピックアップさせていただきましたが、機会があればそれらのライブラリについても調査してみたいと思います。</p>
<h2>参考</h2>
<p><a href="https://reactjs.org/docs/optimizing-performance.html#the-power-of-not-mutating-data">The Power Of Not Mutating Data</a><br>
<a href="https://immerjs.github.io/immer/">Immer</a><br>
<a href="https://zenn.dev/luvmini511/articles/85e8e3c71a2f41">イミュータブルが大事な理由、そしてImmerで簡単実現！</a></p>


React開発におけるイミュータブルを意識した実装

<p>こんにちは、zonです。<br>
大規模リリースが増えてきた昨今の弊社、メンテナンス画面が欲しくなり色々と調べました。</p>
<p>使用頻度は高くないですが、定期的に大規模なリリースをしたりするときにはあるべきだと思います。<br>
またトラブル発生時も対応中であることが伝えられるのでユーザーの不安もある程度解消できますね。</p>
<p>簡単そうに見えて意外といろいろな選択肢があることや、厄介な制約があることにも気がつけたので、調べたことをつらつらと書いていきます。</p>
<p>※弊社はReact, Next.jsベースのWebアプリなのでその場合のパターンが主になります。</p>
<h2>フロントベース（ReactまたはNext.js前提）</h2>
<h3>React + CloudFront + S3 + WAF</h3>
<p>クラウドフロントにWAFをアタッチする方法です。<br>
WAFからのカスタムエラーレスポンスによってCloudFrontが別のS3バケットからメンテナンスページを取得して返します。</p>
<p><img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/386799/d7c48002-8293-9373-e3be-8d68866063f5.png" alt="スクリーンショット 2022-02-02 11.47.53.png"></p>
<ul>
<li>WAFのアタッチのみで適用でき運用が楽</li>
<li>フロントエンドの工数がかからない</li>
<li>サーバーサイドの工数がかからない</li>
</ul>
<h3>Next.js + Vercel</h3>
<p>Next.jsをVercelに乗せた場合です。Vercelはメンテナンスモードをサポートしていないのでそれっぽく自分で実装するしかありません。</p>
<ol>
<li>メンテナンスページをソース内に作成します。</li>
<li>環境変数にNEXT_MAINT_MODEなどの変数をセットし、booleanなどセットしておきます。</li>
<li>その値によって分岐処理を書き、メンテナンスページに遷移させる処理を書きます。</li>
<li>メンテナンスモードにするときは、Vercel上で環境変数の値を書き換えて再デプロイします。</li>
</ol>
<p>運用の手間がそこそこかかるのと、開発者がメンテナンス中に本番環境の画面を確認することができないのがネックですね。</p>
<h2>APIベース(ALBを使用している前提)</h2>
<h3>ALB + ECS(orEC2)</h3>
<p>ALBのリスナルールと固定レスポンス機能を使って503を返す方法です。<br>
メンテナンスモードにする際はリスナルールの優先順位を入れ替えるだけです。</p>
<p><img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/386799/7a96ab23-5e12-2296-d5b3-31a3ef778c77.png" alt="スクリーンショット 2022-02-02 11.47.48.png"></p>
<ul>
<li>ドメインごとにルールを決められる</li>
<li>切り替えがやや手間</li>
</ul>
<h3>ALB + WAF + ECS(orEC2)</h3>
<p>ALBにWAFをアタッチするパターンで、503を返すのはWAFのお仕事になります。</p>
<p><img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/386799/85118c9c-b5eb-0e3b-6580-61eb3b3c0e8e.png" alt="スクリーンショット 2022-02-02 11.47.37.png"></p>
<ul>
<li>ドメインごとにルールを決められる</li>
<li>特定のIPを許可できる</li>
<li>WAFのアタッチのみで適用でき運用が楽</li>
<li>複数プラットフォーム共用のAPIである場合はWAFのみの設定で済むため管理が楽</li>
</ul>
<h2>感想</h2>
<p>全サービスが共通のAPIサーバ使っている場合にはALBの固定レスポンスかWAFアタッチが楽だと思っています。<br>
リクエスト元のホストを絞ればサービスを限定することができるし、IPホワイトリストを設定すれば開発者はメンテ中も画面を覗くことができるし、ということでおそらく実装するとしたらAPIサービス側でやることになりそうです。</p>
<p>それぞれ長所短所ありますが非常に勉強になりました。</p>
<h2>参考</h2>
<p><a href="https://dev.classmethod.jp/articles/alb-fixed-response/">[新機能]EC2やS3不要！ALBだけでメンテナンス画面を表示するなど固定レスポンスが返せるようになりました！<br>
</a><br>
<a href="https://tech-blog.yayoi-kk.co.jp/entry/2019/07/04/110000">Misoca メンテナンス画面の裏側</a></p>


AWSを使ったメンテナンス画面の設計について

<h1>はじめに</h1>
<p><code>TypeScript</code>での<code>null</code>と<code>undefined</code>の使い分け方に対する考えと、<code>null</code>と<code>undefined</code>の違いについて、自分なりに調べて学んだことを書いていきます。</p>
<h1>どっちを使うべき？</h1>
<p><strong><code>undefined</code>を積極的に利用していくべき</strong><br>
（<code>null</code>の利用を避けられない場合を除いて）</p>
<p>ではないか、という結論になりました。</p>
<p><code>TypeScript</code>開発チームのGithub wiki にあるコーディングガイドにも</p>
<blockquote>
<p>Use undefined. Do not use null.</p>
</blockquote>
<p>「<code>null</code>は使用せず、<code>undefined</code>を使用してください。」<br>
と記載されています。<br>
（あくまで<code>TypeScript</code>の開発チーム内での決め事ではありますが、）</p>
<p>https://github.com/Microsoft/TypeScript/wiki/Coding-guidelines#null-and-undefined</p>
<h1>null と undefined の違い</h1>
<p><code>null</code>も<code>undefined</code>もプリミティブ型の値の一つ。<br>
どちらも「値が存在しない」ことを表現するものであるものの、<code>null</code>と<code>undefined</code>には明確な違いがある。</p>
<h2>意味合いでの違い</h2>
<p><strong>null</strong>: 代入すべき値が存在しないため、値がない（変数がメモリに対する参照を保持しない）<br>
<strong>undefined</strong>: 値が代入されていないため、値がない（変数が未定義である、初期化されていない）</p>
<h2>言語使用上での違い</h2>
<h2>nullは自動的に設定されないが、undefinedは自動的に設定される</h2>
<p><strong>null</strong>: 開発者が意図的に設定しない限り設定されない。<br>
<strong>undefined</strong>: 開発者が意図しなくても、自動的に設定される。</p>
<pre><code class="language-js">// 変数を宣言したときに初期値が存在しなければ、その変数にundefinedが設定される。
let value;
console.log(value); //=&gt; undefined
</code></pre>
<pre><code class="language-js">// オブジェクトに存在しないプロパティや配列にない要素にアクセスしたときも、自動的にundefinedになる。
const obj = {};
console.log(obj.foo); //=&gt; undefined
const arr = [];
console.log(arr[0]); //=&gt; undefined
</code></pre>
<pre><code class="language-js">// 戻り値がない関数の戻り値を取得したときもundefinedになる。
function func() {}
console.log(func()); //=&gt; undefined
</code></pre>
<h2>nullはリテラル、undefinedは変数</h2>
<p><strong>null</strong>: <a href="https://wa3.i-3-i.info/word15346.html">リテラル</a>なのでnullという名前の変数を作ることはできない。<br>
<strong>undefined</strong>: 変数なので<code>undefined</code>という変数を作ることができる。（グローバルより内側のスコープに限る）</p>
<p>※ ちなみに<code>window</code>オブジェクト（グローバルオブジェクト）は<code>undefined</code>というプロパティを持っている。この初期値は<code>undefined</code>。</p>
<table>
<thead>
<tr>
<th>コンソール（Google Chromeディベロッパーツール）</th>
</tr>
</thead>
<tbody>
<tr>
<td><img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/621162/7c7bab83-0ee4-18e6-7b19-2c2f3ae481a2.png" width="300" /></td>
</tr>
</tbody>
</table>
<h2>typeof の挙動</h2>
<pre><code class="language-js">typeof null          // &quot;object&quot; (歴史的な理由で &quot;null&quot; ではないらしい)
typeof undefined     // &quot;undefined&quot;
</code></pre>
<h2>isNaN の挙動</h2>
<pre><code class="language-js">isNaN(1 + null)      // false
isNaN(1 + undefined) // true
</code></pre>
<h2>JSON での挙動</h2>
<p><strong>null</strong>: 設定できる。<br>
<strong>undefined</strong>: 設定できない。</p>
<pre><code class="language-js">console.log(JSON.stringify({ foo: undefined })); //=&gt; {}
console.log(JSON.stringify({ foo: null })); //=&gt; {&quot;foo&quot;: null}
</code></pre>
<h1>おまけ</h1>
<h2>== と === で比較</h2>
<pre><code class="language-js">null === undefined   // false
null  == undefined   // true
</code></pre>
<h1>まとめ</h1>
<p>冒頭でも述べた通り、<code>TypeScript</code>での開発では<br>
<code>null</code>の利用を避けられない場合を除いて、<code>undefined</code>を積極的に利用していくべき、かなと考えました。</p>
<p>理由としては、<br>
「値が存在しない」ことを表現する方法を、「自動的に発生してしまう<code>undefined</code>」に寄せた方が統一しやすいから、と思いました。（日本語難しい...）</p>
<p>ただ一方で、<code>null</code>を返すAPIなどのハンドリングをする場合などは<code>null</code>の利用を避けられなかったりするので、完全に<code>null</code>を利用しないことは難しいのかもしれない。</p>
<p>いろいろと調べてきたものの、</p>
<blockquote>
<p>使い分け意識を育てる労力は、それに見合うメリットが少ない</p>
</blockquote>
<p>との意見もありました。</p>
<h2>参考</h2>
<p>ありがとうございました！</p>
<ul>
<li>https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/null</li>
<li>https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/undefined</li>
<li>https://typescriptbook.jp/reference/values-types-variables/undefined-vs-null</li>
<li>https://typescript-jp.gitbook.io/deep-dive/recap/null-undefined</li>
<li>https://github.com/Microsoft/TypeScript/wiki/Coding-guidelines#null-and-undefined</li>
<li>https://www.amazon.co.jp/%E7%8B%AC%E7%BF%92JavaScript-%E6%96%B0%E7%89%88-CodeMafia-%E5%A4%96%E6%9D%91-%E5%B0%86%E5%A4%A7/dp/479816027X/ref=sr_1_1?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&amp;keywords=%E7%8B%AC%E7%BF%92JavaScript&amp;qid=1639187025&amp;s=books&amp;sr=1-1</li>
</ul>


【JavaScript / TypeScript】null と undefined の違いと比較

<p>こんにちは。みやぞんです。</p>
<p>前回の記事ではLPの記事投稿部分のヘッドレスCMS化に伴い、Next側ではどのようにレンダリングするのが正解なのだろうと色々考え、結果的にはSGを選択したと説明しました。しかし後になってISRに関する理解が誤っていたことに気が付き二転三転としたところでISRの採用に落ち着きました。</p>
<p><a href="https://tech.anotherworks.co.jp/article/nextjs-sg-isr">https://tech.anotherworks.co.jp/article/nextjs-sg-isr</a></p>
<p>今回は、そのときに少し深掘して学んだISRの挙動についての記事になります。</p>
<h2>CDNとは</h2>
<p>まずはWebの基本知識であるCDNについてです。ISRを理解する上でキャッシュやCDNの理解は必須です。CDNとはContents　Delivery Networkのことで<strong>複数のキャッシュサーバ(エッジサーバとも呼ばれる)で構成されたネットワーク</strong>のことです。オリジンサーバとクライアントの間に位置するネットワークで、以下の利点があります。</p>
<ul>
<li>負荷分散（オリジンサーバにアクセスが集中しない）</li>
<li>キャッシュによるコンテンツ配信の高速化</li>
<li>可用性向上</li>
</ul>
<p><img src="https://storage.googleapis.com/zenn-user-upload/6390d596cf0d-20220123.png" alt=""><br>
画像：<a href="https://www.kagoya.jp/howto/it-glossary/web/cdn/">カゴヤのサーバ研究室</a></p>
<p>CDNではアクセスするクライアント間でキャッシュが共有されます。</p>
<p>もう少し詳しい説明はこちら。<br>
<a href="https://gihyo.jp/book/pickup/2021/0012">https://gihyo.jp/book/pickup/2021/0012</a></p>
<h2>Vercel　エッジネットワーク</h2>
<p><strong>Vercel製のCDN</strong>のようなものです。エッジネットワークは世界中の数十の場所で稼働しています。</p>
<p><img src="https://storage.googleapis.com/zenn-user-upload/728d7190bdf0-20220123.png" alt=""></p>
<p><a href="https://vercel.com/docs/concepts/edge-network/overview">https://vercel.com/docs/concepts/edge-network/overview</a></p>
<p>AWSもエッジロケーションっていうのが至るところにありますよね。</p>
<h2>Vercelのキャッシュについて</h2>
<p>静的ファイルは最初のリクエストの後、自動的にキャッシュされます。(最大31日間)<br>
また、再デプロイ時にはキャッシュは事実上無効となります。</p>
<p>静的ファイルはハッシュによってキャッシュされるため、ファイルが変更されない場合はデプロイをまたいで持続することができます。</p>
<p><a href="https://vercel.com/docs/concepts/edge-network/caching">https://vercel.com/docs/concepts/edge-network/caching</a></p>
<h3>stale-while-revalidate</h3>
<p>Vercelのキャッシュの特徴は<strong>stale-while-revalidate</strong>というCache-Controlヘッダーの拡張機能をサポートしている点です。</p>
<p>簡単に説明すると、キャッシュが再生成される時間を決めて、キャッシュ生成されてから指定の時間が生成するとリクエストをトリガーにして新しいキャッシュがバックグラウンドで生成されるというものです。<br>
つまり動的コンテンツであっても静的ページを定期的に更新することでキャッシュできるようになります。</p>
<p>詳しい挙動はISRと一緒に追っていくとわかりやすいと思います。</p>
<h2>ISRの挙動について</h2>
<p>ここまできたらISRは実際にどのように動いているのかを追ってみましょう。</p>
<p>Vercel公式の画像を借りて説明します。<br>
<img src="https://storage.googleapis.com/zenn-user-upload/94090434b8d6-20220123.png" alt=""></p>
<ol>
<li>コンテンツのキャッシュが未生成の場合はオリジンサーバにリクエストを送りSSRでページを生成する。またこのときキャッシュサーバー(CDN)にキャッシュを作る。</li>
<li>次のリクエストからキャッシュサーバがキャッシュを返す。</li>
<li>キャッシュが生成されてからrevalidationで設定した秒数が経過するまでは同じキャッシュを返し続ける。</li>
<li>指定した秒数が経過してから初めてのリクエスト時に、それがトリガーとなってキャッシュ(ver.2)を再生成する。このアクセスではまだ古いキャッシュ(ver.1)が返される。(つまり単に指定した秒数が経過しただけでは勝手にキャッシュを再生成することはない)</li>
<li>新しくキャッシュが生成されてからその次のリクエストからは新しいキャッシュが返される。</li>
</ol>
<p>これが「stale-while-revalidate」というキャッシュ戦略を利用したISRの動作です。</p>
<p>ちなみに、developer toolでCache-Controlを確認するとISRのどのフェーズにいるのかがわかります。</p>
<p><code>MISS</code>: キャッシュが生成されていないのでSSRによってページを生成した<br>
<code>HIT</code>: ISRによって生成された新しいキャッシュを利用中<br>
<code>STALE</code>: キャッシュのrevalidate秒数を超えているので古いキャッシュを返しつつ、裏で新しいキャシュを生成します。次のアクセスから新しいキャッシュを返します(HIT)</p>
<p>https://vercel.com/docs/concepts/next.js/incremental-static-regeneration</p>
<p>CDNは共有キャッシュなのでこのサイクルはクライアント一人ひとりで生じるわけではなく、サイクルごと共有されている。つまりAさんが「キャッシュが作られていない状態のアプリケーション」にアクセスしたとき、それがトリガーとなってSSRが実行され同時にキャッシュも生成されます。その後すぐにBさんがアクセスしたらBさんが受け取るのはすでに生成されているキャッシュとなるのです。</p>
<p>なので最初にアクセスしたAさんは二回目のアクセスからからキャッシュが提供がされ、それ以外のクライアントは初回からキャッシュが提供されます。</p>
<p>ここまでISRのことを学んでみると、前の記事でも書いたとおり、強整合性が求められるようなページでない限りは動的ページはISR一択なのでは改めて感じます。(SEOやOGPの関係ないところではCSRもありだとは思います。)</p>
<h2>最後に</h2>
<p>公式ドキュメントに必ず正しい仕様は書いてあるので、面倒臭がらずに穴が空くほど目を通さないとなと感じました。エンジニアになりたての頃は心がけていたはずでしたが...。精進します！</p>


stale-while-revalidateから紐解くNext.jsのISR

<p>こんにちは。zonです</p>
<p>以下の記事で以前既存のプロダクトLPをヘッドレス化する計画について書きました。<br>
<a href="https://zenn.dev/hk_206/articles/8ff4c0567ed247">stale-while-revalidateから紐解くNext.jsのISR</a><br>
今回はそのヘッドレスCMS化したLPの公開にあたり、Next.js側の設定でどのレンダリング方法を選択するのが最適なのかについての記事になります。</p>
<h1>レンダリング方法の選定</h1>
<p>レンダリング方法はCSR/SSR/SG/ISRの4種類がありますが、LPという特性上SEOと表示速度に焦点を当てて選定をしました。<br>
<a href="https://nextjs.org/docs/basic-features/data-fetching">Data Fetching Overview</a></p>
<h2>CSR</h2>
<p>通常のSPAです。クライアント側でデータフェッチおよびレンダリングを行います。<br>
<img src="https://storage.googleapis.com/zenn-user-upload/dbc132b230e3-20220122.png" alt=""></p>
<h4>メリット</h4>
<ul>
<li>リアルタイムにデータが反映がされる</li>
</ul>
<h4>デメリット</h4>
<ul>
<li>SEOに弱い(クローラによる)</li>
<li>データが反映されていないページが最初に一瞬表示される</li>
</ul>
<h4>結果</h4>
<p>特に理由がない限りCSRで基本はいいのかなと思っているのですが、SEOの点で引っかかるので今回は無しとしました。</p>
<h2>SSR</h2>
<p>サーバーサイドでデータフェッチおよびレンダリングを行う方法です。<br>
<img src="https://storage.googleapis.com/zenn-user-upload/a1bf99bdd1e4-20220122.png" alt=""></p>
<h4>メリット</h4>
<ul>
<li>クライアント側のスペックに左右されず、高速でレンダリングできる</li>
<li>リアルタイムにデータが反映がされる</li>
<li>SEOに強い</li>
</ul>
<h4>デメリット</h4>
<ul>
<li>遷移にラグを感じる(サーバーサイドでレンダリングが完了するのを待つため)</li>
</ul>
<h4>実装方法</h4>
<p>getServerSidePropsを使って実装します。</p>
<pre><code class="language-typescript">export async function getServerSideProps(context) {
　　　　// サーバーサイドで実施するデータフェッチなどの処理を書きます
  return {
    props: {}, // ページコンポーネントにpropsとして渡されます
  }
}
</code></pre>
<h4>結果</h4>
<p>SEOに強いのは嬉しいのですが、遷移のラグが気になります...。選択肢の1つとしてはありです。</p>
<h2>SG</h2>
<p>ビルド時にあらかじめ静的ページを生成し、リクエスト時はそのページを返すだけという方法。<br>
<img src="https://storage.googleapis.com/zenn-user-upload/b000c5c0be20-20220122.png" alt=""></p>
<h4>メリット</h4>
<ul>
<li>表示速度が速い</li>
</ul>
<h4>デメリット</h4>
<ul>
<li>データの更新が即時反映されない</li>
</ul>
<h4>実装方法</h4>
<p>getStaticPropsを使って実装します。</p>
<pre><code class="language-typescript">export async function getStaticProps(context) {
  return {
    props: {}, // ページコンポーネントにpropsとして渡されます
  }
}
</code></pre>
<p>Dynamic Routingの場合は別途<code>getStaticPaths</code>を設定する必要があります。これによりどのページをビルド時に生成するか決めることができます。</p>
<pre><code class="language-typescript">// この関数はサーバーサイドのビルド時に呼び出されます
// ここで指定していないパスに対してリクエストがあった場合はSSRもしくはCSRによりページが生成されます
export async function getStaticPaths() {
  const res = await fetch('https://.../posts')
  const posts = await res.json()
  const paths = posts.map((post) =&gt; ({
    params: { id: post.id },
  }))

  // ここに指定したパスのみビルド時にプリレンダリングします
  // { fallback: blocking } と記述すると、指定していないパスに対してリクエストがあった場合SSRが実行されキャッシュが生成されます
  return { paths, fallback: 'blocking' }
}
</code></pre>
<h4>結果</h4>
<p>表示速度が早くSEOも強いのでできればこれが良い...！<br>
ただデータの更新が(ビルドしないと)反映されないというのがネックだなと。完全静的ページしか使えない気がします。<br>
定期実行でビルドさせたり、Webhookで記事更新タイミングでビルドが走るのならありですね。</p>
<p><strong>おまけ</strong><br>
SSGって一昔前の呼び方らしいです。おじさんみ👨‍🦳を出さないためにも僕はSGって読んでます。頑張ってます。</p>
<h2>ISR</h2>
<p>SGの機能に加えて定期的にデータを更新して裏で新たなページを生成します。SGの欠点を補うレンダリング方法になります。<br>
<img src="https://storage.googleapis.com/zenn-user-upload/55359ce0155b-20220122.png" alt=""></p>
<h4>メリット</h4>
<ul>
<li>キャッシュにより2回目以降の表示速度が爆速</li>
</ul>
<h4>デメリット</h4>
<ul>
<li>初回アクセス(つまりキャッシュがない場合)はSSR(またはCSR)になる</li>
<li>定期的なデータ更新により新しいキャッシュ生成後の1回目のリクエストでは古いキャッシュが返される</li>
</ul>
<h4>実装方法</h4>
<p>returnする値に、　<code>revalidate</code>を追加するだけです。キャッシュの再生成をする秒数になります。<br>
getStaticPathsでpathsを指定してしまうと、そのページは初回アクセス時にビルド時の情報が表示され続けてしまうことになるので、ISR時はここを<code>[]</code>にしておく必要がありそうです。</p>
<pre><code class="language-typescript">export async function getStaticProps() {
  const res = await fetch('https://.../posts')
  const posts = await res.json()

  return {
    props: {
      posts,
    },
    // 10秒ごとにキャッシュを更新
    revalidate: 10, // 秒数を指定
  }
}

export async function getStaticPaths() {
  return {
    paths: [],
    fallback: 'blocking',
  };
};
</code></pre>
<h4>結果</h4>
<p>実装の手間もかからず、すごく便利な機能を備えています。<br>
ただ、初回アクセス時のSSR特有の遷移ラグは気になりました。</p>
<p>Zennでも一部のページでISRを採用しているとのこと。<br>
ユーザーが投稿するシステムなので、投稿頻度もかなり多いと思いますしそういった特性のものはISRのほうが良さそう。<br>
<a href="https://zenn.dev/catnose99/articles/8bed46fb271e44">Next.jsのISRで動的コンテンツをキャッシュするときの戦略</a></p>
<h1>結果ISRを選択しました</h1>
<h2>ISRの初回アクセス時のオーバーヘッドは特段気にしなくて良い</h2>
<p>ISRのデメリットとして「初回アクセス時(キャッシュがない場合)のSSRのオーバーヘッドがある」と述べましたが、キャッシュはVercelのCDNに存在するためその現象が生じるのはビルド後に初めてアクセスしたユーザー1人のみです。</p>
<p>なので、ビルド後に初めてアクセスしたユーザーがAさんだとすると、Aさんの初回アクセスはSSRが走るため多少のオーバーヘッドを感じます。しかしその後アクセスするBさん、CさんはVercelが提供するCDNにキャッシュがある状況でのアクセスになるため、そのままキャッシュを使用できます。</p>
<p>記事を更新するたびにビルドが走るのはできるだけ避けたいと考えていたので、少々revalidateの時間を待つことにはなりますがシビアなデータを取り扱っているわけでもないためISRを選択するに至りました。</p>
<p><a href="https://gihyo.jp/book/pickup/2021/0012">Web配信の技術 ～キャッシュとは</a><br>
<a href="https://vercel.com/docs/concepts/edge-network/caching">Caching | Vercel</a><br>
<a href="https://vercel.com/docs/concepts/next.js/incremental-static-regeneration">Incremental Static Regeneration | Vercel</a></p>
<h1>その他の参考記事</h1>
<p><a href="https://qiita.com/thesugar/items/47ec3d243d00ddd0b4ed">Next.jsにおけるSSG（静的サイト生成）とISRについて（自分の）限界まで丁寧に説明する</a><br>
<a href="https://zenn.dev/bitarts/articles/37260ddb28ae5d">図解 CSR, SSR, SG(SSG), ISR</a></p>


Next.jsのSGとISRの話

<p>こんにちは。hakemaruです。<br>
複業クラウドのアプリはReact Nativeで開発しています。<br>
Androidアプリのパフォーマンスが悪いことが課題の一つとして上がっており、HermesというJavaScriptエンジンを導入することで改善を行いました。</p>
<h2>Hermesとは</h2>
<p>Meta(旧Facebook)が開発しているReactNative用に最適化されたオープンソースのJavaScriptエンジン。<br>
Hermesを有効にすると、起動時間が改善され、メモリ使用量が減少し、アプリのサイズが小さくなります。</p>
<p>ref：<a href="https://reactnative.dev/docs/hermes">Using Hermes</a></p>
<h2>仕組み</h2>
<h3>バイトコードの事前コンパイル</h3>
<p>通常のJavaScriptエンジンは、JavaScriptソースがロードされた後に解析し、バイトコードを生成しますが、HermesはJavaScriptを事前コンパイルによりバイトコードを生成しています。<br>
また、実行時にJavaScriptをパースしてバイトコードを生成するというステップが省略できることによる起動時間の短縮を実現しています。</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/b5c46642-9564-4d3b-b01b-da18e56f567b%2F923085c800bf-20220906.gif" alt=""><br>
ref：<a href="https://engineering.fb.com/2019/07/12/android/hermes/">Hermes: An open source JavaScript engine optimized for mobile apps, starting with React Native</a></p>
<h2>Hermesについて</h2>
<p>Android：ReactNative 0.60.4以上<br>
iOS：React Native 0.64以上</p>
<p>expoを利用している場合<br>
Android：SDK42以上<br>
iOS：SDK43以上（SDK43では実験的サポートになっているので注意）</p>
<p>また、expo buildではなくeas buildを使用する必要があります。<br>
（eas buildを利用することでnative層の変更も可能になるため）<br>
expo buildの利用は2023年までと発表があったので、どこかのタイミングで切り替えていく必要があります。<br>
ref：<a href="https://blog.expo.dev/turtle-goes-out-to-sea-d334db2a6b60">expo build’s Final Year</a></p>
<h2>導入</h2>
<p>基本的にドキュメントに沿って実装すれば大丈夫でした。<br>
実際に導入で詰まる点はありませんでした。</p>
<p>また、リロードを高速に保つために、デバッグビルドは事前コンパイルを使用していません。<br>
なので導入したからと言って開発体験が悪くなるといった問題も今の所はないです。</p>
<p>ref：<br>
<a href="https://reactnative.dev/docs/hermes">素のReactNative</a><br>
<a href="https://docs.expo.dev/guides/using-hermes/">expo</a></p>
<h2>導入結果</h2>
<p><strong>初期起動時間の減少</strong><br>
約6秒程度から3秒程度に(端末によって異なる場合あり)<br>
→起動からhome画面に遷移するまでの時間を計測</p>
<p><strong>アプリサイズ減少</strong><br>
デバイス上のアプリサイズが約8MB減少<br>
48MB→40MB</p>
<p><strong>全体的にパフォーマンスが向上</strong><br>
メモリの使用率が減ったことにより、全体的にパフォーマンスが向上</p>
<h2>最後に</h2>
<p>仕組みや開発背景についてはMeta公式のブログに詳しく書かれているので興味のある方は以下をみてください。<br>
ref：<a href="https://engineering.fb.com/2019/07/12/android/hermes/">Hermes: An open source JavaScript engine optimized for mobile apps, starting with React Native</a></p>


AndroidアプリにHermesを導入した話

<p>過去に開いたAWS勉強会のスライドが元になっています。<a href="https://speakerdeck.com/hokuo/awsmian-qiang-hui-day1-ec2-rds?slide=26">こちら</a>からご覧ください。</p>
<h2>IPアドレスとは</h2>
<p><img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/386799/54c48b11-5590-62c6-4716-6ea2c51609d7.png" alt="スクリーンショット 2021-11-30 22.05.13.png"><br>
IPアドレスというのは送信データに「送信元IP」「送信先IP」としてそれぞれ1つずつ設定できるもので、これがないとルーターを介した通信ができません。<br>
私達がよく見る192.168.33.13のようなIPアドレスはIPv4という部類であり、最近ではIPの数が足りていないのでIPv6という規格も主流になっています。<br>
ここではIPｖ４をベースにお話をしていきます。</p>
<h2>IPアドレスの構造</h2>
<p><img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/386799/cd491d20-1347-5658-2bdc-e53dc2592f43.png" alt="スクリーンショット 2021-11-30 22.05.18.png"><br>
IPアドレスの構造は最大3桁の数字がピリオド区切りで4つ並んでいます。<br>
これは10進数で表されたもので、実態は「2進数8桁の数字をピリオド区切りで4つ並べたもの」になります。</p>
<h2>サブネットマスク</h2>
<p><img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/386799/1ddf9ede-56cb-df0b-ae29-caafbadc2910.png" alt="スクリーンショット 2021-11-30 22.05.22.png"><br>
よくIPアドレスの後ろに「/16」などと書かれたものがあり、見かけたことがある方もいると思いますが、これはサブネットマスクと呼びます。</p>
<h2>サブネットマスクの役割</h2>
<p><img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/386799/c9ff14f2-3e67-093f-6589-27b083bb9d23.png" alt="スクリーンショット 2021-11-30 22.05.25.png"><br>
IPアドレスに近い構造ではありますが、後に説明する「IPアドレスのネットワーク部とホスト部の境目」を示すものになります。<br>
同じように2進数の8桁のピリオド区切りで4つ並べたもので、16という数字は左から16桁目までが1だよということを示してくれています。(1になっている部分はネットワーク部を示す。つまり2進数表記におけるIPアドレスの左から16桁目までがネットワーク部になるということ)<br>
同じネットワークに所属しているIP同士はルータを使わなくても通信できます。社内で同じルーターを使っていれば、みんなは同じネットワークに所属しているはずですので、ネットワーク部を割り出して確認してみてください。</p>
<h2>IPアドレスとサブネットマスクの確認の仕方</h2>
<p><img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/386799/48d1094a-2b7b-0f44-1fd9-c111dca3b58c.png" alt="スクリーンショット 2021-11-30 18.57.56.png"><br>
「ifconfig」コマンドでen0の欄を見ると自分のIPとサブネットを確認することができます。<br>
netmastkがサブネットマスクのことですが、ここでは16進数になっているので10進数では「255.255.255.0」となりCIDR表記では「/24」になります。</p>
<h2>IPが決まると、ネットワーク内に割り当てられるホストの数が決まる</h2>
<p><img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/386799/142d1f04-831f-df8c-4877-a9c61cdca013.png" alt="スクリーンショット 2021-11-30 22.05.36.png"><br>
このネットワークとホストの境目が決まると、同じネットワークに所属しているホストの数が決定されます。/16であればネットワーク部が16桁で、ホスト部が残りの16桁になるのでホスト部の数字の組み合わせは2の16乗となり65536ホストとなります。<br>
実際の設計では、このホスト(PCやサーバー)の使用する台数によって数値を絞るようにサブネット小さくを切ります。(/24など。ホストが1台の場合は/32など)<br>
中には割り当てることができない特殊なIPも存在します。</p>
<h2>一部の特殊なIPアドレスの紹介</h2>
<p><img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/386799/a43f32cc-53ec-6180-59f0-12e64cdd4fe1.png" alt="スクリーンショット 2021-11-30 22.05.40.png"><br>
特にループバックアドレスは馴染みがありそうですね。localhostのIPアドレスであり、自分のローカルIPアドレスとなります。</p>
<h2>実際の通信はどうなっているのか</h2>
<p>実際にルータを使用した通信の例を見てみます。<br>
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/386799/280c6bcc-47f4-13f2-a8e6-057880c26216.png" alt="スクリーンショット 2021-11-30 22.05.53.png"><br>
まずARPというプロトコルで先ほど紹介した「ブロードキャストアドレス」を使用して同じネットワークのすべてのホストに対して「このアドレス知ってる人います？」と質問します。<br>
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/386799/26b79a0f-fb8b-9f2e-20dc-f60165d6d2b3.png" alt="スクリーンショット 2021-11-30 22.05.55.png"><br>
それがわかると、機器固有のMACアドレスを質問者にわたし、それをもとにその危機にデータをわたします。はじめに説明の通り、送信先のIPは一つしか持てないので、中継する機器はMACアドレスを渡して「こっちにパスしてくれー」と合図を送っているわけです。<br>
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/386799/6a85f6b8-5e5c-795a-55ac-f83d91f4de5c.png" alt="スクリーンショット 2021-11-30 22.05.57.png"><br>
これらを繰り返して目的地までのデータ送信を進めていきます。</p>
<h2>終わりに</h2>
<p>今回はIPアドレスに関する簡単な解説しながら実際の通信を覗いてみました。<br>
もう少し実践的な使い方や説明はこちらのスライドをご覧ください。<br>
https://speakerdeck.com/hokuo/awsmian-qiang-hui-day1-ec2-rds</p>
<p>また、AWSの勉強も兼ねて学んでみたい方は下記の書籍がおすすめですのでぜひ。</p>
<ul>
<li>
<p>基礎知識<br>
<a href="https://www.amazon.co.jp/Amazon-Services-%E5%9F%BA%E7%A4%8E%E3%81%8B%E3%82%89%E3%81%AE%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF-%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC%E6%A7%8B%E7%AF%89-%E6%94%B9%E8%A8%823%E7%89%88/dp/4296105442/ref=sr_1_7?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&amp;keywords=aws+%E6%9C%AC&amp;qid=1638267431&amp;sr=8-7">Amazon Web Services 基礎からのネットワーク&amp;サーバー構築</a></p>
</li>
<li>
<p>パターン構築<br>
<a href="https://www.amazon.co.jp/Amazon-Services-%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3%E5%88%A5%E6%A7%8B%E7%AF%89%E3%83%BB%E9%81%8B%E7%94%A8%E3%82%AC%E3%82%A4%E3%83%89-%E6%94%B9%E8%A8%82%E7%AC%AC2%E7%89%88-Informatics/dp/4797392576/ref=sr_1_1?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&amp;keywords=AWS+%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3&amp;qid=1638267453&amp;sr=8-1">Amazon Web Services パターン別構築・運用ガイド</a></p>
</li>
</ul>


Webエンジニアのためのネットワーク基礎 - IPアドレス編 -

<p>こんにちは、Another works のみやぞんです。<br>
つい最近、Reactのアップデートを行ったので React v17 での変更で学んだことについて紹介したいと思います。</p>
<h2>アップデート内容</h2>
<ul>
<li>新機能 “なし”</li>
<li>段階的なアップグレードが可能になった</li>
</ul>
<p>公式：<a href="https://ja.reactjs.org/blog/2020/10/20/react-v17.html">https://ja.reactjs.org/blog/2020/10/20/react-v17.html</a></p>
<h2>破壊的変更があった部分</h2>
<p>アップデート内容にもあった「段階的なアップグレード」を実現するための変更が「Event Delegationの変更」です。React v17 における最も大きな変更と言えます。<br>
公式の言うEvent Delegation(イベント委譲)の変更とは、イベントハンドラが登録される方法が変わったということです。 これまではdocumentオブジェクトで全てのイベントをハンドリングしてましたが、v17 からは<code>ReactDOM.render()</code>の第二引数で渡された要素上でイベントをハンドリングします。<br>
(Event Delegationでイベントのハンドリング場所を一箇所に集めることのメリットはメモリ節約やコード量の点にあるみたいです。)</p>
<p>以下の図は公式からの引用です。</p>
<p><img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/386799/c5777211-87e3-d6af-65cd-dfedc6ff9325.png" alt="react_17_delegation.png"></p>
<p>この図にある通り、React は DOM の Event Delegation を利用して document にイベントハンドラを登録しています。 DOM の Event Delegation については W3C の図を引用します。</p>
<h2>Event Delegation</h2>
<p><img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/386799/3f399a33-5add-65b5-b0bb-90f3c2716f7d.png" alt="20201030001442.png"></p>
<p><a href="https://www.w3.org/TR/uievents/#event-flow">https://www.w3.org/TR/uievents/#event-flow</a>より<br>
DOMのイベント実行までの流れには以下のようなフェーズがあります。</p>
<h4>Capture Phase</h4>
<p>イベントオブジェクトはターゲットの親たちを経由して Window からターゲットの親要素へと伝搬します。</p>
<h4>Target Phase</h4>
<p>イベントオブジェクトは、イベントオブジェクトのイベントターゲット(イベントがトリガーされる場所)に到着します。</p>
<h4>Bubbling Phase</h4>
<p>イベントオブジェクトはターゲットの親たちを逆順に伝搬し、ターゲットの親から始まり、Window で終了します。</p>
<p>これまでのReactではインラインで宣言したonClickなどのイベントはdocument.addListenerされます。つまり、イベントの登録をdocumentに対して行います。<br>
デフォルトではバブリングフェーズでイベントが発火するので、この場合だと発火するタイミングは「要素をクリックしてバブリングフェーズに入ってからdocumentまでさかのぼったとき」です。</p>
<p>一方でReact v17では、documentではなくその下のReactをマウントしている部分(RootNode)に登録されます。なので、イベント発火のタイミングはバブリングフェーズでRootNodeに到達したときとなります。</p>
<h2>実際のコード</h2>
<p>これで何が変わるのかというと、Reactの外にaddEventListenerにてイベントハンドラを登録しているときの挙動です。例えばReactのRootNodeよりも上層のbodyやdocumentに対して addEventListener を使いイベントハンドラを登録している場合にReact v17へのアップデートで違いが出ます。</p>
<ul>
<li>
<p>React v16<br>
<a href="https://codepen.io/hk206/pen/wvexLwy">https://codepen.io/hk206/pen/wvexLwy</a></p>
</li>
<li>
<p>React v17<br>
<a href="https://codepen.io/hk206/pen/MWoBMYx">https://codepen.io/hk206/pen/MWoBMYx</a></p>
</li>
</ul>
<p>上記のコードは、React v16, v17でそれぞれ同じコードを書いているのですが、挙動が異なります。<br>
このコードには　body　に対して登録したイベントと、ボタンにインラインで指定したイベントがあります。ボタンをクリックしたときは**e.stopPropagation()**によりバブリングを止め、そこから上層のイベントは発火しないように制御できます。<br>
このコードで実現したかったのは、ボタンを押したときはボタンに書いた処理は走ってほしいけど、bodyをクリックしたときの処理は走らせないというものです。</p>
<h3>React v16</h3>
<p>React v16の場合はクリック時にどちらも走ってしまいます。なぜでしょう？<br>
これは冒頭にも説明したとおり、インラインで書かれたイベントはdocumentオブジェクトに登録されるからで、処理としてはボタンをクリックしてからバブリングフェーズでbodyの処理がはじめに発火し、それからさかのぼってdocumentに登録されたイベントを発火します。stopPropagationを実行するときにはすでにbodyは通過しているため、思ったような挙動にはなりません。</p>
<h3>React v17</h3>
<p>ここではReactのRootNodeがbodyよりも下にあることを前提とします。<br>
React v17ではちゃんと意図したとおり、ボタンクリックの場合はボタンの処理のみ、その外をクリックしたときはbodyに登録した処理が走っています。これはインラインで記述したイベントの委譲先がdocumentではなくReact RootNodeになっているからで、stopPropagationはbodyの下にあるRootNode要素で実行されるのでバブリングが止まり、bodyの処理が走ることはありません。</p>
<h2>おわりに</h2>
<p>これが、今回のアップデートで変更があったイベントハンドラの登録先の変更です。(Event Delegation)</p>
<p>実際のケースでは、例えばモーダルの外をクリックしたときに閉じる処理を実装する場合に、モーダルの最外要素にe.stopPropagation()を記述することでbodyのクリック、つまりモーダルの外側がクリックされた時にだけモーダルを閉じる仕様を簡単に実現することができます。これまでのようにモーダルの外をクリックしたのか、中をクリックしたのかという処理をわざわざ書く必要はありません。</p>
<p>簡単ですが、以上がReact v17へのアップデートで私が学んだEvent Delegationについてでした。<br>
またフロントチームでLT会やプログラミング研究会という機会を活用して技術の深堀りを続けていこうと思います。</p>


React v17から学んだEvent Delegationについて

<h1>こんな悩みはありませんか？</h1>
<ul>
<li>書いたコードに予期せぬバグがあるのではと心配になり、夜も眠れない</li>
<li>変更後に致命的なバグが突然発生する悪い夢にうなされる</li>
</ul>
<h1>テストの目的</h1>
<ul>
<li>「想定通りに動くのか」を担保するため</li>
<li>開発者自身のため</li>
<li>変更に強い仕様書をつくる</li>
</ul>
<h1>テストってどうやってを書くの？</h1>
<h2>Testing Torophy</h2>
<ul>
<li>JSテスト界の大御所Kent.Cが提唱するテストのコンセプト</li>
<li>体積が大きいところほど重要であるとしている(ここではIntegrationが最も大きい)</li>
</ul>
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/386799/16c8cc69-2e11-9fbf-5ac8-158943e082fd.png" width="550">
<h2>トレードオフの発生</h2>
<ul>
<li>テストの実行スピード</li>
<li>工数</li>
<li>カバレッジ</li>
</ul>
<img src="https://qiita-user-contents.imgix.net/https%3A%2F%2Fqiita-image-store.s3.ap-northeast-1.amazonaws.com%2F0%2F82363%2Fda49f860-4296-9ab4-cc08-186ecc8888ad.png?ixlib=rb-4.0.0&auto=format&gif-q=60&q=75&w=1400&fit=max&s=350ca04cddac9646515b2f4a526d9df0" width="700">
<h2>Kent.Cの方針</h2>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/a7aec6d7-3bd6-4fc7-b81e-3c3ad21eaf6b%2FKentCDoddsHeadshot.png" width="300">
Kent.Cがtesting-libraryのドキュメント内で言っていたこと。
<ul>
<li>テストはアプリケーションの利用方法に似ているほど信頼性が得られるのさ</li>
<li>実装の詳細をテストしないことを勧めるよ（実施してもいいけどね)</li>
</ul>
<h1>テストって何を書けばいいの？</h1>
<h2>実際に書いてみる</h2>
<p><strong>テスト対象</strong><br>
Incrementボタンを押すと、数字が1増えて表示される。(初期表示は0)<br>
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/386799/de2c54e1-b76b-06b9-1d92-420e258ed729.png" width="200"></p>
<pre><code class="language-react">export function Counter() {
  const [count, setCount] = useState(0);
  const increment() {
    setCount(count + 1);
  }
  return (
    &lt;&gt;
      &lt;div&gt;Number: {count}&lt;/div&gt;
      &lt;div&gt;
        &lt;button onClick={increment}&gt;Increment&lt;/button&gt;
      &lt;/div&gt;
    &lt;/&gt;
  )
}
</code></pre>
<h2>実際に書いてみる</h2>
<p>仕様ライブラリ: Jest, react-testing-library</p>
<p><strong>テスト内容</strong></p>
<ul>
<li>初期表示はNumber: 0</li>
<li>Increamentボタンを押すと数字が1つ増える</li>
</ul>
<pre><code class="language-react">import { fireEvent, render, screen } from &quot;@testing-library/react&quot;
import { Counter } from &quot;./&quot;

describe(&quot;Counter&quot;, () =&gt; {
  test(&quot;render&quot;, () =&gt; {
    render(&lt;Counter /&gt;)
    expect(screen.getByText('Number: 0')).toBeInTheDocument();
  })
  test(&quot;increment&quot;, () =&gt; {
    render(&lt;Counter /&gt;)
    const button = screen.getByText(&quot;Increment&quot;)
    fireEvent.click(button)
    screen.getByText(&quot;Number: 1&quot;)
  })
})
</code></pre>
<p>なるほどこれは仕様書になる...!</p>
<h2>Reactで優先的に書くべきテスト</h2>
<ul>
<li>ロジックがあるor少し複雑なUIコンポーネントのIntegration Test</li>
<li>Custom Hooksなどの切り出されたロジックのUnit Test</li>
</ul>
<p>ロジックが複雑でバグが出やすそう...<br>
ここが壊れたらヤバい！不安で夜も眠れない...<br>
そんな不安を解消してくれそうな部分からテストを書きましょう。</p>
<h1>はじめてテストをやってみて</h1>
<h2>感想・気づき</h2>
<ul>
<li>サーバーサイドのテストとはまた違った難しさがある</li>
<li>Integration Testをしっかり書けば仕様書になる</li>
<li>E2EテストのCypressも触ってみたい</li>
</ul>


フロントエンドテストのはじめかた

<p>こんにちは。みやぞんです。<br>
かなり前の話ですが、MySQLのインデックスについて調べたことがあり、<br>
そのメモが残っていたので共有します。</p>
<p>インデックスとはなんぞやってところからB-tree構造まで、広く浅く調べたのでまとめてみました。</p>
<h2>インデックスとは</h2>
<p>インデックスは特定のカラムの、あるレコードをすばやく見つけるために使用されるものです。検索が爆速になります。</p>
<p>本を読む時、章ごとに付箋みたいなのを貼っておくと目的のページにたどり着くのが早いのと同じです。(貼らない人は、目次とか索引とかイメージしてもらえれば)</p>
<p>インデックスがないとMySQLは関連するレコードを見つけるために、先頭行から始めてテーブル全体を読みとらないといけなくなります。(<strong>フルテーブルスキャン</strong>)<br>
広辞苑くらいぶ厚い本に索引がなかったり、あいうえお順になっていなかったりしたら...大変ですよね...。</p>
<h2>インデックスの貼り方</h2>
<p>検索をかけるカラムにインデックスを貼るだけ。ほんと簡単なのでやらないのは損。<br>
参照コマンド(自分が貼ったインデックスがわかります。<strong>機能しているとは限りません。</strong>)</p>
<pre><code class="language-sql">SHOW INDEX FROM テーブル名;
</code></pre>
<p><strong>作成コマンド</strong></p>
<pre><code class="language-sql">ALTER TABLE テーブル名 ADD INDEX インデックス名(カラム名);
</code></pre>
<p><strong>削除コマンド</strong></p>
<pre><code class="language-sql">ALTER TABLE テーブル名 DROP INDEX インデックス名;
</code></pre>
<h2>インデックスの効果</h2>
<p>今回はあるテーブルのcategoryカラムにインデックスを貼ってみました。<br>
以下は250万弱のレコードのうち、カテゴリーナンバーが'5'である約２万レコードを抽出した時の例です。</p>
<p><strong>インデックスがない場合</strong><br>
<img src="https://i.imgur.com/e2EMAHY.png" alt=""></p>
<p><strong>インデックスを貼った場合</strong><br>
<img src="https://i.imgur.com/1H3CusK.png" alt=""></p>
<p>以上から分かるようにかかる時間が全然違います。</p>
<p>念のため、本当にインデックスが効いているかどうかをEXPLAINってやつを使って確認しましょ。</p>
<h2>クエリのパフォーマンスを見るEXPLAIN</h2>
<p>インデックスが効いているかどうかを実際に知るには、EXPLAINをクエリの頭につけて実行し確認する方法があります。</p>
<p>以下のコマンドで、どうぞ。</p>
<pre><code class="language-sql">EXPLAIN SELECT カラム名1, カラム名2... FROM テーブル名 WHERE 条件...;
</code></pre>
<p>コマンドを実行すると以下のような結果に。(見づらいけど)<br>
<img src="https://i.imgur.com/RUe6Njx.png" alt=""></p>
<p>これは、データベースからレコードを引っ張ってきているわけではなくクエリ実行時のパフォーマンスを表しています。<br>
１回目の実行結果はインデックスが効いている場合、２回目の実行結果はインデックスが効いていない場合です。<br>
色々読み方が難しいので、ここではインデックス実行時に見るべきところだけを説明します。</p>
<p><strong>type</strong><br>
レコードへのアクセス方法。ここが<code>ref</code>となっている場合は、constではないインデックスを使って等価検索を行いアクセスしたことを表しているとのこと。とりあえずこれならOK。<br>
<code>ALL</code>って書いてある場合は、<strong>フルテーブルスキャン</strong>していることを表し、インデックスが全く使用されていないことを示すため注意が必要です。</p>
<p><strong>possible_keys</strong><br>
貼られる可能性のあるインデックスを示す。ここでは<code>price</code>のみとなっているが、複数つけた場合は複数表示される。例えば<code>category</code>, <code>price</code>とあったら、カテゴリー順のインデックスと、値段順のインデックスどっちでも使える状態だよってことです。実際に使用されているわけではありません。</p>
<p><strong>key</strong><br>
実際に使用されているインデックス。ここに希望のインデックスがあるかどうか確認します。もちろん<code>possible_keys</code>の中から選ばれます。ここでは、使われたインデックスが<code>price</code>であることがわかります。</p>
<p><strong>rows</strong><br>
そのテーブルから参照される行数の<strong>大まかな</strong>見積もり。これがインデックスを貼った時に減っていればインデックスが効いていることになります。</p>
<p>だいたいこの辺の項目を見ておけばインデックスが効いているかがわかります。</p>
<h2>インデックスってなんで早くなるの？</h2>
<p>早くなるからただ使っているっていうのは、なんだか気持ち悪いので色々仕組みを調べてみました。</p>
<p>インデックスを貼ると、検索用に最適化されたデータベースが生成されるそうで、それを参照することで処理するレコード数を効率的に減らしているらしいです。<br>
検索用のデータベースってなんぞやってのを理解するためには、データ構造のひとつでMySQLが採用している<strong>B+tree構造</strong>(びーぷらすつりーこうぞう)について理解する必要があります。<br>
ですが、やや複雑ですのでよりシンプルな<strong>B-tree構造</strong>について先に説明します。</p>
<h3>B-tree構造</h3>
<p>一種のデータ構造のことで、下図のとおり二分探索しやすいように値を大小で振り分けたデータ構造のことを言います。MySQLでインデックスを貼る時に生成されるデータベースはこの構造になっています。</p>
<p><img src="https://i.imgur.com/VY8ZzIv.png" alt=""></p>
<p><strong>上図右側</strong><br>
インデックスを貼ってない普通のデータ構造です。先頭から順に計算していくため、ある一つのデータを抽出するためには最大７回の計算をしなければならないことになりますね。</p>
<p><strong>上図左側</strong><br>
対して<strong>B-tree</strong>は、ターゲットが中央値より大きいか小さいかで分岐させ、それを繰り返す二分探索をするため計算は最大３回で済みます。<br>
このデータ構造の仕組みにより、検索を高速化できます。</p>
<p>この**O(n)**ってやつのOはOrderで計算量を表します、()内のnはレコード数になります。インデックスを使うことで計算量は対数関数的に減っていきますよって感覚がわかりますね。テーブルが大きくなれば受ける恩恵は大きいってことです。</p>
<h3>カテゴリー検索例</h3>
<p>簡単な例を作ってみた。</p>
<p><img src="https://i.imgur.com/jbxJvpt.png" alt=""></p>
<p>インデックスが貼られた時、検索時に使用するデータを新たに生成します。それが上図右側のB-tree構造のデータです。</p>
<p>検索をかけた時には、検索用のB-tree構造のインデックスデータにアクセスし、該当するレコードだけを引っ張り出します。</p>
<p>例えば、category'2'を抽出したい時、普通であれば全レコード総数と等しい１５回の計算を行わなければなりません。しかしインデックスを貼った場合には、２回の計算で済むため効率的に目的のレコードを参照できることがわかります。</p>
<h4>補足</h4>
<p>以上の例では7種類の値をもつカテゴリーカラムに対してインデックスを使用する場合を例にあげました。B-tree構造を簡潔にしたいがためにそのような例にしましたが、実際にこのような貼り方は好ましくありません。詳しくは&quot; <a href="#%E5%8E%9F%E5%89%87%E3%81%AF%E3%82%AB%E3%83%BC%E3%83%87%E3%82%A3%E3%83%8A%E3%83%AA%E3%83%86%E3%82%A3%E3%81%8C%E9%AB%98%E3%81%84%E3%82%82%E3%81%AE%E3%81%AB%E8%B2%BC%E3%81%A3%E3%81%A6%E3%81%84%E3%81%8F">カーディナリティの高いものから貼っていく</a> &quot;に記載しています。</p>
<h3>実際のMySQLはB+tree構造を採用している</h3>
<p>名前が似ていてややこしいですがB+tree(びーぷらすつりー)について説明します。実は、MySQLはこっちの構造を採用しています。B-treeと似ているようで若干構造が異なります。<br>
とはいっても先ほどのB-tree構造を理解してしまえば簡単です。以下はB-treeとB+treeの構造を比較したものです。<br>
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/386799/a263692d-a888-439d-e699-2dc945e56c60.png" alt="Untitled Diagram (3).png"><br>
今までに説明したB-treeは一番下の段(リーフノード)だけではなく一段目(ルートノード)、二段目(子ノード)にもデータを持たせており、探索時、上流でヒットすればそれだけ早く計算が終了するという特徴があります。<br>
それに対して<strong>B+tree</strong>では、リーフノードに全ての情報を持たせており、かつそのそれぞれを繋げています。上流にはデータを持たせていません、あくまで計算して分岐させるだけです。<br>
何が利点かというと、<strong>範囲検索に強い</strong>ことです。例えば3〜５の検索をした時、３までたどり着けばそのまま横にずれて4と5の条件も拾っていけます。B-treeだと範囲検索時はいちいち上流から計算し直さなければなりません。これがB+treeの利点です。</p>
<h2>インデックスを貼るときの注意点</h2>
<h3>インデックスをむやみに貼らない</h3>
<p>じゃあインデックスとりあえず全部貼っておくかってなりそうだけどそうはいきません。</p>
<h4>B-treeを生成するデメリット</h4>
<ul>
<li>データ容量を圧迫する</li>
<li>データ挿入時、更新時に処理が重くなる</li>
</ul>
<p>これらは検索用のデータを新たに生成する事による弊害です。<br>
データを増やすことが容量を圧迫することになるのは容易に想像できますね。<br>
また、データ挿入や更新時には他の全てのインデックス用データベースも更新しなければなりません。インデックスを１個しか使わなくていいものを１０個貼ったのなら、９個分のデータベースを余計に更新することになります。このことにより処理が重くなります。</p>
<p>ではどのようにインデックスを貼っていけば効率的なのでしょうか。</p>
<h4>原則はカーディナリティが高いものに貼っていく</h4>
<p><strong>カーディナリティ</strong>は多重度とか、選択度という意味があります。好みですが、選択度の方が理解しやすい気がします。</p>
<p>これはどういうことかというと、カラム内の値の種類が２種類しかない時、例えば男女で分ける場合には絞り込み度は50％となります。50%というのはカーディナリティがかなり低い部類に入ります。これはインデックスを貼ってもあまり効果が見込めません。</p>
<p>対して500万レコードの顧客情報に苗字カラムがあったとして、その種類が5千種類だとすると、インデックスを貼った場合の絞り込み度は0.02%になります。これはカーディナリティの高い状態であり、インデックス使用時の効果が高くなります。</p>
<p>ですので、原則インデックスはカーディナリティの高いものに貼っていくべきで、低いものに貼る場合にはしっかり効果を確認して判断する必要があります。(低いものでも効果が見込める場合があるため)</p>
<h3>インデックスが適用されない場合もある</h3>
<p>他にも、インデックスを貼ったはずなのに効いてないこともあるので注意が必要です。<br>
以下のような時にはインデックスは適用されません。</p>
<ul>
<li>LIKEが%で始まる場合</li>
<li>DB全体を読んだ方が早いとMySQLが判断した場合(レコードが全体の30%を超える場合や、1000件未満の場合など）</li>
<li>ORDER BYを使用している場合</li>
</ul>
<p>他にも色々あるので調べてみてください！<br>
とりあえず効いてるかはEXPLAINで必ず確認しておくといいと思います。</p>
<h2>参考</h2>
<p><a href="https://dev.mysql.com/doc/refman/5.6/ja/mysql-indexes.html">8.3.1 MySQL のインデックスの使用の仕組み</a><br>
<a href="https://qiita.com/C058/items/1c9c57f634ebf54d99bb#%E3%83%81%E3%83%A5%E3%83%BC%E3%83%8B%E3%83%B3%E3%82%B0%E3%81%99%E3%82%8B%E9%9A%9B%E3%81%AE%E3%83%A1%E3%83%A2">MySQLでインデックスを貼る時に読みたいページまとめ(初心者向け）</a><br>
<a href="https://qiita.com/kiyodori/items/f66a545a47dc59dd8839">B-treeインデックス入門</a></p>


Recent Articles