Another works Developers Blog

<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 がダメなのか？

<h1>■はじめに</h1>
<p><code>TypeScript v4.9</code>から利用可能になった <code>satisfies</code> Operator</p>
<p><a href="https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-9.html">https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-9.html</a></p>
<p>弊社リポジトリでも <code>satisfies</code>Operator を使い始めています。</p>
<p>そこで<code>satisfies</code>について学んでいるうちに、<br>
<code>satisfies</code>を使えば<code>型注釈 (type annotation)</code>は必要ないのでは？</p>
<p>という考えが浮かび記事にしてみました。</p>
<h4>型注釈 (type annotation) 参考資料</h4>
<ul>
<li><a href="https://typescriptbook.jp/reference/values-types-variables/type-annotation">変数宣言の型注釈 (type annotation)</a></li>
<li><a href="https://typescriptbook.jp/reference/values-types-variables/object/type-annotation-of-objects">オブジェクトの型注釈 (type annotation)</a></li>
</ul>
<h1>■結論</h1>
<p>ほとんどのケースで、<br>
<code>型注釈 (type annotation)</code>ではなく、<code>satisfies</code>を利用した方がよいと考えています。</p>
<p><code>satisfies</code>の機能・動作の説明とともに後述していきます。</p>
<h1>■satisfies とは</h1>
<p>ざっくり<br>
<strong>型推論を効かせながら型を限定できる機能</strong></p>
<p>と理解しました。</p>
<h1>■satisfies の良いところを動作とともに確認していく</h1>
<p>satisfies の良いところは下記２つを実現できるところにあります。</p>
<ol>
<li><strong>型を限定できる</strong></li>
<li><strong>型推論をいい感じに効かせることができる</strong></li>
</ol>
<p>最初下記のように定義したとします。</p>
<pre><code class="language-ts">type Color = {
  // Mapped Typesで key を限定
  [key in 'red' | 'blue' | 'green']: string | number[]
}
const colorsSatisfies= {
  red: '#ff0000',
  blue: '#0000ff',
  green: [0, 255, 0],
} satisfies Color;
</code></pre>
<h2>1. 型を限定できる</h2>
<p>型チェックが効いてくれる</p>
<pre><code class="language-ts">const colorsSatisfies= {
  red: '#ff0000',
  blue: '#0000ff',
  green: [0, 255, 0],
  // NG: 許容しない型を定義しようとするとエラー
  yellow: [255, 255, 0],
} satisfies Color;
</code></pre>
<h2>2. 型推論を効かせることができる</h2>
<p>型推論が効くので、下記型になります。</p>
<ul>
<li><code>red: string</code></li>
<li><code>blue: string</code></li>
<li><code>green: number[]</code></li>
</ul>
<pre><code class="language-ts">// NG: string は map を持っていないためエラー
colorsSatisfies.red.map((v) =&gt; v)

// OK
colorsSatisfies.green.map((v) =&gt; v)
</code></pre>
<h1>■satisfies を利用しない場合</h1>
<p>型を限定したい場合ほとんどの場合<code>型注釈 (type annotation)</code>を利用すると思います。</p>
<pre><code class="language-ts">type Color = {
  // Mapped Typesで key を限定
  [key in 'red' | 'blue' | 'green']: string | number[]
}
const colorsAnnotation: Color = {
  red: '#ff0000',
  blue: '#0000ff',
  green: [0, 255, 0],
}
</code></pre>
<h3>◯型注釈でも型は限定できる</h3>
<p>型チェックが効いてくれる</p>
<pre><code class="language-ts">const colorsAnnotation: Color = {
  red: '#ff0000',
  blue: '#0000ff',
  green: [0, 255, 0],
  // NG: yellow を許容しないためエラー
  yellow: [255, 255, 0],
}
</code></pre>
<h3>◯型注釈では型推論を効かせることができない</h3>
<p><code>型注釈 (type annotation)</code>の場合、型推論がいい感じに効いてくれません。<br>
下記の型になる。</p>
<ul>
<li><code>red: string | number[]</code></li>
<li><code>blue: string | number[]</code></li>
<li><code>green: string | number[]</code></li>
</ul>
<pre><code class="language-ts">// NG: string のため当然エラー
colorsAnnotation.red.map((v) =&gt; v)
// NG: string の可能性もあるためエラー
colorsAnnotation.green.map((v) =&gt; v)
</code></pre>
<p>このパターンで<code>map関数</code> を利用したい場合、型ガードを利用すればできます。<br>
（なかなか、しんどい実装...）</p>
<pre><code class="language-ts">if (typeof colorsAnnotation.green !== 'string') {
  // OK
  colorsAnnotation.green.map((v) =&gt; v)
}
</code></pre>
<h1>■型注釈はもう必要ないのか？</h1>
<p><code>satisfies</code>は<strong>型を限定できる</strong>かつ<strong>型推論をいい感じに効かせることができる</strong>ので、<br>
<code>型注釈 (type annotation)</code>もういらないのでは？ と思えてきます。</p>
<p>ただ、<br>
<strong>型が推論できない場面では<code>satisfies</code>を利用することはできない</strong>です。</p>
<pre><code class="language-ts">type UnionColor = 'red' | 'blue' | 'green'

