Another works Developers Blog

<p>こんにちは。みやぞんです。</p>
<p>以前create-react-app製のReactアプリケーションのAlias Pathの設定で苦戦した事があったため、記事にして情報を共有します。</p>
<p>※現在、弊社Another worksが展開する複業クラウドのフロントエンド開発スタックはすべてNext.js＋TypeScriptで行っています。</p>
<h1>導入背景</h1>
<p>Alias Pathはパスを設定する際にわずらわしいパスの記述を短縮して簡潔にかける仕組みになります。<br>
当時弊社ではReactを採用しており、インポート文におけるパスの記述でまさにその煩わしさを感じていたのと、別プラットフォームのNext.jsではそのAlias Pathを利用していたので統一したい想いがありました。<br>
Alias Pathとは、<code>import { SomeComponent } from '@/components/SomeComponent</code> のようなものです。</p>
<p>Next.jsではAlias Pathがサポートされており、以下の記事のように簡単に設定できます。<br>
<a href="https://nextjs-ja-translation-docs.vercel.app/docs/advanced-features/module-path-aliases">https://nextjs-ja-translation-docs.vercel.app/docs/advanced-features/module-path-aliases</a></p>
<p>Reactでも設定は可能なのですが、create-react-app製であると内部にwebpackの諸々の設定が隠蔽されてしまうので、アプリケーションを作る上では非常に便利なのですが、こういったところで微妙につらみがてきてしまいました。</p>
<h1>CRAでAlias Pathを設定するには</h1>
<p>CRAではwebpackやbabelの設定が内部で勝手に行われているためにファイルがそもそも存在しないません。<br>
そこで、設定を変更するには以下の2つの方法があります。</p>
<ul>
<li>npm run ejectでCRAをejectする</li>
<li>cracoやrewiredといった拡張ツールでCRAの設定を拡張(上書き)する</li>
</ul>
<p>EjectするとReactアプリのトッププレイヤーにwebpackやbabel系のファイルが出てくるので手動で設定可能になります。しかしさすがにCRAの恩恵をAlias Pathのためだけに捨てるのは微妙なので後者を選択しました。</p>
<h1>CRA拡張ツールの選択肢</h1>
<p>react-app-rewiredは今後のサポートが不安そうな部分もあったので、今回はCRACO利用しました。</p>
<p>react-app-rewired<br>
<a href="https://www.npmjs.com/package/react-app-rewired">https://www.npmjs.com/package/react-app-rewired</a></p>
<p>CRACO<br>
<a href="https://www.npmjs.com/package/@craco/craco">https://www.npmjs.com/package/@craco/craco</a></p>
<p>CRACOをインストールしたら、package.jsonのコマンド類を説明書きどおりに書き換えましょう。</p>
<h1>ファイルの変更</h1>
<p>変更するファイルは以下の3つになります。</p>
<ul>
<li>craco.config.js</li>
<li>tsconfig.json</li>
<li>tsconfig.paths.json</li>
</ul>
<pre><code class="language-typescript">// craco.config.js
const path = require('path');

