Live data from Hacker News

Mistakes AngularJS Developers Make

airpair.com

61–70 of 74 posts

Re: Mistakes AngularJS Developers Make

#61
post #34

I disagree with #10 (Using jQuery). Why would I rewrite perfectly good widgets (jQuery plugins) in Angular (or any other library) when I can create a thin Angular wrapper around them? Because the philosophy is different? That's hogwash. At the end of the day, you're still manipulating HTML no matter what library you use or don't. This is pure nonsense, not to mention impractical, and bad advice.

I think a better way to phrase #10 is "Don't do DOM manipulation anywhere other than a directive." If there's a complex jQuery widget (say, a date selector) that works well for you, then wrap it in a simple directive and be done. I've done this a number of times with no problem.

This is the way to go. Sometimes you just have to build your own from scratch.

Re: Mistakes AngularJS Developers Make

#62

The modules one isn't necessarily true. I'm seeing a lot of Angular devs keep things under one module (esp for libraries). I don't think the value of multiple modules has really been realized. Exs: we do this for Angular Material and Ionic.

Hey I'm the author of the article. I created a library of modules that were reused across single page apps. For individual libraries I agree it doesn't make sense, but not enough people take advantage of the module system

At the moment breaking a monolithic app into modules has little benefit, but is theoretically a beneficial practice to take advantage of future Angular features. I'm speculating but my guess would be some sort of lazy-loading system will be implemented.

I can't find the exact article I read where the authors discussed this, but I did find a presentation by Brian Ford[1] that touches on the subject.

[1]https://docs.google.com/presentation/d/1Gv-dvU-yy6WY7SiNJ9QR...

Re: Mistakes AngularJS Developers Make

#63
post #55

Earlier quoted context omitted.

> #11 - Overly "DRY" Jasmine tests. Agreed. I've gone down that rabbit-hole myself more times than I'd like to admit. It's very easy to waste time DRYing up your test suite with beforeEach calls; there is a kind of nagging temptation to reduce every spec down to the minimum number of lines required, and it's a pretty cathartic way to avoid doing real work (especially if you're taking a TDD approach), but ultimately,…

Been there as well. I call it being clever with your test suites. Figuring out a way to hack your test suites so you can write as little code as you can. Except your test suite ends up unreadable because of all the magic you made for... DRY.

Yup, per Sandi Metz:

https://twitter.com/sandimetz/status/514411916480249856

I've also heard it expressed as "the pain caused by code duplication is nothing compared to the pain caused by wrong abstractions".

Re: Mistakes AngularJS Developers Make

#64
9: There are no excuses for not testing an AngularJS app, I have never actually written unit or integration tests.

The author mentions nothing of protractor's use of selenium webdriver and how it does blackbox testing of your app. There is no mention of Karma interacting with your app's code for integration tests, as well. They talk about unit tests under the "Protractor" header, but integration tests can be run both by Karma and Protractor.

9.2: "Once integration tests have been written using Protractor?" Karma and Protractor are both test runners that support tests written for Jasmine (among other various JS testing frameworks). Perhaps the author meant to say "Once integration tests have been written using Jasmine."

Also, I fail to see how, "Waiting for tests to run, especially integration tests, can be frustrating for developers" has anything to do with Karma.

The rest of the stuff was useful, but the author clearly has never even coherently used these testing tools.

Re: Mistakes AngularJS Developers Make

#65
post #32

This is possibly better called a list of framework design mistakes made by the AngularJS team. #3: The fact that the default dependency injection mechanism breaks when minified means it should never have been included. If this mechanism sneaks in anywhere in your app (and there are plenty of third party libs that use it), it wont start breaking until you bundle and minify the code, at which point you may already be i…

As for #3, that's what "testing" (or "acceptance", if automated tests are run not in "development" phase, but at a separate "testing" stage) in development→testing→production sequence is for. It's virtually the same setup, running the code intended for production, but not visible to general audience.

Re: Mistakes AngularJS Developers Make

#66

Earlier quoted context omitted.

It doesn't necessarily make sense when you have a team working on different things, front-end devs working on the templates and back-end devs working on services, etc. Furthermore most likely you will be sharing many partial templates or widgets between different views and sections in your app. So those have to go in some sort of common views folder, losing much of your grouping. I wouldn't say either way is right or…

Why doesn't the widget go in its own folder?

or in their own module, pulled into the project with bower

Re: Mistakes AngularJS Developers Make

#67
post #38

These types of articles are great, but too frequently I see phrases such as, "It makes testing much simpler" sprinkled throughout them without any justification. These claims are generally not untrue, but it seems like it would be appropriate to demonstrate scenarios of the unit and e2e tests actually being affected by decisions in the application code.

Apologies if this comes across as unsolicited advice; but if you really struggle with this, your software dev fundamentals are weak. Before learning frameworks, you should focus on concepts like decoupling, single responsibility, etc...

upvoted because software developers who avoid heavily testing their code, and the use of code analysis tools, are often surprised once they start testing and analyzing their code.

Re: Mistakes AngularJS Developers Make

#68
post #60
post #56

Earlier quoted context omitted.

> I think the real mistake in that scenario is not minifying the code until "in production". You should minify your code from the day one. How are you debugging minified code?

That's a big problem. Firefox and Chrome these days support debugging source mapped files. However, I'm running through two source map steps: TypeScript to JavaScript and JavaScript to minified JavaScript. For whatever reason the browser debuggers don't work that well with this setup. They're buggy and make the browser very slow. I often do have to resort to "console.log" debugging. On the plus side I'm always runnin…

I use Webpack with a similar setup (CoffeeScript->JavaScript->Minified) and I didn't notice any issues. Source maps stop working when using Webpack's hot code reloading, but it's a price I'm willing to pay.

Re: Mistakes AngularJS Developers Make

#69
post #40
post #37

It's a good article, but a good portion of these aren't "mistakes" but rather "opinions". #1 isn't a "mistake" it's a preference, really. Also, I'm really not sure about putting the template files in the directory with the other files. Then I guess I'd have to add something to my build script to copy them to a hosted directory? #3.1 IMO, Is actually more of a mistake. Imagine you have 3-4 modules, which one do you de…

DAMP?

In this context, how about something like this?

"Don't repeat yourself (As Much as Possible)"

Re: Mistakes AngularJS Developers Make

#70
post #32

This is possibly better called a list of framework design mistakes made by the AngularJS team. #3: The fact that the default dependency injection mechanism breaks when minified means it should never have been included. If this mechanism sneaks in anywhere in your app (and there are plenty of third party libs that use it), it wont start breaking until you bundle and minify the code, at which point you may already be i…

Wow, bang on. I completely agree with all of this, and it has been my experience working on a large-ish Angular project as well.
Post reply on HN