I like these recommendations, especially around decorators, maybe I’ll start following them
reviews Angular app
oh
TypeScript Features to Avoid
31–40 of 212 posts
Re: TypeScript Features to Avoid
#32I 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…
> I honestly don't care what this transpiles down to, the point for us at least is not to make things "truly private" (good luck with that in JavaScript). It's simply to compiler-enforce rules. It’s not just JavaScript. With reflection in C# and Java, you can mess around with private variables from outside the classes. For Java, this can have some pretty interesting results, such as 2+2 being equal to 5 .[0] The whol…
Agreed, with reflection you can get around that also, but in JS it's even less of a "real thing" at the moment and I don't see that changing until the far future where we can drop some of this legacy cruft.
Re: TypeScript Features to Avoid
#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, TypeScript gives general intersection types, which is quite rare among its peers. (What I wouldn't give some days for mypy to have intersection types, or bivariant functions, or conditional types, or ...)
The only other impetus for this post I can imagine is some weird desire to see typescript as a strictly separate layer above JavaScript that "could be removed" if we wanted it to be. I suppose that was the project's original telos, but today the abstraction is leaky in a few places. I'm a world where JSX is common and radically departs from what would be considered normal JS, I don't see a problem with TypeScript being leaky here and there. Hell, I'd prefer TS to be leakier and add opt-in runtime checking (i.e. code gen), because it would make my life easier in certain instances.
Re: TypeScript Features to Avoid
#34I've never had any issues with enums, namespaces or private keywords (can't speak for decorators as I haven't used them yet). Although I do understand the reasoning for using the '#somePrivateField' rather than 'private somePrivateField'. But features like enums are part of the reason why we even have tools like TypeScript, because JavaScript lacks these features.
I wish TypeScript somehow would use #-private fields underwater when compiling code. `#field` is pretty confusing; I keep thinking it's a comment and it looks ugly
Although I do understand the reasoning in the article, I completely agree with you.
Switching between Python and TypeScript/JavaScript all the time, using ‘#’ to define private field feels weird and I personally prefer more explicit way of writing code. Plus AFAIK the ‘private someField’ is common in other languages (Java, Scala,…).
Re: TypeScript Features to Avoid
#35> it has to generate new JavaScript code that doesn't exist in the original TypeScript code That’s nonsense, the code is there otherwise what are we talking about? You just need to understand how some TS features map to JS, that’s all.
I think you may have misunderstood the complaint, which is perfectly valid. A few paragraphs earlier: > The downside to enums comes from how they fit into the TypeScript language. TypeScript is supposed to be JavaScript, but with static type features added. If we remove all of the types from TypeScript code, what's left should be valid JavaScript code. The formal word used in the TypeScript documentation is "type-lev…
esbuild seems to support enums fine
Re: TypeScript Features to Avoid
#36Earlier quoted context omitted.
I'd go further. There's no strong argument for why code-gen is bad. Why is a compilation process that is simply "remove type annotations" inherently better than one that emits code, or does code transformations, other than just personal preference, aesthetics, or simplicity? About the only positive that is qualitatively different is the simplicity of comparing the output to the input. But for someone building a large…
I see the next to zero codegen in typescript as a strategy: it removes all discutions about languages features besides typing, guarantees next to zero issues in production in case of code generation bug, making compiler deliveries safe and avoid need of coordination in toolchain.
Enums and namespaces are hardly complex code gen or generate 'issues'. People would often manually namespace in JS a few years ago, and namespaces and enums can really just be seen a lightweight holder object instances. Indeed, enums in Java are class instances.
Besides, there is an straightforward way to remove enums from a program just like removing type annotations: Inline them as static fields of an object.
There is a simple syntactic transformation.
e.g. change 'enum' to 'const', add a '=' before the '{'
and use ':' instead of '='
const HttpMethod = {
Get: 'GET',
Post: 'POST'
};
// now this no longer breaks
const method = HttpMethod.Post;
Re: TypeScript Features to Avoid
#37The author misses I think an important point regarding enums: using a union type instead means you can't iterate the list of valid values without restating them in the value domain in a non-DRY fashion. The reason enum generates code is that it is both a type construct and a value construct... That ends up being useful in myriad contexts.
Re: TypeScript Features to Avoid
#38I disagree with the point about enums, they can be used to alias otherwise inconsistent long strings with more readable, consistent, succinct ones. For instance, product SKUs. I've had absolutely no problems with them with either past or current tooling (e.g. esbuild).
They can also be used in the more traditional form to represent some arbitrary values.
They shouldn't be overused, though.
Re: TypeScript Features to Avoid
#39> 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…
Based on how two of the four points key into it, I think the author is stuck using a tool in their tool chain that doesn't support TypeScript and has been bitten by that tool doing something Byzantine in response to TypeScript-generated code.
That's a problem a lot of developers won't have. I've covered a lot of ground without ever finding a tool that either hasn't been retrofit to support TypeScript or that has issues that are tickled by TypeScript generated code. My blunt recommendation if somebody hits that problem is to find a better tool.
Re: TypeScript Features to Avoid
#40> 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…
The TypeScript ecosystem is bigger than just the official compiler, though. Many projects use alternative compilers like esbuild or @babel/preset-typescript for their main pipeline and only use the official TypeScript compiler as a typechecker (with `--noEmit`, during CI).
It's true that enums are harder to support for alternative compilers. Especially `const enum` seems to be harder.