Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
as(型アサーション)を書く前にできること
Search
maroKanatani
November 16, 2024
Programming
11
4.1k
as(型アサーション)を書く前にできること
TSKaigiKansai 2024
maroKanatani
November 16, 2024
Tweet
Share
More Decks by maroKanatani
See All by maroKanatani
App Router を実プロダクトで採用して見えてきた勘所をちょっとだけ紹介
marokanatani
3
1.9k
長期運用に耐えるフロントエンド目指して
marokanatani
2
45k
S3のキー設計でハマった話
marokanatani
0
1.5k
Other Decks in Programming
See All in Programming
ローターアクトEクラブ アメリカンナイト:川端 柚菜 氏(Japan O.K. ローターアクトEクラブ 会長):2720 Japan O.K. ロータリーEクラブ2025年12月1日卓話
2720japanoke
0
730
「コードは上から下へ読むのが一番」と思った時に、思い出してほしい話
panda728
PRO
38
26k
これならできる!個人開発のすゝめ
tinykitten
PRO
0
100
愛される翻訳の秘訣
kishikawakatsumi
3
320
AtCoder Conference 2025「LLM時代のAHC」
imjk
2
480
リリース時」テストから「デイリー実行」へ!開発マネージャが取り組んだ、レガシー自動テストのモダン化戦略
goataka
0
130
Flutter On-device AI로 완성하는 오프라인 앱, 박제창 @DevFest INCHEON 2025
itsmedreamwalker
1
110
宅宅自以為的浪漫:跟 AI 一起為自己辦的研討會寫一個售票系統
eddie
0
500
Tinkerbellから学ぶ、Podで DHCPをリッスンする手法
tomokon
0
130
TUIライブラリつくってみた / i-just-make-TUI-library
kazto
1
380
大体よく分かるscala.collection.immutable.HashMap ~ Compressed Hash-Array Mapped Prefix-tree (CHAMP) ~
matsu_chara
2
220
AIコードレビューがチームの"文脈"を 読めるようになるまで
marutaku
0
350
Featured
See All Featured
Build The Right Thing And Hit Your Dates
maggiecrowley
38
3k
Fantastic passwords and where to find them - at NoRuKo
philnash
52
3.5k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
122
21k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
The Language of Interfaces
destraynor
162
25k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
130k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.4k
Into the Great Unknown - MozCon
thekraken
40
2.2k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
128
54k
RailsConf 2023
tenderlove
30
1.3k
The Illustrated Children's Guide to Kubernetes
chrisshort
51
51k
The Power of CSS Pseudo Elements
geoffreycrofte
80
6.1k
Transcript
クラスメソッド株式会社 TSKaigi Kansai 2024.11.16 as(型アサーション)を書く前にできること maroKanatani
Classmethod 自己紹介 Frontend Ops ...etc maroKanatani ソフトウェアエンジニア ほぼフロントエンドエンジニア Japan AWS
All Certifications Engineer (2022~2024)
as 使ってますか?
TSのコードレビューをしていて感じること any の濫用はよくない という風潮はある程度広まってきた …しかし as の濫用については any ほど広まってなさそう 有効な場面もあるが、カジュアルに使われることも多い印象
(適切に使っている人には釈迦に説法な話かも) > 理解が浅い人が真似することで良くない使い方が割れ窓的に広がることがある
なぜ as の濫用は良くないのか コンパイラの挙動を上書きしてしまう コンパイラよりも型について理解している場合は as を用いても良い? > 力には責任が伴う 潜在的に
any と同様の副作用があるとも言える >(自分は理解しているつもりでも)チームの他のメンバーは違うかもしれない とはいえ全く使わないのは難しい > スコープを最小限に留める、コメントを書くなどして用法用量を守る あくまで「濫用」が良くない
こんなコード書いていませんか?
こんなコード書いていませんか? いずれもサブタイプ関係にあるスーパータイプを サブタイプで型アサーションしているのが良くない
こんなコード書いていませんか?(修正版)
こんなコード書いていませんか?(修正版) 基本的にはちゃんと型ガードする
タグ付きユニオンを使ったリファクタ
タグ付きユニオンを使ったリファクタ 個別のプロパティをチェックするサンプルが多いが 判別用のプロパティを生やすのも場合によっては有効
zod を使った Scheme First なリファクタ
zod を使った Scheme First なリファクタ 型はスキーマから作成 パースする
インターフェース境界での as には要注意
インターフェース境界での as には要注意 role が string型に推論されるため as を使っている
インターフェース境界での as には要注意 role が string型に推論されるため as を使っている プロパティが増減した場合に 型エラーが発生しない
インターフェース境界での as には要注意(修正版)
インターフェース境界での as には要注意(修正版) 型制約をつける or satisfies を使う
as が必要な例
as が必要な例 result をミュータブルな オブジェクトとして扱っている 参考: 敗北者のTypeScript (https://qiita.com/uhyo/items/aae57ba0734e36ee846a) as が有効なスコープが最小限に留まっている
as を書く前に 型ガードや型制約、satisfiesで済ませられないか? 必要になる根本的な原因は何か? 割れ窓的に広がらないように必要に応じてコメントも書こう 実態に合わせてきちんとメンテすることで読み手側の負荷はきっと下がる その as はなぜ必要なのか? 必要な場合はスコープを小さく
型はドキュメント
ご清聴ありがとうございました