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

71–80 of 167 posts

Re: TypeScript 3.7

#71

Post by reggieband »

I'm a big fan of the new operators.

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);
    }
I really want some kind of structures that allow me to make `result` constant. In some cases I've rolled my own Maybe/Either wrapper and then move the try/await/catch into a function but that is still a pain.

This is such a common pattern in my code ... I wish there was a more elegant way to deal with it.

Re: TypeScript 3.7

#72

Post by dstaley »

rraval wrote: post #70
dstaley wrote: post #58

I'm super excited about this release, but it got off to a rocky start for me. Prior to 3.7, all our tests worked fine, but something in 3.7 changed that caused the type-checker to fail previously valid code. What's worse is that I can't reproduce the issue in a playground. Thankfully the workaround is "make your code more explicit", which is fine, but it was just a surprise to see something like this break. For those…

> That being said though, I'd expect that a tuple would satisfy a `any[]` type. 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; } The error matches yours: Type 'any[]' is missing the following properties from type '[number, string]': 0, 1 From poking the playground, `any[]` hasn't been assignabl…

Yeah, that's my assumption as well. It would explain why there's no mention of it in breaking changes, and why being specific about the generics in `SinonStub` fixes the error.

Makes me wonder what other unsoundness the compiler isn't catching.

Re: TypeScript 3.7

#73

Post by city41 »

z3t4 wrote: post #61
nothrabannosir wrote: post #50

Earlier quoted context omitted.

This is correct. Move to TypeScript for the types. If all you want is the latest syntactic developments from ES, babel is a better fit. It tends to be further ahead than TS for the bleeding edge features.

You can even make your own definitions and syntax sugar using Babel. (If we continue to add more syntax sugar to JS, it will soon be more complicated then C++.)

You can as well in TypeScript, it's just never been promoted or talked about much. Which is a shame. When I get a decent chunk of free time I plan to play with it, I'm curious if it's possible to write a translation layer that would allow using babel plugins in TS.

Here is an article on the TS feature: https://dev.doctorevidence.com/how-to-write-a-typescript-tra...

Re: TypeScript 3.7

#74

Post by isthisreality »

reggieband wrote: post #71

I'm a big fan of the new operators. 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); } I really want some ki…

There's this keyword called "var"

Re: TypeScript 3.7

#75

Post by 52-6F-62 »

reggieband wrote: post #71

I'm a big fan of the new operators. 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); } I really want some ki…

I’ve run into the exact same situation and continue to repeatedly. In fact this is a stupidly common pattern in a library in working on at work right now.

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.

Re: TypeScript 3.7

#76

Post by akiselev »

isthisreality wrote: post #74
reggieband wrote: post #71

I'm a big fan of the new operators. 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); } I really want some ki…

There's this keyword called "var"

`let` and `const` are transpiled by Typescript/babel to `var`.

Re: TypeScript 3.7

#77

Post by shtylman »

reggieband wrote: post #71

I'm a big fan of the new operators. 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); } I really want some ki…

Can you hoist the `if (result)` into the `try` part of the statement? (Without seeing more context hard to know why that wouldn't work for you).

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);
  }

Re: TypeScript 3.7

#78

Post by btown »

shtylman wrote: post #77
reggieband wrote: post #71

I'm a big fan of the new operators. 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); } I really want some ki…

Can you hoist the `if (result)` into the `try` part of the statement? (Without seeing more context hard to know why that wouldn't work for you). 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);…

And if you hate the indentation from the `if (result) {}` you can combine this with the poor man's ? operator.

    const result = await funcThatReturnSomeType().catch(convertError); // result: SomeType | Error
    if (isError(result)) return result;
    // now result: SomeType
EDIT: the ? operator in question - https://doc.rust-lang.org/edition-guide/rust-2018/error-hand...

Re: TypeScript 3.7

#79

Post by nikeee »

btown wrote: post #78
shtylman wrote: post #77

Earlier quoted context omitted.

Can you hoist the `if (result)` into the `try` part of the statement? (Without seeing more context hard to know why that wouldn't work for you). 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);…

And if you hate the indentation from the `if (result) {}` you can combine this with the poor man's ? operator. const result = await funcThatReturnSomeType().catch(convertError); // result: SomeType | Error if (isError(result)) return result; // now result: SomeType EDIT: the ? operator in question - https://doc.rust-lang.org/edition-guide/rust-2018/error-hand...

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 the catch block.

Re: TypeScript 3.7

#80

Post by cloverich »

52-6F-62 wrote: post #75
reggieband wrote: post #71

I'm a big fan of the new operators. 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); } I really want some ki…

I’ve run into the exact same situation and continue to repeatedly. In fact this is a stupidly common pattern in a library in working on at work right now. 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…

Its unnecessary until the clause above it changes and the assumption no longer holds. That's how I fight my urge to go with the cast.
Post reply on HN