Live data from Hacker News

Mistakes AngularJS Developers Make

airpair.com

41–50 of 74 posts

Re: Mistakes AngularJS Developers Make

#41
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?

Descriptive And Meaningful Phrases

https://stackoverflow.com/questions/6453235/what-does-damp-n...

Re: Mistakes AngularJS Developers Make

#42
post #7
post #3

Grouping files by feature has made navigating and reasoning about a codebase so much easier. I've even found myself grouping stylesheets & test files alongside templates and app code, it really helps enforce the idea of composing smaller apps together. Google has released a recommended app structure similar to this as well [0], though I haven't actually seen it being used too often in the projects I've come across. […

I understand the grouping of the JS files by feature. But I have a hard time including the partials/HTMLs with that. Because when building (concat, minify etc) the project, they will then need to be copied around and all template-references updated. It's easier instead to just dump all of them into one place and copy that folder, no need to update references etc. then. Any ideas on how to solve this?

Packaging up the templates? (e.g. https://www.npmjs.org/package/grunt-angular-templates)

Re: Mistakes AngularJS Developers Make

#43
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…

#1 -- Separating by concerns is much preferable to me, organizing by controllers/directives/services/... is a separation of technology, not the high level concept. There's a great React video on this concept, as well as some other good stuff! [1]

[1] https://www.youtube.com/watch?v=x7cQ3mrcKaY

Re: Mistakes AngularJS Developers Make

#44
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…

>#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 in production.

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.

Although I agree that the "not safe for minifying" mechanism shouldn't have been included in AngularJS.

On the other (other) hand, it's pretty abhorrent that minifying is something that developers need to actually place any thought into..

Re: Mistakes AngularJS Developers Make

#45
post #35
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…

There are angular specific minifiers dealing just fine with #3. It's more of a toolchain problem. For #5 the real deal is the provider and everything else is syntactic sugar on top of it. Once you have a very large application you start to appreciate the distinction. The naming of concepts is awful though; could have been much more clearer.

>There are angular specific minifiers dealing just fine with #3. It's more of a toolchain problem.

I'm sorry to say it's pretty "retarded" to add in framework-specific minifiers to the build process. I don't want to tweak 10 different minifiers if I'm using 10 different libraries in my application.

Re: Mistakes AngularJS Developers Make

#46
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…

do you mind explaining the acronyms? DRY and DAMP sound more like a degree of wetness unless a definition is provided.

Re: Mistakes AngularJS Developers Make

#47
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…

> #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, you just end up constricting your test suite in a way that wastes even more time when the day comes that you have to adjust a few specs in a manner which is incompatible with the beforeEach templates you've established for the suite.

Nowadays, as a rule of thumb, if the tests are already passing, I forbid myself from refactoring any specs that test an unshipped feature. Maybe I should be a full time test engineer because it's really not a very healthy behavior. :)

Re: Mistakes AngularJS Developers Make

#48
On point 1: "AngularJS is, for lack of a better term, an MVC framework."

It is not an MVC framework. The angular team even describes it as an MVW framework (the W stands for Whatever).

Angular on its own does not provide enough structure to work on large projects. It requires a better structure than using directories called 'controllers', 'services' and 'directives'. These are just angular concepts that do not translate well into understanding of what functionality should go in each directory. If you've worked on a larger project, you may have already seen this problem.

Angular documentation is not very helpful in pushing this point to the developer, however. It recommends[1] the use of 'services' as the place to do all business logic, which causes many projects to put most of the code in the 'services' directory.

To work on larger projects, you should create the MVC structure to fill in the gaps that angular does not provide. Creating top level folders such as: Models, View Controllers, Controllers, Endpoints (server communication). And using services, not as a top level folder, but as a way to instantiate components.

[1] https://docs.angularjs.org/guide/concepts

Re: Mistakes AngularJS Developers Make

#49
post #45
post #35

Earlier quoted context omitted.

There are angular specific minifiers dealing just fine with #3. It's more of a toolchain problem. For #5 the real deal is the provider and everything else is syntactic sugar on top of it. Once you have a very large application you start to appreciate the distinction. The naming of concepts is awful though; could have been much more clearer.

>There are angular specific minifiers dealing just fine with #3. It's more of a toolchain problem. I'm sorry to say it's pretty "retarded" to add in framework-specific minifiers to the build process. I don't want to tweak 10 different minifiers if I'm using 10 different libraries in my application.

Sorry, I was wrong at the first time it's not actually the minifier that deals with injection. It's a preprocessor called ng-min. You can use any minifier after that. It's been a while since I touched my grunt file. I stand corrected.
Post reply on HN