Usually generic code tries to make everything type safe but having some portions of your code be dynamic is completely fine imo.
TypeScript Features to Avoid
121–130 of 212 posts
Re: TypeScript Features to Avoid
#122Earlier 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?
Re: TypeScript Features to Avoid
#123He 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.
Mechanically, a const dictionary, or a string union might achieve the same.
But semantically, an enum (sometimes) reads better.
Re: TypeScript Features to Avoid
#124Earlier 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...
Re: TypeScript Features to Avoid
#125After 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
#126The 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’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
#127After 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…
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
#128Earlier 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 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
#129Earlier 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.
Re: TypeScript Features to Avoid
#130Earlier 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.)