Another works Developers Blog

<h2>はじめに</h2>
<p>こんにちは。株式会社Another worksのnonoyamalfoyです。</p>
<p>先日、ドロップダウンコンポーネントを作成した際にGenericsを活用して汎用的なドロップダウンコンポーネントを作成したので共有します。<br>
<img src="https://storage.googleapis.com/zenn-user-upload/5fde573ec091-20230206.gif" alt=""></p>
<p>ドロップダウンformで持ちたいvalueの型は様々かと思います。<br>
stringで持ちたい場合はもちろん、個数選択ならnumber, Objectの場合も想定されます。<br>
しかし、anyはつかいたくない。そんなときにGenericsを使うことでのformで持ちたいvalueの型を利用側から指定できるようにします。</p>
<h2>実際にコードを見てみる</h2>
<p>コンポーネント側</p>
<pre><code class="language-jsx">// 選択肢の型
type Item&lt;Value&gt; = {
  imageUrl?: string;
  text: string;
  value: Value | undefined;
};

type Props&lt;Value&gt; = {
  ...
  // 選択中のItemの値
  selectedValue: Value;

  // 選択肢の配列
  items: Item&lt;Value&gt;[];

  // 選択肢をクリックしたときのイベントハンドラ
  onClickSelectorItem?: (item: Item&lt;Value&gt;) =&gt; void
}

export function Dropdown&lt;Value&gt;({
  ...
  selectedValue,
  items,
  onClickSelectorItem
}: Props&lt;Value&gt;) {
  return (
     ...
  )
}
</code></pre>
<p>呼び出し側で型を指定できる</p>
<pre><code class="language-jsx">
const [selectedValue, setSelectedValue] = useState&lt;string&gt;(&quot;text1&quot;)
const items = [
  {
    text: 'text1',
    value: 'text1',
  },
  {
    text: 'text2',
    value: 'text2',
  },
]
...

// genericsで型を指定
&lt;Dropdown&lt;string&gt;
  ...
  // selectedItemValueがgenericsで指定した型になる
  selectedItemValue={selectedItemValue}

  // valueがgenericsで指定した型になる
  items={items}

  // 引数のvalueがgenericsで指定した型になる
  onClickSelectorItem={onClickSelectorItem}
/&gt;
</code></pre>
<p>このようにGenericsを使用することで、あらゆるvalueの型に対応し、汎用性の高いコンポーネントを実現できます。</p>
<h2>補足</h2>
<p>以下のように厳格な比較をしている場合<br>
valueの型にObject型を指定したい場合にはitemsに渡すvalueとselectedValueの参照先を同じにしないといけないので注意。</p>
<pre><code class="language-jsx">//　選択中のitemを判断するロジック
const selectedItem = useMemo(
   () =&gt; items.find(({ value }) =&gt; value === selectedItemValue),
   [items, selectedItemValue],
);
</code></pre>
<p>MUIのSelectコンポーネントでもvalueにObjectを使うときは注意しろという文言がありました。</p>
<blockquote>
<p>値がオブジェクトの場合、選択されるためには、そのオプションと参照一致しなければならない。値がオブジェクトでない場合、選択されるためには、その文字列表現はオプションの文字列表現と一致しなければならない</p>
</blockquote>
<p><a href="https://mui.com/material-ui/api/select/">Select - MUI</a></p>


Genericsを活用して汎用的なドロップダウンUIを作成する

<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>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開発におけるイミュータブルを意識した実装

<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>こんにちは、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>


#Frontend