TypeScript 5.3 First Look
Вставка
- Опубліковано 10 лип 2024
- TypeScript 5.3 is coming, and today we got the first hints on what it might contain. Here's the full breakdown!
00:00 Intro
00:20 Import Attributes
01:23 Throw Expressions
02:13 Isolated Declarations
03:39 Narrowing in Generic Functions
04:33 Loose Autocomplete
05:10 Fetch in Node
05:38 Outro
Full article: www.totaltypescript.com/types...
Become a TypeScript Wizard with my free beginners TypeScript Course:
www.totaltypescript.com/tutor...
Follow Matt on Twitter
/ mattpocockuk
Join the Discord:
mattpocock.com/discord - Наука та технологія
The one thing I am realy excited about is fetch XD
But one thing I would love typescript to add is strongly typed throw errors
Ideas for your TypeScript book:
- Teach the TSConfig well with sensible defaults
- Mention the annoying caveats with React, etc and how to deal with them.
- Idea for a more advanced exercise, maybe for near the end of the book: "Try to implement a Repeat that outputs TString repeated TNum times."
TSConfig is definitely in there. Caveats with React are in my React module on TT.
@@mattpocockuk Thanks, I'll watch those modules, awesome
Think my fav with all this is the throw expression
I hope you can also do return, yield, continue and break in the same way.
I actually used this expression a lot in regualar js some time back before using ts. When moved code to ts, it gave me that exact error. I was perplexed and just thought maybe there's something i m not aware of that this messes up since I never saw it used anywhere and had to refactor code. 😅 happy to see ts catching up on this.
@@emmanuelmahuni8163 it's not that TS is catching up.. It's NEVER been possible in JS (and currently still isn't)..
You may have wrote the code, but trust me, it wasn't working..
I'm really glad to discover you. Thanks to you Matt I'm improving a lot 👍👍👍
Thanks for this summary. Looking forward to work with 5.3
Really excited about the narrowing
Great work 🎉
great informative video, looking forward to your TS book :)
this was worth the watch just to see some of those hacks!
For anyone running into the @typescript-eslint/ban-types: Don't use `{}` as a type. `{}` actually means "any non-nullish value" problem.
You can get around this error by doing this instead. type IconSize = "small" | "medium" | "large" | (string & NonNullable);
This strips undefined and null from unknown which leaves you with {}, This is equivalent to the code in the video but you no longer have to disable the rule in your editor. Hope that helps :)
Hi Matt, can you also check prisma on how we can create props base on the prisma setup, that would be great too 😊
I would like to have "throws" declarations in typescript. This way we could better describe functions that should have a try / catch block around their call.
This won't be added, for many reasons - should record a video about this.
Similar to checked exceptions in Java. Possibly one of the most complained about features of Java though. I remember Phpstan has an interesting approach to it.
Doesn’t this kind of go against the pattern of functional programming? Not to say that’s really at play here, but feels like this new “throws” declaration leans back towards the classic try/catch style of code.
@@mattpocockuk I will look forward to it. That there is currently no way of telling that a function can error is one of the biggest downfalls of JS and TS doesn't provide any improvement here.
@@barneylaurance1865 I rather have some way of telling a function errors then none. Uncatched errors are a nightmare in JS/TS.
Interesting to hear about that string union trick. Might be IDE specific, since I’ve just done `| string` before and WebStorm autocompletes just fine
I guess that's because Webstorm adds some of their own stuff on top of the default language service.
They just recently included their own version of the "pretty-ts-errors" lib into the thing and it's already pretty good.
Even cooler than throw expression would be return expression. The throw case can already kind of achieved by wrapping it in a function, but with return that is not possible.
I hope they allow import statements with extentions
can't stop the TS-train 🔥🔥🗣🗣🗣🗣
they substituted the previously deprecated with keyword for import-type-assertions???
The proposal changed from assertions to attributes.
Let em ship
autocomplete for "| string" lets go!!
throw expression and (string & {}) 👌👌👌👌👌
Well, the autocomplete is indeed a cool feature. Linter has always been pissed about an intersection type with a {} 💩
I don't understand the IconSize example. If you want other values, then why not include them in the union?
You want _arbitrary_ values, like '10px' or something.
It's kind of an auto complete for the members but you can still assign any other string. This is useful if you don't know all members or it's just not worth to have all of them.
@@mattpocockuk I guess this is a old issue because now it's fixed with template literal types.
I’d rather have nullish coalescing throw. It is way obvious in null pointer context: (example): null ?? throw new Error(‘…’);
Once this proposal lands, you can also have nullish coalescing throw, or throw in a ternary.
Don't really get import attributes. If the argument is security, then you could have a compiler flag that checks if the extension that you are trying to import is actually what it claims to be.
If the counter argument to this is that you want to do it selectively, then something like: import json from './foo.json' with check; would be more clear.
But I guess this gives freedom to import any extension and check for any extension at the cost of boilerplate.
import attributes are part of javascript not typescript so there's no compiler checks.
and in web land, extensions don't determine types, mime types do so a foo.json could resolve to a javascript module with a javascript mime type
Nice but can browsers finally start allowing import json?
@@codernerd7076 well Apple is one of the companies who already do support it. Firefox and Opera are the only ones that do not. Safari has done since IOS 15 or ALMOST 2 YEARS and you say they are fighting against it, brainwashed person
Finally they fixed throwing errors in conditional statements...
Not personally a fan of the proposal for imports. If you give developers the option, most won't use it and the rest will probably use it wrong. Since there's no reason I know of to ever import, for example, JSON with type Javascript, only ever with type JSON, just infer the "with" type based on the file extension and do the security check behind the scenes.
And with that, you just automatically boosted the security of every Typescript application from 5.3 onwards without any developer needing to do anything different. _That_ would be a good change.
This is not because people "make a JSON file that has JS in it", it's to ensure that the code will only accept JSON from the server, so a malicious actor can't swap out the content of a JSON file with something else.
Oh they are fixing the string autocomplete thing? I have a lint rule that disallows using {}, so I guess the eslint disable comment there is now officially temporary :)
#NotSoHotTake:
Errors as value > Throwing. The fact that you can't know if a function is going to throw or not and the inconsistency in the "standard" library are incredibly frustrating! Return an error type like Go and Rust, have strong prototypes like the Option or Result in Rust, either way would be 100 times better than throwing errors.
Throw expressions are very weird, an expression whose value is never used and one that only exists for its side effects? weird imo.
It's an expression whose type is never, which makes sense because the expression never evaluates to anything. It would be very handy to use a `throw` expression as the default at the end of a long chain of optionals, like this:
type X = null | { y?: { z?: string } };
const f = (x: X): string => x?.y?.z ?? throw new Error('Cannot get x.y.z');
It was implemented in PHP 8.0, which came out in 2020. Maybe a little weird, but very useful and I can't see any reason not to have it.
Has anybody tried Matt's courses ? On Reddit people disliked his courses a lot since it's pricey and don't teach much, all he did was just giving problems that will never be appeared in real life or anything like that ? I am confused here. His content on youtube is too good to even believe that.
The free tutorials should give you a taste!
www.totaltypescript.com/tutorials
@@mattpocockuk Thanks, I'll give it a try. Please excuse me if I say anything that can make you sad, it's just pretty pricey for asians like me so I have to consider. again thanks!
@@brangtoggez6363 No worries pal, it's absolutely an investment. It's ideally designed for your work to pay with an education budget.
Any problem sometime will ocur in real life.
I feel like people who have hard time with "problems that will never appear in real life" just dont understand generalization / abstraction (or are not aware of it), like if you learn to solve problem X, and you need to solve Z, your mind could get to answer using parts of X (and you wont even necessarily know your brains did that, they can do lot of stuff on the background)
string & {} 🤯
Well, the updates start shippin' and they don't stop shippin'…
Needing to include the dom lib types just to use native fetch has always been really annoying
They need to simplify TS, not make it more complicated... unless it increases DX and developer ergonomics.
Thats exactly what theyre doing here lol.
@@philheathslegalteam not so sure...
I think Next version should be: Integrating TypeScript with Copilot marks a new era where AI handles type management, freeing developers for more innovative tasks. Let's redefine our workflow, making types the domain of AI, and elevate creativity for developers!
it's 2023!
Actually the opposite if you don’t have an interface copilot has a stroke and even tried to divide by 0 and such
Typescript moving too far ahead from Javascript the main function is types. But they now act like it's their language and trying to force Javascript features to be added.
I can live with that. It acts like a polyfill until JS catches up. The fact that you can write obj.with?.optional.props and then tell TS to output valid es5 with a bunch of `(_a = obj.with) === null || _a === void 0 ? void 0 : _a.optional.props` to make it work.. LOVE IT..
And TS being the forerunner means they can just polyfill until JS catches up in like ES2045 or what ever.
And I wouldn't mind that one bit!
exceptions as an expression ? i hope this never happens.
you either deal with exceptions, which is a side effect, or with errors as value, but why mix both ?
i think this is really stupid and yet another pile of junk on top of javascript.
Imagine thinking JavaScript of all things in the planet is perfect and needs no changed in top of it to make it bearable 🥶
“Type”Script taking types too seriously
Throw Expressions would be amazing...you can have them today with.....
const X = Y || (() => { throw Error('nope') })()
Posted a comment above about nullish coalescing throw (imo, would look more obvious) const { x } = obj ?? throw new Error() or const x = obj.x ?? throw new Error()