Another works Developers Blog

<h2>■ はじめに</h2>
<p><code>&lt;div&gt;</code>などの<code>HTML</code>要素ごとに入れ子にしていいものと、入れ子にしてはいけないものがあることはご存知でしょうか？</p>
<p>最近ブラウザや<code>HTML</code>などの<code>Web標準に備わる技術</code>を学ぶなかで、<code>HTML</code>要素ごとの<code>入れ子ルール</code>がちゃんと定義されていることを知りました。</p>
<pre><code class="language-html:html">&lt;div&gt;ここに入れていいものと、入れてはダメなものがあるよ！&lt;/div&gt;
</code></pre>
<p>「じゃあ、そのルール破ったらどうなるねん」 という疑問からこの記事を書いています。</p>
<p>通常の<code>HTML</code>の例と私が普段利用している<code>Next.js</code>での例を用いて説明していきます。<br>
興味を持った方はぜひ最後まで読んでください。</p>
<h2>■ 入れ子ルールとは？</h2>
<p>この入れ子ルールのことを、<code>Content model</code>といいます。<br>
<code>HTML Standard</code>では<a href="https://html.spec.whatwg.org/multipage/dom.html#concept-element-content-model"><code>Content model</code></a>を</p>
<blockquote>
<p>A normative description of what content must be included as children and descendants of the element.<br>
要素の子や子孫としてどのような内容を含めなければならないかを規範的に記述したもの。</p>
</blockquote>
<p>と説明しています。</p>
<p>この<code>Content model</code>のルールは１つ１つの要素ごとに決められており、<code>HTML Standard</code>や<code>MDN</code>にも要素ごとのルールが記載されています。</p>
<p>そのルール付けは大きく</p>
<ul>
<li>コンテンツカテゴリーを基準にルール付けされている要素</li>
<li>複雑なルール付けがされている要素（コンテンツカテゴリーにくくられず）<br>
の２つに区分できそうです。</li>
</ul>
<p>※ コンテンツカテゴリーとは(MDNより)</p>
<blockquote>
<p>ほとんどの HTML 要素は 1 つ以上のコンテンツカテゴリーに属していて、カテゴリーごとに共通した特徴を持つ要素を分類しています。これは緩やかなグループ分けです（実際にはこれらのカテゴリーの要素間の関係を作成していません）。しかし、これらは、特にその複雑な詳細に遭遇したときに、カテゴリーの共有動作とその関連ルールを定義し記述するのに役立ちます。どのカテゴリーにも属さない要素も存在します。</p>
</blockquote>
<ul>
<li><a href="https://developer.mozilla.org/ja/docs/Web/HTML/Content_categories">MDN コンテンツカテゴリー</a></li>
<li><a href="https://html.spec.whatwg.org/multipage/dom.html#kinds-of-content">HTML Standard Kinds of content</a></li>
</ul>
<h3>◎ コンテンツカテゴリーを基準にルール付けされている要素</h3>
<p><code>HTML Standard</code>で<a href="https://html.spec.whatwg.org/multipage/sections.html#the-h1,-h2,-h3,-h4,-h5,-and-h6-elements"><code>&lt;h1~6&gt;</code>要素</a>の<code>Content model</code>を確認してみます。</p>
<p><code>&lt;h1~6&gt;</code>要素は非常にシンプルなルールとなっており、<a href="https://html.spec.whatwg.org/multipage/dom.html#content-categories"><code>７つのコンテンツカテゴリー</code></a>のうち<a href="https://html.spec.whatwg.org/multipage/dom.html#phrasing-content-2"><code>Phrasing content</code></a>のみを許容します。</p>
<p><img src="https://storage.googleapis.com/zenn-user-upload/e1eab097f490-20230708.png" alt=""></p>
<p>ただ、<code>&lt;h1~6&gt;</code>要素のように７つのコンテンツカテゴリーを基準にルール付けされているものは稀なようです。</p>
<h3>◎ 複雑にルール付けされている要素</h3>
<p><code>HTML Standard</code>で<a href="https://html.spec.whatwg.org/multipage/tables.html#the-table-element"><code>&lt;table&gt;</code>要素</a>の<code>Content model</code>を確認してみます。</p>
<p>なかなか複雑に書いてあるものの、<br>
<code>&lt;caption&gt;</code>, <code>&lt;colgroup&gt;</code>, <code>&lt;thead&gt;</code>,<code>&lt;tbody&gt;</code>, <code>&lt;tr&gt;</code>, <code>&lt;tfoot&gt;</code><br>
を入れ子にしていいようです。</p>
<blockquote>
<p>HTML Standard table<br>
<img src="https://storage.googleapis.com/zenn-user-upload/e723f61c3cd3-20230708.png" alt=""></p>
</blockquote>
<p><code>HTML Standard</code>よりは信憑性が落ちそうなものの、<code>MDN</code>でも確認できます。</p>
<blockquote>
<p><a href="https://developer.mozilla.org/ja/docs/Web/HTML/Element/table">MDN <code>&lt;table&gt;</code></a><br>
<img src="https://storage.googleapis.com/zenn-user-upload/50e37f077748-20230708.png" alt=""></p>
</blockquote>
<h2>■ 入れ子ルールをやぶるとどうなる？</h2>
<p>では、気になる<strong>入れ子ルールをやぶるとどうなる</strong>のでしょうか？</p>
<p>結論として、<strong>原則としてエラー補正はされずにそのままDOMツリーに追加される</strong>ようです。<br>
しかし、<strong>要素の種類によってはエラー補正がされてDOM構造が変換される</strong>ことがあります。</p>
<p>それでは、<br>
<strong>要素の種類によってはエラー補正がされてDOM構造が変換される</strong>ことを例を用いて解説していきます。</p>
<h3>◎ <code>&lt;table&gt;</code>要素で試してみる</h3>
<p>では、<code>&lt;table&gt;</code>内に<code>&lt;p&gt;</code>を入れてみます。<br>
先程確認したように<code>&lt;table&gt;</code>は<code>&lt;p&gt;</code>を入れ子に許容しません。</p>
<pre><code class="language-html:html">&lt;table&gt;
  &lt;tbody&gt;
     &lt;tr&gt;
      &lt;th&gt;見出しのセル&lt;/th&gt;
      &lt;td&gt;データのセル&lt;/td&gt;
    &lt;/tr&gt;
  &lt;/tbody&gt;
  &lt;!--    &lt;table&gt;タグの中に&lt;p&gt;タグはいれるのはルール違反だよ！--&gt;
  &lt;p&gt;Pテキストだよ&lt;/p&gt;
&lt;/table&gt;
</code></pre>
<blockquote>
<p>Google chrome で表示<br>
<img src="https://storage.googleapis.com/zenn-user-upload/57e7a52a7e7e-20230707.png" alt=""></p>
</blockquote>
<p>構文エラーとなり、このようにブラウザで解釈されて表示されていることがわかります。</p>
<pre><code class="language-html:html">&lt;p&gt;Pテキストだよ&lt;/p&gt;
&lt;table&gt;
  &lt;tbody&gt;
    &lt;tr&gt;
      &lt;th&gt;見出しのセル&lt;/th&gt;
      &lt;td&gt;データのセル&lt;/td&gt;
    &lt;/tr&gt;
  &lt;/tbody&gt;
