My criteria on whether I should trust someone's tips or not is by their navigation on their IDE, as this is a sign of not only experience but mastery. You are trustworthy.
This reminds me of the book by Scott Wlaschin - Domain Modelling Made Functional. It is for F# but after seeing this video I believe the idea can be applied for TS as well. Really cool stuff!
It seems like you could use this to actually make some nicer types for numbers. Something like `Integer` for array accessors, `NotZero` for division, etc. Pretty neat - never have seen someone use these typescript features in this way.
@@Typed-Rocks I think the challenge would be balancing value vs ergonomics. For example, is it really worth checking every single number you use to index into lists for validity? Maybe - but probably not. It might be worth it if you're doing something that needs to manipulate indices a lot, such as an array-mapped heap. But it does seem a bit rare that this would be worth it. Still, very cool concept that might be worth exploring more.
Yes, it's an extension I've written called "WiTT" You can find it in the jetbrains marketplace: plugins.jetbrains.com/plugin/23294-witt--typescript-type-hints-like-in-the-ts-playground
Is it possible to create a dynamic asserts function based on a union type? ie: type MyType = {salmon: string} | {bacon: string} const myVar: MyType = { bacon: string }; somehowAssertAsSalmonOrBacon(myVar); // myVar (asserted as {bacon: string}, but could be asserted as {salmon: string} if it was initialized that way)?
That would not work and not make sense. Maybe, what you want is type inference. In your example, you can do this: const myVar = { bacon: 'foo' } // myVar will be inferred/asserted as { bacon: string } or wherever you initialized. Also, you cannot create a dynamic assert function based on a type cuz all type information is erased at compile time.
No, __brand is a variable holding a symbol. The symbol is the key, not ‘__brand’ itself. Important part is the square brackets around the key in the extra object, this sets the value of a variable as the key.
@@skylerockspecial yea I know. You know what I mean. That type will be assumed to have that extra field, referenced by that symbol even though it doesn’t.
Branded types are nice, and I am using it a lot, but the problem I have with functions using "asserts" in TypeScript is that such free and randomly throwing of errors inside programs is one of the worst practices and anyone who writes code like this should be ashamed of themselves.
@Typed-Rocks Unfortunately there is no agreement between us here. In my opinion and that of my project team, handling errors with "try-catch" is the worst nightmare. Errors should be treated only as values - this is the safest way to work with errors, because we secure the program and guarantee its stability.
@@coder_onetry catch turns errors into values… Typed-Rocks is saying they throw and handle it with error handlers. I think Typed-Rocks would agree errors as values is awesome, and that throwing with try catch is effectively errors as values because a throw wrapped in try catch gives you opportunity to turn errors into values. I don’t think there is many people who say try catch is cool or nice. I think we all hate it lol.
If the check for the email is only checking if the email contains an “@“, why not just create type Email = `${string}@${string}` and then move the asserts function into the send email function?
He just demonstrated the type-checking, at the end this is just for typescript. In practice you add actual email checking, like for example zod schema for an email inside that function. The includes @ is just a basic example.
Looks overcomplicated in my opinion. Just write JavaScript with zod. No need to add so many types and make working with strings more complex in my opinion.
You can always add zod to the typeguard function. But of course it always depends what you want to achieve. Sometimes you don‘t want to add another library to your project which the team has to get used to. But zod is great nonetheless 👍
My criteria on whether I should trust someone's tips or not is by their navigation on their IDE, as this is a sign of not only experience but mastery.
You are trustworthy.
I really like your channel, especially how you showcase the problem your solving in a quick and simple way before getting to the solutions.
Thank you very much :)
The pattern is known as 'Parse, don't validate'.
He did validate, though
This reminds me of the book by Scott Wlaschin - Domain Modelling Made Functional. It is for F# but after seeing this video I believe the idea can be applied for TS as well. Really cool stuff!
Cool! I’ve learned something today!
That‘s awesome to hear. Thank you, that‘s what I want to achieve 👍
This is really neat.
Glad you like it 🙏
Interesting idea,i will try it out,i usually use asserts but without the branded primitives. Good video 👍
It seems like you could use this to actually make some nicer types for numbers. Something like `Integer` for array accessors, `NotZero` for division, etc. Pretty neat - never have seen someone use these typescript features in this way.
This is an awesome idea. Will think about making a video about it 🙏
@@Typed-Rocks I think the challenge would be balancing value vs ergonomics. For example, is it really worth checking every single number you use to index into lists for validity? Maybe - but probably not. It might be worth it if you're doing something that needs to manipulate indices a lot, such as an array-mapped heap. But it does seem a bit rare that this would be worth it. Still, very cool concept that might be worth exploring more.
nice!
typescript just recently released type validations with regex. Would this change your approach in this video knowing that?
That‘s a great question. Maybe will also create a video about it. Thank you 🙏. I will look into it
Is the // ^? type check thing from an extension?
Yes, it's an extension I've written called "WiTT" You can find it in the jetbrains marketplace: plugins.jetbrains.com/plugin/23294-witt--typescript-type-hints-like-in-the-ts-playground
Is it possible to create a dynamic asserts function based on a union type? ie:
type MyType = {salmon: string} | {bacon: string}
const myVar: MyType = { bacon: string };
somehowAssertAsSalmonOrBacon(myVar);
// myVar (asserted as {bacon: string}, but could be asserted as {salmon: string} if it was initialized that way)?
That would not work and not make sense.
Maybe, what you want is type inference. In your example, you can do this:
const myVar = { bacon: 'foo' }
// myVar will be inferred/asserted as { bacon: string } or wherever you initialized.
Also, you cannot create a dynamic assert function based on a type cuz all type information is erased at compile time.
It's unfortunate that this is not built-in in TS
Wouldn’t typescript then think that it has a __brand property even though it does not, potentially causing a runtime error?
No, __brand is a variable holding a symbol. The symbol is the key, not ‘__brand’ itself.
Important part is the square brackets around the key in the extra object, this sets the value of a variable as the key.
@@skylerockspecial yea I know. You know what I mean. That type will be assumed to have that extra field, referenced by that symbol even though it doesn’t.
if you don't try to use it on a string while it's coerced to the Email type, no it won't. @@thirtykey
Branded types are nice, and I am using it a lot, but the problem I have with functions using "asserts" in TypeScript is that such free and randomly throwing of errors inside programs is one of the worst practices and anyone who writes code like this should be ashamed of themselves.
I often use error handlers which handle non recoverable errors. The asserts can also be wrapped in try catch blocks to handle them properly👍
@Typed-Rocks Unfortunately there is no agreement between us here. In my opinion and that of my project team, handling errors with "try-catch" is the worst nightmare. Errors should be treated only as values - this is the safest way to work with errors, because we secure the program and guarantee its stability.
@@coder_onetry catch turns errors into values… Typed-Rocks is saying they throw and handle it with error handlers. I think Typed-Rocks would agree errors as values is awesome, and that throwing with try catch is effectively errors as values because a throw wrapped in try catch gives you opportunity to turn errors into values. I don’t think there is many people who say try catch is cool or nice. I think we all hate it lol.
🤘🏻🤘🏻
no no, thanks!
If the check for the email is only checking if the email contains an “@“, why not just create
type Email = `${string}@${string}`
and then move the asserts function into the send email function?
@@joeyfinkel This check of course was just a demonstration and in reality would be more complex. 😁
@@Typed-Rockswhat would be a practical example to use a branded type like this?
@@joeyfinkel a phone number for example which can have different prefixes and lengths
@@Typed-Rocksor just an email that actually checks all of the restrictions for an email address, as you implied.
He just demonstrated the type-checking, at the end this is just for typescript. In practice you add actual email checking, like for example zod schema for an email inside that function. The includes @ is just a basic example.
Looks overcomplicated in my opinion. Just write JavaScript with zod. No need to add so many types and make working with strings more complex in my opinion.
You can always add zod to the typeguard function. But of course it always depends what you want to achieve. Sometimes you don‘t want to add another library to your project which the team has to get used to. But zod is great nonetheless 👍