Another works Developers Blog

<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 を使おう

<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】 バージョンにつける「^」「~」は何を意味するのか？

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


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>


#TypeScript

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

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

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

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

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

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

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

Another worksテックブログの裏側

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

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

#TypeScript

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

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

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

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

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

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

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

Another worksテックブログの裏側

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

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

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