&lt;/table&gt;
</code></pre>
<p><code>&lt;table&gt;</code>要素では、入れ子のルールをやぶると<br>
<strong>エラー補正がされてDOM構造が変換される</strong>ことが確認できました。</p>
<h3>◎ HTML 解釈の仕様ルール</h3>
<p>このように<code>DOM構造</code>が変換されるような<code>HTML</code>解釈の仕様ルールが定められているようです。<br>
<a href="https://html.spec.whatwg.org/multipage/parsing.html">https://html.spec.whatwg.org/multipage/parsing.html</a></p>
<p><code>&lt;table&gt;</code>要素の場合、不正な子孫要素が前に追い出される形になります。<br>
この、不正な子孫要素が前に追い出されるのは<a href="https://html.spec.whatwg.org/multipage/parsing.html#foster-parent"><code>foster parenting</code></a>というルールらしいです。</p>
<h2>■ Next.js で入れ子ルールをやぶるとどうなる？</h2>
<p>今度は<code>Next.js</code>で入れ子ルールをやぶってみます。<br>
先程の例と同じように<code>&lt;table&gt;</code>と<code>&lt;p&gt;</code>を例に試します。</p>
<pre><code class="language-json:package.json">// 動作確認実行環境
&quot;next&quot;: &quot;13.4.3&quot;,
&quot;react&quot;: &quot;18.2.0&quot;,
</code></pre>
<pre><code class="language-tsx:tsx">&lt;table&gt;
  &lt;tbody&gt;
     &lt;tr&gt;
      &lt;th&gt;見出しのセル&lt;/th&gt;
      &lt;td&gt;データのセル&lt;/td&gt;
    &lt;/tr&gt;
  &lt;/tbody&gt;
  {/* &lt;table&gt;タグの中に&lt;p&gt;タグはいれるのはルール違反だよ */}
  &lt;p&gt;Pテキストだよ&lt;/p&gt;
&lt;/table&gt;
</code></pre>
<p>すると<code>DOM構造</code>はマークアップしたものと変わらずに表示されるものの、エラーになりました。</p>
<p><img src="https://storage.googleapis.com/zenn-user-upload/a18731801bad-20230707.png" alt=""></p>
<pre><code class="language-bash:error">Unhandled Runtime Error
Error: Hydration failed because the initial UI does not match what was rendered on the server.
Warning: Expected server HTML to contain a matching &lt;p&gt; in &lt;table&gt;.

See more info here: https://nextjs.org/docs/messages/react-hydration-error
</code></pre>
<p><strong>エラー日本語訳</strong></p>
<blockquote>
<p>エラー：初期UIがサーバーでレンダリングされたものと一致しないため、Hydration に失敗しました。<br>
ワーニング：サーバーのHTMLは<code>&lt;table&gt;</code>内に<code>&lt;p&gt;</code>を含むことを期待しました。</p>
</blockquote>
<p>エラー文で案内されている、<a href="https://nextjs.org/docs/messages/react-hydration-error"><code>Next.js</code>のドキュメント</a>にも、エラー発生理由の説明として下記内容が記載されています。</p>
<blockquote>
<p>アプリケーションのレンダリング中に、事前レンダリングされた React ツリー (SSR/SSG) と、ブラウザーでの最初のレンダリング中にレンダリングされた React ツリーとの間に差異がありました。最初のレンダリングはReact の機能である Hydration と呼ばれます。</p>
</blockquote>
<p>これにより、React ツリーが DOM と同期しなくなり、予期しないコンテンツ属性が存在する可能性があります。</p>
<p><strong>ここから自己解釈</strong><br>
どうやら、<code>React</code>側ではマークアップのそのままを想定して <code>Hydration</code>しようとした。<br>
しかし、実際はブラウザで解釈された結果がそのマークアップと異なるため <code>Hydration</code>に失敗するようです。</p>
<p><strong>※Hydration, Hydrate とは</strong><br>
サーバー側で生成されたHTMLにJSの各ロジックを接続していくこと。<br>
つまり静的な状態のHTML要素にJSのイベントハンドラなど接続していき、動的ウェブページに変換していく処理のこと。<br>
クリックなどのイベントが発火されない静的な状態のUIをクリック可能な動的なUIにする処理。</p>
<p><code>SSR</code>や<code>Hydration</code>についても解説していますのでこちらの記事もよかったら読んでください。<br>
<a href="https://tech.anotherworks.co.jp/article/react-suspense-react18">今後の React ではどの範囲を Suspense で囲むかという設計が重要になってくる</a></p>
<h2>■ さいごに</h2>
<p>Web標準の技術を学ぶことの重要性を実感しているところです。<br>
深く学ぼうとするとやっぱり面白いです。</p>
<h4>参考資料</h4>
<ul>
<li><a href="https://html.spec.whatwg.org/multipage/">https://html.spec.whatwg.org/multipage/</a></li>
<li><a href="https://developer.mozilla.org/ja/docs/Web/HTML/Content_categories">https://developer.mozilla.org/ja/docs/Web/HTML/Content_categories</a></li>
<li><a href="https://zenn.dev/yusukehirao/articles/learn-new-html-elements">https://zenn.dev/yusukehirao/articles/learn-new-html-elements</a></li>
<li><a href="https://www.w3.org/TR/2011/WD-html5-20110113/parsing.htmlhttps://developer.mozilla.org/ja/docs/Web/HTML/Element/table">https://www.w3.org/TR/2011/WD-html5-20110113/parsing.htmlhttps://developer.mozilla.org/ja/docs/Web/HTML/Element/table</a></li>
<li><a href="https://webliker.info/html/46840/#toc_1">https://webliker.info/html/46840/#toc_1</a></li>
<li><a href="https://zenn.dev/onikun/articles/28fb8de056c89a">https://zenn.dev/onikun/articles/28fb8de056c89a</a></li>
<li><a href="https://nextjs.org/docs/messages/react-hydration-error">https://nextjs.org/docs/messages/react-hydration-error</a></li>
</ul>


【HTML】要素の入れ子ルールをやぶるとどうなるのか？

