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.
@ryan_t_brown2 ай бұрын
I really like your channel, especially how you showcase the problem your solving in a quick and simple way before getting to the solutions.
@Typed-Rocks2 ай бұрын
Thank you very much :)
@markyip5542 ай бұрын
The pattern is known as 'Parse, don't validate'.
@parlor31152 ай бұрын
He did validate, though
@volvopls2 ай бұрын
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!
@albert219942 ай бұрын
Cool! I’ve learned something today!
@Typed-Rocks2 ай бұрын
That‘s awesome to hear. Thank you, that‘s what I want to achieve 👍
@__azt2 ай бұрын
This is really neat.
@Typed-Rocks2 ай бұрын
Glad you like it 🙏
@bahaaalhalabi89402 ай бұрын
Interesting idea,i will try it out,i usually use asserts but without the branded primitives. Good video 👍
@lukewood57512 ай бұрын
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-Rocks2 ай бұрын
This is an awesome idea. Will think about making a video about it 🙏
@lukewood57512 ай бұрын
@@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.
@muchis2 ай бұрын
nice! typescript just recently released type validations with regex. Would this change your approach in this video knowing that?
@Typed-Rocks2 ай бұрын
That‘s a great question. Maybe will also create a video about it. Thank you 🙏. I will look into it
@cotyhamilton2 ай бұрын
Is the // ^? type check thing from an extension?
@Typed-Rocks2 ай бұрын
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
@_WyreZ2 ай бұрын
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)?
@Perer876Ай бұрын
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.
@nomoredarts89182 ай бұрын
It's unfortunate that this is not built-in in TS
@thirtykey2 ай бұрын
Wouldn’t typescript then think that it has a __brand property even though it does not, potentially causing a runtime error?
@skylerockspecial2 ай бұрын
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.
@thirtykey2 ай бұрын
@@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.
@Kitulous2 ай бұрын
if you don't try to use it on a string while it's coerced to the Email type, no it won't. @@thirtykey
@coder_one2 ай бұрын
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-Rocks2 ай бұрын
I often use error handlers which handle non recoverable errors. The asserts can also be wrapped in try catch blocks to handle them properly👍
@coder_one2 ай бұрын
@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.
@xorlopАй бұрын
@@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.
@wertig69252 ай бұрын
🤘🏻🤘🏻
@guicercal2 ай бұрын
no no, thanks!
@joeyfinkel2 ай бұрын
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?
@Typed-Rocks2 ай бұрын
@@joeyfinkel This check of course was just a demonstration and in reality would be more complex. 😁
@joeyfinkel2 ай бұрын
@@Typed-Rockswhat would be a practical example to use a branded type like this?
@Typed-Rocks2 ай бұрын
@@joeyfinkel a phone number for example which can have different prefixes and lengths
@evanbelcher2 ай бұрын
@@Typed-Rocksor just an email that actually checks all of the restrictions for an email address, as you implied.
@bahaaalhalabi89402 ай бұрын
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.
@gabrielbianchi22462 ай бұрын
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.
@Typed-Rocks2 ай бұрын
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 👍