Announcing TypeScript 2.2
blogs.msdn.microsoft.com
Announcing TypeScript 2.2
1–10 of 123 posts
Re: Announcing TypeScript 2.2
#2My favorite: the new `object` type. Non-nullable and cannot refer to primitives.
Re: Announcing TypeScript 2.2
#3My favorite: the new `object` type. Non-nullable and cannot refer to primitives.
The new `react-native` jsx target is also a good step in the right direction of creating smooth React Native projects in TS. I can't wait for it to be a seamless dev experience, but now the ball's in RN's court. [1]
(Context: using TS in a RN project is currently a bit disjointed because of its closed dev bundling workflow. You need a separate build task running concurrently to feed JS files to the main watch/build task.)
Re: Announcing TypeScript 2.2
#4My favorite: the new `object` type. Non-nullable and cannot refer to primitives.
Non-nullable
This is incorrect, as is the announcement. The following is valid.
class Bar{}
let foo:object = new Bar()
foo = null
foo = undefined
For the people mentioning, --strictNullChecks. That applies to all types not just object. For example, "let x:string = null" would also be an error. That option applies to any type that is not of type Any/null/undefined, and has been in place since 2.0. In that way, "object" is non-nullable under strictNullChecks just as every other type is.
Re: Announcing TypeScript 2.2
#5My favorite: the new `object` type. Non-nullable and cannot refer to primitives.
Can you show a few examples of where this is useful?
Re: Announcing TypeScript 2.2
#6My favorite: the new `object` type. Non-nullable and cannot refer to primitives.
Non-nullable This is incorrect, as is the announcement. The following is valid. class Bar{} let foo:object = new Bar() foo = null foo = undefined edit: For the people mentioning, --strictNullChecks. That applies to all types not just object. For example, "let x:string = null" would also be an error. That option applies to any type that is not of type Any/null/undefined, and has been in place since 2.0. In that way, "…
I guess it's only so with `strictNullChecks` enabled?
Anyway, TypeScript's `strictNullChecks` in general has a huge hole in that it allows uninitialized properties (https://github.com/Microsoft/TypeScript/issues/8476).
Re: Announcing TypeScript 2.2
#7My favorite: the new `object` type. Non-nullable and cannot refer to primitives.
Non-nullable This is incorrect, as is the announcement. The following is valid. class Bar{} let foo:object = new Bar() foo = null foo = undefined edit: For the people mentioning, --strictNullChecks. That applies to all types not just object. For example, "let x:string = null" would also be an error. That option applies to any type that is not of type Any/null/undefined, and has been in place since 2.0. In that way, "…
No, object is not a nullable type.
For your code to work, you'd need to run it with strictNullChecks disabled. That's probably what you're doing, since it's the default.
Re: Announcing TypeScript 2.2
#8Object type, better index access, and the quick fixes are all great additions. Awesome job TS team, keep it coming!
Re: Announcing TypeScript 2.2
#9My favorite: the new `object` type. Non-nullable and cannot refer to primitives.
Non-nullable This is incorrect, as is the announcement. The following is valid. class Bar{} let foo:object = new Bar() foo = null foo = undefined edit: For the people mentioning, --strictNullChecks. That applies to all types not just object. For example, "let x:string = null" would also be an error. That option applies to any type that is not of type Any/null/undefined, and has been in place since 2.0. In that way, "…
I think you can use the `--strictNullChecks`[1] compiler option to get that behavior though.
1: https://www.typescriptlang.org/docs/handbook/compiler-option...
Re: Announcing TypeScript 2.2
#10Relaxing index-signature access is definitely great as it will make writing code easier. Dynamic properties can lead you to hairy code but it's hard to ignore the reality that it's used everywhere.
For example, no more awkward `e["code"]` where `e.code` is just as valid.