You just got another sub this is exactly the type of content I love. Fast, efficient and clear. Looking forward to satisfies but agreed that it should be the default implementation.
What a banger release! I've been waiting for the 'in' operator fix for a long time, and the 'satisfies' operator is something I didn't realize I needed badly! I'm not sure about auto-accessors, I don't see the point of using that instead of regular properties. Great stuff nonetheless.
It's very useful for when you want to add logic to getting or setting an attribute. Normally you'd have to add a function and then mass replace all setters to the new function. With auto-accessors, you can add the logic without having to mass replace any code. The way you get & set remains unchanged while you did add getter and setter logic
I've never seen your content before, very nice video! The satisfies operator seems like it would have been incredibly useful for some things I was working on about a month ago, so I can't wait to try it out.
Thanks for the explanations! I read this article when TS 4.9 became RC. Really nice to refresh it in my memory after 4.9 is released! Please keep going with such videos! And thanks for the amazing TS tips!
I guess, the satisfies operator could also be used to strongly type inline objects passed as "any" arguments or into "any" fields. If so, this feature is highly appreciated. I used to create generic helper method to enforce the type of an inline object, which was a hassle an looked weird.
Anyone wanting a behavior similar to 'satisfies' in an older TypeScript version can use a utility function that looks like this... const satisfiesType = () => (s: S) => s; type RGB = [number, number, number]; /* use it like this */ const test = satisfiesType()({ red: [123, 42, 255], blue: '1', green: '0', }); /* 'test' is of type - {red: [number, number, number], blue: string, green: string} */ Paste it in your ide to view it properly ;)
it's dumb that i need satisfies. It should work like that by default. If i say it's a string or tuple, if i write a string it should be a string, if i write a tuple it should obviously be that tuple or it should error out.
It should not work like that by default imo. There’s no guarantee that the typing will stay the same, especially since the declared typing literally says it could be one type or another.
The issue with doing it automatically is that Typescript would have to maintain two types for any annotated assignment, the type of the annotation (the `const variable: Record< ... >`) and the specific type of the object at instantiation ` = { asdf: ... }`. This would be difficult and slow.
It should not behave that way by default. Without an operator like satisfies, typescript would not be able to tell you if you are performing a type-unsafe operation. That is why without satisfies, you must use the if statement to narrow the type so that the compiler can be certain that the value will be the type you are treating it as. What satisfies is doing is leaving the objects type as it would have been inferred, but placing a constraint on it to say that this type must SATISFY the shape of the following type. This way the actual type is as narrow as possible (it knows that property is RGB and not string), but also that the inferred type would be able to cast cleanly into that satisfied type.
When you want to add extra logic like validation to certain fields. So inatead of having to create a function like obj.setX(...) and validating in there. You use the auto-accessor and users can just do: obj.x = ... and it'd still run the validation. It's also very useful if you want to add said validation later on. Having to add a function and then mass replacing all the uses of the attrbute is a lot of work. With auto-accessors you can add the necessary logic wothout having to change any getter or setter code
I think that type declaration behaviour should be "statisfies" behaviour. I mean, what's the point to use the type declaration over "satisfies" keyword if "satisfies" is better?
The Next GetServerSideProps type issue really annoyed me for so long
ปีที่แล้ว
Re: Watching via file system events - Are you sure this affects VS Code?I always assumed that VS Code has its file watching mechanism and does not rely on typescript cli to observe for changes, in particular as VS Code typescript observes changes even if you do not save the file. I do see this affecting 'tsc --watch'. Re: getServerSideProps - Couldn't have they made getServerSideProps generic function with props as type parameter? Seems like something that would work nicely with existing Typescript version (note: I've never worked with next so I don't know if this is maybe not possible for some reason)
1. Yes, because VSCode relies on a language server 2. No, because then you'd be _declaring_ the types, not _inferring_ them. The latter is much better because you don't need to specify the type twice.
I can confirm it has a huge impact on IDEs. I'm running Webstorm, and in development we have 3 different local servers running with typesafety. Webstorm went from hogging 70% of my CPU 24/7 when running all those servers to basically 0% at idle with TS 4.9. Gamechanger.
You mean like 'as const' does? I don't think so, it just narrows the type to what it would infer if you had assigned a value without explicit type information, while simultaneously checking that it satisfies the given type.
It's very useful for when you want to add logic to getting or setting an attribute. Normally you'd have to add a function and then mass replace all setters to the new function. With auto-accessors, you can add the logic without having to mass replace any code. The way you get & set remains unchanged while you did add getter and setter logic
Because you don't always _want_ the satisfies behaviour. const record = {} satisfies Record; record.name = 'Matt'; With colon, this will work. With satisfies, it won't.
I see that colon gives you flexibility to reassign values within an object. However in the specific case of a union type within an object, it should always be the case that react should be able to infer right type within the union from the object literal. I think in this case they should've made the colon operator be able to deduce that in its own.
Why isn't "satisfies" just the default behaviour? Now you can do it the wrong way (defining a type) or do it the right way (satisfy a type). It's so... double. And it doesn't make intuitive sense at all.
@@mattpocockuk I've worked with TS for the past 6 years now, mostly full-time, at companies like Apple and Amazon, as a senior engineer. But your reply takes a ton of brainpower to attempt to dissect ;) In my case I need to work with it in practice before it "clicks." But man, I love your content so much. If you could perhaps go a little deeper into "satisfies" and how to make it an intuitive decision to use (or not use), I think other people might also benefit from it.
Guess what? The old code can no longer support the new libraries due to TypeScript and framework upgrades. Ok, we're going to upgrade the framework. Guess what? Now the libraries cannot work because they are not compatible with newer frameworks. Due to the rapid upgrading of frameworks and principles in TypeScript, the maintainers cannot manage to update the libraries and follow every change! Even with 5+ years in JS, I can't solve the problem with any tool and I don't have time to develop my own! Congratulations! We got nowhere! The JS world is collapsing right now and there is nothing we can do!
![F.HERO Ft. JSPKK x ลำไย ไหทองคำ x M-PEE - ไม่สนิทบิดหมด (Thai Riders Anthem) [Official MV]](http://i.ytimg.com/vi/kPJZ0UihBfk/mqdefault.jpg)
Your explanation always amazes me. Thanks, Matt. Waiting for more. :)
You just got another sub this is exactly the type of content I love. Fast, efficient and clear. Looking forward to satisfies but agreed that it should be the default implementation.
That gSSP example was excellent, thank you for that!
What a banger release! I've been waiting for the 'in' operator fix for a long time, and the 'satisfies' operator is something I didn't realize I needed badly! I'm not sure about auto-accessors, I don't see the point of using that instead of regular properties. Great stuff nonetheless.
I'm pretty sure auto-accessors are going to be useful when the decorator proposal finally gets implemented.
It's very useful for when you want to add logic to getting or setting an attribute. Normally you'd have to add a function and then mass replace all setters to the new function. With auto-accessors, you can add the logic without having to mass replace any code. The way you get & set remains unchanged while you did add getter and setter logic
I've never seen your content before, very nice video!
The satisfies operator seems like it would have been incredibly useful for some things I was working on about a month ago, so I can't wait to try it out.
Wow, when I suggested it, I didn't think you would actually do it.
Thanks for the explanations!
I read this article when TS 4.9 became RC. Really nice to refresh it in my memory after 4.9 is released!
Please keep going with such videos!
And thanks for the amazing TS tips!
Definitely keep coming out with this content. You are great at making it!
I want to see it, can't wait
I guess, the satisfies operator could also be used to strongly type inline objects passed as "any" arguments or into "any" fields. If so, this feature is highly appreciated. I used to create generic helper method to enforce the type of an inline object, which was a hassle an looked weird.
Satisfies is really good!
Amazing explanation thanks!!
great video, Matt! can you bring more content about satisfies?
Thank god for the 'in' operator, it has frustrated me so many times!
OMG, bumping our repos to 4.9 right away
Cool content , hello from Minsk 👋
Hello from Oxford!
That's my man tells about typescript
Cheers buddy!!!
Really Good Features :)
Thattttsss goood ❤
Thanks for the video!
Anyone wanting a behavior similar to 'satisfies' in an older TypeScript version can use a utility function that looks like this...
const satisfiesType = () => (s: S) => s;
type RGB = [number, number, number];
/* use it like this */
const test = satisfiesType()({
red: [123, 42, 255],
blue: '1',
green: '0',
});
/* 'test' is of type - {red: [number, number, number], blue: string, green: string} */
Paste it in your ide to view it properly ;)
What is that ^? comment, where can I find documents about it?
Great content!
it's dumb that i need satisfies. It should work like that by default. If i say it's a string or tuple, if i write a string it should be a string, if i write a tuple it should obviously be that tuple or it should error out.
i think it's the way UNION works. now you can have an `optimal` version of it but you probably won't need to switch every UNION you have today
It should not work like that by default imo. There’s no guarantee that the typing will stay the same, especially since the declared typing literally says it could be one type or another.
@@flygonfiasco9751 if its const and not any. It should behave like that.
The issue with doing it automatically is that Typescript would have to maintain two types for any annotated assignment, the type of the annotation (the `const variable: Record< ... >`) and the specific type of the object at instantiation ` = { asdf: ... }`. This would be difficult and slow.
It should not behave that way by default. Without an operator like satisfies, typescript would not be able to tell you if you are performing a type-unsafe operation. That is why without satisfies, you must use the if statement to narrow the type so that the compiler can be certain that the value will be the type you are treating it as. What satisfies is doing is leaving the objects type as it would have been inferred, but placing a constraint on it to say that this type must SATISFY the shape of the following type. This way the actual type is as narrow as possible (it knows that property is RGB and not string), but also that the inferred type would be able to cast cleanly into that satisfied type.
Do you know any cases when auto-accessors should be used instead of regular properties?
When you want to add extra logic like validation to certain fields. So inatead of having to create a function like obj.setX(...) and validating in there. You use the auto-accessor and users can just do: obj.x = ... and it'd still run the validation.
It's also very useful if you want to add said validation later on. Having to add a function and then mass replacing all the uses of the attrbute is a lot of work. With auto-accessors you can add the necessary logic wothout having to change any getter or setter code
nice explanation, thx a lot, btw, getserversideprops is get dumped in next13
Neither dumped or deprecated - still fully supported in pages!
This also works for loaders/actions in Remix, too.
I think that type declaration behaviour should be "statisfies" behaviour. I mean, what's the point to use the type declaration over "satisfies" keyword if "satisfies" is better?
The Next GetServerSideProps type issue really annoyed me for so long
Re: Watching via file system events - Are you sure this affects VS Code?I always assumed that VS Code has its file watching mechanism and does not rely on typescript cli to observe for changes, in particular as VS Code typescript observes changes even if you do not save the file. I do see this affecting 'tsc --watch'.
Re: getServerSideProps - Couldn't have they made getServerSideProps generic function with props as type parameter? Seems like something that would work nicely with existing Typescript version (note: I've never worked with next so I don't know if this is maybe not possible for some reason)
1. Yes, because VSCode relies on a language server
2. No, because then you'd be _declaring_ the types, not _inferring_ them. The latter is much better because you don't need to specify the type twice.
I can confirm it has a huge impact on IDEs. I'm running Webstorm, and in development we have 3 different local servers running with typesafety. Webstorm went from hogging 70% of my CPU 24/7 when running all those servers to basically 0% at idle with TS 4.9. Gamechanger.
What extension is that gives that comment for what the type is?
wrapping getStaticSideProps with satisfied while accessing Contentlayer resulting error: ReferenceError: allPosts is not defined
Sounds like you need to add some extra parentheses somewhere.
Does 'satisfies' allow TS to figure out the values of compile time constants? Im not sure I fully understand how its semantics work
You mean like 'as const' does? I don't think so, it just narrows the type to what it would infer if you had assigned a value without explicit type information, while simultaneously checking that it satisfies the given type.
im pretty sure that it actually doesn’t change the returned type at all, it only makes sure the value can satisfy the type provided
Am I missing something or are auto-assessors just bloating the code? How are they different from class fields?
It's very useful for when you want to add logic to getting or setting an attribute. Normally you'd have to add a function and then mass replace all setters to the new function. With auto-accessors, you can add the logic without having to mass replace any code. The way you get & set remains unchanged while you did add getter and setter logic
Really, TS didn't use filesystem events before? Basically every bundler used it for ages.
Many bundlers still don't, like esbuild. It's faster in some cases to poll - not always clear cut.
Lol the amount of bollocks ive introduced into the code base just to get around what that satisfies keyword is for is ridiculous
shouldnt satisfies be the default typescript behaviour?
The best typescript is the one you don’t write.
Why couldn't they just put this more intelligent typing into the colon operator directly? Why make a whole new syntax for it with "satisfies"
Because you don't always _want_ the satisfies behaviour.
const record = {} satisfies Record;
record.name = 'Matt';
With colon, this will work. With satisfies, it won't.
I see that colon gives you flexibility to reassign values within an object.
However in the specific case of a union type within an object, it should always be the case that react should be able to infer right type within the union from the object literal. I think in this case they should've made the colon operator be able to deduce that in its own.
Why isn't "satisfies" just the default behaviour? Now you can do it the wrong way (defining a type) or do it the right way (satisfy a type). It's so... double. And it doesn't make intuitive sense at all.
What if you need to reassign to the type? Perhaps another branch of the union? Satisfies should not be default behaviour.
@@mattpocockuk I've worked with TS for the past 6 years now, mostly full-time, at companies like Apple and Amazon, as a senior engineer. But your reply takes a ton of brainpower to attempt to dissect ;)
In my case I need to work with it in practice before it "clicks." But man, I love your content so much. If you could perhaps go a little deeper into "satisfies" and how to make it an intuitive decision to use (or not use), I think other people might also benefit from it.
@@mahadevovnl Agree, I've got a video cooking on when NOT to use it!
Bro save your head asap.
Guess what? The old code can no longer support the new libraries due to TypeScript and framework upgrades. Ok, we're going to upgrade the framework. Guess what? Now the libraries cannot work because they are not compatible with newer frameworks. Due to the rapid upgrading of frameworks and principles in TypeScript, the maintainers cannot manage to update the libraries and follow every change! Even with 5+ years in JS, I can't solve the problem with any tool and I don't have time to develop my own! Congratulations! We got nowhere! The JS world is collapsing right now and there is nothing we can do!
I love Rust