<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>複数の<code>DOM</code>要素を参照するために<code>useRef</code>を何回も利用したくなる場面がありました。<br>
そのときに、<code>ref callback function</code>というものを利用していい感じに実装できたので、その備忘録と知識の深掘りです。</p>
<p><a href="https://react.dev/reference/react-dom/components/common#ref-callback">https://react.dev/reference/react-dom/components/common#ref-callback</a></p>
<h3>◎ やりたかったこと</h3>
<p>やりたかったこととしては、<br>
件数が可変のリストのアイテム要素を指定して、その要素までスクロールして、フォーカスを当てるという動作です。</p>
<p>ヘッダーの数値ボタンをクリックしてその数値のアイテムまでスクロール+フォーカスさせる感じ<br>
<img src="https://storage.googleapis.com/zenn-user-upload/3d42b89f4b74-20230702.gif" alt=""><br>
この要件を満たすために、事前にリストの件数を知らない状態で実装しなければいけません。</p>
<p>今回はこちらの <code>React 公式</code>のサンプルコードを参考にしています。<br>
<a href="https://react.dev/learn/manipulating-the-dom-with-refs#how-to-manage-a-list-of-refs-using-a-ref-callback">https://react.dev/learn/manipulating-the-dom-with-refs#how-to-manage-a-list-of-refs-using-a-ref-callback</a></p>
<p>サンプルを実装しながら解説していきます。<br>
リポジトリはこちら（汚いコメントなども残ってますが、よろしければ見てみてください）<br>
<a href="https://github.com/TomoyukiMatsuda/React-pra/blob/master/otamesiproject/src/pages/multiple-use-ref-scroll/index.tsx">https://github.com/TomoyukiMatsuda/React-pra/blob/master/otamesiproject/src/pages/multiple-use-ref-scroll/index.tsx</a></p>
<h2>■ <code>ref callback function</code>とは？</h2>
<p>まず<code>ref callback function</code>とは<br>
<code>div</code>等要素の<code>ref属性</code>に<code>refオブジェクト</code>ではなく、関数を渡したときのものです。</p>
<pre><code class="language-tsx">&lt;div ref={(node: HTMLDivElement | null) =&gt; console.log(&quot;div ref callback node&quot;, node)} /&gt;
</code></pre>
<h3>◎ <code>ref callback function</code>が呼び出されるタイミングと渡される引数</h3>
<p><code>ref callback function</code>は呼び出されるタイミングにより、渡される引数が異なります。</p>
<p><a href="https://react.dev/reference/react-dom/components/common#ref-callback">React 公式</a>と実際の動作を確認した限り下記のようになるようです。</p>
<ul>
<li><strong>DOM要素が画面に表示されたとき<code>Node</code>を引数として呼び出し</strong></li>
<li><strong>DOM要素が画面から削除されたとき<code>null</code>を引数として呼び出し</strong></li>
<li><strong>再レンダリングされたとき（※<code>ref callback function</code>が異なる参照を持つ場合）</strong>
<ol>
<li>前の参照をもつ関数に対して<code>null</code>を引数として呼び出される</li>
<li>次の新しいの参照をもつ関数に対して<code>Node</code>を引数として呼び出される</li>
</ol>
</li>
</ul>
<p>※<code>div</code> を例にとると DOM要素=<code>div</code>要素, <code>Node</code>=<code>HTMLDivElement</code>と読み替えることができます</p>
<h4>◯再レンダリングされたときは<code>ref callback function</code>が異なる参照を持つ場合のみ呼び出される</h4>
<p>つまり、<br>
次の例だと再レンダリングのたびに<code>ref callback function</code>が呼び出されます。<br>
これは、再レンダリング時に毎回関数が生成されて異なる参照先を保持する関数を渡しているためです。</p>
<pre><code class="language-tsx">&lt;div ref={(node: HTMLDivElement | null) =&gt; console.log(&quot;div ref callback node&quot;, node)} /&gt;
</code></pre>
<p>再レンダリングのたびにコンソールが吐かれており、<br>
<strong>１回目</strong></p>
<blockquote>
<p>DOM要素が画面に表示されたとき<code>Node</code>を引数として呼び出し</p>
</blockquote>
<p><strong>2回目, 3回目</strong></p>
<blockquote>
<p><strong>再レンダリングされたとき（※<code>ref callback function</code>が異なる参照を持つ場合）</strong></p>
<ol>
<li>前の参照をもつ関数に対して<code>null</code>を引数として呼び出される</li>
<li>次の新しいの参照をもつ関数に対して<code>Node</code>を引数として呼び出される</li>
</ol>
</blockquote>
<p>のタイミングで呼び出されています。<br>
<img src="https://storage.googleapis.com/zenn-user-upload/1ef2d768ff1d-20230702.png" alt=""></p>
<p>次の例だと再レンダリング時には<code>ref callback function</code>呼び出されません。<br>
これは、関数をメモ化することにより、異なる参照先になることを防いでいるためです。</p>
<pre><code class="language-tsx">const refCallbackFn = useCallback(
    (node: HTMLDivElement | null) =&gt; console.log(&quot;div ref callback node&quot;, node),
    []
  );
  
// ...
&lt;div ref={refCallbackFn} /&gt;
</code></pre>
<p>再レンダリング時にはコンソールを吐かず、</p>
<blockquote>
<p>DOM要素が画面に表示されたとき<code>Node</code>を引数として呼び出し</p>
</blockquote>
<p>のタイミングだけで呼び出されています。<br>
<img src="https://storage.googleapis.com/zenn-user-upload/e1077791c8fb-20230702.png" alt=""></p>
<h2>■ 実装していく</h2>
<h3>◎ リストアイテム要素を参照するための<code>RefObject</code> を作成</h3>
<p>まずは、リストアイテム要素を参照するための<code>RefObject</code>を定義します。<br>
ここの<code>key</code>にリストアイテムのIDが入り、対象の<code>HTMLLIElement</code>を<code>value</code>に持ちます。</p>
<pre><code class="language-tsx">const listItemRefs = useRef&lt;{
    [key in number]: HTMLLIElement;
  }&gt;({});
</code></pre>
<p>こんな形で持たせる。</p>
<pre><code class="language-tsx">console.log(&quot;listItemRefs&quot;, listItemRefs.current);
</code></pre>
<p><img src="https://storage.googleapis.com/zenn-user-upload/6ee6160b5103-20230702.png" alt=""></p>
<h3>◎ リストアイテム要素を取得して ref にセットする</h3>
<p><code>ref callback function</code>に渡す関数を作成して、配列の要素に値の１つとしてもたせます。<br>
この関数で対象のリストアイテム要素の<code>Node</code>を受け取り、セットしていきます。</p>
<p><code>node</code>が<code>null</code>で取得される場合に<code>delete listItemRefs.current[id];</code>としているのは、<br>
参照不要になった値を<code>listItemRefs</code>(<code>RefObject</code>)に保持するのを防ぐためにおこなう処理です。</p>
<pre><code class="language-tsx">/**
 * refCallbackFunction を持つ形に配列を整形
 * useMemo でメモ化しつつ、refCallbackFunction を配列要素の値として持たせることで
 * 関数の参照先が意図せず変更されることを防いでいる
 */
const convertedList = useMemo(
  () =&gt;
    list.map((v) =&gt; ({
      id: v.id,
      refCallbackFunction: (node: HTMLLIElement | null) =&gt; {
        if (node !== null &amp;&amp; listItemRefs.current[v.id] === undefined) {
          // node が null でなく、かつ、ref が未登録の場合
          listItemRefs.current[v.id] = node;
        } else {
          // node が null の場合は、対象の node を管理する必要がなくなるため削除
          delete listItemRefs.current[v.id];
        }
      },
    })),
  [list]
);
</code></pre>
<p><code>Node</code>を取得するために配列に持たせた関数を<code>ref</code>にコールバック関数として渡します。</p>
<pre><code class="language-tsx">{convertedList?.map((v) =&gt; (
  &lt;li key={v.id} ref={v.refCallbackFunction} tabIndex={0}&gt;
    {v.id}
  &lt;/li&gt;
))}
</code></pre>
<h3>◎ ボタンをクリックしたときに対象のリストアイテム要素を参照して、イベントを発火する</h3>
<p>クリックしたときに、<code>id</code>から<code>listItemRefs</code>(<code>RefObject</code>)の値である<code>HTMLLIElement</code>が取得できるので、その<code>HTMLLIElement</code>に対して<br>
実行したい処理であるスクロールイベントとフォーカスイベントを発火させます。</p>
<pre><code class="language-tsx">const handleClickHeaderItem = useCallback((id: number) =&gt; {
  // id から 対象の ref を取得
  const itemRef = listItemRefs.current[id];
  itemRef?.scrollIntoView({
    behavior: &quot;smooth&quot;,
    block: &quot;center&quot;,
  });
  itemRef?.focus();
}, []);
</code></pre>
<p><code>handleClickHeaderItem</code>をヘッダーのボタンにセットする</p>
<pre><code class="language-tsx">{/* ヘッダー */}
&lt;header&gt;
 {list?.map((v) =&gt; (
    &lt;button key={v.id} onClick={() =&gt; handleClickHeaderItem(v.id)}&gt;
      {v.id}
    &lt;/button&gt;
  ))}
