Live data from Hacker News

TypeScript 3.7

typescriptlang.org

61–70 of 167 posts

Re: TypeScript 3.7

#61

Earlier quoted context omitted.

I'm assuming by optional operator you're referring to optional chaining? If so, it's very cool but strikes me as an odd reason to move to TypeScript, because it's a stage 3 proposal in JavaScript too, so is likely to be widely supported soon.

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

Re: TypeScript 3.7

#62

The optional chaining and null coalescing operators are very nice. Dart has had those for several years and they really do come in handy.

Definitely. It's a shame that dart gets so much unwarranted hate. I mean, I also think it's an absolutely awful language but it's really proven to be a valuable source of data for what other programming languages should do and perhaps more importantly: not do. I really hope we see a lot more things like Dart, and not so much negativity.

I haven't heard this general hatred of Dart. Why do you think it's an absolutely awful language?

Re: TypeScript 3.7

#63
post #13

I really like the new optional operator, this might be what gets me to bite the bullet and start moving some of my projects over to typescript - dealing with potential undefined objects in those chains is one of the things I actively dislike about writing in vanilla Javascript.

I'm assuming by optional operator you're referring to optional chaining? If so, it's very cool but strikes me as an odd reason to move to TypeScript, because it's a stage 3 proposal in JavaScript too, so is likely to be widely supported soon.

The operator is much better with nullable types because you're less likely to add it everywhere defensively.

Hopefully tsc or eslint will actually warn when you use optional chaining on a non-nullable receiver.

Re: TypeScript 3.7

#64
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…

Keep in mind that TypeScript does make breaking changes in point releases. They don’t ascribe to semver. Not sure if that’s your issue or a bug though

Re: TypeScript 3.7

#65
post #51

Optional Chaining also coming soon to create-react-app, planned for v3.3 (current release is react-scripts@3.2.0) - https://github.com/facebook/create-react-app/pull/7438 I think they're just waiting on support for the new syntax in prettier.

Is it not bizarre that you're blocked on a syntax formatter to make a release? If that's what's happening, it sounds like prettier should be core and non-optional, the same way gofmt is.

The commenter was talking about a release of create-react-app, which is a starter-kit/scaffold. For such a project with the goals of being a packaged collection of tools/configurations, it seems prudent to only release if your set of tools present a consistent experience.

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.

Re: TypeScript 3.7

#66
post #13

I really like the new optional operator, this might be what gets me to bite the bullet and start moving some of my projects over to typescript - dealing with potential undefined objects in those chains is one of the things I actively dislike about writing in vanilla Javascript.

I'm assuming by optional operator you're referring to optional chaining? If so, it's very cool but strikes me as an odd reason to move to TypeScript, because it's a stage 3 proposal in JavaScript too, so is likely to be widely supported soon.

The TypeScript team is only implementing features that have a chance of 100% of landing in JS or 0%. Therefore, they wait for Stage 3.

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.

Re: TypeScript 3.7

#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, not undefined, so rewriting code such as:

  const match = str.match(/reg(ex)/);
  return match && match[1];
is not the same thing as:

  return match?.[1];
because the latter returns undefined, not null, in case of match failure. This can cause problems if subsequent code expects null for match failure. An equivalent rewrite would be:

  return match?.[1] ?? null;
which is longer than the original and arguably less clear.

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'
This can be easily remedied by changing the first line to:

  const v = await foo().catch(_ => undefined);
Of course, these new operators are very welcome and will greatly simplify and help increase the safety of much existing code. But as in all things syntax, being judicious about usage of these operators is important to maximize clarity.

Re: TypeScript 3.7

#68
post #52

I really like the optional chaining operator for statically typed languages. Especially in TypeScript where you have the nullabilaty information baked into the type system. 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. May…

It's nice for situations where you want to access a deeply nested prop, and you only care whether the whole path is there or not. Saves you having to add a seperate check for every level of the hierarchy. e.g. You can do: foo?.bar?.baz || "default"; Rather than: (foo && foo.bar && foo.bar.baz) || "default"; Agree that developers can be careful about nullability (in fact I pulled someone up on this in a code review ea…

Shouldn't that be

    foo?.bar?.baz ?? "default"

Re: TypeScript 3.7

#69

The optional chaining and null coalescing operators are very nice. Dart has had those for several years and they really do come in handy.

Definitely. It's a shame that dart gets so much unwarranted hate. I mean, I also think it's an absolutely awful language but it's really proven to be a valuable source of data for what other programming languages should do and perhaps more importantly: not do. I really hope we see a lot more things like Dart, and not so much negativity.

Depending on when you last looked at Dart, there's a good chance we've either fixed or are fixing the things you hate about it. What didn't you like?

Re: TypeScript 3.7

#70
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 assignable to tuples since at least v3.3.3

My guess is that the compiler got smarter around reasoning about your `SinonSub` generic and is now forcing you to deal with lingering unsoundness.

Post reply on HN