Another works Developers Blog

<p>こんにちは、はけまるです！</p>
<p>2023/06/22に弊社が主催した、豪華5社によるフロントエンドイベント「<strong><a href="https://anotherworks.connpass.com/event/285095/">Front-end Deep Dive Online</a></strong>」についてのレポートを書かせていただきます！</p>
<p>ご参加いただいた5社☆</p>
<ul>
<li>株式会社クラスメソッド</li>
<li>株式会社ゆめみ</li>
<li>株式会社SmartHR</li>
<li>株式会社HRBrain</li>
<li>株式会社Another works</li>
</ul>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/a1f7f4d1-9e46-43e4-ba53-b92c77410235/24a4bfb7671904855fa97ae3594dcfe3.png" alt="24a4bfb7671904855fa97ae3594dcfe3.png"></p>
<h1>目次</h1>
<ul>
<li>イベントの概要</li>
<li>LT登壇内容
<ol>
<li>「巨大tableのパフォーマンスを改善する」</li>
<li>「フロントエンド開発エクササイズ」</li>
<li>「改善活動に戦略と秩序を持たせる」</li>
<li>「HRBrainの生態系を支えるフロントエンドチームの取り組み」</li>
<li>「頑張りすぎない、開発生産性を上げるフロントエンドテスト戦略」</li>
</ol>
</li>
<li>おわりに</li>
</ul>
<h1>イベントの概要</h1>
<p>Another worksでは、技術力を磨きたい、あるいは他社のチームの取り組みについて知りたいと考えている方々向けに定期的にイベントを開催しています！</p>
<p>今回は、各社のCTOやテックリード、エンジニアリングマネジャー、フロントエンドエンジニアの方々に技術や生産性、チームの成長、実装時の考え方など様々なテーマで登壇いただきました！</p>
<p>参加人数は120名を超え、 <strong>#AwEngineerMeetup</strong> のハッシュタグでたくさんの方にTweetしていただけました！</p>
<h1>LT登壇内容</h1>
<ol>
<li>株式会社クラスメソッド 高橋 ゆうき様：<strong>「巨大tableのパフォーマンスを改善する」</strong></li>
<li>株式会社ゆめみ スー様：<strong>「フロントエンド開発エクササイズ」</strong></li>
<li>株式会社SmartHR 山本 裕太様：<strong>「改善活動に戦略と秩序を持たせる」</strong></li>
<li>株式会社HRBrain 山口 祐司様：<strong>「HRBrainの生態系を支えるフロントエンドチームの取り組み」</strong></li>
<li>株式会社Another works 塩原 基弘：<strong>「頑張りすぎない、開発生産性を上げるフロントエンドテスト戦略」</strong></li>
</ol>
<h2>1.「巨大tableのパフォーマンスを改善する」</h2>
<p>株式会社クラスメソッド <a href="https://twitter.com/hbsnow">高橋 ゆうき様</a></p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/24088843-fe84-4dfe-b8ca-324c27cecf1e/%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%882023-07-0419.31.40.png" alt="スクリーンショット2023-07-0419.31.40.png"></p>
<h3>内容</h3>
<ul>
<li>巨大テーブルのパフォーマンス改善に立ち向かう</li>
<li>requestIdleCallbackにより、CPUに余裕があるときに順次表示するDeferコンポーネント</li>
<li>IntersectionObserverで最下部まで到達したら以降のコンテンツを読み込む</li>
<li>uiがブロックされるとき、useTransitionが使える</li>
</ul>
<p>サンプルサイトは<a href="https://hbsnow-sandbox.github.io/react-heavy-table/">こちら</a>！</p>
<h3>はけまるレポート</h3>
<p>requestIdleCallbackやIntersectionObserverは聞いたことはありましたが、実際に使ったことは初めてだったのでとても勉強になりました！<br>
「最初に思い浮かんだ方法が唯一の解決方法とは限らない」という考え方はプロダクト開発者としてとても大切にしていきたいです！</p>
<h2>2.「フロントエンド開発エクササイズ」」</h2>
<p>株式会社ゆめみ <a href="https://twitter.com/TakamasaSuzuki6">スー様</a></p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/787100aa-58ad-45a5-934c-83a78031b52d/%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%882023-07-0320.20.45.png" alt="スクリーンショット2023-07-0320.20.45.png"></p>
<h3>内容</h3>
<ul>
<li>より良いコードを書くためのガイドラインをエクササイズ形式で伝授</li>
<li>エクササイズ項目はこちら！
<ul>
<li>classNameプロパティ禁止</li>
<li>optionalプロパティ禁止</li>
<li>プロパティは最大3つ</li>
<li>exportするものは全体でユニークな名前にする</li>
<li>スナップショットテストの導入役割ごとにファイルを分ける</li>
</ul>
</li>
</ul>
<h3>はけまるレポート</h3>
<p>すーさんの話す「じゃあやめましょう」がとても聞き心地がよく、癖になりました！笑<br>
特にoptionalプロパティを使いすぎると条件分岐が増えてつらい思いをしたことがあるので、共感しました。すぐに実践できる内容も多く、今後の実装時に意識していきたいと思います！</p>
<h2>3.「改善活動に戦略と秩序を持たせる」</h2>
<p>株式会社SmartHR <a href="https://twitter.com/YtYmmt">山本 裕太様</a></p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/0a0def6b-94a0-4a5e-b07b-e83e546d8d59/%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%882023-07-0320.27.32.png" alt="スクリーンショット2023-07-0320.27.32.png"></p>
<h3>内容</h3>
<ul>
<li>フロントエンドエンジニアの横串チームにおける、改善活動の課題と、実際に行った施策のお話</li>
<li>大規模スクラム（LeSS）で開発する組織の中で、チーム外の活動に対し、いかにメンバーが戦略を理解し、活動を自分ごと化できるようにしていったかのアプローチを解説</li>
<li>「横串会」を改善するために実際にやったこと
<ul>
<li>目的の言語化</li>
<li>課題の発散から収束（洗い出し→現状理解→優先度づけ）</li>
<li>課題の可視化（zatsuバックログの作成）</li>
</ul>
</li>
</ul>
<h3>はけまるレポート</h3>
<p>サイドワーク的な側面と明確な行動目的、どちらも兼ね備えた「横串会」が、とても魅力的でした！<br>
サイドワーク的な側面が強すぎると、成果があまり出ないことが多く、やるからにはしっかり目的を持って行動することが大切だと再認識。<br>
フロントエンドやエンジニアはもちろん、様々な職種で使える考え方を学ぶことができ、とても有意義な内容でした！</p>
<h2>4.「HRBrainの生態系を支えるフロントエンドチームの取り組み」</h2>
<p>株式会社HRBrain <a href="https://twitter.com/yug1224">山口 祐司様</a></p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/0a26e2fb-ed4a-4638-b52e-5c26b7747eba/%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%882023-07-0419.33.36.png" alt="スクリーンショット2023-07-0419.33.36.png"></p>
<h3>内容</h3>
<ul>
<li>マルチプロダクト×フロントエンドの不を改善する
<ul>
<li>デザインシステムとUIコンポーネントライブラリ</li>
</ul>
</li>
<li>活躍人材の再現性を高めるための改善
<ul>
<li>フロントエンドオフィスアワー</li>
<li>コミュニケーションの可視化</li>
</ul>
</li>
</ul>
<h3>はけまるレポート</h3>
<p>メンバーが活躍できるようにするために様々なアプローチがあることを知り、視野が広がりました！特にコミュニケーション量の可視化でこんなことがわかるのかと、とても驚きました。笑<br>
フロントエンドオフィスアワーで実施されていたTypeChallenge、昔ひとりで挑戦して数問で挫折したので、弊社メンバーでもやってみたいな〜</p>
<h2>5.「頑張りすぎない、開発生産性を上げるフロントエンドテスト戦略」</h2>
<p>株式会社Another works <a href="https://twitter.com/MotohiroSiobara">塩原 基弘</a></p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/112a2445-bced-4540-afec-cfe516b2ba7b/IMG_9111585945BA-1.jpeg" alt="IMG_9111585945BA-1.jpeg"></p>
<h3>内容</h3>
<ul>
<li>開発生産性を向上させるという目的でテストを書くことで安定性と開発の効率化を促す直近の取り組みについて</li>
<li>テストは小さく始める（あれもこれも手を出さない）</li>
<li>取り組み事例
<ul>
<li>playwrightを利用したクロスブラウザQAを動画で行う</li>
<li>PR差分に対してのカバレッジレポートを導入</li>
<li>バグが発生したときにみんなで集まって、テストを書く</li>
</ul>
</li>
</ul>
<h3>はけまるレポート</h3>
<p>テストはあと回しにしがちなので、最初は小さくはじめ、重要かつ簡単な部分から始めることで導入がよりしやすくなるというのはとても共感しました！<br>
また、複数の主要ブラウザをすべてQAするのは難しいので動画を取ってくれるplaywriteはとても便利ですね〜<br>
今後はテストをうまく使って楽をしていきたいと思います！</p>
<h1>LT後交流会</h1>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/88bfb9a0-d20b-4569-aeab-438bf08a4a59/%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%882023-07-0419.54.39.png" alt="スクリーンショット2023-07-0419.54.39.png"></p>
<p>LT後は登壇者のメンバーで意見交流会を実施！<br>
横串会やテストについてなど各社の開発体制によって様々な意見があり、とても勉強になりました〜！</p>
<h1>おわりに</h1>
<p>Another worksでは7月, 8月と毎月イベントを開催していく予定です！<br>
 <strong>#AwEngineerMeetup</strong> のハッシュタグ付きでツイートで一緒に盛り上げいただけると嬉しいです！<br>
