JSON ファイルと Vue の間に中間層を設ける

[nard-tech]

👏 解決する issue / Resolved Issues

• JSONファイルとVueの間に中間層を設ける #1100

📝 関連する issue / Related Issues

• 非機能要件（可読性・拡張性・設計） 問題点・改善点の整理 #2790
• JSONファイルとVueの間に中間層を設ける #3008

背景

#3008 は 2020年4 - 5月のもので，そのまま merge することはできないため，#3008 を引き継ぐ形でこの PR を作成した．

⛏ 変更内容 / Details of Changes

• JSONファイルの型や変換コードを quicktype で自動生成し，libraries/auto_generated/data_converter 以下に配置

📸 スクリーンショット / Screenshots

見た目の変更はなし

---

issueの関連付けを修正 — @MaySoMusician (2021/03/14 22:15)

[nard-tech]

#3008 の commit との対応関係

• 0c7fe0f add: install quicktype, lodash, types
  • d604b49, 5a5024a で対応
• a0a9e95 add: data type generator
  • a220240 で対応
• 37b542c add: tsconfig exclude tool directory
  • 対応しない
• 7f935b8 add: generate data type
  • 1698676 で対応
• 587339f add: .eslintignore
  • 2b9ba23 で対応
• 13e10b7 add: Repository layer
  • e31253e で対応
• eb4fba2 add: Instance Registry
  • 9825d38 で対応
• 8b36fe1 update: use Repository
  • fc79cf1, f18d802, 3bc7edd, b5ef176, c4f0a82, cc5797d, 5b8e8ca で対応
• d60cd8c fix: alias
  • 記法については各 PR で対応
• e79f95f fix: lint
  • 対応しない
• 4197bf3 update: use generated type
  • 対応しない
• 1017d50 add: enable ESLint cache
  • 対応しない
• edcb529 update: move directory
  • data_converter ディレクトリについては a220240, 2b9ba23, 750fb23 で対応
  • utils については対応しない
• 1aa691c update: create directory for auto generated files
  • data_converter ディレクトリについては a220240, 2b9ba23, 750fb23 で対応
• 5322d94 update: README
  • cab20ca で対応
• c96f628 update: remove express and move to devDependencies
  • 対応しない
• e1f206f fix: use import path alias
  • 対応しない

[nard-tech]

@MaySoMusician

quicktype で自動生成されたファイルについては、冒頭に「自動生成されたファイルであり、直接編集してはいけない」みたいな（ちょうど yarn.lock の冒頭にあるようなやつ）注意文を付け足すことは可能なのでしょうか？

直接編集することで注意文を追加し，後に更新するときは注意文が削除されないように，更新された行だけ git で add, commit すればよいと思いますが，もっと仕組み化したいところです．

もし quicktype のオプションなどで独自の文言を追加できそうならやっておきたいところです

ちょっと厳しそうですので，GitHub Actions で danger を回すとよいと思います．
libraries/auto_generated/data_converter 以下のファイルが更新された場合は pull request 上に警告を出すことができます．

[MaySoMusician]

@MaySoMusician

statuses() に対する型アノテーションなどは一律不要になります

確かにそうなのですが，エディタ上で

  computed: {
    statuses(): IInfectionMedicalCareProvisionStatusData {
      return this.infectionMedicalCareProvisionStatus.data

の IInfectionMedicalCareProvisionStatusData の部分から直接 libraries/auto_generated/data_converter 以下に書かれている interface の定義に飛べる利便性を考慮してこのようにしています．

(略)

string のようなプリミティブな型については書かなくてもよいと思いましたが，全体の統一性を考慮し，すべてに型を付けています．

@nard-tech 確かに利便性はありますが、 type Computed = の方で指定している型と computed 内のアノテーションの型で同じ型を2度書くのは冗長だと思います。片方を更新し忘れるとTSエラーこそ出ますが（Vetur導入時）、エラーメッセージもあまり直感的ではない（原理的には正しいメッセージなのですが）のでちょっと大変そうです。VSCodeなら type Computed = の方の型アノテーションから定義に飛べますが、それだとまずいですかね？

[MaySoMusician]

#6102 (comment) の件以外については、僕としては問題ないと思います。
@nard-tech お手数ですがコンフリクトの解決をしていただけると助かります

[nard-tech]

@MaySoMusician conflict は解消しました (e1c56a2)

エラーメッセージもあまり直感的ではない（原理的には正しいメッセージなのですが）

上の画像のようなメッセージのことを仰っているのだと思いますが，直感的でないことはいずれにしろ変わらなさそうです．

型については，わりと好みの問題だと思っていて，Java のようなガチガチの型アノテーションが必要な言語に慣れていると，TypeScript であっても冗長なのを承知の上でしっかり型を記述したくなります．

VSCodeなら type Computed = の方の型アノテーションから定義に飛べます

好みの問題はさておき，結局，問題は「type Computed = の方にカーソルを移動して定義に飛ぶ手間と，重複した型アノテーションを付けてメンテナンスする手間どちらが大きいか」になるかと思います．

機能拡張で新しく computed, data などを追加する場合，既に書かれているコードとその型に注意しながら実装するケースが多くなると思うので，コードから型定義に飛びやすいというのはメリットではないでしょうか．

---

サンプルとして c5d406c を追加しました．

[nard-tech]

この PR が merge されたら #5404 を rebase して作り直したいと思います．

[kaizumaki]

@nard-tech @MaySoMusician フォローありがとうございます 🙏
つまるところ、個々人のコーディングスタイルや使用しているエディタによるのかなと思いましたが、私個人的にはエディタの機能も含め、とても勉強になりました。
とりあえず、この状態でこちらのPRを採用し、またご意見などあればその都度ディスカッションの上、取り入れていくこととしたいと思います。

[kaizumaki]

長いことissueをフォローしていただいてありがとうございます！LGTMです！

[nard-tech]

@kaizumaki こちらこそ，ありがとうございました．