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

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.

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

Not sure yet, but I'm sure it will be able to work the same way given enough iteration.

`typeof null === "object"` is the issue.

@@maelstrom57 I missed that detail. You're right.

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'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

It's also been in VSCode for a long time, but just not in the inlay hints.

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

Keynote

powerpoint

Keynote

oh wow! totally and it comes built-in! I need to figure this out...

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.

They were planning to champion that in TC39, not sure where that ended up.

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

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

haha yup he iss

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.

Yep, the TS team needed to make some changes to tsserver to help VSCode get it working.

Of course you can do switch (typeof input) too. switch (true) is just one choice among many.

why??

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

@_Karlsson 😄

@_Karlsson A finished project is one that no-one uses any more.