&lt;/header&gt;
</code></pre>
<h4>コードの全体像</h4>
<pre><code class="language-tsx">function Component({ list }: { list: { id: number }[] }) {
  // Mapped Types で型定義した RefObject を作成
  const listItemRefs = useRef&lt;{
    [key in number]: HTMLLIElement;
  }&gt;({});

  /**
   * refCallbackFunction を持つ形に配列を整形
   * useMemo でメモ化しつつ、refCallbackFunction を配列要素の値として持たせることで
   * 関数の参照先が意図せず変更されることを防いでいる
   */
  const convertedList = useMemo(
    () =&gt;
      list.map((v) =&gt; ({
        id: v.id,
        refCallbackFunction: (node: HTMLLIElement | null) =&gt; {
          if (node !== null &amp;&amp; listItemRefs.current[v.id] === undefined) {
            // node が null でなく、かつ、ref が未登録の場合
            listItemRefs.current[v.id] = node;
          } else {
            // node が null の場合は、対象の node を管理する必要がなくなるため削除
            delete listItemRefs.current[v.id];
          }
        },
      })),
    [list]
  );

  const handleClickHeaderItem = useCallback((id: number) =&gt; {
    // id から 対象の ref を取得
    const itemRef = listItemRefs.current[id];
    itemRef?.scrollIntoView({
      behavior: &quot;smooth&quot;,
      block: &quot;center&quot;,
    });
    itemRef?.focus();
  }, []);

  return (
    &lt;div&gt;
      {/* ヘッダー */}
      &lt;header&gt;
        {list?.map((v) =&gt; (
          &lt;button key={v.id} onClick={() =&gt; handleClickHeaderItem(v.id)}&gt;
            {v.id}
          &lt;/button&gt;
        ))}
      &lt;/header&gt;

      {/* リスト */}
      &lt;ul&gt;
        {convertedList?.map((v) =&gt; (
          &lt;li key={v.id} ref={v.refCallbackFunction} tabIndex={0}&gt;
            {v.id}
          &lt;/li&gt;
        ))}
      &lt;/ul&gt;
    &lt;/div&gt;
  );
}
</code></pre>
<h2>■ アンチパターン（よろしくない実装）</h2>
<h3>◎ ループ処理内で<code>useRef</code>をおこなうパターン</h3>
<p>リストをもとに<code>map</code>のなかで<code>useRef</code>を実行したくなります。<br>
しかし、当然ながら<code>React hooks</code>のルールに反するので怒られます。</p>
<pre><code class="language-tsx">const convertedList = list.map((item) =&gt; ({
    id: item.id,
    ref: useRef(null),
  }));
</code></pre>
<pre><code class="language-txt">React Hook &quot;useRef&quot; cannot be called inside a callback.
React Hooks must be called in a React function component or a custom React Hook function.
(react-hooks/rules-of-hooks)
</code></pre>
<p><a href="https://react.dev/warnings/invalid-hook-call-warning">https://react.dev/warnings/invalid-hook-call-warning</a></p>
<p><code>createRef</code>という関数を利用してもできそうではあるものの、<code>createRef</code>はクラスコンポーネントでの利用を前提としており、関数コンポーネントでの利用はよくなさそうです。</p>
<pre><code class="language-tsx">// 関数コンポーネントでの利用はよくない
const convertedList = list.map((item) =&gt; ({
    id: item.id,
    ref: createRef&lt;HTMLLIElement&gt;(),
  }));