// NG
let colors satisfies UnionColor
// OK
let colors: UnionColor
</code></pre>
<p>つまり、推論すべき値が存在しない場面では<br>
<code>satisfies</code> を利用できず、<br>
<code>型注釈</code>を利用するしかないです。</p>
<p><strong>型が推論できない場面</strong> を除いては<code>satisfies</code>を使った方がいいと思います。</p>
<p>最後に さらに便利な<code>satisfies</code>の使い方を紹介していきます。</p>
<h1>■<code>as const</code>と<code>satisfies</code>を一緒に使うと便利</h1>
<p>satisfies と as const を組み合わせて使うと、３つの恩恵を享受できます。</p>
<ol>
<li><code>satisfies</code>により型を限定することができる</li>
<li><code>as const</code>により値が widening されない</li>
<li><code>as const</code>により readonly の値にできる</li>
</ol>
<p><a href="https://zenn.dev/estra/articles/typescript-widening">TypeScript の Widening</a><br>
※ widening の例: <code>'#ff0000'型 -&gt; string型</code>に広がって推論されてしまう</p>
<h2>1. <code>satisfies</code>により 型を限定することができる</h2>
<pre><code class="language-ts">type Color = {
  // Mapped Typesで key を限定
  [key in 'red' | 'blue' | 'green']: string | readonly number[]
}
const colorsAsConstSatisfies = {
  red: '#ff0000',
  blue: '#0000ff',
  green: [0, 255, 0],
  // NG: yellow を許容しないためエラー 型を限定することができる
  yellow: [255, 255, 0],
} as const satisfies Color;
</code></pre>
<h3><code>as const</code> だけだと型を限定できない</h3>
<pre><code class="language-ts">const colors = {
  red: '#ff0000',
  blue: '#0000ff',
  green: [0, 255, 0],
  // キーを限定できない yellow を許容する
  yellow: [255, 255, 0],
} as const;
</code></pre>
<h2>2. <code>as const</code>により値が widening されない</h2>
<pre><code class="language-ts">type Color = {
  // Mapped Typesで key を限定
  [key in 'red' | 'blue' | 'green']: string | readonly number[]
}
const colorsAsConstSatisfies = {
  red: '#ff0000',
  blue: '#0000ff',
  green: [0, 255, 0],
} as const satisfies Color;
</code></pre>
<p>型推論の結果</p>
<pre><code class="language-ts">// widening されない
const colorsAsConstSatisfies = {
  readonly red: '#ff0000';
  readonly blue: '#0000ff';
  readonly green: readonly [0, 255, 0];
}
</code></pre>
<h3><code>satisfies</code>だけだと widening されてしまう</h3>
<pre><code class="language-ts">const colorsSatisfies = {
  red: '#ff0000',
  blue: '#0000ff',
  green: [0, 255, 0],
} satisfies Color;
</code></pre>
<p>型推論の結果</p>
<pre><code class="language-ts">// widening されてしまう
const colorsSatisfies = {
  red: string;
  blue: string;
  green: number[];
}
</code></pre>
<h2>3. <code>as const</code>により readonly の値にできる</h2>
<pre><code class="language-ts">type Color = {
  // Mapped Typesで key を限定
  [key in 'red' | 'blue' | 'green']: string | readonly number[]
}
const colorsAsConstSatisfies = {
  red: '#ff0000',
  blue: '#0000ff',
  green: [0, 255, 0],
} as const satisfies Color;
</code></pre>
<p><code>red</code> に代入しようとすると</p>
<pre><code class="language-ts">// NG: readonly のためエラー 
colorsAsConstSatisfies.red = 'red'
</code></pre>
<h3><code>satisfies</code>だけだと readonly の値にならない</h3>
<p><code>red</code>に代入しようとすると</p>
<pre><code class="language-ts">const colorsSatisfies = {
  red: '#ff0000',
  blue: '#0000ff',
  green: [0, 255, 0],
} satisfies Color;

// OK: readonly ではないため
colorsSatisfies.red = 'red'
</code></pre>
<h1>■最後に</h1>
<p>読んでいただきありがとうございました！</p>
<h3>参考資料</h3>
<p>ありがとうございました！</p>
<ul>
<li><a href="https://zenn.dev/moneyforward/articles/typescript-as-const-satisfies#satisfies-%E3%81%AA%E3%81%97%E3%80%81-as-const-%E3%81%82%E3%82%8A%E3%81%AE%E5%A0%B4%E5%90%88">https://zenn.dev/moneyforward/articles/typescript-as-const-satisfies#satisfies-%E3%81%AA%E3%81%97%E3%80%81-as-const-%E3%81%82%E3%82%8A%E3%81%AE%E5%A0%B4%E5%90%88</a></li>
<li><a href="https://qiita.com/suin/items/1b74645158263d2fa9af">https://qiita.com/suin/items/1b74645158263d2fa9af</a></li>
<li><a href="https://zenn.dev/luvmini511/articles/55ad71c1ae99ba#3.-satisfies-%E3%81%A7%E8%A7%A3%E6%B1%BA%E3%81%A7%E3%81%8D%E3%82%8B%E5%95%8F%E9%A1%8C">https://zenn.dev/luvmini511/articles/55ad71c1ae99ba#3.-satisfies-%E3%81%A7%E8%A7%A3%E6%B1%BA%E3%81%A7%E3%81%8D%E3%82%8B%E5%95%8F%E9%A1%8C</a></li>
<li><a href="https://zenn.dev/estra/articles/typescript-widening">https://zenn.dev/estra/articles/typescript-widening</a></li>
<li><a href="https://typescriptbook.jp/reference/values-types-variables/object/type-annotation-of-objects">https://typescriptbook.jp/reference/values-types-variables/object/type-annotation-of-objects</a></li>
</ul>


【TypeScript / satisfies】型注釈(type annotation) はもういらない？

