Closed6

TS会議まとめ（2025）

kuairenkuairen

TS会議の動画が公開されているので、勉強がてら面白いなと思った動画をまとめる

kuairenkuairen

"良い"TSのコードを書く為のマインドセット - Kei / TSKaigi2025

https://www.youtube.com/watch?v=3ZwQN_OIHBQ

まとめ

  • TypeScriptはの型システムは「構造的型付け」
  • 集合論的な動きで型が判断される
  • なんでこんな動きの型システムを採用しているのか？ ⇒ 大元の言語がJavaScriptだから
  • 動的言語であるJavaScriptとの親和性を高めるために構造的型付けを採用している

The Soundness

Soundness（健全性）

  • コードの中の健全性

実行前のコード（型）が
実行中にも同じ状態であるという様。
"実行時とコンパイル前は同じ型である。"

Usability（実用性）

Soundnessと引き換えに、コードの実行自体を優先しているさま

Mindset

  • SoundnessとUsabilityのトレードオフを"意識的"に行うこと

Usabilityを優先

  • サーバー側でスキーマ and/or テストが担保されている
  • チームメンバーがサーバー側のコードにアクセスできる
  • プロジェクトがPoC
  • プロダクトがインターナル向け

Soundnessを優先

  • BackendとFrontendがしっかり分かれている
  • APIがサードパーティ製
  • 会社（チーム）の規模が大きく、誰がコードを触るかわからない
  • プロダクトが大きく、どこから依存されてるか追うのが不可能

感想

型のことを理解してないと、Backend / Frontendのチーム分担にも影響がありかなり影響度が大きいなと思った

kuairenkuairen

型推論の扉を開く―集合論と構造的型制約で理解する中級へのステップ - 栃川晃佑 / TSKaigi2025

https://www.youtube.com/watch?v=1jH4pDcEH-0

まとめ

  • 型の区別や判定に関しては2つのアプローチがある
    • 名称的型付け: 型同士が同一かどうかを判断する際に、その名前が重要な役割を果たす（JavaやC#）
    • 構造的型付け: 型の名前ではなく、その構造に着目して型の区別や互換性を判定する（TypeScript）
  • TypeScriptの構造的型付けは集合論で考えと良い
  • 役立つポイント①: 知識の吸収がしやすくなる（any, unknown, never等）
  • 型エラーの理由が瞬時にわかる

感想

上記動画を見た後にこちらを見たので、いい感じに補完された

kuairenkuairen

機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する - NoritakaIkeda / TSKaigi2025

https://www.youtube.com/watch?v=WJKxlM6WWU0

まとめ

  • 前提: コンポーネント分割の観点はいろいろあるが、「ドメインや要件の観点」での話

凝集度とは

モジュール（関数、クラス、パッケージなど）が単一の目的にどれだけ集中しているか、内部の要素（変数、関数など）がどれだけ密接に関連しているかを表す指標

  • 凝集度は高い、低いで表現され、凝集度の高いモジュールは堅牢性、信頼性、再利用性、可読性などの点で好ましい
  • UIの観点では、論理的凝集（低）と機能的凝集（高）くらいしか出会わないのでその2点を比較

論理的凝集

似たような処理をフラグや条件で切り替えて1つにまとめている状態（避けたい）

  • コンポーネントに条件分岐が多く点在するようになり、可読性が落ち、保守のコストが増加する
  • 共通化としてやりがち

機能的凝集

モジュール全体が単一な目的のために構成されている状態（理想的）

  • コンポーネントの責務が明確になりがち
  • 共通化したい余地は残る

違い

機能的凝集は責務ごとにコンポーネントを分け、論理的凝集は条件分岐で責務を切り替える

なぜ機能的凝集を目指すのか

  • 機能の修正や追加に耐えやすい
  • 要件とコードが一致しているか確認しやすい

実際の機能的凝集パターン

  • ①ルーティングで分岐できる
    • ログインユーザーのロールごとに類似画面を表示する
    • 新規作成画面と編集画面
  • ②分岐がコンポーネント内から排除できない
    • ディレクトリページ: APIから取得したデータや型をもとに分岐する
      • 出し分けの責務を親コンポーネントに委譲する
      • 出し分けの責務を持ったコンポーネントを作る
      • mapの中で出し分ける
    • 通知機能: サイト横断でトリガーされるため、UIは似てるがちょっとした見た目や遷移先が違う
      • APIのスキーマ型をts-patternでだし分けると機能的凝集になりやすい
      • .exhausive()を使うと型の抜け漏れを防げる
  • ③共通化の欲が出てきた（エンジニア的な嗅覚）
    • 分割したい箇所の実装量、複雑さ
    • 分割したい箇所がFigmaでグルーピングもしくはコンポーネント化できるか
    • 分割したい箇所がAPIのオブジェクト型の塊と一致しているか
    • チーム内の合意に従う
    • 要件定義的にも同じといえるか（意味的に同じか）
    • APIのオブジェクト型的に同じといえるか
  • ④コンポーネント分割単位との競合する場合
    • 商品詳細画面: 差分が小さい類似機能
      • 差分が小さい場合責務が薄いコンポーネントができてしまう
      • ロールやTypeのような意味的な命名のフラグではなく、機能を表示するかしないか等のフラグであれば、機能的凝集にしやすい

感想

あまり意識せずに論理的凝集で書いてしまっていたので、今後機能的凝集も意識しながら書いていきたい。また最後の意味的なフラグではなく、機能的なフラグを使う点も目から鱗だった。

kuairenkuairen

フロントエンドがTypeScriptなら、バックエンドはPHPでもいいじゃない - 富所 亮 / TSKaigi2025

https://www.youtube.com/watch?v=tSvIMnBrAuI

まとめ

  • フロントエンドはいつ生まれたのか？ - 2010年前半
  • それ以降、フロントエンドはどんどん高度・複雑化して専門分野として独立
  • バックエンドエンジニアの強み - インフラ、DB、サーバー構築、CI/CD（がいつの間にか職域に...）
  • フロントエンドエンジニアの強み - HTML/CSS/JS、アクセシビリティ、UI/UX
    • 変化が激しく、キャッチアップも大変。バックエンドまで領域を伸ばせる人は少ない。

バックエンドエンジニアはなぜ必要？

  • BaaS、IDaaSがあれば不要なのでは？
  • セキュリティの担保、非同期処理・ジョブ実行、ビジネスロジックの隠蔽、外部システム連携

BaaS、IDaaSについて

  • メリット・デメリットの慎重な検討が必要
  • アプリケーションの性質や運用体制によって正解が異なる
  • BaaS、IDaaS剥がしという職が存在するらしい

フロントエンドとバックエンドは分離すべきか？

  • 基本的には分離すべき
  • Information Leakage
    • モジュールが、自分の責任範囲を超えて他のモジュールの知識や制約に依存してしまっている状態
  • あとから分けるの無理
  • アーキテクチャの柔軟性
    • ビルドプロセスの分割
    • バージョンアップ、脆弱性対応

感想

  • 最近Next.jsを中心にモノレポが復活してきているが、やはり基本は分離すべき
  • モノレポのバージョンアップとかを実施して、大変さを実感してみたい
  • モノレポで「速さ」を重視すると長期的にはデメリットしかない
    • 個人開発、PoC、使い捨て社内アプリケーション？
このスクラップは3ヶ月前にクローズされました