Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TypeScript 3.7

typescriptlang.org

Post reply on HN
Print view View original

101–110 of 167 posts

Re: TypeScript 3.7

#101

Post by shhsshs »

Klathmon wrote: post #95
SirensOfTitan wrote: post #36

I feel really excited about 3.7. Optional chaining and null coalescing will clean up a TON of code. ... 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.

This is a moment where the postfix `!` operator comes in handy. 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…

When I plug in your example (in Chrome console and in the TypeScript compiler), `a` is type `() => Promise` and `b` is type `() => any`.

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)(),
    ])
When I do this, `a` and `b` have their proper types.

Re: TypeScript 3.7

#103

Post by knocte »

From the snippets in the release notes:

```

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.)

Re: TypeScript 3.7

#104

Post by paulddraper »

achou wrote: post #67

I just did some refactoring on a medium size code base and here are a few things to watch out for when adopting optional chaining and the new null coalescing operator: foo && await foo(); is not the same as await foo?.(); this will work in most cases but subtly, the await wraps the undefined case into a Promise, while the original code would skip the await altogether. String regular expression matching returns null,…

&& ?. || ??

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

Re: TypeScript 3.7

#105

Post by Klathmon »

shhsshs wrote: post #101
Klathmon wrote: post #95

Earlier quoted context omitted.

This is a moment where the postfix `!` operator comes in handy. 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…

When I plug in your example (in Chrome console and in the TypeScript compiler), `a` is type `() => Promise ` and `b` is type `() => any`. 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)(), ]) When I do this, `a` and `b` have their proper types.

Ah good catch, I was spacing on the easiest way to show how to easiest show the operator and forgot to invoke my functions!

Re: TypeScript 3.7

#106

Post by gavinray »

desert_boi wrote: post #97
nikeee wrote: post #79

Earlier quoted context omitted.

You can also get rid of `if(result){}` by setting the return type of "doSomethingWithErr" to "never": 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); ..or just return in…

Interestingly when I was encountering this myself recently, I discovered that JS finally blocks can return after a function has nominally already returned. Consider the following closure. (() => { 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' } })()

What the hell?

Re: TypeScript 3.7

#109

Post by vikingcaffiene »

paulddraper wrote: post #104
achou wrote: post #67

I just did some refactoring on a medium size code base and here are a few things to watch out for when adopting optional chaining and the new null coalescing operator: foo && await foo(); is not the same as await foo?.(); this will work in most cases but subtly, the await wraps the undefined case into a Promise, while the original code would skip the await altogether. String regular expression matching returns null,…

&& ?. || ?? 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...

Sorry, JS? While JS might get this stuff one day, these language features are for TypeScript which is its own language. It's strongly typed and just happens to interop with and in some scenarios transpile down to JavaScript. It's whole existence is to deal with that billion dollar mistake you mentioned.

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`

Re: TypeScript 3.7

#110

Post by huy-nguyen »

iLemming wrote: post #81
alipang wrote: post #19

Great incremental release. 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.

Ha. Try Clojurescript. You'll be surprised.

Or ReasonML.
Post reply on HN