module.exports = {
  webpack: {
    alias: {
      '~': path.resolve(__dirname, './src/'),
    },
  },
};
</code></pre>
<p>tsconfig.jsonで<code>&quot;extends&quot;: &quot;./tsconfig.paths.json&quot;</code> を含めましょう。</p>
<pre><code class="language-typescript">// tsconfig.json
{
  &quot;compilerOptions&quot;: {
    &quot;target&quot;: &quot;es6&quot;,
    &quot;sourceMap&quot;: true,
    &quot;lib&quot;: [&quot;dom&quot;, &quot;dom.iterable&quot;, &quot;esnext&quot;, &quot;es2019&quot;],
    &quot;allowJs&quot;: true,
    &quot;skipLibCheck&quot;: true,
    &quot;esModuleInterop&quot;: true,
    &quot;allowSyntheticDefaultImports&quot;: true,
    &quot;strict&quot;: true,
    &quot;forceConsistentCasingInFileNames&quot;: true,
    &quot;module&quot;: &quot;esnext&quot;,
    &quot;moduleResolution&quot;: &quot;node&quot;,
    &quot;resolveJsonModule&quot;: true,
    &quot;isolatedModules&quot;: true,
    &quot;noEmit&quot;: true,
    &quot;jsx&quot;: &quot;react&quot;,
    &quot;baseUrl&quot;: &quot;./src&quot;,
    &quot;noFallthroughCasesInSwitch&quot;: true
  },
  &quot;include&quot;: [&quot;src/**/*&quot;],
  &quot;exclude&quot;: [&quot;node_modules&quot;, &quot;src/**/*.spec.ts&quot;],
  &quot;extends&quot;: &quot;./tsconfig.paths.json&quot;
}
</code></pre>
<pre><code class="language-typescript">// tsconfig.paths.json
{
  &quot;compilerOptions&quot;: {
    &quot;paths&quot;: {
      &quot;~/*&quot;: [&quot;./*&quot;],
    }
  }
}
</code></pre>
<p>これでAlias Pathが動作します。</p>
<h1>おわりに</h1>
<p>以上が、CRA製のReactアプリケーションにAlias Pathを設定する方法になります。<br>
webpack関連を気にしなくても良いのは非常に便利ですが、こういった細かい部分に関しては便利なライブラリを使用しながら適応していく必要がありそうです。</p>


create-react-app(CRA)でAlias Pathを設定する方法

<p>こんにちは！<br>
Another worksのみやぞんです。<br>
今回は今月リリースした本テックブログについて説明します。</p>
<h1>Headless CMS(Newt) + Next.js</h1>
<p>このテックブログは、Headless CMSのNewtとNext.jsで構成されています。</p>
<p>サービスLPやコーポレートサイトでも利用しているSTUDIOが実は最有力だったのですが、シンタックスハイライトに対応していないところが唯一の欠点でした。</p>
<p>Headless CMSは過去にmicroCMSをサービスLPで利用したこともあり、バックエンドのコードやDBを保つ必要がなく、フロントエンドも自由に実装ができる点が魅力的で気に入っています。</p>
<p>今回、microCMSではなくNewtを選定した理由は<strong>無料枠が大きい</strong>。これに尽きます。</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/ebe71419-8d73-4a64-933c-37667a79157e%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-1915.14.59.jpg" alt="スクリーンショット2022-12-1915.14.59.jpg"></p>
<p>またNext.js製のテンプレートが用意されており、デザインから考えなくてもシンプルなカードビューレイアウトや検索機能、タグ機能が利用できるようになっている点も「とりあえず立ち上げたい」という人にとって嬉しいポイントです。</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/9c9c3986-0652-4a71-bb51-fe8f121f6162%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-1915.16.01.jpg" alt="スクリーンショット2022-12-1915.16.01.jpg"></p>
<h1>シンタックスハイライト</h1>
<p>STUDIOを採用することができなかった理由の一つがこのシンタックスハイライト機能になります。<br>
これはNewtのテンプレートにも含まれていないため、自前で実装を行います。</p>
<pre><code class="language-tsx">import cheerio from &quot;cheerio&quot;;
import hljs from &quot;highlight.js&quot;;
import &quot;highlight.js/styles/github-dark.css&quot;;

const body = useMemo(() =&gt; {
    const cheerRoot = cheerio.load(currentArticle.body);
    cheerRoot(&quot;pre code&quot;).each((_, elm) =&gt; {
      const result = hljs.highlightAuto(cheerRoot(elm).text());
      cheerRoot(elm).html(result.value);
      cheerRoot(elm).addClass(&quot;hljs&quot;);
    });
    if (currentArticle?.body) {
      return {
        __html: cheerRoot.html(),
      };
    }
    return {
      __html: &quot;&quot;,
    };
  }, [currentArticle?.body]);
</code></pre>
<p>CheerioによりcurrentArticle.body(Newtから送られてくる記事のDOM情報)をパースし、hljsによってスタイリングを行っています。<br>
とにかく早く構築したいので、便利なライブラリたちに頼りました。</p>
<h1>On-Demand-ISR</h1>
<p>ブログ構築の際に考えたいのが、記事更新と再ビルドの関係についてです。<br>
Next.jsのSGやISRなどのレンダリング方法については以下の記事に書いておりますので、是非参考にしてください。</p>
<p><a href="https://zenn.dev/hk_206/articles/6981eca2fb56c5">サクッとわかるNext.jsのSGとISRの話</a></p>
<p>SGは静的ページの生成にぴったりなものの、ブログであるとWebHookを使って記事更新ごとにビルドしないといけないことがネックになります。(複数人が同時に実行するとスタックが生じる)<br>
またISRはSSRとSGのいいとこ取りをした素晴らしい機能ですが、キャッシュ更新感覚を固定で設定する必要があるので、記事更新後に内容が即時反映されなかったりなどの煩わしさがあります。</p>
<p>そこで便利なのが、今年8月に晴れて安定版になったのがNext.jsのOn-demand ISRの機能です。</p>
<ul>
<li>これまでのISRは <code>revalidate</code> で指定した時間が経過されるまでは、キャッシュされた情報が返されるので、データを更新してもすぐ反映されなかったが、On-demand ISRは任意のタイミングででキャッシュのパージとページの再生成ができる</li>
<li>APIルートで、<code>revalidate</code> を実行すると<code>getStaticProps</code>を使用する個々のページのキャッシュを再生成する</li>
</ul>
<p>参考：<a href="https://zenn.dev/shimabukuromeg/articles/955cea236650d4">On-demand ISRの機能を試してみた</a></p>
<p>実装例はこちら。</p>
<pre><code class="language-typescript">// pages/api/revalidate.ts

import type { NextApiRequest, NextApiResponse } from 'next';

export default async function handler(
  req: NextApiRequest,
  res: NextApiResponse
) {
  if (req.query.secret !== process.env.REVALIDATE_SECRET_TOKEN) {
    return res.status(401).json({ message: 'Invalid token' });
  }

  try {
    const { slug } = req.body;
    await res.revalidate(`/articles/${slug}`);
    return res.json({ revalidated: true });
  } catch (err) {
    return res.status(500).send('Error revalidating');
  }
</code></pre>
<p>これで<code>https://[domain]/api/revalidate</code>を外部から叩くことで、任意のタイミングでキャッシュをパージすることができます。</p>
<p>後はこのURLをNewtのWebHook機能で記事更新などのタイミングで実行するように設定をすれば、記事更新ごとにデプロイすることなく内容が反映されます。</p>
<h1>Sitemap + Search Console</h1>
<p>ブログを公開したら、検索結果に反映されるようにクローラに検索有効なページを教えて上げる必要があります。<br>
それがサイトマップと呼ばれるものですが、これが生成できるように設定をしましょう。</p>
<pre><code class="language-jsx">// pages/sitemap.xml.tsx
import { GetServerSidePropsContext } from &quot;next&quot;;
import { fetchArticles } from &quot;../lib/api&quot;;

export const getServerSideProps = async ({
  res,
}: GetServerSidePropsContext) =&gt; {
  const xml = await generateSitemapXml();

  res.statusCode = 200;
  res.setHeader(&quot;Cache-Control&quot;, &quot;s-maxage=86400, stale-while-revalidate&quot;);
  res.setHeader(&quot;Content-Type&quot;, &quot;text/xml&quot;);
  res.end(xml);

  return {
    props: {},
  };
};

async function generateSitemapXml() {
  let xml = `&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;`;
  xml += `&lt;urlset xmlns=&quot;http://www.sitemaps.org/schemas/sitemap/0.9&quot;&gt;`;
  xml += `&lt;url&gt;
            &lt;loc&gt;https://[domain]/&lt;/loc&gt;
            &lt;changefreq&gt;weekly&lt;/changefreq&gt;
        &lt;/url&gt;
        `;

  const { articles } = await fetchArticles();
  articles.forEach((article) =&gt; {
    xml += `
        &lt;url&gt;
          &lt;loc&gt;https://[domain]/article/${article.slug}&lt;/loc&gt;
          &lt;changefreq&gt;weekly&lt;/changefreq&gt;
        &lt;/url&gt;
      `;
  });

  xml += `&lt;/urlset&gt;`;
  return xml;
}

const Page = () =&gt; null;
export default Page;
</code></pre>
<p>SSRで生成することでクローラに対応します。<br>
このページは<code>https://[domain]/sitemap.xml</code> になるので、これをGoogle Search Consoleに登録して完了です。<br>
参考：<a href="https://technical-seo.jp/searchconsole-sitemap/">Google Search Consoleへのサイトマップの登録</a></p>
<h1>GTM + GA</h1>
<p>テックブログの運用はエンジニアの工数で成り立っているので、その工数により得られた成果が可視化できるようにGTMやGAを導入しました。<br>
Twitter, オーガニックなどどこからの流入であるか、記事公開後の反響などを分析しましょう。<br>
参考：<a href="https://zenn.dev/keitakn/articles/nextjs-google-tag-manager">Next.jsでのGTMやGAの導入方法</a></p>
<h1>さいごに</h1>
<p>いかがでしたでしょうか。<br>
今回はNext.jsによる弊社のテックブログの構築についてお話しました。</p>
<p>テックブログの構築によって、ついでにOn-demand ISRについて実際に触れることができたことは良かったなと感じています。<br>
みなさんもぜひ使ってみてください！</p>


Another worksテックブログの裏側

<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>こんにちは、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を使ったメンテナンス画面の設計について

<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>過去に開いた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>


Articles by zon