Todoリスト育成日記
hajimismディレクトリ構成
hajimismApp Routerで、こうなってる
.
├── app
├── common
│ ├── components
│ │ ├── functional
│ │ ├── layout
│ │ └── ui
│ ├── hooks
│ └── lib
│ └── date
├── model
│ ├── todo
│ │ ├── components
│ │ ├── hooks
│ │ ├── lib
│ │ └── query
│ └── user
│ ├── components
│ ├── hooks
│ ├── lib
│ └── query
├── public
└── styles
ファイルまで書くとこう
.
├── app
│ ├── favicon.ico
│ ├── layout.tsx
│ ├── page.stories.tsx
│ ├── page.tsx
│ └── providers.tsx
├── common
│ ├── components
│ │ ├── functional
│ │ ├── layout
│ │ └── ui
│ ├── hooks
│ │ └── debounce.ts
│ └── lib
│ ├── cn.ts
│ ├── date
│ ├── error.ts
│ ├── fetcher.ts
│ ├── generateId.ts
│ ├── getInitial.ts
│ ├── guard.ts
│ ├── log.ts
│ ├── result.ts
│ └── schema.ts
├── model
│ ├── todo
│ │ ├── atom.ts
│ │ ├── components
│ │ ├── hooks
│ │ ├── index.ts
│ │ ├── lib
│ │ ├── mock.ts
│ │ ├── query
│ │ └── type.ts
│ └── user
│ ├── atom.ts
│ ├── components
│ ├── hooks
│ ├── index.ts
│ ├── lib
│ ├── mock.ts
│ ├── query
│ └── type.ts
app/common/modelで分けてる
- app: routing + page特有のモジュール
- common: どこでも使う、他のプロジェクトにも使い回せる、low-context
- model: アプリケーション特有のモデルに関心があるモジュール、high-context
hajimismfeatures/xxxは「ディレクトリの機能的凝集」という本質的な良さがある一方で、機能同士の結合度が高いとき（例: 閲覧-プレビュー-編集）に分割基準をどこに置くかが難しいという問題があるのでnot for meだった。featuresを単にmodelとするだけで、線引が明確になることに気がついた。
実際workしていると思う。
hajimismモデル定義は model/xxx/type.tsなどでやる
たまたまvalibotでやったけど、valibot良かった
hajimism前まではcomponents/以下だけmodelを置いてて、libとかでもcommonとmodel分けたいなあっていう悩みがあった（正確には、とりあえずapp/でコロケーションさせてたものがページをまたいで使われるようになったときにどこに置くか迷った）のだが、そういう悩みが一切なくなった。
todo/lib/とかはこんなかんじ
hajimismモジュールの命名とかも意識はしてて、例えばuseDeleteTodoはmodel/todo/hooks/delete.tsにおいてある。これをmodel/todo/hooks/useDeleteTodo.tsとかいうファイル名にしないほうがいい。todo/hooks/の時点でuse〇〇Todoが導けるので、〇〇のところをファイル名に書くだけでいい。
hajimismコンポーネントの命名・ファイル名も同様で、なるべくコンパクトで納得感が高いようにしている。
import { TodoTableRow } from "@/model/todo/components/table/row";
model/xxx/以下のモジュールは必ず名前にxxxが入るようにする。commonや他のモデルのモジュールとと区別するため。
hajimismエラーハンドリング
hajimismこの記事を全体的に参考にして、Result型を使っている。
hajimismカスタムエラーを書いて
Result型を書いて（今回はoption-tを使用）
API callを若干抽象化して
エンドポイントごとにquery関数を定義している
hajimismvalibotのsafeParseはもともとResult型っぽいインターフェイスだったが、プロジェクトのResult型に合わせた。
hajimismtry/catch書いてた頃より断然気が楽な感じがする。コントロールできている感じ、というか。
hajimismglobalにDialogを仕込んで、エラーのときはとりあえずDialogを出すようにしている。
shadcn/ui/toastみたいな感じで抽象化してあるけれど、Errorのためのより具体的な呼び出し関数も予め用意している
hajimismisErrの確認のときにほんまにエラーだったらloggingするようにしている。これも完全に最初の記事の受け売り。
hajimismこれもあってもいいかもしれないけどまだやってない
hajimismState設計
hajimismServer StateはTanstack、それ以外のGlobal StateはJotaiでちょこちょこ書いている感じ
hajimismApp RouterのキャッシュとTanstackのキャッシュが二重にあって色々うざいなあって思ってたけどまだちゃんと向き合ってない
hajimismTodoリストをリストのStateだけで持つと各アイテムの要素の変更を書くのがだるいので、atomFamilyを使ってアイテムのStateを分離して保持している。
hajimism二重Stateっぽさは否めないものの、setStateは直感的だし勝手にOptimisticになるし結構気に入っている
hajimismリストStateから各アイテムを変更するのはかなりだるくて、Result使っているとなおさらだった（一度検証しなきゃなので）
hajimismfetchingが絡むとき、T[]に対する操作はTanstackで状態管理して、Tに対する操作はatomFamilyで状態管理するのは、これからもちょくちょく使うかも。
hajimismそういえば、NextのRequest dedupingがうまく効いてなくて、このコンポーネントを複数並べたときにコンポーネントの数だけ/usersへのリクエストが飛んでたことがあった。当時はuseQueryで書いてた。
atomWithQueryにしたことでデータフェッチがコンポーネントの外側で行われるようになったので、1回で済むようになった。
hajimismこゆこと
hajimismいやまあ、Nextが期待通りにworkするのが一番なんだけれど。
hajimismSuspense設計
hajimismページでfetchするとgetServerSidePropsみたいにall-or-nothingになっちゃうのでコンポーネント側でなるべくデータ取得するのは当然として、データ取得層はContainerとして分けるようにしている。
hajimismTanstack Queryはsuspense modeのときにundefinedを消して欲しい
hajimism大体イメージこんな感じになる
some-component
├── container.tsx
├── index.tsx
└── skeleton.tsx
<Suspense fallback={<ComponentSkeleton />}>
<ComponentContainer />
</Suspense>
Containerをコンポーネントの名前に含めることで、どれを<Susupense>で囲うべきなのか明示する。これもESLint rule書けそう。
hajimismデータフェッチもmodel側で完結するので、app側でやることは本当にただの組み立てだけだなーって感じ。
hajimism一方で、コンポーネントの使用箇所ごとにfetchのoptionsを指定し直したかったらそう簡単にはいかなさそう。
hajimismまあそれもRoute Group側の設定で書けばいいのか。
hajimismcontainerもSkeletonもindexからexportしたいのはある
ので、こうでも良いかも。
some-component
├── container.tsx
├── index.tsx
├── skeleton.tsx
└── view.tsx
単純なTodoリストのつもりだけど、それでも作るのこんなにむずいんだなっていう感想を持った。そりゃソフトウェア開発むずいわ。
たぶん10hも手を動かしてないと思うけど、その間にも設計の改善のために右往左往リファクタした。思いがけずいい経験になったし、やっぱり設計に向き合うのは好き。
チーム開発するとなると、設計思想は全員で共有してこそはじめて威力を発揮するので、言語化・布教活動も頑張っていきたい。特にディレクトリ構成みたいな大枠でスムーズに合意したい。
hajimismまだ全然触ってないとこあるし、例えばo-tel入れてみたりOAuth実装してみたりCI/CDちゃんと組んでみたりServer Actions使ってみたりと試せることはたくさんあるので、気が向いたら都度育てていきたい。