<a href="https://anotherworks.connpass.com/">Connpass</a>でグループメンバーになっていただけると開催通知が送られますので、以下より是非グループメンバー登録をよろしくお願いします！</p>


2023/06/22 Front-end Deep Dive Online イベントレポート

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

// ... 

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

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

const initialState = {
  todos: []
}

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

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


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

<p>こんにちは。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を導入した話

<h2>はじめに</h2>
<p>こんにちは。nonoyamalfoyです。<br>
弊社ではwebをnext.js, アプリをreact-nativeで開発しています。<br>
フロントエンドアーキテクチャので最近流行りのfeaturesアーキテクチャについての見解を述べようと思います。</p>
<h2>featuresとは</h2>
<p>超簡単にいうと、機能ごとにUIやロジックを隠蔽していくディレクトリ構造。</p>
<pre><code class="language-jsx">features
   ├── message（メッセージ機能）
   │    ├── hooks/
   │    ├── types/
   │    └──  ui
   │         ├── origin/
   │         └── pages/
   ├── profile/（プロフィール機能）
   └── signin/（サインイン機能）
</code></pre>
<h2>React公式の見解</h2>
<p>React は、ファイルをフォルダーに入れる方法について意見を持っていませんが、以下の２つを例として上げています。</p>
<ul>
<li>機能またはルートによるグループ化<br>
「機能」の定義は普遍的なものではなく、粒度を選択するのはユーザー次第とのこと。<br>
featuresなどはこちらに分類されます。</li>
</ul>
<pre><code class="language-ts">message/
    index.ts
    messageApi.ts
    message.tsx
    message.css
    message.story.tsx
    message.test.ts
