アーキテクチャ系

componentsのprops。を

interface Props {
  title: string
  description?: string
  to: string
  icon?: string | any
  children?: any
  layout?: 'vertical' | 'horizontal'
}

こういう形ではなくて、
interface Props ; CustomTypeみたいな形にしている。
ので、typeが溢れる。

ただ、モジュール内の型として、型を定義することで舵を切ったため。再考が必要だということ。

これはただ、マッピングが様々な所でされるという懸念を表明しただけっぽい
hooksで管理、まとめた。以上。決。

SWRの扱いづらいところ。

• keyの指定とsrevices層呼び出し関数の関連性
• keyがfalsyな時発火しないをkey以外の指定材料がある時(詳細でidとか)
• optionalの分離
• GET的なPOST（これはそもそもswr設計意図に反している）

common削除。
決

utilとcommonの話をしよう。

基本的にこう。
commonは共通コンポーネントまたは、業務ロジック。
utilは汎用的。

これを考えると、commonは削除しなくてもよかったかもしれない。
ただ、features階層の構成とsrc階層の構成的に判断したということにしておこう。

そして、utilについて。

共通処理をまとめるディレクトリを作成すると、
「なんでもかんでも入れる」になってしまいがちである。
メンテナンスしにくくなるので、

意識としては、

• 絞ること。汎用的すぎる関数を作らない。
• どこでその関数を使う想定であるか明記する。

これは業務仕様ここに書くべきことではない。決

何の問題点があって、この記述をしたのか忘れた。

apps Routerとpages Routerを混同させながら記述したのだろう。
RSCの話している時はapps Routerの話として良いだろう。

ということで、RSCどうのこうのは一旦放置。

dynamic import は？導入しなかったけど、できるところはあるし、すぐ導入できるように設計はしたはず。