My company is locked into some pretty poorly typed 3rd party libraries. Contractually we have to use. So needing to cast types is a necessity. It's a computer scientist purest vs business time is money situation. The business always wins
I created my Branded types by using the intersaction & with an object with a property of type never and i don't have to do any crazy stuff to make it works with prmitives type Longitude = number & { __whatever?: never } const x: Longitude = 123 I created a utility type called "FromType" that does it and instead of using a normal property i used a unique symbol to avoid naming clashes declare const derivedTypeSymbol: unique symbol; export type FromType = T & { [derivedTypeSymbol]?: never };
@@syntaxfm First, because there is no such thing as "too much boilerplate". You configure a snippet and you have it in 3 keystrokes. Second, because using basic types is just OK for small projects with few entities. The time you start working with multiple people, and have tens of different entities you are going to, at some point, either mix them or not know what that string is actually representing. The amount of problems nominal types catch at compile time is to meaningful to say "They're not work it".
Was listening you on podcasts apps usually. Nice to watch you now, guys!
My company is locked into some pretty poorly typed 3rd party libraries. Contractually we have to use. So needing to cast types is a necessity. It's a computer scientist purest vs business time is money situation. The business always wins
Totally. Some times casting just gets the job done.
You could potentially write the type definitions
@@13odmanyeah probably that's what they do with the 'as Sometype' castings
So now with Invokers, html WILL become the most popular ”programming language” 😅
Will be irrefutable
I created my Branded types by using the intersaction & with an object with a property of type never and i don't have to do any crazy stuff to make it works with prmitives
type Longitude = number & { __whatever?: never }
const x: Longitude = 123
I created a utility type called "FromType" that does it and instead of using a normal property i used a unique symbol to avoid naming clashes
declare const derivedTypeSymbol: unique symbol;
export type FromType = T & { [derivedTypeSymbol]?: never };
Nice!
First?
Those who don't understand the value of branded (AKA nominal types) are just worse developers, period.
What makes you say that?
snooty Typescript dev is hilarious, do you get paid in Monopoly cash too?
@@pookiepats I don't take any other currency
@ 🤣 great response
@@syntaxfm First, because there is no such thing as "too much boilerplate". You configure a snippet and you have it in 3 keystrokes. Second, because using basic types is just OK for small projects with few entities. The time you start working with multiple people, and have tens of different entities you are going to, at some point, either mix them or not know what that string is actually representing. The amount of problems nominal types catch at compile time is to meaningful to say "They're not work it".