概要
Vueでフォルダツリーを実装することになったのですが、
UIが複雑なので、ロジック部分にもある程度の工夫が求められました。
ここで、Githubでよく見る下記のようなフォルダ階層表示のコンポーネントが参考になりました。

前提
要求、要件は下記のようになっていました。
要求:
- フォルダおよびファイルを階層構造で一覧表示できること
- フォルダごとに配下のファイル数を確認できること
要件:
- フォルダ階層は最大3階層までとする
- 階層構造を表現できるツリー形式で表示すること
- 各フォルダに対し、配下ファイル数を算出・表示すること
- ファイル数は子フォルダ配下のファイルも含めて集計すること
第一案:フロント優先のAPI
画面側で階層構造を作るのはコストが高いので、APIの利用を検討しました。
自分は複雑なUIコンポーネントに対するAPIの設計は初めてだったので、手探りで、画面に寄りそう形で設計。
一旦、バックエンドで階層構造のオブジェクトを完全に作成し返却する形にしました。
ただ、検討していく中で、下記の記事を見ました。コメントにこうありました。
システムが進化するとAPIの利用者は、フロントエンドだけではなくて別のバックエンド(別のマイクロサービス)になりますよ。
その時には、画面仕様に合わせたAPIは後悔しますよ。画面のリニューアルの時もバックエンドの大改修が入って、プロジェクトマネージャーから何でそんなに工数がかかるの?って詰められそう。
画面の為には、Backend For Frontendを挟むとか、REST APIではなくGraphQLにするとかがセオリーかな。
https://zenn.dev/ak_yoshimatsu/articles/backend-api-develop-20260118
なるほど、と。
フロントに依存したAPIは技術負債になる、と。
再利用しやすいAPIがいいと思い、もう少し小さい機能として、リソース指向に分離されたAPIを検討しました。
第二案:使いまわししやすいAPI
まず現状の要件をまとめると、「検索」と「集計」と「階層構造化」に分けられました。
実装においては、Githubの階層表示を参考にしました。
色々触って分析すると、
・フォルダを開くまでは、該当フォルダ配下のデータはフェッチしない
・フェッチするデータは開いたフォルダの直下の情報のみで、サブディレクトリの情報はフェッチしない
という点がとても、参考になりました。
フォルダを開くときに「https://github.com/tramlinehq/tramline/tree/main/app/assets?noancestors=1 」のようなリクエストが発生する。
検索
検索に関しては、現状、検索のAPIがあったのでそれを拡張することで対処しました。
新しいルートを増やすのではなく、検索のServiceクラスを拡張するだけで済みそうとわかりました。
フォルダA > フォルダB > ファイル
というデータがあった場合、
search?first_dir="フォルダA"&second_dir="フォルダA"
というイメージにすることで対応しました。
集計
集計に関しては、それ専用のAPIを新規で用意しました。
これも規模としては小さく、集計の責務だけをもったAPIを設計することができました。
階層構造化
階層構造化については、当初、バックエンドで行おうとしていましたが、
「フォルダを開くまでは、該当フォルダ配下のデータはフェッチしない」という工夫を使用することにしたので
フロントエンドで必要な分だけ階層構造化することにしました。
以上の設計により、整理された設計になったと思います。
まとめ
フロントの特定の機能に対応するAPIの設計として、いい経験ができたなと思います。
今後の業務においても、こういった、小規模の機能開発をやりたいなと思います。
また、アドバイスなどございましたらぜひコメントくださいませ。
※機密情報については一部表現を変えています。