profile/
    index.ts
    profileApi.ts
    profile.tsx
    profile.css
    profile.story.tsx
    profile.test.ts
</code></pre>
<ul>
<li>同様のファイルをグループ化<br>
Atomicデザインなどはこちらに分類される。</li>
</ul>
<pre><code class="language-ts">api/
    messageApi.ts
    profileApi.ts
components/
    profile.tsx
    profile.css
    profile.story.tsx
    profile.test.ts
    message.tsx
    message.css
    message.story.tsx
    message.test.ts
</code></pre>
<p><a href="https://reactjs.org/docs/faq-structure.html">File Structure - React</a></p>
<h2>複業クラウドの例</h2>
<h3>初期の頃の構成</h3>
<p>リリース初期は同様のファイルをグループ化する形をとっていました。</p>
<ul>
<li>componentsやhooksの肥大化が発生。</li>
<li>componentsディレクトリに切り分けたコンポーネントを入れていくので、抽象的な名前をつけてしまうと名前が被ることがあり後々後悔することになる。</li>
<li>該当のコンポーネントがどこにあるのか、どこで使われているのかがわかりにくい</li>
</ul>
<pre><code class="language-jsx">src
├── components（ドメインロジックのない汎用的なコンポーネント）
│      ├── atoms/（最小の粒度、TextAtom, IconAtomなど）
│      ├── molecules/（atomの集合体、基本的に複数箇所で利用される）
│      └── organisms/（atom,moleculesの集合体、複数箇所で利用されない場合もある）
├── windows
│      ├── components/（ドメインロジックのあるコンポーネント、ページの肥大化、コンポーネントの共通化を目的に切り分けたものを格納）
│      ├── member/
│      ├── public/
│      └── route/(ルーティング)
├── lib/
├── models/
├── modules/(サーバーとの接続)
└── hooks/
</code></pre>
<h3>2023年1月現在</h3>
<p>features内でhooksやuiを分けることで機能ごとの依存を防ぐようにしました。</p>
<pre><code class="language-jsx">src
├── features
│      ├── message（メッセージ機能）
│      │           ├── hooks/
│ 	  │           ├── types/
│      │           └──  ui
│      │                 ├── origin/
│      │                 └── pages/
│      ├── profile/（プロフィール機能）
│      └── signin/（サインイン機能）
├── ui
│    ├── origin
│    └── homeland
├── adapter/(サーバーとの接続,apiを叩いてデータを返す)
└── lib/(汎用的なロジック)
</code></pre>
<h2>featuresアーキテクチャの特徴</h2>
<ul>
<li>機能単位ごとに疎結合にできる（これが一番大きいメリットだと感じています。）
<ul>
<li>機能単位で改善することが多いので不要なデグレを避けることができる</li>
<li>機能削除する際にディレクトリごと消せばいい</li>
</ul>
</li>
<li>featuresディレクトリを見ると、プロダクトにどんな機能が存在するのかわかる</li>
<li>機能を意識した実装や見積もりを行うことができる
<ul>
<li>機能によってはUIから作成したい場合、ロジックから作成したい場合、型から実装したい場合などいろいろなケースがあるかと思います。</li>
</ul>
</li>
<li>コンポーネントの命名に迷うことが減る。</li>
<li>ドメインを意識した開発を行える。</li>
</ul>
<p>下記でもう少し詳しく解説します。</p>
<h2>機能単位ごとに疎結合にできる</h2>
<p>プロダクト開発は機能単位で改善、削除することが多いです。<br>
そのため、他のfeatures同士で依存しないよう意識すれば編集を入れても他の機能への影響が出にくくなります。<br>
また、機能削除する際にディレクトリごと消せばいいので楽になります。</p>
<h2>プロダクトにどんな機能が存在するのかすぐにわかる</h2>
<p>以下のようにfeaturesを見ればmessege, profile, signinの機能があることがすぐにわかります</p>
<pre><code class="language-jsx">features
   ├── message（メッセージ機能）
   │    ├── hooks/
   │    ├── types/
   │    └──  ui
   │         ├── origin/
   │         └── pages/
   ├── profile/（プロフィール機能）
   └── signin/（サインイン機能）