<h1>はじめに</h1>
<p>Another works でエンジニアをしているまっちです！</p>
<p>今回は**【package.json】 バージョンにつける「^」「~」は何を意味するのか？**というテーマを深掘って書いていきます！</p>
<p>自分の感覚では<code>^</code>チルダはじまりで<code>package.json</code>にのバージョン指定がされているライブラリが多い印象です。<br>
そこで <code>^</code>や `~' ってなんでつけてるの？<br>
という疑問から色々と調べたことを書いていきます。</p>
<pre><code class="language-json:package.json">  &quot;dependencies&quot;: {
    &quot;react&quot;: &quot;^18.2.0&quot;, // これ
    &quot;next&quot;: &quot;~12.0.2&quot;, // これ
    ,,,
</code></pre>
<h1>^ 表記で破壊的な変更がない範囲で最新バージョンを利用できる</h1>
<p><code>package.json</code>に<code>^</code>表記でバージョン指定が多い理由として<br>
<code>package</code>を破壊的な変更がない範囲で最新の機能を利用できるバージョンにできる（はず）だから、</p>
<p>と考えました。(違ったらすみません！)</p>
<p>その理由を後述していきます。<br>
前提として、</p>
<ul>
<li><code>package.json</code>の仕様</li>
<li><code>npm</code>の推奨しているセマンティックバージョニングについて<br>
理解したあと、</li>
</ul>
<p><code>package.json</code>のバージョン指定方法を説明しながら考えてみます。</p>
<h1>前提１： package.json にはバージョン範囲を記述する</h1>
<h4>package.jsonには</h4>
<p>インストールする package の範囲を記述します。</p>
<h4>package.lock.jsonには</h4>
<p>実際にインストールされている package のバージョン（などの）情報が記載されます。<br>
つまり、<code>node_modules</code>に入っている package 郡の情報が記載されます。</p>
<h1>前提２: npm の推奨しているセマンティックバージョニング</h1>
<p>ざっくり、<code>npm</code>はパッケージを<br>
<strong>意味のある数字でバージョンを管理しようぜ</strong>、ということを推奨しています。<br>
※<a href="https://eow.alc.co.jp/search?q=semantic">セマンティック(semantic)</a>: 意味の, 語義の, 意味論的な<br>
https://docs.npmjs.com/about-semantic-versioning</p>
<p>このセマンティックバージョニングではバージョンを表す3つの数字<code>x.x.x</code>に<br>
<code>[major, minor, patch]</code>という意味をもたせています。<br>
それぞれの意味するところは次のようなものです。</p>
<ul>
<li><code>major</code>: <code>前のバージョンと互換性を損なう変更</code>をするときに上げる数字</li>
<li><code>minor</code>: <code>前のバージョンと互換性を持つ新機能追加の変更</code>をするときに上げる数字</li>
<li><code>patch</code>: <code>前のバージョンと互換性を持つバグ修正の変更</code>をするときに上げる数字</li>
</ul>
<p>※つまり<code>majorアップデート</code>では<strong>破壊的な変更を含む可能性が高い</strong>ということです。</p>
<h4>例を用いて考える</h4>
<p><code>3.4.5</code>というバージョンが最新の<code>package</code>があった場合、<br>
セマンティックバージョニングに則れば</p>
<ul>
<li><code>majorアップデート</code>を3回</li>
<li>3系になって(<code>majorアップデート</code>3回目以降)から
<ul>
<li><code>minorアップデート</code>を4回</li>
<li><code>patchアップデート</code>を5回</li>
</ul>
</li>
</ul>
<p>おこなっているpackageということになります。</p>
<h1>package.json のバージョン指定方法</h1>
<p><code>~</code>, <code>^</code>を含めて大きく4つのバージョン指定方法があるようです。<br>
https://www.npmjs.com/package/semver/v/4.3.6</p>
<h3>1. バージョンの数字のみ記載</h3>
<p>範囲なし(固定)<br>
記載したバージョンをインストールする。</p>
<p><code>1.2.3</code>: 1.2.3 (記述したバージョンのみ許容)</p>
<h3>2. <code>x</code> or <code>*</code></h3>
<p><code>x</code>, <code>*</code>を記載した箇所のバージョン更新を許容</p>
<ul>
<li><code>*</code> : &gt;=0.0.0 (どのバージョンの更新も許容)</li>
<li><code>1.x</code> : &gt;=1.0.0 &lt;2.0.0 (major バージョン以外の更新を許容)</li>
<li><code>1.2.x</code> : &gt;=1.2.0 &lt;1.3.0 (patch バージョンだけの更新を許容)</li>
</ul>
<h3>3. <code>~</code>チルダ</h3>
<p>minorバージョンが指定されている場合、patchバージョンの変更を許容。そうでない場合は、minorバージョンの変更を許容。</p>
<ul>
<li><code>~1.2.3</code>: 1.2.3以上 1.3.0未満</li>
<li><code>~1</code>: 1.0.0以上 2.0.0未満</li>
</ul>
<h3>4. <code>^</code>キャレット</h3>
<p>３つの数字<code>[major, minor, patch]</code>で１番左側にある<code>0</code>でない数字を変更しない更新を許可。（ややこしい）</p>
<ul>
<li><code>^1.2.3</code>:1.2.3以上 2.0.0未満(1の変更は許容しない）</li>
<li><code>^0.2.3</code>:0.2.3以上 0.3.0未満(2の変更は許容しない）</li>
<li><code>^0.0.3</code>:0.0.3以上 0.0.4未満(3の変更は許容しない,つまり変更不可？)</li>
</ul>
<p>つまり<code>major</code>バージョンの更新を許容せずに最新バージョンに更新することを許容するようです。</p>
<h2>なるほど、つまり</h2>
<p><code>^</code>チルダ表記でバージョン指定をすれば前のバージョンとの互換性を保ちながら、最新バージョンに保たれる可能性が高いといえます。</p>
<p>ただし、セマンティックバージョニングに則っているpackageであること(majorアップデート以外で破壊的な変更がされない)という前提があります。</p>
<h1>さいごに</h1>
<p>恥ずかしながら今回書いたことは調べるまで知らないことだらけでした。<br>
ライブラリ(package)の開発者も利用者もセマンティック バージョニングについて理解しながら開発をすることが大事だと感じました。</p>
<p>お読みくださりありがとうございました！</p>
<h1>参考</h1>
<p>参考にさせていただきました。ありがとうございました。</p>
<ul>
<li>https://zenn.dev/luvmini511/articles/56bf98f0d398a5</li>
<li>https://zenn.dev/ikuraikura/articles/d6ff3821017e29539a7a</li>
<li>https://www.npmjs.com/package/semver/v/4.3.6</li>
<li>https://docs.npmjs.com/about-semantic-versioning</li>
</ul>


【package.json】 バージョンにつける「^」「~」は何を意味するのか？

<p>こんにちは、まっちです！今回は、弊社 <strong><a href="https://anotherworks.co.jp/">Another works</a></strong> と <strong><a href="https://smarthr.co.jp/">SmartHR</a></strong> さんで 2023/4/18(火) に開催したLT×交流会 <a href="https://anotherworks.connpass.com/event/278310/">FRONT-END DEEP DIVE</a> のイベントレポートをお届けします！</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/c2cf104b-c0fa-48b4-947b-9a33302cc782/IMG_5373.jpg" alt="IMG_5373.jpg" title="会場"></p>
<h1>目次</h1>
<ul>
<li>イベントの概要</li>
<li>LT登壇内容
<ul>
<li>1.「Web Components を使ったウィジェット埋め込みの話」</li>
<li>2.「Next13新機能 App Routerにどう向き合うか？」</li>
<li>3.「元フロントエンドエンジニアからみたデザイナーとの協業と実態」</li>
</ul>
</li>
<li>交流会</li>
<li>さいごに</li>
</ul>
<h1>イベントの概要</h1>
<p>これまで8回ほど Another works が開催してきたフロントエンドLTイベント！<br>
今回は SmartHR さんにご協力いただき、オフィスをお借りして共催イベントを開催しました！</p>
<p>オフライン約60名、オンライン約80人と<strong>フロントエンドに DEEP DIVE したい</strong>たくさんの方に参加をいただきました！</p>
<p>SmartHR さんにお借りした会場すごすぎる。</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/51784638-a29c-42b7-8026-511c75f0417e/IMG_5382.jpg" alt="IMG_5382.jpg" title="会場の様子"></p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/7df13b33-7a93-45af-a962-3ffdedb96caa/IMG_5420.jpg" alt="IMG_5420.jpg" title="受付でお渡しした案内"></p>
<h1>LT登壇内容</h1>
<p><strong>1. <a href="https://twitter.com/nabeliwo">nabeliwo</a> 株式会社SmartHR フロントエンドエンジニア： 「Web Components を使ったウィジェット埋め込みの話」</strong></p>
<p><strong>2. <a href="https://twitter.com/MotohiroSiobara">sol</a> 株式会社Another works 取締役CTO：「Next13新機能 App Routerにどう向き合うか？」</strong></p>
<p><strong>3. <a href="https://twitter.com/uknmr">uknmr</a> 株式会社SmartHR プロダクトデザイナー：「元フロントエンドエンジニアからみたデザイナーとの協業と実態」</strong></p>
<h2>1.「Web Components を使ったウィジェット埋め込みの話」</h2>
<p><strong><a href="https://twitter.com/nabeliwo">nabeliwo</a> 株式会社SmartHR フロントエンドエンジニア / <a href="https://speakerdeck.com/nabeliwo/embedding-widgets-using-web-components">登壇資料</a></strong></p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/e910abad-a3b9-4a49-b01e-14fe95a7d3b4/IMG_5401.jpg" alt="IMG_5401.jpg"></p>
<h3>内容</h3>
<ul>
<li>Web Components ってそもそもなんだっけのおさらい</li>
<li>Platform 事業で Web Compnents を採用した話</li>
<li>なぜ Web Components を採用したのか</li>
<li>実際に使ってみてどうだったか</li>
<li>今後の Platform 事業の技術的な展望</li>
</ul>
<h3>ひとことレポ</h3>
<p>現状の SmartHR さんが抱えている複雑さ（haml + jQuery,  React でそれぞれ動いている、など）にどう向き合っているのか、というリアルを知れる話でした。同じような悩みを抱える人、今後プロダクトを長く運用することを考えている人にとっては勉強になる内容だったのではないでしょうか？そして、SmartHR さん の Platform 事業における展望もあり、今後の開発が楽しみになる内容でした！</p>
<h2>2.「Next13新機能 App Routerにどう向き合うか？」</h2>
<p><strong><a href="https://twitter.com/MotohiroSiobara">sol</a> 株式会社Another works 取締役CTO / <a href="https://drive.google.com/file/d/1zcO7QymmyTF5m64elzubvoJFOTjwnklh/view">登壇資料</a></strong></p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/baf7b5ed-49ce-4044-82b0-4ae75579b265/IMG_5404.jpg" alt="IMG_5404.jpg"></p>
<h3>内容</h3>
<ul>
<li>どのように機能を開発しているか？
<ul>
<li>心構え</li>
</ul>
</li>
<li>App Router とは？
<ul>
<li>今のプロダクトに App Router を導入すべきかどうか</li>
<li>導入メリット</li>
<li>実際に試してみる</li>
</ul>
</li>
<li>Server Components とは？
<ul>
<li>経営者目線で Server Components のメリットを見てみる</li>
</ul>
</li>
<li>今後やりたいこと</li>
</ul>
<h3>ひとことレポ</h3>
<p>多くのプロダクトで利用されている Next.js の新機能である App Router の導入メリット、懸念点に関する話でした。また、「検証までのスピード向上」や、「セキュリティリスクの軽減」ができるという内容がありました。その点を「経営者目線で考える」と嬉しいことが多い、という話があり、取締役でありながらエンジニアでもある sol さんならではの考え方で興味深いものでした！</p>
<h2>3.「元フロントエンドエンジニアからみたデザイナーとの協業と実態」</h2>
<p><strong><a href="https://twitter.com/uknmr">uknmr</a> 株式会社SmartHR プロダクトデザイナー / <a href="https://docs.google.com/presentation/d/1k8RoNRXAMNazayzIGs14BZcVFeADVYvL2GxbaSeAGwM/edit#slide=id.p">登壇資料</a></strong></p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/90816bb7-7f84-4b52-8963-95beef6d2d56/IMG_5414.jpg" alt="IMG_5414.jpg"></p>
<h2>内容</h2>
<ul>
<li>自己紹介と職歴紹介</li>
<li>SmartHR のプロダクトデザイナー</li>
<li>デザイナーとの協業あるある?</li>
<li>実際の働き方 1</li>
<li>実際の働き方 2</li>
</ul>
<h2>ひとことレポ</h2>
<p>「コミュニケーションを蜜に取りながら改善しながらプロダクトをつくっていくスタイル」がユニークでした（気になる方はぜひ登壇資料をご覧ください！）。そして、SmartHR さんのスタイルは下記部分が前提となっている、という話がありました。</p>
<ul>
<li>良いプロダクトをつくる気持ちがある</li>
<li>本質的なプロダクトをやっていく環境がある</li>
<li>本気で SmartHR が日本の労働を変えていけると信じている</li>
</ul>
<p>そういった環境、人たちと働くことができる SmartHR さんの開発環境は魅力的に思います！</p>
<h1>交流会</h1>
<p>交流会にはLT登壇者も参加しました。LT内容についての話や、フロントエンドの深い話、普段の開発におけるあれこれ、など最後まで大変盛り上がり、話題の尽きない時間でした！</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/33252b84-6d19-431d-aa4a-167ccc498cbe/PXL_20230418_122355664.jpg" alt="PXL_20230418_122355664.jpg" title="交流会の様子"></p>
<h1>さいごに</h1>
<p>Another works では今後も学びと交流の場となるイベントを開催していく予定です！</p>
<p>Connpassでグループメンバーになっていただけると開催通知が送られますので、以下より是非グループメンバー登録をよろしくお願いします！<br>
<a href="https://anotherworks.connpass.com/">Another works Connpass</a></p>
<p>なお今回のイベントの感想など <strong>#AwEngineerMeetup</strong> のハッシュタグ付きでツイートをして盛り上げていただけると嬉しいです！</p>
<p>SmartHR のみなさま、ご参加いただいたみなさまありがとうございました！</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/47ff651f-11c9-4e2b-bb0a-aeabe89b1868/PXL_20230418_115508340.jpg" alt="PXL_20230418_115508340.jpg" title="参加いただいたみなさまでの集合写真"></p>


Another works × SmartHR 【FRONT-END DEEP DIVE】イベントレポート

<p>こんにちは、まっちです！<br>
今回は、弊社 <strong>Another works と HRBrain</strong> 様で 2023/3/30(木) に開催したLT×交流会 <a href="https://anotherworks.connpass.com/event/276673/">Front-end Meetup 2023</a>のイベントレポートをお届けします！</p>
<p>オフライン約50名、オンライン約70人と多くの方に参加のお申込みをいただきました！</p>
<h1>イベントの概要</h1>
<p>これまで7回ほどAnother worksが開催してきたフロントエンドLTイベント！今回はHRBrain様にご協力いただき、初めて共催イベントを開催しました！<br>
HRBrain様のオフィスをお借りして実施しました。また、オフラインだけではなくオンラインでも参加できるように準備しました！</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/2e8c6028-8fcc-4db0-a468-d24dccb2b620%2FIMG_5343.jpg" alt="IMG_5343.jpg" title="受付の様子"></p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/d1d6ee66-ba60-4e77-a03a-ed1218361b7f%2FPXL_20230330_111105845.jpg" alt="PXL_20230330_111105845.jpg" title="たくさんの方にお集まりいただきました"></p>
<p>イベントの前半では、<br>
各社のCTOやテックリードがアーキテクチャやUIライブラリ開発などのフロントエンドの深い部分に触れるLTを実施。<br>
後半は、オフライン参加の方限定で交流会を実施し、技術や、開発における話や情報交換の場を設けました！</p>
<h1>LT登壇内容</h1>
<ol>
<li>㈱ HRBrain CTO 鈴木 悠大： 「SaaSフロントエンド開発の現場で求められる技術」</li>
<li>㈱ Another works CTO 塩原 基弘：「複業クラウドのフロントエンドに関する全てを公開します！」</li>
<li>㈱ HRBrain SubTL 岩本 佳吾：「HRTech SaaSで開発している共通UIライブラリについて」</li>
</ol>
<h2>1. 「SaaSフロントエンド開発の現場で求められる技術」</h2>
<p>㈱ HRBrain CTO 鈴木 悠大 / <a href="https://www.figma.com/proto/4JTZKEkxziVdWxXS3kPxjU/Front-end-Meetup-2023?node-id=1-2&amp;scaling=contain">登壇資料</a></p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/d4589254-09ce-416c-b870-e34af59b534e%2FIMG_8014.jpg" alt="IMG_8014.jpg"></p>
<h3>内容</h3>
<ul>
<li>HRBrainの実例を基に、企業向けSaaS開発で求められるフロントエンドの特長と、それを解決するために使用している技術について</li>
<li>企業向けSaaSの世の中のイメージ
<ul>
<li>堅実なアプリケーション作りが求められるため、面白さに欠ける印象があるかもしれない</li>
</ul>
</li>
<li>企業向けSaaSの特徴
<ul>
<li>カスタマイズ性が求められがち</li>
<li>データ入力が多くなりがち</li>
<li>データの可視化が求められがち</li>
</ul>
</li>
<li>まとめ
<ul>
<li>SaaSフロントエンドでは情報量が多く、見せ方や扱いにフロントエンド力が重要</li>
<li>技術がなくても基本要件は満たせるが、使いやすさに大きく影響する</li>
<li>顧客に向き合うとSaaSのフロントエンドは楽しい</li>
</ul>
</li>
</ul>
<h3>ひとことレポ</h3>
<p>顧客とフロントエンドの技術に向き合って開発をする楽しさが伝わってきました。<br>
HRBrainさんのフロントエンド開発の魅力が感じられる登壇内容でした！</p>
<h2>2. 「複業クラウドのフロントエンドに関する全てを公開します！」</h2>
<p>㈱ Another works CTO 塩原 基弘 / <a href="https://docs.google.com/presentation/d/1mkzER_urMPXyYchzVyGcOc6mER_K2MwBK-exHvAvgG8/edit#slide=id.g22331a12ada_0_0">登壇資料</a></p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/6650f1d3-2c27-460a-ace8-99f25e24e21f%2FIMG_8019.jpg" alt="IMG_8019.jpg"></p>
<h3>内容</h3>
<ul>
<li>複業クラウドというプロダクトについて
<ul>
<li>コンテキストの違い</li>
<li>機能は一見シンプルだけど意外と複雑になりがち</li>
</ul>
</li>
<li>どのように機能を開発しているか？
<ul>
<li>成果を意識する</li>
<li>とにかくドキュメンテーション</li>
<li>事象や課題を意識した上で開発を行う</li>
</ul>
</li>
<li>フロントエンドの設計について
<ul>
<li>設計思想
<ul>
<li>共通化よりも多少の重複を許容する</li>
<li>楽に考え捨てやすくする</li>
<li>利用可能な範囲をなるべく限定的にする</li>
</ul>
</li>
<li>コンポーネント設計</li>
<li>ディレクトリ設計</li>
</ul>
</li>
<li>DX(Developer Experience)の取り組み
<ul>
<li>コーディング規約とそれを守れる仕組み</li>
<li>バンドルサイズレポート</li>
</ul>
</li>
<li>失敗事例の紹介
<ul>
<li>フロントエンド設計を各リポジトリーオーナーに任せる</li>
<li>フロントエンドにクリーンアーキテクチャの概念を導入</li>
<li>Atomic Designの失敗</li>
</ul>
</li>
<li>今後やりたいこと
<ul>
<li>フロントエンドのさらなる開発生産性の向上！！</li>
<li>高速でベータ版をリリースして検証できる仕組み</li>
</ul>
</li>
</ul>
<h3>ひとことレポ</h3>
<ul>
<li>フロントエンドにクリーンアーキテクチャの概念を導入</li>
<li>Atomic Designの失敗</li>
</ul>
<p>などの失敗事例の紹介では共感されている方も多くいたようで、フロントエンドの辛いところはどの開発現場でも似たような部分があるのだな、と改めて感じました！</p>
<h2>3. 「HRTech SaaSで開発している共通UIライブラリについて」</h2>
<p>㈱ HRBrain SubTL 岩本 佳吾 / <a href="https://speakerdeck.com/shippokun/hrtech-saastekai-fa-siteirugong-tong-uiraihurarinituite">登壇資料</a></p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/1180a16d-941f-4524-8944-f7254df21492%2FIMG_6684.jpeg" alt="IMG_6684.jpeg"></p>
<h3>内容</h3>
<ul>
<li>HRBrainでのUIライブラリの立ち位置</li>
<li>運用体制・これまでの開発</li>
<li>採用技術
<ul>
<li>一部コンポーネントの紹介</li>
</ul>
</li>
<li>運用していく中での課題感と対策</li>
<li>UIライブラリを開発していく中で難しい部分としくじり</li>
<li>まとめと今後
<ul>
<li>貢献しやすい状態を作り出すことで継続的な改善をする</li>
<li>UIライブラリとプロダクトの責務を定義することで迷わない開発を</li>
</ul>
</li>
</ul>
<h3>ひとことレポ</h3>
<p>エンジニアだけでなくデザイナーもコントリビュートを狙っている、というのが良い文化だと感じました。<br>
エンジニアとデザイナーの協調、相互理解の助けにもなっていそうですね！</p>
<h1>交流会</h1>
<p>交流会にはLT登壇者も参加しました。<br>
LT内容についての話や、普段の開発におけるあれこれ、興味関心のある技術の話など最後まで大変盛り上がり、話題の尽きない時間となりました！</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/dd3bcc30-863b-4c52-94c0-575e0a0ef219%2FIMG_0030.jpg" alt="IMG_0030.jpg" title="交流会の様子"><br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/9774d1b1-39e1-4fcb-8ff9-972e98875e7a%2FIMG_0031.jpg" alt="IMG_0031.jpg" title="交流会の様子"></p>
<h1>さいごに</h1>
<p>Another works では今後も学びと交流の場となるイベントを開催していく予定です！</p>
<p>Connpassでグループメンバーになっていただけると開催通知が送られますので、以下より是非グループメンバー登録をよろしくお願いします！<br>
<a href="https://anotherworks.connpass.com/">Another works Connpass</a></p>
<p>なお今回のイベントの感想など <code>#AwEngineerMeetup</code> のハッシュタグ付きでツイートをして盛り上げていただけると嬉しいです！</p>
<p>HRBrain のみなさま、ご参加いただいたみなさまありがとうございました！</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/1039305d-1a01-4c6e-bc11-b469a55bedb0%2FPXL_20230330_114304938.MP.jpg" alt="PXL_20230330_114304938.MP.jpg" title="集合写真"></p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/b3d515a2-8879-4ca2-94e8-b54cfdc39a60%2FPXL_20230330_125214161.MP.jpg" alt="PXL_20230330_125214161.MP.jpg" title="運営メンバーでパシャリ"></p>


Another works / HRBrain【Front-end Meetup 2023 】イベントレポート

今後の 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 設計

<p>こんにちは、ノブです。</p>
<p>データドリブンな意思決定をよりスピーディに行うために分析工程をより速く・正確に行う方法がないかを日々試行錯誤しています。</p>
<p>その中の試みの一つについて記載します。</p>
<p>運用から３ヶ月程度経過し、効果を実感しているため、同じような悩みをお持ちの方の何かヒントになればとても嬉しく思います。</p>
<h3>分析工程のボトルネック</h3>
<p>分析の速度・正確性を考えた時に分析業務を以下の３つに大別しました。</p>
<ul>
<li>
<p>分析を計画する<br>
　- 明確にしたいものを定義する<br>
　- 分析にあたっての取得するデータを定義する<br>
　- どのような分析、可視化を行うかを考える</p>
</li>
<li>
<p>データを取得する<br>
　- DBの中身を把握する<br>
　- クエリを考える<br>
　- 可視化を行う</p>
</li>
<li>
<p>分析をする<br>
　- 可視化したものや情報を元に実際に分析を行う<br>
　- 議論できるように結果をレポーティングする</p>
</li>
</ul>
<p>この中で特に時間がかかっていて改善の余地が見込まれたのが「データを取得する時間」でした。</p>
<h3>複業クラウドにおける BigQuery</h3>
<p>複業クラウドでは、ログデータや同期したマスタテーブルを分析用に整形せずに生に近い状態で BigQuery に蓄積しており、データレイクとして活用していました。</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/1857e4dc-e5c4-49af-aa1f-e1d4f3f81dee%2Ftech_blog.001.jpeg" alt="tech_blog.001.jpeg"></p>
<p>上図のように分析者や BIツールはこの BigQuery を参照してデータ取得を行っていましたが、生データに近いが故に以下の課題を持っていました。</p>
<ul>
<li>分析に不要な情報が多く存在する</li>
<li>値や構造が実装者寄りで分析者寄りではない</li>
</ul>
<p>一つ目の「分析に不要な情報が多く存在する」についてです。<br>
同期したマスタテーブルでは、どの分析でも落としている情報がありました。<br>
例えば、求人データの公開日は重要ですが同じテーブルに存在するシステムで出し分けのために使っている値は分析では必ず落としていました。</p>
<p>二つ目の「値や構造が実装者寄りで分析者寄りではない」についてです。<br>
システムとしての良いテーブル構造が必ずしも分析にとって都合の良い構造ではないということは良くあることだと思います。<br>
具体的には、分析を目的とした SQL では結合や条件句が非常に多くなってしまい可読性やメンテナンス性に乏しいクエリとなっていました。</p>
<h3>解決策</h3>
<p>解決策として DWH（データウェアハウス）を作成することとしました。<br>
DWH は目的を分析に絞り、不要な情報は先に落とし、構造も分析寄りにしました。</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/c9251136-61eb-49f6-b5fd-08f57517207e%2Ftech_blog.002.jpeg" alt="tech_blog.002.jpeg"></p>
<p>DWH を設けることは BigQuery のビューを使うことで容易にできたので利用サービスが増えることもありませんでした。</p>
<p>ビューの使用方法は<a href="https://cloud.google.com/bigquery/docs/views?hl=ja#console">公式のドキュメント</a>に記載されているため割愛しますが、得られた効果を考えるとビューを用いた DWH の作成コストは非常に小さいと改めて感じています。</p>
<h3>効果</h3>
<p>DWHの運用は、効果を十分に感じています。</p>
<p>得られた効果は大きく二つあります。</p>
<ul>
<li>クエリが簡潔になった</li>
<li>分析用の単語の定義にブレがなくなった</li>
</ul>
<p>どちらの効果も分析のスピードをあげるだけでなく人的ミスを減らすことにも貢献してくれています。<br>
また、今後分析を担当するメンバーが増えた際にも全てのテーブルの関係性を説明するのではなく、目的にそった DWHを説明すれば良くなりました。</p>
<h3>まとめ</h3>
<p>今回は BigQuery のビューを用いて DWH を設けた話をさせていただきました。<br>
DWH を作成すると、今後はデータマートを作成することも容易となり、またこの話もできればと思っています。</p>
<p>サービスの進化に合わせて保持するデータは常に変わっていくもので、それを途切れることなく貯めていく分析基盤は非常に難しく魅力的なものですが、分析のための正しいデータ運用をこれからも模索できればと思っています。</p>


BigQueryのビューでDWHを作る

<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>こんにちはAnother works CTOの塩原です。</p>
<p>複業クラウドのバックエンドではDDDとクリーンアーキテクチャを導入しています。</p>
<p>社内では、<a href="https://twitter.com/little_hand_s">松岡さん</a>の書籍やTwitterなどを参考にしながらDDDの開発に取り組んでいます。</p>
<p>DDDの記事は参考になるものが松岡さんの記事やその他の人が書いた記事など豊富にあるため、設計方法についてはそこまで困ることはありません。</p>
<p>DDDの記事を見ているとJavaやKotlin、Scalaだったり、一部フレームワーク独自構文を使ってDDDを実装しているものも多いため、今回はTypescriptで実装するための方法を記事にすることで、Node.jsを使っている方や、Typescriptを使っている方に参考になればと思い、書かせていただきました。</p>
<h1>この記事で書くこと・書かないこと</h1>
<h2>書くこと</h2>
<ul>
<li>ドメインイベントをTypescriptで実装する方法</li>
</ul>
<h2>書かないこと</h2>
<ul>
<li>ドメインイベントを始め、DDDに関する説明</li>
</ul>
<h1>シナリオ</h1>
<p>求人作成した際に、求人のデータなどを把握することができる求人レポートを生成することができる</p>
<h3>簡易ドメイン図</h3>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/d788e481-82e5-4a50-90d5-36177a978ec8%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-1914.46.59.png" alt="スクリーンショット2022-12-1914.46.59.png"></p>
<h3>イベント周りの処理フロー図</h3>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/9f479852-ad4c-40cd-90b6-b57992fc4188%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-1914.53.43.png" alt="スクリーンショット2022-12-1914.53.43.png"></p>
<h1>ドメインイベント</h1>
<p>まずはドメインイベントクラスを実装します</p>
<p>EventListenerでイベントごとに実行する処理を変える必要があるので、nameで判断できるようにします</p>
<pre><code class="language-tsx">export type DomainEventName = 'projectCreateEvent'

export interface DomainEvent {
    name: DomainEventName
}

type ProjectInfo = {
  title: string
}

/**
 * 求人作成イベント
 */
export class ProjectCreateEvent implements DomainEvent {
    name: 'projectCreate' = 'projectCreate'
    projectInfo: ProjectInfo

    constructor(params: { projectInfo: ProjectInfo }) {
        this.projectInfo = params.projectInfo
    }
}
</code></pre>
<h1>ドメインイベントの生成</h1>
<p><code>DomainEventStorable</code> という抽象クラスで、エンティティーがイベントを保持するための機能を抽象化しています。</p>
<p><code>ProjectDomainModel</code>で継承し、create関数の中で <code>ProjectCreateEvent</code> を発火するようにしています。</p>
<pre><code class="language-tsx">export abstract class DomainEventStorable {
    private domainEvents: DomainEvent[] = []

    protected addDomainEvent(domainEvent: DomainEvent) {
        this.domainEvents.push(domainEvent)
    }

    getDomainEvents(): DomainEvent[] {
        return this.domainEvents
    }

    clearDomainEvents() {
        this.domainEvents = []
    }
}

export default class ProjectDomainModel extends DomainEventStorable {
  constructor() {
    super()
    //...
  }

  static create(title: string) {
    //...
    // 
    model.addDomainEvent(
        new ProjectCreateEvent({
            projectInfo: {
                title
            },
        })
    )
  }
}
</code></pre>
<h1>イベント発行処理</h1>
<p>Node.jsにはEventEmitterという標準クラスがあり、イベント処理など行えるので <code>DomainEventListener</code> というクラスを使ってイベント処理をラップしています。</p>
<p><code>DomainEventPublisherImpl</code> はイベントを発行する処理で <code>ProjectRepositoryImpl</code> の関数の引数に渡して、repository内でpublish処理を行うようにする</p>
<p>publishする処理はドメインイベント全体で共通となっているので、ドメインイベントごとに作成する必要はありません。</p>
<pre><code class="language-tsx">import EventEmitter from 'events'

const emitter = new EventEmitter()
emitter.setMaxListeners(0)
export class DomainEventListener {
    static on&lt;T extends DomainEvent&gt;(
        eventName: T['name'],
        callback: (event: T) =&gt; void
    ) {
        emitter.on(eventName as string, callback)
    }

    static emit(eventName: DomainEvent['name'], event: DomainEvent) {
        emitter.emit(eventName as string, event)
    }
}

export interface DomainEventPublisher {
    publish(event: DomainEvent): Promise&lt;void&gt;
}

export class DomainEventPublisherImpl implements DomainEventPublisher {
    async publish(event: DomainEvent): Promise&lt;void&gt; {
        try {
            DomainEventListener.emit(event.name, event)
            new DomainEventEntity(DotEnvConsts.getFcLoggerEnv())
                .setData({
                    eventInfo: JSON.stringify(event),
                    eventName: event.name,
                    time: new DateLib().formatDate(
                        new Date(),
                        'YYYY-MM-DD HH:mm:ss'
                    ),
                })
                .save()
        } catch (e) {
            SentryLib.captureException(e)
            LoggerLib.error(`${event.name}: ${e};event: ${event}`)
        }
    }
}

export class ProjectRepositoryImpl implements ProjectRepository {
  async save(
        model: ProjectDomainModel,
        publisher: DomainEventPublisher
    ): Promise&lt;void&gt; {
    // 保存処理
    model.getDomainEvents().forEach((event) =&gt; publisher.publish(event))
  }
}
</code></pre>
<h1>イベントリスナー</h1>
<p>イベントリスナークラスはドメインごとに複数作成します。</p>
<p>今回イベントを受け取って振る舞いを定義するのはProjectReportになるので、 <code>ProjectReportListener</code>として作成して受け取ったイベントの振る舞いを定義しています。</p>
<pre><code class="language-tsx">export class ProjectReportEventListener {
  
  constructor(private repository: ProjectReportRepository) {
        DomainEventListener.on&lt;ProjectCreateDomainEvent&gt;(
            'projectCreate',
            (event: ProjectCreateDomainEvent) =&gt;
                this.callback(event)
        )
  }
  
  private callback(event: ProjectCreateDomainEvent) {
    // repositoryを使って、ProjectReportのsave処理を行う
  }
}

// index.ts
createConnection().then(() =&gt; {
    app.listen(DotEnvConsts.getAppPort(), () =&gt; {
        LoggerLib.debug(`Start on port ${DotEnvConsts.getAppPort()}.`)
        // Event Lisntenerを起動
        new ProjectReportEventListener()
    })
})
</code></pre>
<h1>まとめ</h1>
<p>今回はNode.jsとTypescriptを使って実装する方法を書きました。</p>
<p>TypescriptはkotlinやScaleなどと比較すると型システムとして足りない機能などありますが、ジェネリクスなどをうまく使うことでやりたいことを達成することができます。</p>


Node.jsとTypescriptでドメインイベントを実装する

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


Recent Articles

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

【TypeScript / satisfies】型注釈(type annotation) はもういらない？

【package.json】バージョンにつける「^」「~」は何を意味するのか？

Another works × SmartHR 【FRONT-END DEEP DIVE】イベントレポート

Another works / HRBrain【Front-end Meetup 2023 】イベントレポート

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

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

BigQueryのビューでDWHを作る

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

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

Node.jsとTypescriptでドメインイベントを実装する

Another worksテックブログの裏側

Recent Articles

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

【TypeScript / satisfies】型注釈(type annotation) はもういらない？

【package.json】 バージョンにつける「^」「~」は何を意味するのか？

Another works × SmartHR 【FRONT-END DEEP DIVE】イベントレポート

Another works / HRBrain【Front-end Meetup 2023 】イベントレポート

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

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

BigQueryのビューでDWHを作る

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

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

Node.jsとTypescriptでドメインイベントを実装する

Another worksテックブログの裏側

【package.json】バージョンにつける「^」「~」は何を意味するのか？