Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TypeScript Features to Avoid

executeprogram.com

Post reply on HN
Print view View original

101–110 of 212 posts

Re: TypeScript Features to Avoid

#101

Post by DrJokepu »

activitypea wrote: post #43
baryphonic wrote: post #33

> 1. Avoid Enums What? This is IMO bad advice. Having a sum type is quite handy for general type-checking, at least insofar as the type truly is an enumerated type (i.e. all possible values are known at design-time). There have been times when TypeScript enums have been indispensable to me when declaring the external interface to some client-facing API. Whatever the API boundary is, a sum type is useful. Also, TypeSc…

What are the advantages of enums over a string literal union? I can only see disadvantages.

If you have to change one of the underlying values, you only need to change it in one place. Of course, you could just use constants, but then you’ll just have a const enum with extra steps.

Re: TypeScript Features to Avoid

#102

Post by iakov »

gwbas1c wrote: post #90
maronato wrote: post #16

The article's premise is wrong imo. Typescript is a superset[1] of javascript, so typescript-only syntactic sugar is entirely to be expected. [1]: https://github.com/microsoft/TypeScript (repo description)

Not saying I agree, but this is a completely valid viewpoint. When I initially saw Typescript, I thought the point was to add features from strongly-typed languages and then transpile into Javascript. (IE, a more modern version of GWT, a Java to Javascript transpiler.) The point of the article, though, is that Typescript works best when its extensions to the language can simply be dropped. That's clearly a "we've wor…

Typescript works fine with it's extensions to the language. In fact, I can't imagine how it would not work fine - that would be a serious issue in the official compiler or tools.

It's the other tools that author is/was using that are having issues. It's silly to provide blanket statements about very useful features like enums or namespaces just because some third-party tool is struggling with them IMO.

Re: TypeScript Features to Avoid

#103

Post by conaclos »

joshstrange wrote: post #99

After trying enums in TS a long time back I also realized it was best to avoid them. Here is my solution to this: // filename: role.ts export const Role = { CUSTOMER: 'customer', ADMIN: 'admin', SYSTEM: 'system', STAFF: 'staff', } as const; type TRole = keyof typeof Role; export type TUserRole = typeof Role[TRole]; Using this structure I can reference any of my roles by `Role.CUSTOMER` and the value is `customer` bec…

You can also name your type with the same name as the value:

  export const Role = {
      CUSTOMER: 'customer',
      ADMIN: 'admin',
      SYSTEM: 'system',
      STAFF: 'staff',
  } as const
  export type Role = typeof Role[keyof typeof Role]

Re: TypeScript Features to Avoid

#104

Post by conaclos »

joshstrange wrote: post #99

After trying enums in TS a long time back I also realized it was best to avoid them. Here is my solution to this: // filename: role.ts export const Role = { CUSTOMER: 'customer', ADMIN: 'admin', SYSTEM: 'system', STAFF: 'staff', } as const; type TRole = keyof typeof Role; export type TUserRole = typeof Role[TRole]; Using this structure I can reference any of my roles by `Role.CUSTOMER` and the value is `customer` bec…

`as const` is needed for ensuring that TypeScript uses literal types for the enum members. Otherwise you ends with `TUserRole = string`.

Re: TypeScript Features to Avoid

#105

Post by joshstrange »

conaclos wrote: post #103
joshstrange wrote: post #99

After trying enums in TS a long time back I also realized it was best to avoid them. Here is my solution to this: // filename: role.ts export const Role = { CUSTOMER: 'customer', ADMIN: 'admin', SYSTEM: 'system', STAFF: 'staff', } as const; type TRole = keyof typeof Role; export type TUserRole = typeof Role[TRole]; Using this structure I can reference any of my roles by `Role.CUSTOMER` and the value is `customer` bec…

You can also name your type with the same name as the value: export const Role = { CUSTOMER: 'customer', ADMIN: 'admin', SYSTEM: 'system', STAFF: 'staff', } as const export type Role = typeof Role[keyof typeof Role]

:facepalm: of course I can, I don't know why it never occurred to me. Probably a case of "if it's ain't broke" but going forward I'll probably switch to this style.

Re: TypeScript Features to Avoid

#106

Post by msoad »

Vinnl wrote: post #81

This basically comes down to: avoid TypeScript features that clash with TypeScript's design goals. Specifically, the one to: > Avoid adding expression-level syntax. https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi... And that makes sense to me. IMHO it's best to consider TypeScript as a tool that aims to help you write JavaScript by catching common errors; it's more like a linter than a separate language…

Yes, I think if they could the would remove namespaces and enums

Re: TypeScript Features to Avoid

#107

Post by cypressious »

joshstrange wrote: post #99

After trying enums in TS a long time back I also realized it was best to avoid them. Here is my solution to this: // filename: role.ts export const Role = { CUSTOMER: 'customer', ADMIN: 'admin', SYSTEM: 'system', STAFF: 'staff', } as const; type TRole = keyof typeof Role; export type TUserRole = typeof Role[TRole]; Using this structure I can reference any of my roles by `Role.CUSTOMER` and the value is `customer` bec…

Have you tried `const enum`?

See https://www.typescriptlang.org/docs/handbook/enums.html#cons...

> Const enums can only use constant enum expressions and unlike regular enums they are completely removed during compilation. Const enum members are inlined at use sites.

Re: TypeScript Features to Avoid

#108

Post by conaclos »

joshstrange wrote: post #105
conaclos wrote: post #103

Earlier quoted context omitted.

You can also name your type with the same name as the value: export const Role = { CUSTOMER: 'customer', ADMIN: 'admin', SYSTEM: 'system', STAFF: 'staff', } as const export type Role = typeof Role[keyof typeof Role]

:facepalm: of course I can, I don't know why it never occurred to me. Probably a case of "if it's ain't broke" but going forward I'll probably switch to this style.

For a long time I avoided to use the same name for a type and a value because I was afraid of possible breaking change in the feature.

And then I realized that this is an intended feature of TypeScript: type merging. Here the type `Role` merges with the type of the value `Role :)

Re: TypeScript Features to Avoid

#109

Post by BrandonM »

EMM_386 wrote: post #23

I disagree with this. We have a reasonably large Angular application that is only going to get much bigger (hard to define what that means ... big telephony app with tens of thousands of customers). I am the lead and architect. We use enums and private keywords. With the private keywords, all I care about is that it is logically correct. We use private when things are truly private, i.e. they are only called from wit…

From the article:

    this.downloadService.fileWithProgress(url, 'POST', 'download', body);

    ...

    public fileWithProgress(url: string, reqType: RequestType, actionType: ActionType, body: ...): void {
        ...
    }
    ...
    export type RequestType = 'GET' | 'POST' | ...;
    export type ActionType = 'download' | ...;

Re: TypeScript Features to Avoid

#110

Post by eyelidlessness »

The reason enums are useful—and the private keyword until recently with JS adding private fields—are that they’re nominal types. You can have…

  enum HTTPMethod {
    POST = 'post',
    // ...
  }

  enum FenceMaterial {
    POST = 'post',
    // ...
  }
… and you can be sure 'post' is not ambiguous.

Private fields have the same benefit, which is particularly useful for treating abstract classes as nominal interfaces. But yes, if your target environments support private fields natively, it’s more idiomatic to use those than the private keyword now.

I generally avoid namespaces, but they’re also sometimes useful eg satisfying weird function signatures expecting a callback with additional properties assigned to it. This is of course uncommon in TypeScript, but fairly common in untyped JavaScript and its corresponding DefinitelyTyped declarations.

Post reply on HN