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 within the same class and don't need to be made visible to the view template or outside of the class. 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. We also have ESLint to ensure that our private fields are all below the public ones to keep things nice and neat.
I also enforce that we actually make things as public although that isn't needed, and I enforce returning void.
So instead of:
someMethod() {}
I have us use:
public someMethod(): void {}
Just to state what you intend.
I realize "I don't care what this transpiles down to" might really irk some people, but I really don't. In our C# back-end I am much more strict about this stuff, but in JS at the moment given the standardization of the #private fields and the fact I consider them really ugly, I honestly don't care. Just give me a clean code base that enforces we can't reference private fields and methods from our templates.
For enums, I recently wrote a method that does exactly what this article says not to do, use it for GET, POST, and PUT.
What would be a cleaner way to write this? If it has to be refactored into something much "uglier" I don't think I'd prefer it.
This is a service I wrote that handles real-time progress (i.e. show an accurate progress bar when downloading files). I think this is clean and logical.
> 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 whole point of compiler level annotations is to keep good programmers honest.
If some devious JavaScript developer wants to ruin your library, that's their fault.
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.
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 within the same class and don't need to be made visible to the view template or outside of the class. 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. We also have ESLint to ensure that our private fields are all below the public ones to keep things nice and neat.
I also enforce that we actually make things as public although that isn't needed, and I enforce returning void.
So instead of:
someMethod() {}
I have us use:
public someMethod(): void {}
Just to state what you intend.
I realize "I don't care what this transpiles down to" might really irk some people, but I really don't. In our C# back-end I am much more strict about this stuff, but in JS at the moment given the standardization of the #private fields and the fact I consider them really ugly, I honestly don't care. Just give me a clean code base that enforces we can't reference private fields and methods from our templates.
For enums, I recently wrote a method that does exactly what this article says not to do, use it for GET, POST, and PUT.
What would be a cleaner way to write this? If it has to be refactored into something much "uglier" I don't think I'd prefer it.
This is a service I wrote that handles real-time progress (i.e. show an accurate progress bar when downloading files). I think this is clean and logical.