Type-Level TypeScript by is my new favorite thing and you should 100% use your education budget on it. Here's part of a URL parser 🤯
type-level-typescript.com
Conversation
![type PathToParams<path, params = {}> =
path extends [infer first, ...infer rest]
? first extends `:${infer param}`
? PathToParams<rest, params & Record<param, string>>
: PathToParams<rest, params>
: params
type res1 = ParseUrlParams<"user/:userId">;
type test1 = Expect<Equal<res1, { userId: string }>>;
type res2 = ParseUrlParams<"user/:userId/dashboard">;
type test2 = Expect<Equal<res2, { userId: string }>>;
type res3 = ParseUrlParams<"user/:userId/dashboard/:dashboardId">;
type test3 = Expect<Equal<res3, { userId: string } & { dashboardId: string }>>;](https://pbs.twimg.com/media/FlFN9SeWAAENe2l?format=jpg&name=large)
Replying to
This game is my (old) favorite thing but you probably can't use your education budget on it. You should buy it anyway!
5
That's an interesting take.
I usually use -expect error to assert expected failures in type usage. Respectively, no failures if I expect autocompletion to work properly.
3
But can we add types to the type system? Need another runtime layer on top of typescript to deal with that glaring omission.
Quote Tweet
My TSConf 2021 video is up: "Statically Prevent 404s". I build real-world types live, combining advanced TS features (mapped, conditional, and template literal types). It also introduces the statically-typed path library used in production by @exec_prog. youtube.com/watch?v=KRMJIi
No doubt about it! Type-Level TypeScript is a must-have for any developer and investing time on it should be a no-brainer. The URL parser example is incredible.
1
3
