6 ms·

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 po

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.

simlevesque 7y ago
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.
- AgentME 7y ago
  >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.
  - simlevesque 7y ago
    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.
    - charrondev 7y ago
      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.
notus 7y ago
I just use lodash get when I access object properties
- tomconroy 7y ago
  `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`
  - fgkramer 7y ago
    https://www.npmjs.com/package/typesafe-get https://www.npmjs.com/package/typesafe-get works pretty good
  - ssalka 7y ago
    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.
  - notus 7y ago
    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.
- nerdkid93 7y ago
  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
  - notus 7y ago
    I'm aware :) the person I was responding to is not using typescript
andrewingram 7y ago
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.
- nothrabannosir 7y ago
  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.
  - z3t4 7y ago
    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++.)
    - city41 7y ago
      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-transform-plugin-fc5308fdd943 https://dev.doctorevidence.com/how-to-write-a-typescript-tra...
- spankalee 7y ago
  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.
- nikeee 7y ago
  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.
twh270 7y ago
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.
- smichel17 7y ago
  It's also useful as a convenient syntax for maybes.
gmac 7y ago
Me too — it's one of the few remaining things I still badly missed from the time I spent writing CoffeeScript.

simlevesque 7y ago

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.

AgentME 7y ago
>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.
- simlevesque 7y ago
  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.
  - charrondev 7y ago
    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.

notus 7y ago

I just use lodash get when I access object properties

tomconroy 7y ago
`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`
- fgkramer 7y ago
  https://www.npmjs.com/package/typesafe-get https://www.npmjs.com/package/typesafe-get works pretty good
- ssalka 7y ago
  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.
- notus 7y ago
  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.
nerdkid93 7y ago
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
- notus 7y ago
  I'm aware :) the person I was responding to is not using typescript

andrewingram 7y ago

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.

nothrabannosir 7y ago
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.
- z3t4 7y ago
  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++.)
  - city41 7y ago
    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-transform-plugin-fc5308fdd943 https://dev.doctorevidence.com/how-to-write-a-typescript-tra...
spankalee 7y ago
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.
nikeee 7y ago
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.

twh270 7y ago

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.

smichel17 7y ago
It's also useful as a convenient syntax for maybes.

gmac 7y ago

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