DEV Community

I've been writing TypeScript without understanding it -- pt. 2

vincanger on July 09, 2024

Give me a Break. I'm still learning! Hey everyone. I'm back. And, yeah, I'm still making n00b TypeScript mistakes 😢 But luckily I've...

Read full post

John Landgrave • Jul 10

This works for basic exhaustiveness checks, but when things are more complicated (or depend on two things, e.g. a boolean called isSubscribed in combination with an optional plan tier) we've found that ts-pattern is a great library for handling that kind of stuff in a way where the compiler still gives you an exhaustiveness check on your enum, for example.

Also, it allows you to disambiguate arguments, variables, API responses, etc. at run-time structurally (similarly to the way TS does it at design time) which is pretty neat. And you don't have to go full nerd and really understand what things like "contravariance" mean!

vincanger • Jul 11

oh wow. nice! I'll have to check this out.

Juraj • Jul 9

Love this series!
Keep em coming 😄

vincanger • Jul 9

Glad you like it :)

Matija Sosic • Jul 9

I love this "Watch me learn TypeScript" series, and a relaxed tone you use with it. Plus I also learn stuff :)

vincanger • Jul 9

It's never too late to teach an old dog new tricks 🐶

Chris S-D • Jul 11

Very cool idea. Actually leveraging your lack of understanding of something to sell it and also learn at the same time.

One convention I'd like to mention is that for your PaymentPlanId enum, it is commonly assumed that ids represent a non limited identifier which is typically not a good idea for an enum. A more common approach to indicate that an identifier is limited to a short list that will likely not change much is Code. So, it might be better to call it PaymentPlanCode.

Again, this is just a common convention. There is no rule that says you must do it this way, however, you'll often find that conventions like these help convey meaning without bloating code.