🙌

Todoアプリを作ろうと思ったら想定より難航した話

2023/05/23に公開

概要

Todoアプリを作成しました。コンセプトは「タグで管理できる」Todoアプリです。タグによる絞り込みが可能で、フォルダ構造をとるTodoアプリに比べてタスクの確認がより柔軟に行えるのが特徴です。

リポジトリ

https://github.com/sub-t/tag-todo

アプリケーション(GitHub Pages)

https://sub-t.github.io/tag-todo/

単純なアプリケーションではありますが、ここまでこぎつけるのに苦労しました。

結論

本文にこれといって内容がないので、結論から申し上げます。アプリケーションを作成する際には、その大小の如何に関わらずよく調査を行い、よく計画を練ることが非常に重要です。当然のことではありますが、これができておりませんでした。

当初の想定に関して

作成当初に想定していたことを箇条書きにまとめます。

  • 見た目は二の次で機能が実装できれば良い
  • タスクやタグの作成画面でフォームが必要となるので、当然React Hook Formを使うものだと思っていた
  • Zodはマスト(バリデーションの実装有無によらず)

ライブラリ選択

現在の技術スタックは

  • 見た目:Radix UI + Stitches
  • 状態管理:Jotai

このような感じですが、当初想定していた技術スタックは異なりました。

  • 見た目:Chakra UI (+ Emotion)
  • 状態管理:Zustand、React Hook Form + Zod

React Hook Formを状態管理ライブラリとすることに抵抗はありますし、ましてやZodをこの括りに入れることには違和感がありますがあまり気にしないでください。

なぜ難航したのか

Todoといったらアプリ開発のチュートリアル的な立ち位置であり、制作難度は事実かなり低いです。なぜ、このTodoアプリの作成に難航したのでしょうか。

見た目に関して

作成当初、使用を想定していたのはChakra UIでした。選考基準はコンポーネントの多さです。Radix UIはスタイリングを自前で行う必要があり正直面倒でした。スタイルがあらかじめ当たっていて、かつMUIでないものといったら当時の私にとってはChakra UIが全てであったので、1年ぶり近くを経て利用することにしました。

が、早々に破綻します。原因は、日時の取得方法とタグの複数選択機能の実装でした。Chakra UIにおける日時の取得方法といえばInputコンポーネント(type="datetime-local")です。これが要望に適うものではなかったので、雲行きが怪しくなりました。加えて、複数選択機能(MUIやMantine UIのMulti Selectに当たるもの)ですが、Chakra UIに直接該当するものはなく、実装にも一苦労しそうだということなので、方針を切り替えることを考えました。結果、デザインの変更もあり自前でスタイリングをゴリゴリ書いていくなら、慣れているRadix UIでということでChakra UIの使用を断念しました。

状態管理に関して

デザインや実装方針の変更が状態管理方針にも波及しました。当初はできるだけ純粋なForm要素を用いてフォーム(入力画面)を構成することを考えていました。しかし、フォームの構成要素のうちタスク・タグの本文を入力する部分以外が純粋なForm要素でなくなったため、React Hook Formを用いる恩恵がかなり薄れてしまいました。getValuessetValueを駆使して、非制御コンポーネントとしてInputを監視しつつ、他のカレンダーや複数選択用のコンポーネントの状態を監視することは可能でした。ただ、そこまでしてReact Hook Formのバリデーションをはじめとした便利機能にあやかりたいかと考えるとそうではなかったので、React Hook Formの使用を取りやめました。また、このとき同時にZodの使用も断念します。このアプリケーションにおけるスキーマの定義の重要性が低かったためです。

結局、フォームの状態管理をZustandに一任することにしたのですが、後にJotaiに切り替えます。タスクとタグの一覧管理・永続化だけで済むならZustandのままでよかったのですが、ダイアログやドロワの実装の際にも状態管理ライブラリの力を借りたくなるわけです。特定の範囲に状態の管理対象が絞りこめればコンテクストでも構わないわけですが、影響範囲が広範囲に及びそうだったので、状態管理ライブラリにこれらコンポーネントの状態の管理を任せることにしました。こういう細かい使用を考え始めると、Zustandに比べJotaiを使いたくなるわけで、結果後者に乗り換えることにしました。

あとがき

そもそも、このアプリケーションはこれ自体が目的ではなく、簡便なアプリケーションを作ってテストを書く練習をすることが目的でした。ただ、実装や仕様の変更が相次いで起こったので、結局テストが書けておりません(現状、エラーが出ていてテストが正常に動作しないことも原因ではありますが)。

また、Chakra UIからRadix UIに乗り換えたうえで、さらにMantine UIに乗り換えようとも考えています。Mantine UIにはCalendarMulti Selectが備わっていて、しかも独自のuseFormフックを使用することでZodとつなぎ合わせて検証を行ってくれる(はず)ということで、Mantine UIが最適解であったと考えています。

加えて、ZustandからJotaiに状態管理ライブラリを移行したわけですが、Jotaiに比べRecoilのほうが単純に情報が多いので、こちらを取るべきだったと後悔しています。Jotaiを使えば、Recoilではキーを指定しなくて済むだなんてことを考えていましたが、データの永続化を行う際のatomWithStorageでキーを指定する必要が出てきたので、ちょっとした嬉しいポイントも瞬く間に消えて無くなりました。

Discussion

ログインするとコメントできます