TypeScript Meetup #4に参加しました。
TypeScriptでテストコードを徹底的に型推論する
テストを書く時overloadしているものなどだと型定義を追うのが大変でanyを使いがち. Mapped Types, Conditional Typesを駆使するとよい
いやー型に厳密な言語は読み込むコード量多くて大変ですね. JavaScriptにしよう(おい
tslibとimportHelpersの基本と、async functionの実行時エラー収集で困った話
async functionはECMAScript 2017から。transpile targetが2015だと__awaiterに変換されgeneratorを使っている。defaultだとファイルごとに重複するのでbundleサイズが大きくなりがち。importHelpers flagをつけると重複が減り、最終的なbundleサイズを小さくできる。
application内エラーをrethrowすると最終的にブラウザが拾うのでエラートラッカーで簡単に管理できる. ただ、同期的関数と非同期関数だと同じエラーを投げても挙動が違うのでターゲットバージョンの違いの影響を受ける。
bundle size小さくしたいという要望はどこでもあるので実践的。内部の挙動を把握できてよかった。
Azure Static Web Apps と Visual Studio Codespaces で快適な TypeScript 環境を構築する
Azure Static Web Appsはプレビュー期間は無料。Microsoft LearnにStatic Web Appsもあり、sandbox環境で試せる。プルリクエストのプレビュー機能があり自動でstaging環境にデプロイ可.
Visual Studio Codespacesでdevcontainer.jsonを使うとチームで拡張を共有、強制できる
競合はFirebase Hostingですかね。Heroku Review Appsの競合もAzureに欲しい
Nuxt+aspida+Expressで作るTypeScript大統一システム
サーバーサイドとクライアントをTypeScriptで統一して開発できるfrourioを作った. 通常のfrontend frameworkに追加でserver dirがある構成。TypeScript界隈のRails的なものを目指している。
aspida, JSONのAPIの仕様を静的に検査できるというのは便利ですね。
GraphQLでも思うけどバックエンド的にはfrontendのAPI callの仕様が愚直になるほどModel.all叩くことが簡単になりそうでアクセス負荷こわい
所感
JSONのスキーマチェックは昔似た様な事を少し考えてAPIに対応するJSON Schemaを対応するlocationに置くconventionを作ればAPIの定義が不要な世界が最終的な形なのではと思ったことがあります。
Railsでdb:migrateするとschema.rbが作られてモデルファイル自体にはカラムの定義は不要ですね。同じ事をfrontend流に解釈するとAPIのスキーマファイルがサーバー側に置かれていればAPI call前にフロントエンドでfetchしてモデルの定義みたいなものを書かなくてもそのまま使えるというか。
まだアイディアがボヤッとしているので時間見つけてやってみたい。
