8 ms·

TypeScript 3.7 Beta

117 points by sebazzz 7y ago

Epskampie 7y ago
Looks nice. I love how dedicated typescript is to sticking to standard javascript, even by championing features through the ecmascript standards track. They understand very well how bad it would be if the two languages were to diverge.
- stefan_ 7y ago
  It just means we are at embrace & extend. And personally I can't wait to hit extinguish. Good riddance "ECMAScript".
- munchor 7y ago
  Yes, I agree. I also think that if they were starting out today, they wouldn't have either Enums or Namespaces since those features require adding runtime code (as opposed to every other TS feature which is erasable). However, when they started out, JavaScript wasn't as evolved (and it didn't look like it would evolve this much) and so they had to add a few things "on their own".
  - azangru 7y ago
    I started writing this comment thinking "no way, enums make so much sense", but then remembered Flow, where an enum is modelled simply as a union type, and agree that that approach would have probably been better.
    - skrebbel 7y ago
      Yep, and nowadays TS has string literal types and unions so enums are pretty much obsolete. type Direction = "up" | "down";
      - azangru 7y ago
        Interesting. I swear that when I previously tried this approach I had to explicitly tell typescript that a string is indeed of a particular type: const test(direction: Direction) => direction; test('up' as 'up'); But now that I'm testing in typescript playground, I no longer need to write the "as" part — simply `test('up');` works fine as well. I wonder if you've seen this quirk of typescript before.
        skrebbel 7y ago
        I have. It's when you do const dir = "up"; // TS infers type "string" test(dir); // error For mutable variables (let/var), you usually want TS to infer `string` in the first line. IMO the fact that they also infer `string` for constants is a design flaw, that I hope will one day be fixed. They recently added a feature to make this less painful: const dir = "up" as const; test(dir); // works That's the same as `as "up"` bit without having to duplicate the string.
        mcaruso 7y ago
        `const` variables are actually inferred without widening. So in your example `dir` would be inferred as `"up"`, not `string`. If you use `let` (or `var`) however that would be true.
        azangru 7y ago
        My god, you are right! (example in typescript playground: https://www.typescriptlang.org/play/#code/C4TwDgpgBAIglgJwgY2HA9gOygXigcgFcx8oAfAgE3QHdN8AoB0SKAFQgGdhcoBvBlCGVEKNFgBcsUagyYA3AwC+TBsizcowLjzwAKSgENghqR24BKXAD4oRkwDoRSWVkXrMm57yIkGAGwgeAFtCEwAjQPgEH2J8RWYdPT5nMTkpZyULRW1uZNTXTClQiKjELPkgA0 https://www.typescriptlang.org/play/#code/C4TwDgpgBAIglgJwgY...)
        skrebbel 7y ago
        Oh wow! Great, thanks. I wonder how I recalled that wrong.
      - 7y ago
    - Vinnl 7y ago
      Note that TypeScript also has union types - I never use enums.
dtech 7y ago
Really nice, I work in a project with a lot of nested optional values, and all the `a && a.b && a.b.c && a.b.c.d` checks really introduce a lot of noise.
- manojlds 7y ago
  Mostly it's a code smell though https://en.m.wikipedia.org/wiki/Law_of_Demeter https://en.m.wikipedia.org/wiki/Law_of_Demeter
  - Vanit 7y ago
    4 chains is like reaching into an XHR response to pull out the success result, so I wouldn't say that's necessarily a smell.
  - mattmanser 7y ago
    Not really, especially when you're working with external APIs. That's when I find myself using a lot of this type of code.
  - zhirzh 7y ago
    I'd say it is a design smell and not necessarily code smell. Any API or data interface should try to keep "optional keys" at a minimum. Depending on the language, `a.b && ...` could be checking either or both of the following: - does `a` have key 'b'? - is `a.b` truthy?
    - jiofih 7y ago
      Tell that to the team that created protocol buffers.
  - gridlockd 7y ago
    Programming is fundamentally about the transformation of data and sometimes data is in such a shape that inevitably requires such code. Most of the time, you don't get to decide what shape the data is in. OOP just obfuscates this basic fact of programming life to the point where it's not obvious anymore. That is not a good thing, it's a huge waste of time. Favor plain data over "objects" and functions over methods. Favor plain SQL queries over ORM.
m00dy 7y ago
optional chaining !!! FTW
munchor 7y ago
"Assertion Functions" are quite interesting. When we moved from Flow to TypeScript, this was the number 1 thing that frustrated us about TypeScript. The issue is that we had a lot of calls like this: ``` function assert(condition: boolean, message: string) { if (!condition) { throw new Error(message); } } assert(x !== null, "x can't be null"); // Flow understands that x can't be null here because `invariant` throws an error otherwise, but TS doesn't ``` However, TypeScript couldn't understand that `x` can't be null after that call since it doesn't understand what `assert` does. For that reason, we had to write a codemod that replaced all of our `assert` calls with an if condition that threw an error inline. The new `asserts` syntax is nice (it would be even better if TS could do this automatically like Flow though), and will be a much welcome update for us.
- deepersprout 7y ago
  I don't get Assert Functions. What are they good for? Maybe there is a use case I am not getting, but this function yell(str) { assert(typeof str === "string"); return str.toUppercase(); // ~~~~~~~~~~~ // error: Property 'toUppercase' does not exist on type 'string'. // Did you mean 'toUpperCase'? } function assert(condition: any, msg?: string): asserts condition { if (!condition) { throw new AssertionError(msg) } } Seems like the equivalent to function yell(str : String) { return str.toUppercase(); // ~~~~~~~~~~~ // error: Property 'toUppercase' does not exist on type 'string'. // Did you mean 'toUpperCase'? } But the latter has much less code and is clearer too. What am I missing?
  - bsaul 7y ago
    I’m not sure that’s what you’re asking, but assertion are often used to trigger error in debug mode on runtime properties not covered by the type system (array having a min / max number of elements, code being executed in a background thread, etc..).
    - deepersprout 7y ago
      I still don't get it. Please help me out. Why should the type system have anything to do with something like this? function something(num : number) { assertIsInRange(num); return num + 1; } function assertIsInRange(num: number, msg?: string): asserts num { if (num < 50 || num > 100) { throw new Error('not in range'); } } something(50); How is `asserts num` helping here?
thisBrian 7y ago
Slightly OT, but for those not aware: typescript's type system is turing-complete[0], and there's a playground demonstrating number base conversion[1]. 0: https://github.com/Microsoft/TypeScript/issues/14833 https://github.com/Microsoft/TypeScript/issues/14833 1: https://github.com/Microsoft/TypeScript/issues/14833#issuecomment-535858897 https://github.com/Microsoft/TypeScript/issues/14833#issueco...
blobs 7y ago
> The star of the show in optional chaining is the new ?. operator for optional property accesses. Wow, that took a while! For already about 9 years this feature is in Coffeescript. And indeed it must be the star of the show because once you're used to that you almost can't live without it. Why did JS/ESxx never copied that idea? edit: just read it has just been added to JS some days ago as well..
- blitmap 7y ago
  As an aside... I am still a huge fan of Coffeescript as my main driver. I'm learning more about TypeScript and Rust, but Coffeescript remains my language for concision/expression :) All of the above need method chaining, though: https://en.wikipedia.org/wiki/Method_chaining https://en.wikipedia.org/wiki/Method_chaining
- rimunroe 7y ago
  This may feel a bit nit-picky, but they haven't been added to ECMAScript yet. There are two features here: the optional chaining operator[1] and nullish coalescing operator[2]. Both are at stage 3 of the standardization process. Changes to proposed features can still be made at stage 3 if critical issues come up. Otherwise, once implementors have sufficient experience with them (and tests & multiple implementations exist) the proposals will be eligible to move to stage 4, after which they'll be able to be included as part of the next ECMAScript spec. Both proposals are progressing through the process very smoothly, but I wouldn't rely on them for anything critical just yet. [1] https://github.com/tc39/proposal-optional-chaining https://github.com/tc39/proposal-optional-chaining [2] https://github.com/tc39/proposal-nullish-coalescing https://github.com/tc39/proposal-nullish-coalescing
  - styfle 7y ago
    Thats a good point. It is probably rare for proposals to change after stage 3 which is why the TypeScript team does not implement a ECMAScript feature until it reaches Stage 3. In this case, members of the TS team were actually championing these ES proposals :)

117 points by sebazzz 7y ago

Looks nice. I love how dedicated typescript is to sticking to standard javascript, even by championing features through the ecmascript standards track. They understand very well how bad it would be if the two languages were to diverge.

stefan_ 7y ago
It just means we are at embrace & extend. And personally I can't wait to hit extinguish. Good riddance "ECMAScript".
munchor 7y ago
Yes, I agree. I also think that if they were starting out today, they wouldn't have either Enums or Namespaces since those features require adding runtime code (as opposed to every other TS feature which is erasable). However, when they started out, JavaScript wasn't as evolved (and it didn't look like it would evolve this much) and so they had to add a few things "on their own".
- azangru 7y ago
  I started writing this comment thinking "no way, enums make so much sense", but then remembered Flow, where an enum is modelled simply as a union type, and agree that that approach would have probably been better.
  - skrebbel 7y ago
    Yep, and nowadays TS has string literal types and unions so enums are pretty much obsolete. type Direction = "up" | "down";
    - azangru 7y ago
      Interesting. I swear that when I previously tried this approach I had to explicitly tell typescript that a string is indeed of a particular type: const test(direction: Direction) => direction; test('up' as 'up'); But now that I'm testing in typescript playground, I no longer need to write the "as" part — simply `test('up');` works fine as well. I wonder if you've seen this quirk of typescript before.
      - skrebbel 7y ago
        I have. It's when you do const dir = "up"; // TS infers type "string" test(dir); // error For mutable variables (let/var), you usually want TS to infer `string` in the first line. IMO the fact that they also infer `string` for constants is a design flaw, that I hope will one day be fixed. They recently added a feature to make this less painful: const dir = "up" as const; test(dir); // works That's the same as `as "up"` bit without having to duplicate the string.
        mcaruso 7y ago
        `const` variables are actually inferred without widening. So in your example `dir` would be inferred as `"up"`, not `string`. If you use `let` (or `var`) however that would be true.
        azangru 7y ago
        My god, you are right! (example in typescript playground: https://www.typescriptlang.org/play/#code/C4TwDgpgBAIglgJwgY2HA9gOygXigcgFcx8oAfAgE3QHdN8AoB0SKAFQgGdhcoBvBlCGVEKNFgBcsUagyYA3AwC+TBsizcowLjzwAKSgENghqR24BKXAD4oRkwDoRSWVkXrMm57yIkGAGwgeAFtCEwAjQPgEH2J8RWYdPT5nMTkpZyULRW1uZNTXTClQiKjELPkgA0 https://www.typescriptlang.org/play/#code/C4TwDgpgBAIglgJwgY...)
        skrebbel 7y ago
        Oh wow! Great, thanks. I wonder how I recalled that wrong.
    - 7y ago
  - Vinnl 7y ago
    Note that TypeScript also has union types - I never use enums.

dtech 7y ago

Really nice, I work in a project with a lot of nested optional values, and all the `a && a.b && a.b.c && a.b.c.d` checks really introduce a lot of noise.

manojlds 7y ago
Mostly it's a code smell though https://en.m.wikipedia.org/wiki/Law_of_Demeter https://en.m.wikipedia.org/wiki/Law_of_Demeter
- Vanit 7y ago
  4 chains is like reaching into an XHR response to pull out the success result, so I wouldn't say that's necessarily a smell.
- mattmanser 7y ago
  Not really, especially when you're working with external APIs. That's when I find myself using a lot of this type of code.
- zhirzh 7y ago
  I'd say it is a design smell and not necessarily code smell. Any API or data interface should try to keep "optional keys" at a minimum. Depending on the language, `a.b && ...` could be checking either or both of the following: - does `a` have key 'b'? - is `a.b` truthy?
  - jiofih 7y ago
    Tell that to the team that created protocol buffers.
- gridlockd 7y ago
  Programming is fundamentally about the transformation of data and sometimes data is in such a shape that inevitably requires such code. Most of the time, you don't get to decide what shape the data is in. OOP just obfuscates this basic fact of programming life to the point where it's not obvious anymore. That is not a good thing, it's a huge waste of time. Favor plain data over "objects" and functions over methods. Favor plain SQL queries over ORM.

m00dy 7y ago

optional chaining !!! FTW

munchor 7y ago

"Assertion Functions" are quite interesting. When we moved from Flow to TypeScript, this was the number 1 thing that frustrated us about TypeScript. The issue is that we had a lot of calls like this: ``` function assert(condition: boolean, message: string) { if (!condition) { throw new Error(message); } } assert(x !== null, "x can't be null"); // Flow understands that x can't be null here because `invariant` throws an error otherwise, but TS doesn't ``` However, TypeScript couldn't understand that `x` can't be null after that call since it doesn't understand what `assert` does. For that reason, we had to write a codemod that replaced all of our `assert` calls with an if condition that threw an error inline. The new `asserts` syntax is nice (it would be even better if TS could do this automatically like Flow though), and will be a much welcome update for us.

deepersprout 7y ago
I don't get Assert Functions. What are they good for? Maybe there is a use case I am not getting, but this function yell(str) { assert(typeof str === "string"); return str.toUppercase(); // ~~~~~~~~~~~ // error: Property 'toUppercase' does not exist on type 'string'. // Did you mean 'toUpperCase'? } function assert(condition: any, msg?: string): asserts condition { if (!condition) { throw new AssertionError(msg) } } Seems like the equivalent to function yell(str : String) { return str.toUppercase(); // ~~~~~~~~~~~ // error: Property 'toUppercase' does not exist on type 'string'. // Did you mean 'toUpperCase'? } But the latter has much less code and is clearer too. What am I missing?
- bsaul 7y ago
  I’m not sure that’s what you’re asking, but assertion are often used to trigger error in debug mode on runtime properties not covered by the type system (array having a min / max number of elements, code being executed in a background thread, etc..).
  - deepersprout 7y ago
    I still don't get it. Please help me out. Why should the type system have anything to do with something like this? function something(num : number) { assertIsInRange(num); return num + 1; } function assertIsInRange(num: number, msg?: string): asserts num { if (num < 50 || num > 100) { throw new Error('not in range'); } } something(50); How is `asserts num` helping here?

thisBrian 7y ago

Slightly OT, but for those not aware: typescript's type system is turing-complete[0], and there's a playground demonstrating number base conversion[1]. 0: https://github.com/Microsoft/TypeScript/issues/14833 https://github.com/Microsoft/TypeScript/issues/14833 1: https://github.com/Microsoft/TypeScript/issues/14833#issuecomment-535858897 https://github.com/Microsoft/TypeScript/issues/14833#issueco...

blobs 7y ago

> The star of the show in optional chaining is the new ?. operator for optional property accesses. Wow, that took a while! For already about 9 years this feature is in Coffeescript. And indeed it must be the star of the show because once you're used to that you almost can't live without it. Why did JS/ESxx never copied that idea? edit: just read it has just been added to JS some days ago as well..

blitmap 7y ago
As an aside... I am still a huge fan of Coffeescript as my main driver. I'm learning more about TypeScript and Rust, but Coffeescript remains my language for concision/expression :) All of the above need method chaining, though: https://en.wikipedia.org/wiki/Method_chaining https://en.wikipedia.org/wiki/Method_chaining
rimunroe 7y ago
This may feel a bit nit-picky, but they haven't been added to ECMAScript yet. There are two features here: the optional chaining operator[1] and nullish coalescing operator[2]. Both are at stage 3 of the standardization process. Changes to proposed features can still be made at stage 3 if critical issues come up. Otherwise, once implementors have sufficient experience with them (and tests & multiple implementations exist) the proposals will be eligible to move to stage 4, after which they'll be able to be included as part of the next ECMAScript spec. Both proposals are progressing through the process very smoothly, but I wouldn't rely on them for anything critical just yet. [1] https://github.com/tc39/proposal-optional-chaining https://github.com/tc39/proposal-optional-chaining [2] https://github.com/tc39/proposal-nullish-coalescing https://github.com/tc39/proposal-nullish-coalescing
- styfle 7y ago
  Thats a good point. It is probably rare for proposals to change after stage 3 which is why the TypeScript team does not implement a ECMAScript feature until it reaches Stage 3. In this case, members of the TS team were actually championing these ES proposals :)