</code></pre>
<h2>ドメインを意識した開発がしやすい</h2>
<p>featuresアーキテクチャでは機能ごとにUIとロジックを隠蔽できるため、ロジックから作成する。型から作成する。といった機能に焦点を当てた開発がとてもしやすいメリットがあります。</p>
<h2>コンポーネントの命名に迷うことが減る。</h2>
<p>機能ごとにファイルを隠蔽できるため、別の機能とコンポーネント名がかぶっても問題がない。<br>
例えば機能やページごとに異なる「Header」が存在した場合、「~Header」みたいにする必要はなく「Header」という名前で実装できる。</p>
<h3>Tips</h3>
<p>feature同士の依存を強制的に防ぐために、eslintを利用できます。</p>
<pre><code class="language-json">rules: {
    'import/no-restricted-paths': [
      'error',
      {
        zones: [
	//profile feature以外でtargetのpathをインポートできないように
          {
            from: './src/features/!(profile)/**/*', // 対象の依存パス 
            target: './src/features/profile', // 禁止するパス
            message: 'features同士で依存することはできません',// エラーメッセージ
          },
	 //message feature以外でtargetのpathをインポートできないように
          {
            from: './src/features/!(message)/**/*', // 対象の依存パス
            target: './src/features/message', // 禁止するパス
            message: 'features同士で依存することはできません', // エラーメッセージ
          },
        ],
      },
    ],
  },
</code></pre>
<h2>最後に</h2>
<p>featuresアーキテクチャのメリットをいくつか紹介しましたが、機能の少ないプロダクトやリリース初期のプロダクトは「同様のファイルをグループ化」するほうがいいと思っています。<br>
機能が少ない場合はむしろfeaturesの肥大化が起きたり、どの粒度の機能で切るのか悩む時間が発生します。<br>
機能が増えてディレクトリが肥大化してきたタイミングでfeaturesアーキテクチャの導入を検討するのがいいと思います。</p>
<p>「弊社プロダクトの設計をもっと知りたい！」と思った方は以下を合わせてお読みいただけると幸いです。<br>
<a href="https://tech.anotherworks.co.jp/article/frontend-architecture-for-react">複業クラウドのフロントエンド設計</a></p>
<h2>参考文献</h2>
<p><a href="https://dev.to/profydev/screaming-architecture-evolution-of-a-react-folder-structure-4g25#discussion-of-the-featuredriven-folder-structure">Screaming Architecture - Evolution of a React folder structure</a></p>
<p><a href="https://zenn.dev/meijin/articles/bulletproof-react-is-best-architecture">Reactベストプラクティスの宝庫！「bulletproof-react」が勉強になりすぎる件</a></p>
<p><a href="https://zenn.dev/yodaka/articles/eca2d4bf552aeb">Next.jsディレクトリ構成・設計再考（featuresが何を解決するか）</a></p>
<p><a href="https://ja.reactjs.org/docs/faq-structure.html">ファイル構成 - React</a></p>


Articles by hakemaru

2023/06/22 Front-end Deep Dive Online イベントレポート

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

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

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

Reactのディレクトリ構成にfeaturesを導入してみた