Live data from Hacker News

TypeScript Features to Avoid

executeprogram.com

121–130 of 212 posts

Re: TypeScript Features to Avoid

#121
I would also suggest to avoid too complex genrics, these tend to make te code unreadable and make the compilation super slow.

Usually generic code tries to make everything type safe but having some portions of your code be dynamic is completely fine imo.

Re: TypeScript Features to Avoid

#122
post #94

Earlier quoted context omitted.

In some cases you can use it to define string arguments to an external library. Maybe table names to an ORM or a well-known file path. This helps because you get autocomplete from typing `MyEnum.` and seeing options, even though the external function takes a plain string.

All of that is possible with a string literal union though, surely?

It's not possible to get the autocomplete unless the function/method you're calling takes a union. Many libraries can't do that because they need to be flexible in what they receive. So yeah, you can define a union, but editors don't have the context to know your union applies to the call.

Re: TypeScript Features to Avoid

#123

He is completely incorrect about the purpose of enums. It isn't to simplify changing all locations of an occurrence. It is for defining domain concepts. It is to communicate to other code users, here is every allowed permutation of this type.

I don't know if you are correct, but this is closest to how I think about it

Mechanically, a const dictionary, or a string union might achieve the same.

But semantically, an enum (sometimes) reads better.

Re: TypeScript Features to Avoid

#124
post #83

Earlier quoted context omitted.

In the use cases where I most typically use enums, I don't want to think about the question of runtime representation; I just want a set of arbitrary symbols that are different from one another. Implicitly initialized numeric enums do this idiomatically and concisely.

If you truly don't care about the runtime representation, then it sounds the idiomatic JS/TS construct you actually want is Symbol() https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... https://www.typescriptlang.org/docs/handbook/2/everyday-type...

I agree that it might have been better for that to be the TypeScript idiom, but it's not, due to the longer-standing popularity and concision and language-level support for enums. (Which couldn't have originally been designed to be lowered to symbols, because at the time symbols weren't widely-supported enough.)

Re: TypeScript Features to Avoid

#125

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.

I remember reading somewhere that the TypeScript devs considered const enums to be a mistake and recommend against using them. I don't remember why, though.

Re: TypeScript Features to Avoid

#126
post #62

The arguments against the four language features in this article all boil down to it not being Javascript. If I wanted to write in Javascript, I'd use files with a .js extension. If you've picked Typescript, I don't think you should worry about whether your code is also valid Javascript "if you remove all the type information" (who's going to do that anyway.) Unless you're a solo developer, what's more important it t…

I continue to maintain that despite all the nice features from ES6 onwards working in straight JavaScript is psycho shit. It’s the NFTs of development.

I’m genuinely looking forward to the day where we have other viable options for the DOM. I see TypeScript at best as a temporary band aid because you’re still stuck in the god awful NPM ecosystem at the end of the day.

Re: TypeScript Features to Avoid

#127

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…

I disagree. Enums are fine if they're string-only. It's only the numeric enums that cause the issues everyone complains about enums for. If there were a lint for making sure all enums are string-only, it would be the best solution, IMO.

AFAIK, your solution is (slightly) worse than an enum in several ways and better in none:

    export enum Role {
        CUSTOMER = 'customer',
        ADMIN = 'admin',
        SYSTEM = 'system',
        STAFF = 'staff',
    }
I think that implements everything yours does, but is easier to grok and fewer lines/declarations.

Re: TypeScript Features to Avoid

#128
post #92
post #91

Earlier quoted context omitted.

> It’s a full fledged language that compiles to readable JS Compiling to readable JS is not one of TS's goals. For example: https://www.typescriptlang.org/play?noImplicitAny=false&targ...

That seems very readable , especially in comparison to something like Dart or Elm’s output, both of which can output thousands of lines from something as simple as your example. From the language goals > 4. Emit clean, idiomatic, recognizable JavaScript code. https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...

I don’t really see the value proposition of having a compilation step that also prioritises readability when you have source maps.

I love Dart personally and I mostly see it’s compile to nonsense looking code as a feature not a bug because it’s an ACTUAL compilation step worked on by ex Chrome team members who understand V8 internals not just code splitting and running terser over it and calling it a day. Want to get the same compilation optimisations that Google uses to run all of their multi billion dollar ad business? Cool, that’s enabled by default out of the box. [1]

The part where Dart on the web falls over for me is that they have shitty support right now for modern web APIs. They are building against some ancient version of Chrome’s WebIDL files so you can totally forget about things like web components for example.

So in that sense it doesn’t feel like a sensible choice in 2022 for basic web development which is a shame because it’s otherwise probably the best developer experience I’ve ever seen.

[1] I say this somewhat theoretically, I don’t know that Dart is in anyway an obvious thing to point to in terms of web performance from what I had seen casually. I think their goal there you can write huge business critical applications with stupidly large code bases and still get good performance. But nobody’s experience after using Google Ads is to talk about how snappy it was.

Re: TypeScript Features to Avoid

#129

Earlier quoted context omitted.

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.

[deleted]

Re: TypeScript Features to Avoid

#130
post #83

Earlier quoted context omitted.

If you truly don't care about the runtime representation, then it sounds the idiomatic JS/TS construct you actually want is Symbol() https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... https://www.typescriptlang.org/docs/handbook/2/everyday-type...

I agree that it might have been better for that to be the TypeScript idiom, but it's not, due to the longer-standing popularity and concision and language-level support for enums. (Which couldn't have originally been designed to be lowered to symbols, because at the time symbols weren't widely-supported enough.)

Symbols are very well supported in TS today. You even get proper type enforcement and intellisense when using symbols as the names of methods and properties, for instance. Whether you should use them for enum-like purposes or not has more to do with how you want to use the values though. For instance using symbols for defining numeric protocol values doesn't make sense. Same for HTTP methods, where you are always ultimately passing a string down to the http client/server interfaces
Post reply on HN