TypeScript 5.3 is a no-brainer upgrade
HTML-код
- Опубликовано: 28 июн 2024
- 00:00 Intro
00:28 Import Attributes
01:21 switch (true) Narrowing
02:54 Interactive Inlay Hints
Announcement post: devblogs.microsoft.com/typesc...
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 
Развлечения
For those stumbling in late, I missed this feature for this video because it wasn't mentioned in the release notes:
www.totaltypescript.com/the-typescript-5-3-feature-they-didn-t-tell-you-about
Psyched for your book. Always appreciate these quick updates Matt!
All great features. Thanks for the breakdown as usual Matt.
As usual, great job Matt ! Thank’s 👍
sick animations in this video, well done
Matt, your tutorials are consistently so clear, polished And easy to follow. thank you 🙇
Upgrading Typescript _should_ be very little hassle, but unfortunately we're still stuck on older versions because of dependencies claiming not to support Typescript greater than x version... \*sigh\*
That truly sucks! I wish more library authors would embrace semantic versioning. At least this is not python, where some major libraries have dependencies pinned to patch versions.
Make PR's for those packages to remove the limitation. Or fork it and use your fork.
Easier said than done. Packages that are very slow to update their peer dependencies, are usually also the ones who are very slow to fix things in general or just slow to accept PRs. Forking and using my own fork is also not something I want to do, especially if it's for a company or professional work. So I tend to instead either just live with it, or try to get rid of the library, which of course is also often easier said than done...
Have you considered hosting your own forked versions of deps with upgraded underlying dependencies as your project requires? Depending on the package it might not be the best use of time, but I've done this in the past when absolutely necessary.
Typescript itself doesn't follow semantic versioning. Maybe fix that first
Thank you very much. Good explanations and good video!!! I have subcribed.
Great content!
I did notice some lip-sync issues at the end of the clip.
With the switch(true) in order for people to usually get the "right" type out, usually I have instead done a typeguard to assert it first and then return it.
It is more cumbersome, but it is also accurate and can easily be put on multiple small functions that can also be reused later on.
Thanks for sharing :)
Inlay hints is a feature that the rust language server has had for a while. I've been wondering when other languages would gain the same thing.
Using switch true should be a crime with a 10 years in jail penalty
I'm confused by switch true narrowing as it's a handy hack in JS but could they not have backed an actual pattern matching spec?
Someday, but switch(true) is a great use of existing tools
@@mattpocockuk yeah, it's certainly an improvement and nice to have but feels like this advocates for this use case. I guess I just feel funny about it, even though I've made use of it.
Agreed, the switch true thing is gross and frankly bad for the language. It's the worst kind of mismatch: a semantic mismatch. Makes it harder for new people to learn.
@@andrueanderson8637 it's something that Javascript supports so it makes sense that Typescript supports it properly. Yeah it's gross, but it's not like it didn't exist before this update.
@@andrueanderson8637
I've been a programmer and linguist for over 15 years and I'm getting sick and tired of that "harder for new people to learn" talking point that's brought up every time when discussing a language feature that requires some effort to understand. The majority of the language users are not newbies and as a newbie, you're not supposed to learn everything at once in the first month of your learning journey. And once you're not a newbie, you're expected to understand trivial stuff like switch(true), because it's not rocket science as it uses two basic language features (1. switch case accepts values, 2. expressions evaluate a single value) and it's actually really clever. And there are cases where switch(true) looks much neater than if statement (for example, when you have multiple unrelated simple conditions that should evaluate the same expression).
And I'm pretty sure the people who say it's gross would be the first ones to commit atrocities such as using `as any as SomeType`, or mutating a variable inside a disgusting while loop. Skill issue if I ever saw one.
Why would someone return from an if statement then add "else if" below? "if return" pattern is more clean and easy to read solution then switch!
The goto def is 🔥
Thanks
from early, to now we are almost at the mid typescript times (x.5 to x.7 release)
and now typescript 4 seems so last year
My hero 💖
Which tool do you use to create those code animations?
what does switch (true) snipper you used in the example is for?! returning input if its object string or number? why not write them whole in one IF statement?
Awesome
With query parameters you can have an env.d.ts file define them (e.g., `declare module "*.svg?url" { ... }`), how would that work with import asser- attributes?
Not sure yet, but I'm sure it will be able to work the same way given enough iteration.
Hey Matt! Great work as always! Can you help me with a thing? I love lodash but their typings sucks ass. Once I tried typing the pipe/combine functions just for fun but was completely stuck. Can I suggest you do a video working on that kind of stuff? I think it would yield great content, and there's lots of cases like that in the wild if format pans out. :)
Use remeda instead of lodash. It's fully typed. That is remeda, not ramda.
@@zorzysty Thanks for the tip! Anyways, I think it's a nice problem to tackle, as creating a pipe function using reduce is very easy but typing it is very tricky.
@@zorzysty Thanks for the tip. I used ramda for about a year and I had a hard time to add types to most of the functions. I'm definitely checking this out
Ts-belt is another good alternative that's worth checking out
inlay hints 🔥
Home sweet home rust devs
That unnecessary else statement definitely makes the case better for switch(true).
Why two return points in the switch(true) example? Why not just add a third case to one single return block?
Good point! Just wanted to demonstrate that you _could_ do different things if you wanted to.
@@mattpocockukcool, just checking. PhpStorm normally shouts at me when I do that with match() statements :)
that switch should be "switch (typeof input) ..."
what about this? does it work with type narrowing?
`typeof null === "object"` is the issue.
@@maelstrom57 I missed that detail. You're right.
Been using jump to variable type in vim for ages (gY normally)
It's also been in VSCode for a long time, but just not in the inlay hints.
Do the interactive inlay hints affect non VS-code development? E.g. using WebStorm or another Jetbrains IDE?
I think Webstorm _will_ be able to do it, given a bit of catch up time.
@@mattpocockuk Thanks!
Webstorm should by default open hints if the cursor or pointer is over the type or issue. CMD+b will navigate to the definition on Mac, not sure what the default mapping is on other OSes.
You can't switch(typeof input) in TS?
2:50 why not do `switch (typeof input)`?
I'm really confused by the `switch(true)`, I would never have thought of using a `switch` like that, or even put `true` in the `switch`. What are the benefit over something like:
```ts
switch ( typeof input ) {
case 'string':
case 'number':
return ( input );
case 'object':
return ( !! input ? input : undefined );
}
```
It means you can layer in complex if statements in a nice, readable format. If you need to do 100 different checks, a switch statement will end up being much nicer than 100 if/else if's.
@@mattpocockuk I'm honestly not sure what is better/worse here. Needing to write else ifs or needing to deal with the horrible C style switch that is begging me to forget a break statement
I don't really get why TS limits itself to the JS switch. They could very transpile something like a statement switch in to the C style switch.
For example:
```
when {
typeof thing == "number" && thing%2 == 0 -> {
handleEvenNumber();
}
thing === "hello" -> {
greetBack();
}
}
```
@@mattpocockuk if you need to do 100 checks in a single function, the code really needs some refactoring, I'm not convinced that the switch is the solution here
if(!input && input !== 0) return;
switch(typeof input) {
case 'string':
case 'number':
return input;
case 'object':
return input.toString();
}
That's not the same function. Guard clause should be if (!input) return, except that would also fail for func(0). Also don't stringify the object. Correct way to rewrite is:
if (typeof input === "string") return input
if (typeof input === "number") return input
if (typeof input === "object" && !!input) return input
@@TheBswan yes, ! was incorrect. Thank you
what do you use to animate the code snippets?
powerpoint
Keynote
oh wow! totally and it comes built-in! I need to figure this out...
One Question: Which tool you are using to make the videos?
Keynote
I have a large code base written in TSX.Right now I am using typescript version 4.1.1 how to I upgrade it to 5.3 ? Íf I try to upgrade any chance I see errors, crashes or conflicts ?
Just bump it and see what happens. TS tends to upgrade slow. I doubt you'll have many issues.
@@mattpocockuk I will notify subscribers in here with result's
What, wasn't there also the “value || throw new Error()”?
I mainly waited for this feature to come
They were planning to champion that in TC39, not sure where that ended up.
switch (typeof input) would make more sense to me, but i saw the github issues about this. i don't like the switch (true) syntax, seems strange to switch on a literal
What’s the issue with using switch(typeof input)
typeof null is object
@@CodeWithMario im not sure you wanted to reply to my comment or just post a regular comment
@ 🤦 thanks for pointing that out
that import attribute looks quite verbose. If it's supposed to specify a type, why not something like import image from "./folder/img.png" asType X or something like it?
I didn't understand what inlay hints changes. What about that experience is new?
Edit: Oh I think i get it. Those were inferred types you could hover over, right? That sounds like the most useful of the 3
if (typeof input === "string") return input
if (typeof input === "number") return input
if (typeof input === "object" && !!input) return input
Switch true looks a lot dumber when you write the original function clearly
Bro is the owner of TS😅🔥🙌great content
haha yup he iss
pattern matching at home:
Thanks for confirming my hate for JavaScript
I've taught myself to avoid else clauses whenever possible, I found it to be a good practice to keep track of my state. I can see myself replacing some of my if statements with switch (true) statements when they have bunch of conditions.
why would you use inlay hints when you can, or rather SHOULD type it yourself?
when I turn it on I dont know whether I wrote it or it's the hint lmfao, would have to change font or something about it
it's good for javascript, but all I see for typescript, it's making it look like you typed it, it's hard to tell even, how is this not a bad practice XD
Yeah I also don't use them. Others do, and this is a nice upgrade for them.
According to some recent polls on Twitter, most devs seem to prefer inferred types over explicit types. With inferred types, inlay hints are useful since you then don't need to hover over a variable to find out its type. Also they are quite visually distinct from normal text, at least in IntelliJ.
Interactive Inlay Hints is not a Typescript change, is it?
Yep, the TS team needed to make some changes to tsserver to help VSCode get it working.
I agree with guys, the switch true example is horrible you could just use multiple if without else since you use return!
No. if you use switch(true), i’m closing out your pull request and blocking you on github
please don't use switch true, thx
im so confused as a non full time web dev.
you do switch true everywhere instead of switch(typeof input) mind blown at how thats not the baseline and people just do switch true lmao.
Of course you can do switch (typeof input) too. switch (true) is just one choice among many.
Switch (true) is new for me ❤❤
People are overreacting to that "switch (true)" bit. It doesn't suggest this as a syntax you should use, it was simply a case the compiler didn't cover correctly before and now it does.
No brainer unless you are using Pulumi.
⚡: operator ==== for _very_ precise comparisons added
operator === now does only approximate comparisons
for example:
3 === "3.1" false
3 === 3.1 true
3 ==== 3.1 false
why??
switch(true) makes me wanna hate JS even more 😢
switch true... really ?
You are taking a shortcut by not specifying the return type of that switch true function. In a properly configured typescript project with some basic strict type check options enabled, the compiler should complain that a return type is not specified and that it's missing a final return statement.
For the love of god, DO NOT USE switch(true). What's the point? It's just a more cumbersome if-else statement
I like it, reminds me of the Kotlin “when” blocks. Kinda pattern matching style.
if you have 10 conditions to handle, I'd rather have them in a switch(true) than in an if-else concatenation, just cleaner to the eye and less cluttered, in my opinion
Agreed if there are race or overlapping states it makes for odd behavior
I think this is a bad take. switch(true) definitely has it's uses. Makes code much cleaner than the alternative and it's easy to follow. Statements are evaluated from top to bottom stopping on the first truthy statement. Not rocket science.
I had to deal with quite complicated logic combining 4 or more variables sometimes just some of them sometimes all, not all were dummy simple variables, some of those conditions needed to be resolved on runtime ... imagine reviewing such code or returning to it after few months :D
switch(true) is to me much more readable with no impact on performance
Am I the only person in this world that hates inlay hints and always disable all form of hints in my IDEs? I find them troublesome, they add things that I did not write and aren't part of the source code, I find them more distracting than anything else and I absolutely hate that they sometime shift the rest of the line by 0.5 characters or even weirder values.
The biggest problem with typescript is that you are actually just writing javascript. Don't think they can fix that
bruh switch(true) is literally pattern matching
Can I PUH-LEASE just finish a project before my -framework- -library- language is updated? 😆 /jk
@_Karlsson 😄
@_Karlsson A finished project is one that no-one uses any more.
Nothing interesting for me 🫤