TypeScript 3.7
typescriptlang.org
typescriptlang.org
foo && await foo();
await foo?.();
String regular expression matching returns null, not undefined, so rewriting code such as:
const match = str.match(/reg(ex)/);
return match && match[1];
return match?.[1];
return match?.[1] ?? null;
A common idiom to catch and ignore exceptions can interact poorly with optional chaining:
const v = await foo().catch(_ => {});
return v?.field; // property 'field' does not exist on type 'void'
const v = await foo().catch(_ => undefined);
You can even avoid the problem in the second one by using NonNullable TypeScript types, but I admit that's not common so its still likely to arise.
(() => Promise<void>) | undefined
In the last example, you're right that TypeScript will catch this at compile time. My point was to show how this compile time error can happen from refactoring to use optional chaining, and one easy solution in this case.
It's a shame JS at the beginning doubled down on the "billon dollar mistake" [1] with two(!) kinds of NULL instead of just using Maybe/Option.
Ah well, if it were good it wouldn't be popular :/
[1] https://www.lucidchart.com/techblog/2015/08/31/the-worst-mis...
Speaking of which, optional chaining and null coalescence are core language features of some very good languages. Kotlin and C# for instance. Kotlin, much like TypeScript, interops with a "broken" language (Java and the JVM in its case) and attempts to address some core deficiencies in that ecosystem. Let us have nice things!! :)
I am really excited about these new features and hope they do land in JS sooner rather than later. I hope they do the pipe operator next! `pipe |> operator|> plz`
It does not interop with JavaScript.
> and in some scenarios transpile down to JavaScript
It always transpiles to JavaScript and always runs as JavaScript. There is no such thing as a TypeScript runtime engine.
TypeScript is a superset of JavaScript. Therefore the OP's point is still valid. Any "mistakes" JavaScript might have made about having null AND undefined are also issues for TypeScript.
I don't know what you mean here, but it is certainly possible for TypeScript code to use JavaScript libraries and vice versa, which is presumably what most people mean by "TypeScript interops with JavaScript".
> It always transpiles to JavaScript and always runs as JavaScript.
Technically false... https://assemblyscript.org
> TypeScript is a superset of JavaScript. Therefore the OP's point is still valid. Any "mistakes" JavaScript might have made about having null AND undefined are also issues for TypeScript.
TypeScript adds type checking to JavaScript. The Million Dollar Mistake is having unchecked nulls; TypeScript supports checked nulls so it's not an issue. TypeScript's nulls are much more similar to Maybe/Option than unchecked nulls.
Ah, I can see what you/they mean by that. The point I was trying to get across was: TypeScript doesn't exist when code is actually executing (which is what I think of as interop - it's happening at execution time.) At execution time - it's all just JavaScript.
I have found (working in a TypeScript team currently) that this fact is ignored, primarily by people who "look down" on JavaScript, but it is a VERY important point to remember when you are writing TypeScript, mostly because it's important to remember there is only compile time type checking not run time.
> Technically false... https://assemblyscript.org
Heh, yes - as soon as I posted I realised that was silly. The word "always" is almost "always" incorrect! I should have said: "It usually transpiles to JavaScript and usually runs as JavaScript"
> The Million Dollar Mistake is having unchecked nulls; TypeScript supports checked nulls so it's not an issue. TypeScript's nulls are much more similar to Maybe/Option than unchecked nulls
Good point in theory but my practical experience hasn't borne this out. That is because TypeScript is an "optionally typed" language and it hasn't been true in practice because of excessive use of explicit or implicit "any"s.
<i>Good point in theory but my practical experience hasn't borne this out. That is because TypeScript is an "optionally typed" language and it hasn't been true in practice because of excessive use of explicit or implicit "any"s. </i>
I think that's a matter of your team's discipline. It's good practice, I think, to enable TypeScript's strict checks, including no-implicit-any, and, to the best of your ability, to keep people who don't understand types ignorant of explicit any and to fail any code that uses it. `any` is basically never necessary even in typing existing code - if you genuinely don't know what the type is at a certain point, you should probably write a type like `unknown`.
If you take any of Typescript's options to "ease the transition" you're taking Typescript's options to continue the difficulties. One moves to typescript because javascript's runtime errors are a problem; so it is natural that you will have novel compile time errors.
> It does not interop with JavaScript.
Hm, this depends on your definition of "interop". My JavaScript and TypeScript are languages that exchange information. The execution model ultimately involves JavaScript when I use tsc, but ultimately it also includes an interpreter. My user-space syntax doesn't care.
> There is no such thing as a TypeScript runtime engine.
Not being glib, just a heaps up: https://github.com/denoland/deno
interesting thanks for the heads up - my assumption is though that this is just a wrapper over a V8 engine with typescript compilation on the fly?
Does that make it a TypeScript runtime or not?
They are features of Maybe/Option too, just in a more consistent extensible way.
val a = Some(thing)
val b = a.flatMap(_.part).flatMap(_.subpart)
val c = Some(None) // look Ma! a nested option!
I appreciate the attempt at pedantry, but TypeScript general only implements JS language features or TC39 Stage 3 proposals.
> I hope they do the pipe operator next!
Great example. After many hundreds of upvotes, the status is "waiting for TC39". [1] I.e. it will not be implemented until JS has it or is close to having it.
TypeScript is typed JavaScript, end of story.
How about private variables in classes? (Hint: they're different)
Typescript is a superset not just typed JavaScript.
1. Decorators are currently TC39 Stage 2. [1]
2. Because of its unusual status, TypeScript lists decorators as "experimental, subject to change". Once the EcmaScript proposal advances, TS will ensure it is compatible with the ES standard and then remove the experimental sticker.
3. If it doesn't affect runtime, then you shouldn't expect JS to have the feature. TS private members are no different than public members at runtime; there is no need for JS to have that feature. (Note that TypeScript deliberately chooses not to name-mangle members.)
4. Sure call it a "feature and syntactic superset", but that doesn't make TS any less beholden to JS. Dedicated adherence to that property commits them to support every feature and syntax that JS adds; future-proofing means they can't really add anything that JS doesn't have or is going to have.
5. Note that TS abandoned having a standard long ago. The behavior and validity of TypeScript program is determined by "whatever tsc does" and the ES standard.
6. Again, if you need convincing that TS effectively only implements JS features, refer the linked pipeline issue, locked as "waiting for TC39."
I'm afraid literally everything in this snippet is incorrect. The Typescript website opens with:
> Typescript JavaScript that scales. Typescript is a typed superset of JavaScript that compiles to plain JavaScript.
Typescript is Javascript. It's a superset, and as such its improvements are additive-only, by definition. The purpose of its existence is not to change or replace any JS features, only to augment them.
In the same way as an Animal is a Camel.
Typescript is ECMAScript in the same way as Netscape JavaScript is ECMAScript, in the same way as ActionScript is JavaScript.
In the same was as Scheme is Lisp.
In a similar but not identical way as American English is English (similar but not identical since programming languages and spoken languages are both languages, but not actually the same thing: the analogy cannot map perfectly).
Nullish alone had me back to the == instead of === once I went ts. No reason to care about identity when ts makes sure I don't compare a string to a number, but treating undefined == null as true is what I want 99.9% of the time, and that 0.1% I should be explicit that I do care about treating them differently.
It can be useful to have the latter case distinguished in a dynamic language because it can enable certain powerful patterns. At the end of the day, compressing both these cases to a single concept of null would be lossy. This may have certain advantageous implications for simplicity, but you're trading that off for language power. Which you favour more of course depends on the usecase.
Option[Option[Option[T]]]
Usually zero or one level of nonexistence is enough.
Edit: also `undefined` is a value in JS as well.
One of my remaining gripes with Javascript/Typescript is the try/catch mess around await. It makes assignment of const a pain for async calls that may reject.
e.g.
let result: SomeType;
try {
result = await funcThatReturnSomeType();
} catch (err) {
doSomethingWithErr(err);
}
// at this point result is `SomeType | undefined`
if (result) {
doSomething(result);
}
This is such a common pattern in my code ... I wish there was a more elegant way to deal with it.
My solutions have involved casts (and comments explaining the assumptions involved) instead of the ‘if’ statement more times than I’d like to have done, but it ends up with the same result with the added (however small) compute with the conditional since it can be safe to assume the value is not undefined. It’s not perfect, but it at least omits unnecessary runtime code.
At any rate, I’d appreciate the same thing you would in these cases.
Another pattern to avoid the above is to remember that async functions return promises and that .catch() also returns a promise. So your above logic can be written as:
const result = await funcThatReturnSomeType().catch(doSomethingWithErr);
if (result) {
doSomething(result);
} const result = await funcThatReturnSomeType().catch(convertError); // result: SomeType | Error
if (isError(result)) return result;
// now result: SomeType
function doSomethingWithErr(err: any): never {
throw new Error("Oops");
}
let result: SomeType;
try {
result = await funcThatReturnSomeType();
} catch (err) {
doSomethingWithErr(err);
}
// because doSomethingWithErr has return type "never", result will be definitely assigned.
doSomething(result);
(() => {
try {
// finally will return prior to this console.log
console.log('this try was executed and the return ignored')
return 'try block'
} catch (e) {
return 'error block'
} finally {
return 'finally block'
}
})()Unless one goes the PowerShell way and just forbids returning from finally.
Basically, `finally` gives you a guarantee that it will actually run once the `try` block is exited. Likewise, `return` effectively assigns the return value and exits. But it doesn't (cannot and should not) breach the contract of try-finally, since the purpose of try-finally is to ensure resources are managed correctly, so it either exits to the caller or it exits to the finally block, depending on which one is most recent.
In your case, a return value is assigned and the `try` block is exited using `return`. We then have to continue into the `finally` block, since that is the core meaning of `finally` - we run it after we leave `try`. And then with `return`, we reassign the return value and finally leave the whole function. At this point, the return value is the second one that was assigned to it.
Maybe thinking of it like this is helpful, although I somewhat hope it isn't. You can see that "return" is reassigned before we have a chance to read it. I've simplified by removing any consideration of errors, but I console.logged the final output.
//this is the function call at the end of your IIFP
next_code.push(AfterMe)
goto Anonymous
// this is the function definition
Anonymous:
// this is the try-finally idiom
next_code.push(FinallyBlock);
//this is the try
console.log("this try was executed");
//these two lines are the first return
var return = 'try block';
goto next_code.pop();
//this is the finally
FinallyBlock:
var return = 'finally block'
goto next_code.pop();
// this code gets executed from the FinallyBlock's goto and is as if you have a console.log(..) around your whole definition.
AfterMe:
console.log(result)And now you wrap the function call to doSomething() in the try/catch too. Often (usually?) the try/catch specifically is for the asynchronous function. Usually that's because the async. stuff might fail due to expectable (even if undesirable) runtime conditions (e.g. "file not found"), while synchronous code should work for the most part (external condition errors vs. coding errors - and your catch is about the former, because, for example, you might want coding errors to just crash the app and be caught during testing).
Sure, you can claim that you check for specific errors that could only happen in that function, so that any errors occurring in doSomething() don't matter/don't change the outcome, or that doSomething never throws because you are sure of the code (the async. function may throw based on runtime conditions, but you may have development-time control over any issues in doSomethign() - but if you start going down that path, having to rely on the developer doing there job perfectly for each such construct, later maintainability and readability goes down the drain. You would have to make sure such a claim is valid when you later come across the construct. That is why you really don't want anything inside the try/catch from which you don't want to see any errors in the catch block. So my policy is to never ever do that even if in the given context it would work - it places additional work on whoever is going to read that section later (or they are ignorant of the problem and won't see this potential problem, which is not any better).
const result = await (() => {
try {
return funcThatReturnSomeType();
} catch (err) {
doSomethingWithErr(err);
}
})(); const result = await (async () => {
try {
return await funcThatReturnSomeType();
} catch (err) {
doSomethingWithErr(err);
}
})();const [err, result] = await to(funcThatReturnSomeType());
if(err) doSomethingWithErr(err);
doSomething(result);
try {
doSomething(await funcThatReturnSomeType());
} catch (err) {
doSomethingWithErr(err);
} async function test() {
const promise = Math.random() < 0.5 ?
Promise.resolve('wow') :
Promise.reject('oops');
try {
await promise;
} catch (e) {
console.log('caught');
return;
}
const result = await promise;
console.log('result', result);
}
test();However, in JS itself, it might cause developers to lose track of what can be null/undefined in their code. In case they start to "fix" stuff by throwing in some "?." because they don't know better, the code maintainability will degrade a lot.
Maybe I'm just pessimistic. Let's see how it will perform in the field!
e.g. You can do:
foo?.bar?.baz || "default";
(foo && foo.bar && foo.bar.baz) || "default";
The real bug was that the property in question should never be null/undefined in the first place. It was a lot harder to find the error.
Also, I've seen some typos (or missed renames) being unnoticed without any errors. This caused some weird behavior in the frontend where there was no exception but there is definitely something wrong. Or, worse, the bug is never noticed and other code depends on that behavior.
So if the language is statically typed, the feature is awesome because the cases mentioned above will trigger a compile time error. I've seen some misuse in dynamically typed ones.
foo?.bar?.baz ?? "default"So, by making it “nice” you are making a code smell less smelly, which feels good in the moment, at the syntax level, but makes your code worse at the architecture level.
This is roughly the story for all of ES6... make it “nice” to work with bad code, allowing bad code to look more similar to good code, until everything looks “nice” at the syntax level but you are surrounded by footguns that are impossible to find, and you need more and more static analysis tools (like TypeScript) to even be able to comprehend your control structures.
Callback hell isn’t bad because of indentation, it’s bad because there are too many handoffs in a small space. Promises make it easier to pack more handoffs into a small space, and guess what? Now the problem is even worse.
This new ? operator will make it easier than ever to pass on undefined values. In other words, it will make the problem it solves even worse.
Deeply nested object props are often bad, except for when it's a big dynamically-defined object (eg a directory tree that you would traverse with lodash get). It's also great when you're not deeply nested, you're simply checking for the inclusion of something in a collection that is itself optional. Eg a Map#has on an optional map.
I'm not sure I agree with that statement in all scenarios. For code you control, sure.
But there are many APIs that return very deeply nested structures that are inconsistent in their shape. That, in my view, is the most common place devs will need deep accessors where parts may be null/undefined somewhere in between the root object and the key they are trying to access.
Sure, they could write functions that, similar to get in lodash, expose just the values needed, at which point chaining wouldn't be needed at all in the code that deals with that value. Or it could be serialized into a class object, but again, the chain would be dealt with in the serialization. At some point, the chain needs to be dealt with and often the JSON structures from APIs are not something that's always under our control.
If something is null or undefined, you should deal with it in one place, the correct place. And downstream code should be able to assume all data exists.
I think they're just waiting on support for the new syntax in prettier.
Many js developers see formatters as a sane default, and create-react-app is a layer in the ecosystem that incorporates it as a "core" piece in the way that you meant above.
edit: I'm refering to "noImplicit*" configuration.
Do you mean to avoid using the "strict" rule, or are you referring to other rules? My number one Typescript suggestion is to make sure you start with "strict": true in your tsconfig.json to be sure your code has nullability correctly enforced.
I follow along with types in my IDE, and in a separate command.
Basically Babel for transpilation (which strips all types, correct or not), and type checking in a separate process.
Definitely will be replacing usage of _.get with optional chaining soon.
Here is an article on the TS feature: https://dev.doctorevidence.com/how-to-write-a-typescript-tra...
Hopefully tsc or eslint will actually warn when you use optional chaining on a non-nullable receiver.
If they start implementing features at an earlier stage, there is the risk of implementing a feature with different semantics in TS than in JS, since the JS spec can still change (or event get rejected). Both cases will result in diverging languages, which is something they try to avoid.
Edit: In the past, that didn't work that well. TS 3.8 is planned to ship with JS private fields support (the one with the # syntax). TS had private fields for a long time. In fact, it's one of the first things that the language had.
However, these private fields behave entirety different to what ended up in the ES private fields spec. They can't change it afterwards. So in the future, we will have two semantically different ways of declaring a private field in a class in TS.
Another case are decorators. They are still in stage 2 and may change. They already exist in TS, behind a flag. But every Angular application depends on their current implementation in TS. If the spec changes, it will get interesting.
I would argue that TypeScript absolutely can change things that would be consider breaking changes. And they do have breaking changes in just about every release (sure wish they followed semver for that reason). They'd just want to be careful for big things like private fields or decorators, making sure the breaking changes get communicated publicly and loudly.
... but with that being said, 3.7 seems to have broken many aspects of the `Promise.all` interface. Right now the largest issue seems to be that if any `Promise` result in `Promise.all` is nullable, all of the results are nullable.
The result should instead be a tuple, but IDK how well tuple size inference would work in a case like that.
type Tuple<T, K> = [T, K | null];
...JavaScript would allow you to extend that list during runtime (unless you freeze it)
type Tuple<T, K> = [T, K]
const Tuple<T, K> = (x: T, y: K): Tuple<T, K> => {
const tup = [x, y];
Object.freeze(tup);
return tup;
};It is a well hidden secret, and one that I'm not going to try to lookup the docs for on mobile, but the idea is that the operator strips null/undefined from the type of whatever is before it.
So you can do something like this:
const [ a, b ] = await Promise.all([
async () => ({ foo: 'bar' }),
() => null
])
console.log(a!.foo) // `a!` strips the nullable off `a`I thought you had to actually provide a Promise to `Promise.all`, not functions that return promises (you have to invoke the functions):
const [ a, b ] = await Promise.all([
(async () => ({ foo: 'bar' }))(),
(() => null)(),
])
That the suggested features in this open issue [1] can't be implemented soon enough :)
Is there a roadmap available that would give an idea as to when x, y, z language features may be implemented?
- Extension members are basically done and out the door. (See: https://medium.com/dartlang/extension-methods-2d466cd8b308)
- Non-nullable types are well underway. All but a few corners of the design are pinned down, much of the static checking is implemented, the core libraries have been mostly migrated, and we're working through the runtime implementation, migration tests, etc.
- Next up after that, the current plan (which may change) is control over variance and stuff around pattern matching.
We're working on it.
Groovy had ?. in at least 2005. Then there were CoffeeScript, Kotlin, Swift and a bunch of others in the meantime.
Not that it matters :)
* Optional Chaining & Coalescing
* Assertion Functions
* .d.ts Emit From .js Files
* Smarter Control Flow Analysis
* Flatter Error Messages
also great:
* Function Truthy Checks / Uncalled Function Checks (which was tslint's biggest value prop for me up until now)
I'm for progress, but it makes me a little wary to start my team of no-previous-TS-experience JS devs on a TypeScript project when there's still a new version every few months. Keeping up with Webpack is enough of a hassle...
But even so we (like many teams with large codebases, I suspect) have callbacks, promises, and async/await all mixed together, depending on when the code was (re)written. It's on our list.
At our current pace, we formally release 4 times a year, for reference, which is actually a far cry from the more continuous deployment browser vendors currently have setup.
The main difference is that most people kinda ignore new JavaScript stuff for awhile until it trends or gains sufficient rollout. It's an interesting world - I can't really say that people are actually JavaScript version aware, beyond, maybe, what compatibility presets @babel/preset-env gives them.
Generally speaking, it's not often we add something that _invalidates_ the old way to do something (in the language) - our additions are usually made to make new patterns possible to express.
Maybe this exists, but one thing that would be super helpful is a document that explains any places where there's a "new best way" of doing things, and also details what the old way was.
Here's an example from yesterday: I was Googling about extending a type (I think) and the first SO result (top of Google) says "you can't do that in TypeScript"... but reading the comments someone had said "actually you can, in 2.6 or later". That's the kind of thing that it would be great to have summarised in one place. Not necessarily all the changes (ie, not just all the release notes) but specifically where the language has changed and an old way of doing things, or a previous restriction, is gone. Preferably with examples. (I'd try to create this, but I don't have the skills to do so).
If you find an answer on SO is out of date - suggest a new answer (or ask for one) and get it updated (there's far, far too many for us to keep explicit track of them, there's only a handful of us on the team)! :D
Maybe don't worry about the "best" way to do something and use what works? Typescript has really good backward compatibility, it's very rare for something to stop working that previously worked. If it turns out there is an easier way to do something, you'll likely have reason to want to learn it, but at least in my experience with Typescript you'll rarely find a "need" to learn it or your code will break.
Typescript really isn't the most exciting language, but it's very very helpful. Compared to regular javascript it saves me a lot of time, and so many pains and headaches every day.
log?.(`Request started at ${new Date().toISOString()}`);
// roughly equivalent to
// if (log != null) {
// log(`Request started at ${new Date().toISOString()}`);
// } let bar: any, log: any;
log?.(`foo ${bar()}`);
// becomes
var _a;
var bar, log;
(_a = log) === null || _a === void 0 ? void 0 : _a("foo " + bar());The situation that popped in my mind was something like: f?(++a)
Normally you’d expect the side effects incrementation to occur prior to the start of the function invocation. If the function is not evaluated it’s not clear from the article if increment will occur.
For those that are curious, here's the error that 3.7 introduced:
Type 'SinonStub<[string, RequestBody, (RequestOptions | undefined)?], KintoRequest>' is not assignable to type 'SinonStub<any[], any>'.
Type 'any[]' is missing the following properties from type '[string, RequestBody, (RequestOptions | undefined)?]': 0, 1
You have it backwards, the error in question is complaining that `any[]` does not satisfy the tuple type.
Minimal repro:
function f(x: any[]): [number, string] {
return x;
}
Type 'any[]' is missing the following properties from type '[number, string]': 0, 1
My guess is that the compiler got smarter around reasoning about your `SinonSub` generic and is now forcing you to deal with lingering unsoundness.
Makes me wonder what other unsoundness the compiler isn't catching.
const x = [1,2];
const y = x[666];
const z = y + 3;
TypeScript will say "y" has type "number" when "x[666]" returns undefined. Why does TypeScript not say the type of "y" is "number | undefined"?
Though with tuples, etc. being defined, maybe it's worth re-examining.
I haven't tried it yet but it looks like the new optional element access feature is only checking if the array itself is defined, not if the array index is defined.
Otherwise, you're left to creating a wrapper function and a custom ESlint rule.
Edit: found it https://github.com/microsoft/TypeScript/issues/13778#issueco...
The suggestion is to maintain your own copy of `index.d.ts` with the array indexing interface modified. Yikes!
const x: [number, number] = [1, 2];
Using `as const` will report both the 2nd and 3rd lines as type errors. You've been able to do this in TypeScript for a while even before they introduced the `as const` syntax.
const x = [1, 2] as const;
const r = 666 + 1;
const y = x[r];
const z = y + 3; const x: number[]= [1,2]
const y: number | undefined = x[666]
const z: number = y + 3
const x = [1,2] as const;
//const x: [number, number] = [1,2];
const y = x[666];//Tuple type 'readonly [1, 2]' of length '2' has no element at index '666'.
const z = y + 3;//Object is possibly 'undefined'.
```
function dispatch(x: string | number): SomeType {
if (typeof x === "string") {
return doThingWithString(x);
}
else if (typeof x === "number") {
return doThingWithNumber(x);
}
process.exit(1);
```
It's very embarrassing in my opinion that they haven't done anything yet against having these horrible kind of type checking; comparing against a string that has the type name? "string", "number"? it's completely ludicrous.
I will not take this language seriously until this is fixed. (For sure it's still better than JavaScript, but that's about it.)
function isString(x: any): x is string {
return typeof x === "string";
}
function isNumber(x: any): x is number {
return typeof x === "number";
}
function dispatch(x: string | number): SomeType {
if (isString(x)) {
doThingWithString(x);
} else if (isNumber(x)) {
doThingWithNumber(x);
}
process.exit(1);
}
There is a long list of other languages that compile down to JavaScript or WASM, if you want a language built from clean foundations. But if you want to add gradual typing as a means of slowly reigning in your existing JavaScript behemoth? There is only one TypeScript.