We evaluated TS for a recent project but ended up with JS (and VueJS 3). I have a feeling it would have taken much longer to develop using TS, but lacking experience in TypeScript it's hard to say. I find JS pretty neat for exploratory programming.
TypeScript Features to Avoid
111–120 of 212 posts
Re: TypeScript Features to Avoid
#112Is anyone still using the class keyword in javascript or typescript? private field syntax doesn't matter in the first place if you don't use class {} anywhere ... I feel like most of the typescript code i've been in recently looked like it needed 0 more class declarations.
I use classes quite a lot. And I’m kind of a FP zealot. I generally treat class as a struct value type, and I also generally go to the trouble of marking every property readonly. They’re useful for several reasons:
- Abstract classes are useful for defining nominal interface types
- Classes are a clear signal that a set of methods are designed to interact with related data types
- The prototype chain can be helpful for debugging where POJOs may lose information in the call stack
- JS runtimes can sometimes optimize classes in ways they can’t with POJOs
Re: TypeScript Features to Avoid
#113We evaluated TS for a recent project but ended up with JS (and VueJS 3). I have a feeling it would have taken much longer to develop using TS, but lacking experience in TypeScript it's hard to say. I find JS pretty neat for exploratory programming.
I can assure you that doing it in TS would not have been any slower and you would have gained all the benefits that static type checking brings with it.
VueJS 3 in particular is much better suited to use TS than its predecessor (without any additional plugins).
Re: TypeScript Features to Avoid
#114Article makes no real good arguments about not using the private keyword. It's more descriptive and carries knowledge from other languages compared to putting a hashtag in front of a variable name.
I agree. Just because JS has its way of doing it does not mean you need to stick to that. I mean, TS adds a bunch of new keywords to the language that JS lacks. Why not simply stick to those intuitive keywords rather than this weird variable naming nonsense that JS has to use because it doesn't have access modifiers of any kind?
Re: TypeScript Features to Avoid
#115Earlier quoted context omitted.
I like string enums, since they are self-documenting, I guess int enums are smaller when sent over network. Could you expand on that?
Why do you find them self documenting? Usually it's just enum Method { Get = "GET" // ... } I usually always put doc comments on enums and their variants. Regarding why numeric ones are (only sometimes) more useful than string values: bit flags comes to mind, faster comparison of numbers than strings (not always tho... unless this is a misconception, but I don't believe so), you mentioned smaller bundle size already.…
enum Method {
Get = "method/GET"
// ...
}
Re: TypeScript Features to Avoid
#116Lots of comments seen to have missed that the article isn't recommending against private fields, only the private keyword.
Typescript and JavaScript have a newer brand # to make fields private. The native feature will have runtime benefits while the private keyword creates fields that's are public at runtime.
I still use the private keyword because constructor shorthand doesn't support brands.
constructor (private field)
constructor (#field) // errorRe: TypeScript Features to Avoid
#117Yeah, for sure, I agree with all of this. I think the best way to write TypeScript is to really treat it like the tagline "JavaScript With Syntax For Types" - some of the extras TypeScript provided from before TC39 were active have much less relevance now.
Re: TypeScript Features to Avoid
#118He 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.
You can do that with sum types.
type methods = 'a' | 'b'
const value: methods = 'c' // error
Re: TypeScript Features to Avoid
#119This 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…
> it's more like a linter than a separate language
I wish people wouldn't think like this; it's very possible to write perfectly acceptable JavaScript that's fundamentally terrible TypeScript. By "fundamentally terrible", I mean unnecessarily untypeable, or unnecessarily difficult to type. If you're just writing your usual JavaScript without thinking about the types just figuring you'll "lint" it later with tsc to catch some bugs, if you aren't thinking in TypeScript from the jump, you're likely to make your life much more unpleasant down the line. It's similar to the relationship between C and C++.
Re: TypeScript Features to Avoid
#120After 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.
[deleted]