TypeScript 3.9 has just been released, so it’s only natural to look at what’s coming next! The good news is that since TypeScript is developed in the open, the plans are also available for all to see.
In this article I’ll try to summarize what I could find out by looking at the 4.0 iteration plan. I’ll only cover the language features. I might write additional posts to cover what’s also coming regarding editor productivity, performance and bug fixes.
Please keep in mind that this is article is based on a roadmap, it doesn’t mean that everything will actually be part of 4.0 or even actually implemented! ;-)
Class property inference from constructors
Currently, when tsc is configured in
noImplicitAny mode, the following TS code doesn’t compile:
Now that this PR has been merged and thus, as of TS 4.0, the code above will compile and TypeScript will infer the type of
x to be
string | boolean.
This is one more case where TypeScript’s type inference will help us out!
Short-circuiting assignment operators
It aims to combine logical operators and assignment expressions. Combined with nullish coalescing, which we’ve got since TS 3.7, we will be able to write more condensed code.
Here’s an example given in the proposal:
obj1.obj2.obj3.x ??= 42;
And the same code without those new short-circuiting operators:
obj1.obj2.obj3.x = obj1.obj2.obj3.x ?? 42;
As you can see, with support for this, we would have an even more expressive language, and we’d be able to combine checks and assignments, which would be great.
As mentioned by Daniel Rosenwasser, we’d get one such operator for each of the logical operators, thus:
LeftHandSideExpression &&= AssignmentExpression; LeftHandSideExpression ||= AssignmentExpression; LeftHandSideExpression ??= AssignmentExpression;
Corresponding to what we can currently do with:
LeftHandSideExpression && (LeftHandSideExpression = AssignmentExpression); LeftHandSideExpression || (LeftHandSideExpression = AssignmentExpression); LeftHandSideExpression ?? (LeftHandSideExpression = AssignmentExpression);
Given that the corresponding proposal has hit Stage 3, I bet that this will be part of TS 4.0, which would be great as this is a really nice feature.
Allow unknown on catch clause bindings
Currently, if you try to add a type annotation to a catch clause, the compiler complains:
The code above does not compile and it raises the following error:
TS1196: Catch clause variable cannot have a type annotation
At this point, we simply can’t add a type annotation to a catch clause, which is rather sad from a type safety perspective. The problem is that the errors are always considered to be
any, which lets us do anything with the object within the catch block.
This behavior is simply due to the fact that, originally, the
unknown keyword didn’t exist. But now that it does, it would make much more sense to use it here.
As pointed out in the comments of this proposal, we could get a new strict flag to let us enforce this by default (i.e., make all catch clause errors to be of type unknown). This would force us to correctly check the type before making use of it within the block.
This is one improvement that I’m really interested about!
Labeled Tuple Elements
Another proposal, introduced by Brian Kim, aims to give us the capability of defining labels for tuple elements. I’m not the biggest fan of tuples (I generally prefer objects/custom types), but sometimes they can indeed prove useful, for instance while writing tests (or type definitions for weird libraries like React :p).
Currently, tuples are declared like this:
// length, count type Segment = [number, number];
Since we can’t assign labels to the tuple elements, the simplest (but really ugly) solution is to rely on comments to remind us of what each element corresponds to.
The other solution (cleaner) is to use custom types that have more useful names. Still, there’s room for improvement.
Some languages such as C# and Python for instance support this.
If this gets added to the language, then we would be able to create more expressive tuples much more simply:
type Segment = [length: number, count: number];
Here, by taking a look at the tuple, we directly know what each number corresponds to.
This would be really useful to clearly understand what tuples are composed of. In addition, as mentioned in the proposal, it would also add more expressiveness to APIs that manipulate/return tuples.
As stated by Daniel Rosenwasser, tuple element names won’t enforce anything in the type system; they’ll exist purely to communicate intent.
As Daniel Rosenwasser explains, there are times when we need to be able to tell TypeScript that a type might exist depending on the environment in which the code gets executed.
When a situation like this occurs, we can take advantage of declaration merging. This works, but has some problems, especially when different environment have conflicting types. Also, it only works with custom types and interfaces.
With this new proposal, TypeScript would provide us with means to properly handle such situations, by letting us define placeholder types, which will act as placeholders until an implementation is available. At that point, TypeScript will act as if the placeholder type doesn’t exist anymore.
Here’s an example from the proposal:
If the implementation type does not respect the placeholder type constraints, then the compiler would bail out:
Note that the
existskeyword is only the proposed one, no definitive choice has been made yet.
Check out the proposal for more details.
Better support for Promises and await
In the release notes of TS 3.9, there was a note that I didn’t understand at first about a potential “awaited” keyword, stating that it wasn’t ready for primetime yet.
I haven’t been a huge fan of Promises since I fell in love (haha) with Rx and Observables back in 2016, but after looking at the plans for TS 4.0, I’ve stumbled upon this bug report, which has helped me understand what this is all about.
No matter how many times a promise is wrapped, it is automatically unwrapped for us. This is something that also works in the real world. If you wrap a present inside of a box inside of a box inside of a box and give it to kids, you’ll see how it works ;-)
With the code above, the compiler should complain, because the
p1 promise is actually a
Promise<number> and not a
There are actually a few other issues around Promises and the await keyword in TypeScript, as explained in this PR. TypeScript currently has trouble finding out the correct return types to use with complex promise chains. Also, TS also has difficulties correctly identifying the “awaited type” for a type variable.
The TypeScript team has in mind to introduce an
As this is still in flux, it isn’t clear yet how this will evolve and what will land in 4.0. One thing is for sure though: the TypeScript team will certainly improve the status quo for Promises in TS in the upcoming releases ;-)
Adapt TypeScript’s support for React
Just like TypeScript, React moves crazy fast.
Since TypeScript supports JSX, it indeed needs to follow those evolutions. This is tracked in this issue.
In this article, I’ve shared what I could discover so far about what might be coming in TypeScript 4.0.
I can’t wait to see what we’ll actually get!
That's it for today! ✨
Hello everyone! I'm Sébastien Dubois. I'm an author, founder, and CTO. I write books and articles about software development & IT, personal knowledge management, personal organization, and productivity. I also craft lovely digital products 🚀
If you've enjoyed this article and want to read more like this, then become a subscriber, check out my Obsidian Starter Kit, the PKM Library and my collection of books about software development 🔥.
You can follow me on Twitter 🐦
If you want to discuss, then don't hesitate to join the Personal Knowledge Management community or the Software Crafters community.