Hacker News Reader

Comment by dashwav | Hacker News Reader

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.

View on HN

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

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

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.

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.

Not just Angular, TypeORM and NestJS and a bunch of other server frameworks written in TypeScript make heavy use of decorators. The JavaScript spec for them has been rewritten twice since what TypeScript has so there is going to be a lot of trouble.

> They can't change it afterwards.

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.

I can almost guarantee you'll like it. Kotlin has this same feature and I've found it saves a good amount of boilerplate null checking when inter-operating with lousy legacy Java code.

It's also useful as a convenient syntax for maybes.

Me too — it's one of the few remaining things I still badly missed from the time I spent writing CoffeeScript.

You won't regret it ! It helps me every day. Just be sure to not be too strict in your tsconfig.json in the beginning.

edit: I'm refering to "noImplicit*" configuration.

>Just be sure to not be too strict in your tsconfig.json in the beginning.

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'm talking about "noImplicitAny", "noImplicitReturns", "noImplicitThis"... they get in my way when I'm editing. When I'm about to push my code I activate them back.

Personally I just don’t block the result of my hot dev server on the type checking.

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.

I just use lodash get when I access object properties

`get` will destroy type inference, there's no workaround. Your output types are always `any`. The new optional chaining fixes that problem, giving you the same terseness as `get`

https://www.npmjs.com/package/typesafe-get works pretty good

In lodash's defense, there is a @types package for it, which has a typed _.get. However, in my experience, the lodash typings are really difficult to use correctly.

Definitely will be replacing usage of _.get with optional chaining soon.

right but the person I was responding to isn't using typescript, they were just considering it. For a non typescript user lodash get would be fine.

TS 3.7 obviates the need for using `lodash.get` or `just-safe-get`, but it does so in a way that preserves the type of your object

I'm aware :) the person I was responding to is not using typescript

Reply on news.ycombinator.com