6 ms·

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

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.
  - redact207 7y ago
    Enums and string literals aren't completely interchangable. Enums are transpired to objects so you can iterate the keys/values. You can't do that with SL which are a transpiler feature only. Also you can't codedoc string literal values like you can with enums where it shows up with intellisense. I tend to prefer enums as a result
    - reaktivo 7y ago
      Since TS 3.4 you can have enum-like behaviour by using the `as const` annotation on object and array literals. const types = ['x', 'y', 'z'] as const; const a: typeof types[number] = 'a'; // not ok const b: typeof types[number] = 'z'; // ok
      - styfle 7y ago
        Not to be confused with `const enum` which act more like a preprocessor and emits in the value at compile time. const enum Directions { Up, Down, Left, Right } console.log(Directions.Left) // emits js file with console.log(2) https://www.typescriptlang.org/docs/handbook/enums.html#const-enums https://www.typescriptlang.org/docs/handbook/enums.html#cons...
    - munchor 7y ago
      That is correct. However, I still prefer using union types so that I'm not locked in to TypeScript. By using only union types as "enums" and never using enums or namespaces, I guarantee that all the TS-specific code I write can be erased and if I ever were to use just JavaScript in the future, I could. Also, I use Babel to transpile TS to ES3.
      - reaktivo 7y ago
        You can have the best of both worlds, see this comment https://news.ycombinator.com/item?id=21134911 https://news.ycombinator.com/item?id=21134911
    - deleted 7y ago
      [deleted]
- Vinnl 7y ago
  Note that TypeScript also has union types - I never use enums.

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.
- redact207 7y ago
  Enums and string literals aren't completely interchangable. Enums are transpired to objects so you can iterate the keys/values. You can't do that with SL which are a transpiler feature only. Also you can't codedoc string literal values like you can with enums where it shows up with intellisense. I tend to prefer enums as a result
  - reaktivo 7y ago
    Since TS 3.4 you can have enum-like behaviour by using the `as const` annotation on object and array literals. const types = ['x', 'y', 'z'] as const; const a: typeof types[number] = 'a'; // not ok const b: typeof types[number] = 'z'; // ok
    - styfle 7y ago
      Not to be confused with `const enum` which act more like a preprocessor and emits in the value at compile time. const enum Directions { Up, Down, Left, Right } console.log(Directions.Left) // emits js file with console.log(2) https://www.typescriptlang.org/docs/handbook/enums.html#const-enums https://www.typescriptlang.org/docs/handbook/enums.html#cons...
  - munchor 7y ago
    That is correct. However, I still prefer using union types so that I'm not locked in to TypeScript. By using only union types as "enums" and never using enums or namespaces, I guarantee that all the TS-specific code I write can be erased and if I ever were to use just JavaScript in the future, I could. Also, I use Babel to transpile TS to ES3.
    - reaktivo 7y ago
      You can have the best of both worlds, see this comment https://news.ycombinator.com/item?id=21134911 https://news.ycombinator.com/item?id=21134911
  - deleted 7y ago
    [deleted]
Vinnl 7y ago
Note that TypeScript also has union types - I never use enums.