LT
Documentation testsの恩恵(ssssotaさん)
内容メモ
Rustのlinterのソースコード中のドキュメントに関数の入出力が記載されている。
これがDocumentation tests
vite-plugin-doctestなどを用いて、documentation-testを書くことができる
- 良いてん
- ソースのすぐそばにテストコードが記載できる
- ドキュメントに記載したコードを実行して動作が保証できる
- IDEを介して＠動作保証されたサンプルが閲覧できる
ドキュメントにサンプルコードを書いても廃れるし、誰もJSDoc読み書きしていないみたいなことにならないのが良い
しかし、ドキュメンテーションテストは万能ではない。
ライフサイクル関数が必要だったり、mockが必要だったり、UIのテストはかけない。
導入方法は、vite-plugin-doctestをinstallすれば結構すぐに使える
感想
doctestめっちゃいい。。。
今回は、フロントの話だったけど、バックエンドでも書けないか調べたい。
Full TypeScriptだから実現できる世界線(k-ichirofさん)
内容メモ
Full TypeScriptっていいの？→コンテキストによる！
どんなところでマッチ？
- 規模小さめの組織
- ジュニア多め
- エンジニアがフルスタック的に動く
- 個人開発
ではない事例
- front：ts
- back: Go
- infra: Terraform
それぞれ一人みたいな状況。しかし、一人でもかけたら続けられないので危機感があったけど、キャッチアップしながら進められるような余裕もない。
これをfullTsにしたら、結構いい感じに行った。
採用などにも有利に働く
感想
コンテキストによるけど、どんなコンテキストで活きるのかについて知ることができたのがよかった。
確かに個人開発だとしやすそう
Real World Type Puzzle and Code Generation(Yuku Kotaniさん)
内容メモ
型安全 + コードジェネレーター -> Prisma ということで Prisma のコードを読みながら、型がどのようになっているのかを読み解く
$UserPayload型→スキーマから自動生成されている型
GetSelectIncludeResult型関数→ infer して、mappedTypesにして、ゴニョゴニョしている
型パズル 要素分解すると組み立てやすい。
感想
私は今まで基本的な型しかあまり扱って来なかった。ただ、TypeORMの型サジェストとか内部がどうなっているのだろうとか思っていたけど、コードを読み取っていくことで、理解できるものなんだなということを知った。
今回のような複雑な型について、typeormなどの実際のソースを読んでみようと思った。
