ToC

• 何を学ぶか
• TypeScriptとバンドラ、リンター、フォーマッタ
• nestjs+graphqlのサンプル
  • 使われているパッケージメモ
  • model
• Edge Workerってなんじゃらほい
  • クライアントの拡張
  • ユースケース
• tailwindcss実践入門
  • ユーティリティクラスのメリット 　　　　　　　　　　　　　　　　　
  • 使い方
  • preflightの概念
• 出てきたpackage

何を学ぶか

WEB+DB PRESS vol.133がTypeScriptやTailwindcssについて特集していた
サンプルもあったので、勉強になった内容をメモとして残す

TypeScriptとバンドラ、リンター、フォーマッタ

リンターにi11yに関するものがあるのが学びだった
babelや各ツールの立ち位置と、あまり触れていなかったSWCやTurbopackの立ち位置についても学べた
SWCがbabelを置き換えるものだと思ってなかったんだよなぁと(tsのトランスパイラの一つだと思っていた)

ASTを複数のツールが作るので効率が悪いというのはRomeが作られた経緯から認識していたが、SWCとTurbopackの組み合わせが近い感じになることや、esbuildがトランスパイラとバンドラを兼任していて早いことはちゃんと理解できていなかった

全体的にRustが強くて、今後Rustでプラグインを書くことになるかもしれないと思うと、
ちょいちょいRustを勉強しているのも悪いことではないなと思った

nestjs+graphqlのサンプル

使われているパッケージメモ

• jsonwebtokenというjwtを扱う名前まんまなpackageがある
  • 仕様にしたがってissやaudといったパラメタがpayloadとして指定可能
• その他に passport-jwt と @nestjs/passport を使って、tokenのvalidateを実現してるっぽい

model

• DBの文脈のモデルなのでtypeormのEntityデコレータがくっついてる
  • と思いきや@nestjs/graphqlのObjectTypeもくっついてた
  • 両方のmodelが同じ構造体に対応するということなのかな
  • 各attributeにも、typeormとgraphqlのデコレータがそれぞれ付いている
    • 動的に計算されるものにはgraphqlのデコレータのみがついてておもろい
• ObjectTypeデコレータ
  • これが付与されるとGraphQLのtypeとして解釈される
  • コードファーストな仕組みなので、modelの定義からschemaが決まるみたい
• Fieldデコレータ
  • graphqlで取得するFieldにはFieldデコレータをつける
  • GraphQLのIDやIntといった型は、明示的にデコレータで指定が必要 @Field(() => GraphQLISODateTime) のようになる
• リゾルバの定義
  • *.resolver.tsとして定義されている
  • これらの定義は*.module.tsにまとめられ、更にmoduleはapp.module.tsにまとめられ、mainでNestFactory.createに渡されていた
• リゾルバとrepository
  • DBへのqueryを投げるRepositoryは、*Serviceというクラスにまとめられている
  • でもってリゾルバがこのサービスを呼び出して結果を受け取るという感じ
  • serviceとrepositoryがわかれているけど、NestJSの仕組みだからっぽい？
• dto
  • *.input.tsという名前になっている。gqlのmutationを投げるときに使われる
    • IsUUIDやIsNotEmptyといった、validation pipeという仕組みが class-validator にある。こいつらもデコレータ

覚えるまでにだいぶハードルが高い感触を受けた。DIの仕組みなどは充実しているので、なれるとサクサクいけるのかも

Edge Workerってなんじゃらほい

• クラサバの中間にある存在。リバプロのようなイメージだけど、そこにコードでロジックが書ける
• エッジで動くのでCDNとリクエストをハンドリングするところは同じ。ロジックを書いてキャッシュ制御の仕組みをより柔軟にできる
  • CDNでもできることはあるが、自前で書けることがポイントのようだ

クライアントの拡張

• より柔軟なWebWorkerとして、EdgeWorkerを捉えることができるようだ
  • ServiceWorkerは裏でrequest投げてこっそりキャッシュしたり、リクエストをフックしてmockのデータを返したりしてるけど、あれの強い版？
  • 当たり前だけどクライアントに閉じてるかどうかという差がある。キャッシュヒット率はEdgeのほうが高い。色々飛んでくるからね
    • その他ServiceWorkederはcacheの無効化がむずいという側面もあるそう

ユースケース

• GAのようなトラッキングスクリプトや、タグマネージャのような仕組みをEdge上で動かすユースケースが面白そうだった
  • パフォーマンスも良くなるし、プライバシーも向上するそう
  • UIスレッドでの同期処理が減れば広告Scriptの鬱陶しさも軽減するとか

tailwindcss実践入門

このブログはcss modulesにするかtailwindにするか悩んで、生のcss書く練習要るやろ！ と思って前者にしたのですが、後者に触る機会が減ってしまったので渡りに船

ユーティリティクラスという考え方が面白い。AtomicCSSという近い（というか元祖?）の考え方もあるみたいだけど、クラスに再利用可能な定義だけ持たせて、それを組み合わせて作る
最終的にはただのcssになるし、使わない属性はpargeできるので効率も良い。らしい

本の内容とは別に、そもそも学習コストが高いだのなんだのという批判もあるようだが、その辺の良し悪しに付いては触ってから考えようと思った

tailwindを使う場合コンポーネントは後から見出される。これは実際のデザインを作る過程に近いらしい。答えがない状態でデザインを模索する過程がまずあり、その後コンポーネントとして切り出される、という流れ

ユーティリティクラスのメリット 　　　　　　　　　　　　　　　　　

本には多くのメリットが記載されていて興味深い
再利用性が高いので結果的にCSSのサイズが小さくなる。同じスタイルを当てたいときに使い回せるから、こういうメリットが出てくる

インラインcssに見えるが、メディアクエリや擬似クラスも使用可能

使い方

webpackやviteを使う場合はpostcssとautoprefixerを組み合わせるのが一般的らしい

Tailwind Play というお試し環境があるらしい。最近はなんでもplaygroundがあっていい時代だ...（逆にもう無いと普及しないのかも）

preflightの概念

@tailwind base;で適用されるスタイル
リセットCSS的なものと、ブラウザ間のさいを埋めてくれる(打ち消す?)らしい

ここに書いてある

videoやimgがblock要素として扱われるようになっていたり、画像は親の幅に広がるようになっていたりおもろい

出てきたpackage

• concurrently
  • npmスクリプトを並行して走らせられるパッケージ
• jsonwebtoken
  • jsでjwtを扱うためのpackage
• passport-jwt
  • jwtによる認可を行うpackage。Auth0のSDKでも使えるとか(依存があるわけではない)
• browser-sync
  • ファイルの変更を監視してブラウザのリロードを行ってくれるpackage
  • 複数のブラウザで操作の同期なんてこともできそうそうな
    • 複数端末でも可能だそうだから便利だなぁ
    • 普段はchromeでデスクトップ向けにしかアプリ作らないから知らなかった