</code></pre>
<p><a href="https://react.dev/reference/react/createRef">https://react.dev/reference/react/createRef</a></p>
<h3>◎ 親要素から子要素を参照するパターン</h3>
<p>次に親要素への 1 つの ref を取得して、子要素を参照するやり方が考えられます。<br>
しかし、この方法ではDOM構造が変更されると正常に動作しない可能性があり、推奨されていません。</p>
<pre><code class="language-tsx">const ulRef = useRef&lt;HTMLUListElement&gt;(null);
const handleClickHeaderItem = useCallback((id: number) =&gt; {
  // 親要素から子要素をidで取得する
  const itemRef: HTMLLIElement | null | undefined =
    ulRef.current?.querySelector(&quot;#id&quot; + id.toString());
  itemRef?.scrollIntoView({
    behavior: &quot;smooth&quot;,
    block: &quot;center&quot;,
  });
  itemRef?.focus();
}, []);

// ...
&lt;Ul ref={ulRef}&gt;
  {list?.map((v) =&gt;
    hideItemIds.includes(v.id) ? null : (
      &lt;Li
        key={v.id}
	id={&quot;id&quot; + v.id.toString()} // id を付与
	...
</code></pre>
<h2>■ さいごに</h2>
<p>最後までお読みいただきありがとうございました！</p>
<h4>参考</h4>
<ul>
<li><a href="https://react.dev/learn/manipulating-the-dom-with-refs#how-to-manage-a-list-of-refs-using-a-ref-callback">https://react.dev/learn/manipulating-the-dom-with-refs#how-to-manage-a-list-of-refs-using-a-ref-callback</a></li>
<li><a href="https://react.dev/reference/react/createRef">https://react.dev/reference/react/createRef</a></li>
<li><a href="https://react.dev/warnings/invalid-hook-call-warning">https://react.dev/warnings/invalid-hook-call-warning</a></li>
</ul>


【React】複数 useRef を使いたくなったときは ref callback function を使おう

<p>こんにちは、Another worksのCTO、塩原です。</p>
<p>最近、Another worksではフロントエンドのテスト作成を始める動きがあり、私たちも徐々にテストを書き始めています。<br>
LT会も毎月開催する中で、せっかくなのでそこで話した内容の一部を記事にして公開することにしました。</p>
<h1>今回の目的</h1>
<p>まだテストがほとんど書かれていない状況ですので、まずは「テストを書く」こと自体を習慣化したいと考えています。その一環として、カバレッジレポートが作成できると、テストが増えていく過程を可視化するための一つの指標となり、レビュワーがどれだけテストを網羅して書けているかの確認にも活用できると思います。</p>
<p>ただし、全体のカバレッジレポートだけでは、まだテスト自体をほとんど書いていない現状では、PRを作成する際に新たに書かれたテストを可視化するのが難しいと感じています。そこで、提出するPRの差分がどれだけテストを含んでいるかを可視化するため、新たな取り組みを始めました。</p>
<h1>使用技術</h1>
<ul>
<li>jest &quot;^29.5.0&quot;</li>
<li>@testing-library/react &quot;^14.0.0&quot;</li>
</ul>
<h1>やらなければならないこと</h1>
<p>やらなければならないことは主に二つです。</p>
<ul>
<li>特定のファイルに対するカバレッジレポートを出力すること</li>
<li>生成したカバレッジレポートをPRのコメントとして投稿すること</li>
</ul>
<h1>特定のファイルに対するカバレッジレポートの出力</h1>
<p>まず、jestのカバレッジレポートで特定のファイルに対して出力する方法ですが、以下の公式ドキュメントに方法が記載されています。<br>
https://jestjs.io/ja/docs/cli#--collectcoveragefromglob</p>
<pre><code>$ jest &quot;--coverage&quot; &quot;--collectCoverageFrom=${file_path1}|${file_path2}&quot;
</code></pre>
<p>&quot;|&quot;で区切ることで、複数のファイルに対するカバレッジレポートを一度に出力することが可能です。</p>
<h1>GitHubのPR差分に対して実行する</h1>
<p>GitHubのPR差分を取得するためには、<code>git diff</code>を使用します。ファイルは先ほどのglobパターンに適応するために&quot;|&quot;で区切る必要があります。また、当社ではモノレポを採用しているため、&quot;fc_client_web&quot;というプロジェクトのディレクトリ名を削除しています。</p>
<pre><code>- name: coverage-report
        id: coverage-report
        run: |
          change_files=($(git diff --name-only origin/${GITHUB_BASE_REF}...origin/${GITHUB_HEAD_REF} | grep -E '^fc_client_web/src/.*\.ts(x)?$'))
          for i in &quot;${!change_files[@]}&quot;; do
            change_files[$i]=${change_files[$i]//fc_client_web\//}
          done
          IFS=&quot;|&quot;;files=&quot;${change_files[*]}&quot;;unset IFS;
          npm run unit -- --coverage --collectCoverageFrom=$files --coverageReporters=json-summary
</code></pre>
<h1>生成したカバレッジレポートをPRのコメントとして投稿すること</h1>
<p>カバレッジレポートの生成までは上記で行うことができました。<br>
最後にPRコメントに投稿する方法ですが、<br>
<code>--coverageReporters=json-summary</code> こちらのオプションを付与することで、json形式でレポートの結果を吐き出してくれるのでそのjsonをmarkdownに加工してPRコメントに投稿することができます</p>
<pre><code>- name: Post jest coverage comments
        uses: actions/github-script@v6
        env:
          GH_TOKEN: ${{ github.token }}
          COMMENT: ${{ steps.coverage-report.outputs.GITHUB_ENV }}
        with:
          script: |
            const fs = require('fs')
            const data = JSON.parse(fs.readFileSync('./fc_client_web/coverage/coverage-summary.json', 'utf8'))
            let mdTable = &quot;| File Path | Lines % | Functions % | Statements % | Branches % |\n| --- | --- | --- | --- | --- |\n&quot;;

            for (const path in data) {
                const coverage = data[path];
                mdTable += `| ${path.replace('/home/runner/work/FC_Cloud/FC_Cloud/fc_client_web/', '')} | ${coverage.lines?.pct || 0} | ${coverage.functions?.pct || 0} | ${coverage.statements?.pct || 0} | ${coverage.branches?.pct || 0} |\n`;
            }
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: mdTable
            })
</code></pre>
<p>結果としてはこのようにPRコメントに差分のあるファイルだけがカバレッジレポートとして表示されます。</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/52e7bf7f-c3dc-4d7d-a7e1-899244ec1afd/%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-06-2613.27.48.png" alt="スクリーンショット2023-06-2613.27.48.png"></p>
<h1>まとめ</h1>
<p>カバレッジレポートはあくまでも数値指標の一つでしかないですが、<br>
テストを書く際のモチベーションとしても機能すればと思いこの仕組みを取り入れてみました。<br>
テストについてはまたどこかで記事にできればと思います。</p>


Github PRの差分ファイルに対してだけカバレッジレポートを自動で出力してみる

<h1>■ はじめに</h1>
<p><code>&lt;div&gt;</code>要素に<code>onClick</code>を定義しない方がいい、ということを聞いたことがあります。<br>
みなさんも聞いたことがあるのではないでしょうか？</p>
<p>ただ、なぜ「定義しない方がいい」のか？<br>
理解してなかったので今回調べてみました。</p>
<p>※Aw のリポジトリにも<code>&lt;div&gt;</code>要素に<code>onClick</code>結構あります。</p>
<h4>サンプルコード</h4>
<p>今回動作確認に利用した<a href="https://github.com/TomoyukiMatsuda/React-pra/blob/master/otamesiproject/src/pages/intaractive_content/index.tsx">サンプルリポジトリ</a><br>
コードは<code>React</code>で書いています。</p>
<h1>■ 結論：<code>&lt;div&gt;</code>に<code>onClick</code>を定義するのがなぜダメなのか？</h1>
<p><strong>ユーザーにとって操作性の低いボタンになってしまうから</strong>、です！<br>
要するに UX が悪くなってしまうから！</p>
<p>その理由を解説していきます！</p>
<h1>■ 操作性の低いボタンになってしまう理由</h1>
<p>大きく３つあると考えています。</p>
<p><code>div</code>要素は</p>
<ul>
<li><code>focus</code> を持たないから</li>
<li><code>returnキー</code>, <code>spaceキー</code>を<code>onClick</code>に変換しないから</li>
<li>スクリーンリーダーが認識しない要素だから</li>
</ul>
<h2>◎ focus を持たないから</h2>
<p><code>&lt;div&gt;</code>要素は<code>focus</code>を持ちません。<br>
なので、<code>tabキー</code>で要素にフォーカスを当てようとしても当たりません。</p>
<ul>
<li><code>div</code>: フォーカスが当たらない</li>
<li><code>button</code>: フォーカスが当たる</li>
</ul>
<h4>例</h4>
<pre><code class="language-css"># div, button 両方に focus 時 border style を付与
:focus {
  border: 2px solid blue;
}
</code></pre>
<p><img src="https://storage.googleapis.com/zenn-user-upload/9d34a9b9eeba-20230618.png" alt=""></p>
<h4>divに フォーカスを当てるためには tabindex を付与する</h4>
<p><code>div</code>要素にフォーカスを当てるためには<a href="https://developer.mozilla.org/ja/docs/Web/API/HTMLElement/tabIndex"><code>tabindex</code></a> 属性を付与する必要があります。</p>
<pre><code class="language-tsx">&lt;div tabIndex={1}&gt;
  div
&lt;/div&gt;
</code></pre>
<p>こうすれば<code>div</code>にフォーカスを当てることができます。<br>
<img src="https://storage.googleapis.com/zenn-user-upload/17485659e8f6-20230618.png" alt=""></p>
<h2>◎ returnキー, spaceキー を onClick に変換しないから</h2>
<p>フォーカスできるようにしても、<br>
<code>div</code>要素は<code>returnキー</code>、 <code>spaceキー</code> イベントを<code>onClick</code>に変換してくれません。</p>
<ul>
<li><code>div</code>: <code>returnキー</code>、 <code>spaceキー</code> イベントを<code>onClick</code>に変換しない</li>
<li><code>button</code>: <code>returnキー</code>、 <code>spaceキー</code> イベントを<code>onClick</code>に変換する</li>
</ul>
<h4>例</h4>
<p>アラートダイアログを表示する関数を定義します。</p>
<pre><code class="language-tsx">const handleClick = (element: string) =&gt; {
   window.alert(element + &quot;からクリック&quot;);
};
</code></pre>
<p><code>onClick</code>に関数を渡します。</p>
<pre><code class="language-tsx">&lt;div tabIndex={1} onClick={() =&gt; handleClick(&quot;div&quot;)}&gt;
  div
&lt;/div&gt;
&lt;button onClick={() =&gt; handleClick(&quot;button&quot;)}&gt;
  button
&lt;/button&gt;
</code></pre>
<p><code>button</code>にフォーカスが当たった状態で<code>returnキー</code>、 <code>spaceキー</code>どちらかを押すと<code>onClick</code>イベントが発火します。<br>
<code>div</code>の場合は<code>returnキー</code>、 <code>spaceキー</code>を押しても<code>onClick</code>が発火しないので、アラートダイアログは表示されません。</p>
<p><img src="https://storage.googleapis.com/zenn-user-upload/84e23d472095-20230618.png" alt=""></p>
<h4>div でreturnキー, spaceキー で onClick を発火させるためには onKeyDown などを利用する</h4>
<p><code>onKeyDown</code>などを利用して頑張って実装する形になります。</p>
<pre><code class="language-tsx">&lt;div
  tabIndex={1}
  onClick={() =&gt; handleClick(&quot;div&quot;)}
  onKeyDown={(e) =&gt; {
    if (e.key === &quot;Enter&quot; || e.key === &quot; &quot;) {
      // Enter or Space で実行
      handleClick(&quot;div&quot;);
    }
  }}
&gt;
  div
&lt;/div&gt;
</code></pre>
<p><img src="https://storage.googleapis.com/zenn-user-upload/e84061fad7e5-20230618.png" alt=""></p>
<h2>◎ スクリーンリーダーが認識しない要素だから</h2>
<p>スクリーンリーダーとは、「コンピューターの画面読み上げソフト」のことです。<br>
視覚障害を持つ方などがPCを操作する際の手助けをします。</p>
<p>しかし、スクリーンリーダーなどの支援ツールは<code>div</code>要素をクリック可能な要素として認識しません。</p>
<p><code>div</code>要素だと要素の役割が明確ではありません。そのため、<code>div</code>要素がクリック可能要素であったとしても、<br>
スクリーンリーダーを利用して該当の<code>div</code>要素を見つけてクリックすることが困難になります。</p>
<ul>
<li><code>div</code>: スクリーンリーダーはクリック可能な要素として認識しない</li>
<li><code>button</code>: スクリーンリーダーはクリック可能な要素として認識する</li>
</ul>
<h4>div をスクリーンリーダーが認識する要素にするには role を付与する</h4>
<p><a href="https://developer.mozilla.org/ja/docs/Web/Accessibility/ARIA/Roles"><code>role</code></a>を付与することでスクリーンリーダーにクリック可能要素であることを認識させることができます。</p>
<pre><code class="language-tsx">&lt;div
  role=&quot;button&quot;
  tabIndex={1}
  onClick={() =&gt; handleClick(&quot;div&quot;)}
  onKeyDown={(e) =&gt; {
    if (e.key === &quot;Enter&quot; || e.key === &quot; &quot;) {
      // Enter or Space で実行
      handleClick(&quot;div&quot;);
    }
  }}
&gt;
  div
&lt;/div&gt;
</code></pre>
<h4>アクセシビリティ、スクリーンローダー参考資料</h4>
<ul>
<li><a href="https://developer.mozilla.org/ja/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#%E7%94%BB%E9%9D%A2%E3%83%AA%E3%83%BC%E3%83%80%E3%83%BC">https://developer.mozilla.org/ja/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#%E7%94%BB%E9%9D%A2%E3%83%AA%E3%83%BC%E3%83%80%E3%83%BC</a></li>
<li><a href="https://developer.mozilla.org/ja/docs/Learn/Accessibility/HTML">https://developer.mozilla.org/ja/docs/Learn/Accessibility/HTML</a></li>
<li><a href="https://www.casleydi.com/blog/engineer/6692/">https://www.casleydi.com/blog/engineer/6692/</a></li>
</ul>
<h2>◎<code>&lt;div&gt;</code>に<code>&lt;button&gt;</code>と同じ振る舞いをさせるには</h2>
<p>つまり、<code>&lt;div&gt;</code>要素を<code>&lt;button&gt;</code>要素と同じ振る舞いをさせるためには、<br>
<code>tabindex</code>と<code>role</code>を付与して、<br>
<code>onKeyDown</code>などを利用してけっこう頑張って実装しないといけないわけです。</p>
<pre><code class="language-tsx">&lt;div
  role=&quot;button&quot;
  tabIndex={1}
  onClick={() =&gt; handleClick(&quot;div&quot;)}
  onKeyDown={(e) =&gt; {
    if (e.key === &quot;Enter&quot; || e.key === &quot; &quot;) {
      // Enter or Space で実行
      handleClick(&quot;div&quot;);
    }
  }}
&gt;
  div
&lt;/div&gt;
</code></pre>
<h1>■ HTML の対話型コンテンツと非対話型コンテンツ</h1>
<p>今回、<code>&lt;div&gt;</code>要素に<code>onClick</code>を定義した場合を例に紹介してきました。<br>
しかし実は<br>
<strong><code>&lt;div&gt;</code>要素に限った話ではなく他にも<code>onClick</code>を付与するなどユーザー操作イベントを定義するべきではない要素は多くあります</strong>。<br>
それを説明していきます。</p>
<p><code>HTML</code> には<strong>コンテンツカテゴリー</strong>という概念があり、カテゴリーごとに共通した特徴を持つ要素を分類しているようです。</p>
<p><img src="https://storage.googleapis.com/zenn-user-upload/5f59bf1c4297-20230620.png" alt=""></p>
<p>そのカテゴリーの１つが<a href="https://developer.mozilla.org/ja/docs/Web/HTML/Content_categories#%E5%AF%BE%E8%A9%B1%E5%9E%8B%E3%82%B3%E3%83%B3%E3%83%86%E3%83%B3%E3%83%84">対話型コンテンツ</a>です。</p>
<p>MDNには対話型コンテンツの説明として</p>
<blockquote>
<p>対話型コンテンツ (interactive content) にはユーザとのやり取りのために固有にデザインされた要素が含まれます。</p>
</blockquote>
<p>と記述されています。</p>
<p>つまり下記のように考えられます。</p>
<ul>
<li>対話型コンテンツ: ユーザーの操作を前提としている要素</li>
<li>非対話型コンテンツ： ユーザーの操作を前提としない要素</li>
</ul>
<h2>◎デフォルトで対話型コンテンツに属する要素</h2>
<ul>
<li><code>&lt;a&gt;</code></li>
<li><code>&lt;button&gt;</code></li>
<li><code>&lt;details&gt;</code></li>
<li><code>&lt;embed&gt;</code></li>
<li><code>&lt;iframe&gt;</code></li>
<li><code>&lt;keygen&gt;</code> 非推奨</li>
<li><code>&lt;label&gt;</code></li>
<li><code>&lt;select&gt;</code></li>
<li><code>&lt;textarea&gt;</code></li>
</ul>
<h2>◎特定の条件下にある場合のみ対話型コンテンツに属する要素</h2>
<ul>
<li><code>&lt;audio&gt;</code>: controls 属性がある場合</li>
<li><code>&lt;img&gt;</code>: usemap 属性がある場合</li>
<li><code>&lt;input&gt;</code>: type 属性が hidden 状態ではない場合</li>
<li><code>&lt;menu&gt;</code>: type 属性が toolbar 状態ではない場合</li>
<li><code>&lt;object&gt;</code>: usemap 属性がある場合</li>
<li><code>&lt;video&gt;</code>: controls 属性がある場合</li>
</ul>
<h2>◎対話型コンテンツ以外が非対話型コンテンツ</h2>
<p>対話型コンテンツ以外が非対話型コンテンツに該当します。<br>
つまり、今回説明してきた<code>&lt;div&gt;</code>のような挙動をする要素ということです。</p>
<p>そのため、<code>&lt;div&gt;</code>に限った話ではなく<br>
<strong>ユーザーの操作が可能である要素は、可能な限り対話型コンテンツを使って実装するベき</strong>といえます。</p>
<h3>ESLint の no-noninteractive-element-interactions</h3>
<p>ちなみに、ESLint にも非対話型コンテンツに不適切な役割を与えた場合に警告するものがあります。</p>
<p>https://github.com/jsx-eslint/eslint-plugin-jsx-a11y/blob/main/docs/rules/no-noninteractive-element-interactions.md#jsx-a11yno-noninteractive-element-interactions</p>
<pre><code class="language-tsx">// &lt;div&gt;要素にonClickを追加すると怒られる
&lt;div onClick={handleClick}&gt;...&lt;/div&gt;

ESLint: Avoid non-native interactive elements. 
If using native HTML is not possible, add an appropriate role and support for tabbing, mouse, keyboard, and touch inputs to an interactive content element.(jsx-a11y/no-static-element-interactions)
</code></pre>
<blockquote>
<p>和訳<br>
ネイティブでないインタラクティブな要素は避ける。<br>
ネイティブのHTMLを使用することが不可能な場合、インタラクティブなコンテンツ要素に適切な役割とタブ、マウス、キーボード、タッチ入力のサポートを追加する</p>
</blockquote>
<h1>■ おまけ： 動画サービスを調べてみた</h1>
<p>そういえば、動画サービスでよく<code>returnキー</code>や<code>spaceキー</code>を押して動画の再生と停止を切り替えていたことを思い出しました。</p>
<p>あれはきっと対話型コンテンツで実装されているに違いないと思い、<br>
Chrome DevTools で<br>
<a href="https://www.youtube.com/">Youtube</a>と<a href="https://www.udemy.com/">Udemy</a>の要素を調べてみました。</p>
<p><img src="https://storage.googleapis.com/zenn-user-upload/11e3761fb3b4-20230618.png" alt=""></p>
<p>すると、Youtube も Udemy も動画の部分は<code>&lt;video&gt;</code>要素だったものの、<code>controls属性</code>が付与されておらず（<code>false</code>)でした。</p>
<blockquote>
<p><a href="https://developer.mozilla.org/ja/docs/Web/HTML/Element/video"><code>&lt;video&gt;</code></a>: controls 属性がある場合に対話型コンテンツとなる</p>
</blockquote>
<p>対話型コンテンツじゃないやん！、</p>
<h3>追記： どうやらブラウザの標準の動画コントロールを非表示にして、独自に実装しているようでした</h3>
<p>試しに Youtube で Chrome DevTools から <code>controls属性</code>を付与（<code>true</code>）にしてみました。<br>
すると、「ブラウザの標準の動画コントロール」と「Youtube が独自に実装しているであろう動画コントロール」両方が表示されました。</p>
<p>※ 動画コントロール：再生、停止や音量調節をする部分<br>
<img src="https://storage.googleapis.com/zenn-user-upload/b66c556b4a4d-20230623.png" alt=""></p>
<p>おそらく、デザイン性や細かい動作を調整することが理由だと考えられます。</p>
<h1>■ さいごに</h1>
<p><strong>ユーザーの操作が可能である要素は、可能な限り対話型コンテンツを使って</strong>実装していきましょう！！<br>
そして、ユーザーにやさしいサービスをつくっていきましょう！</p>
<p>最後までお読みいただきありがとうございました！</p>
<h3>参考にさせていただいたもの</h3>
<p>対話型コンテンツ</p>
<ul>
<li><a href="https://developer.mozilla.org/ja/docs/Web/HTML/Content_categories#%E5%AF%BE%E8%A9%B1%E5%9E%8B%E3%82%B3%E3%83%B3%E3%83%86%E3%83%B3%E3%83%84">https://developer.mozilla.org/ja/docs/Web/HTML/Content_categories#%E5%AF%BE%E8%A9%B1%E5%9E%8B%E3%82%B3%E3%83%B3%E3%83%86%E3%83%B3%E3%83%84</a></li>
<li><a href="https://www.dkrk-blog.net/html/img_click_dame_zettai">https://www.dkrk-blog.net/html/img_click_dame_zettai</a></li>
<li><a href="https://catnose.me/learning/tags/%E5%AF%BE%E8%A9%B1%E5%9E%8B%E3%82%B3%E3%83%B3%E3%83%86%E3%83%B3%E3%83%84">https://catnose.me/learning/tags/%E5%AF%BE%E8%A9%B1%E5%9E%8B%E3%82%B3%E3%83%B3%E3%83%86%E3%83%B3%E3%83%84</a>-  <a href="https://catnose.me/learning/tags/%E5%AF%BE%E8%A9%B1%E5%9E%8B%E3%82%B3%E3%83%B3%E3%83%86%E3%83%B3%E3%83%84">https://catnose.me/learning/tags/%E5%AF%BE%E8%A9%B1%E5%9E%8B%E3%82%B3%E3%83%B3%E3%83%86%E3%83%B3%E3%83%84</a></li>
<li><a href="https://web.havincoffee.com/html/html5/com_b_interactive.html">https://web.havincoffee.com/html/html5/com_b_interactive.html</a></li>
<li><a href="https://triple-underscore.github.io/HTML-interactive-elements-ja.html#the-dialog-element">https://triple-underscore.github.io/HTML-interactive-elements-ja.html#the-dialog-element</a></li>
<li><a href="https://datacadamia.com/ui/action">https://datacadamia.com/ui/action</a></li>
<li><a href="https://coliss.com/articles/build-websites/operation/work/need-to-know-about-buttons.html">https://coliss.com/articles/build-websites/operation/work/need-to-know-about-buttons.html</a></li>
<li><a href="https://developer.mozilla.org/ja/docs/Learn/Accessibility/HTML">https://developer.mozilla.org/ja/docs/Learn/Accessibility/HTML</a></li>
</ul>
<p>アクセシビリティ、スクリーンローダー</p>
<ul>
<li><a href="https://www.casleydi.com/blog/engineer/6692/">https://www.casleydi.com/blog/engineer/6692/</a></li>
<li><a href="https://developer.mozilla.org/ja/docs/Learn/Accessibility/HTML">https://developer.mozilla.org/ja/docs/Learn/Accessibility/HTML</a></li>
<li></li>
</ul>
<p><a href="https://developer.mozilla.org/ja/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#%E7%94%BB%E9%9D%A2%E3%83%AA%E3%83%BC%E3%83%80%E3%83%BC">https://developer.mozilla.org/ja/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#%E7%94%BB%E9%9D%A2%E3%83%AA%E3%83%BC%E3%83%80%E3%83%BC</a></p>
<p>tabindex</p>
<ul>
<li><a href="https://developer.mozilla.org/ja/docs/Web/API/HTMLElement/tabIndex">https://developer.mozilla.org/ja/docs/Web/API/HTMLElement/tabIndex</a></li>
</ul>
<p>role</p>
<ul>
<li><a href="https://developer.mozilla.org/ja/docs/Web/Accessibility/ARIA/Roles">https://developer.mozilla.org/ja/docs/Web/Accessibility/ARIA/Roles</a></li>
<li><a href="https://zenn.dev/yusukehirao/articles/acba4a2a3dd909">https://zenn.dev/yusukehirao/articles/acba4a2a3dd909</a></li>
</ul>


なぜ <div> に onClick がダメなのか？

今後の React ではどの範囲を Suspense で囲むかという設計が重要になってくる

<h1>はじめに</h1>
<p>こんにちは！Another works でフロントエンドエンジニアをしている<strong>まっち</strong>です！</p>
<p>今回は汎用的なElementレイヤーのコンポーネントを作るときの Props設計はこうした方がよいのではないか、という話をしていきます！</p>
<p>※ここで言うElementレイヤーとは： input, button, label など、atomic design でいう atom の部分</p>
<h1>ComponentPropsを使おう</h1>
<p>このように一つ一つのプロパティを定義するより</p>
<pre><code class="language-tsx:input.tsx">type Props = {
  value: string;
  onChange?: React.ChangeEventHandler&lt;HTMLInputElement&gt;;
};
export const Input = ({ value, onChange }: Props) =&gt; (
  &lt;input value={value} onChange={onChange} /&gt;
);
</code></pre>
<p><code>ComponentProps</code>を利用して<br>
下記のようにした方がよい、ということです。<br>
（element が持つデフォルトの props を全て受け取れるように）</p>
<pre><code class="language-tsx:input.tsx">// input element が持つ props を全て受け取れるようになる
type Props = React.ComponentProps&lt;'input'&gt;;
export const Input = (props: Props) =&gt; &lt;input {...props} /&gt;;
</code></pre>
<p><code>ComponentProps</code>を利用することで、React が提供している Element が持つ Props を全てうけとれるようになります。</p>
<ul>
<li><code>ComponentProps</code></li>
<li><code>ComponentPropsWithRef</code>：refを許容</li>
<li><code>ComponentPropsWithoutRef</code>：refを許容しない</li>
</ul>
<p>※個人的には<code>ref</code>も許容したい場面が多いので<code>ComponentPropsWithRef</code>を利用することが多いです。</p>
<h1>ComponentPropsを使うメリット</h1>
<p>メリットは<strong>コンポーネントのメンテナンスコストが軽減される</strong>ことにあります</p>
<h3>ComponentPropsを使わない場合</h3>
<p>作成当初は<code>value</code>, <code>onChange</code>のみを受け取れるコンポーネントとして作成</p>
<pre><code class="language-tsx:input.tsx">type Props = {
  value: string;
  onChange?: React.ChangeEventHandler&lt;HTMLInputElement&gt;;
};
export const Input = ({ value, onChange }: Props) =&gt; (
  &lt;input value={value} onChange={onChange} /&gt;
);
</code></pre>
<p><code>type</code>や<code>onBlur</code>を利用する要件に対応させたくなった場合<br>
<code>props</code>を追加する必要があり、都度コンポーネントに手を加える必要があります。</p>
<pre><code class="language-tsx:input.tsx">type Props = {
  value: string;
  onChange?: React.ChangeEventHandler&lt;HTMLInputElement&gt;;
  type: string; // 追加
  onBlur?: React.FocusEventHandler&lt;HTMLInputElement&gt;; // 追加
};
export const Input = ({ value, type, onChange, onBlur, onKeyPress }: Props) =&gt; (
  &lt;input
    value={value}
    onChange={onChange}
    type={type} // 追加
    onBlur={onBlur} // 追加
  /&gt;
);
</code></pre>
<h3>ComponentPropsを使うと</h3>
<p><code>type</code>や<code>onBlur</code>を利用する要件に対応させたくなった場合も<br>
その都度<code>props</code>を追加する必要がなくなります。</p>
<pre><code class="language-tsx">/**
 * React.ComponentProps&lt;'input'&gt;; で
 * input要素が持つPropsを全て受け取れるようになる
 *
 * value?: string;
 * type?: string;
 * onChange?: React.ChangeEventHandler&lt;HTMLInputElement&gt;;
 * onBlur?: React.FocusEventHandler&lt;HTMLInputElement&gt;;
 * onFocus?: React.FocusEventHandler&lt;HTMLInputElement&gt;;
 * onKeyPress?: React.KeyboardEventHandler&lt;HTMLInputElement&gt;;
 * etc...
 */
</code></pre>
<pre><code>type InputProps = React.ComponentProps&lt;'input'&gt;;
export const Input = (props: InputProps) =&gt; {
  // 分割代入で全ての値を渡すことができる
  return &lt;input {...props} /&gt;;
};
</code></pre>
<p><code>props</code>を全てそのまま渡すのではなく、特定の <code>props</code> ではコンポーネント独自の振る舞いをさせたいときは、<code>{...props}</code> の下にその<code>props</code>を渡します。</p>
<p>ex)<code>onChange</code> では特定の振る舞いを強制させたいとき</p>
<pre><code class="language-tsx:input.tsx">type Props = React.ComponentProps&lt;'input'&gt;;
export const Input = (props: Props) =&gt; {
  const handleChange = (e: ChangeEvent&lt;HTMLInputElement&gt;) =&gt; {
    // このコンポーネントで onChange 発火時に必ず実行したい振る舞いを書く
    props.onChange?.(e);
  };
  return (
    &lt;input
      {...props} // &lt;- onChange が含まれるものの
      onChange={handleChange} // &lt;- こちらの handleChange が優先される
    /&gt;
  );
};
</code></pre>
<h1>より実践的な使い方</h1>
<p>より実践的な使い方として下記のようなインプットコンポーネントを例に考えてみます。</p>
<p><strong>デフォルト</strong><br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/9ad99afc-7127-4b49-b577-05fd70962934%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%882023-01-2810.11.32.png" alt="スクリーンショット2023-01-2810.11.32.png"></p>
<p><strong>エラー</strong><br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/05e4b263-855f-4b1a-97f1-0a31a61d5b95%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%882023-01-2810.12.01.png" alt="スクリーンショット2023-01-2810.12.01.png"></p>
<p>先ほどとは異なり、コンポーネント独自のPropsをもたせる必要がでてくるかと思います。</p>
<pre><code class="language-tsx:input.tsx">type InputElementProps = React.ComponentProps&lt;'input'&gt;;
type Props = {
  title: string; // コンポーネント独自のprops
  errorMessage?: string; // コンポーネント独自のprops
  inputElementProps?: InputElementProps; // inputElementのprops
};
export const InputComponent = ({
  title,
  errorMessage,
  inputElementProps,
}: Props) =&gt; {
  const handleChange = (e: ChangeEvent&lt;HTMLInputElement&gt;) =&gt; {
    // このコンポーネントで onChange 発火時に必ず実行したい振る舞いを書く
    inputElementProps?.onChange?.(e);
  };
  return (
    &lt;div style={rootStyle}&gt;
      &lt;p style={titleStyle}&gt;{title}&lt;/p&gt;
      &lt;input {...inputElementProps} onChange={handleChange} /&gt;
      &lt;p style={errorStyle}&gt;{errorMessage}&lt;/p&gt;
    &lt;/div&gt;
  );
};
</code></pre>
<p><strong>コンポーネントを利用するとき</strong></p>
<pre><code class="language-tsx:index.tsx">const Index = () =&gt; {
  const [value, setValue] = useState('');
  return (
    &lt;div&gt;
      &lt;InputComponent
        title=&quot;タイトル&quot;
        errorMessage=&quot;エラーメッセージ&quot;
        inputElementProps={{
          value,
          onChange: (e) =&gt; setValue(e.target.value),
        }}
      /&gt;
    &lt;/div&gt;
  );
};
</code></pre>
<h3>Element がもつ props の仕様を変更したい場合</h3>
<p>さらに、<code>input</code> の <code>value type</code> を <code>password</code> と <code>email</code> だけに限定させたい、というユースケースがあったとします。</p>
<p>その場合、<code>input</code>が持つデフォルトの<code>props</code>である<code>type</code>をコンポーネントで独自に型定義して、<code>InputElementProps</code>は<code>type</code>を除いた型にします。</p>
<pre><code class="language-tsx:input.tsx">type InputElementProps = Omit&lt;React.ComponentProps&lt;'input'&gt;, 'type'&gt;; // input element の props から type が除外される
type Props = {
  title: string;
  type: 'password' | 'email'; // password と email に限定（inputのデフォルトでは string型）
  errorMessage?: string;
  inputElementProps?: InputElementProps; // inputElementのprops
};
export const InputComponent = ({
  title,
  type,
  errorMessage,
  inputElementProps,
}: Props) =&gt; {
  const handleChange = (e: ChangeEvent&lt;HTMLInputElement&gt;) =&gt; {
    // このコンポーネントで onChange 発火時に必ず実行したい振る舞いを書く
    inputElementProps?.onChange?.(e);
  };
  return (
    &lt;div style={rootStyle}&gt;
      &lt;p style={titleStyle}&gt;{title}&lt;/p&gt;
      &lt;input 
        {...inputElementProps}
        type={type} // ここで渡すのを忘れずに
        onChange={handleChange}
      /&gt;
      &lt;p style={errorStyle}&gt;{errorMessage}&lt;/p&gt;
    &lt;/div&gt;
  );
};
</code></pre>
<p><strong>コンポーネントを利用するとき</strong></p>
<pre><code class="language-tsx:index.tsx">const Index = () =&gt; {
  const [value, setValue] = useState('');
  return (
    &lt;div&gt;
      &lt;InputComponent
        title=&quot;タイトル&quot;
        errorMessage=&quot;エラーメッセージ&quot;
        type='password' // password or email しか渡せない
        inputElementProps={{
          value,
          onChange: (e) =&gt; setValue(e.target.value),
          type: 'number' // error: 除外しているのでここでは渡せない
        }}
      /&gt;
    &lt;/div&gt;
  );
};
</code></pre>
<h1>最後に</h1>
<p>自分自身もコンポーネント設計は、現状迷いながら実装している部分が多いです！</p>
<p>最後までお読みいただきありがとうございました！</p>
<h3>参考資料</h3>
<p>ありがとうございました。</p>
<ul>
<li><a href="https://github.com/kufu/smarthr-ui">smarthr-ui</a></li>
<li><a href="https://github.com/mui/material-ui">mui</a></li>
<li><a href="https://zenn.dev/takepepe/articles/atoms-type-definitions">Takepepeさん記事</a></li>
</ul>


React.ComponentPropsを使ったコンポーネントの Props 設計

<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>


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

<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>


#React