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. […
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…
Mistakes AngularJS Developers Make
31–40 of 74 posts
Re: Mistakes AngularJS Developers Make
#32#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.
#5: The service/factory distinction adds a conceptual complexity that is completely unnecessary, as demonstrated in this blog post.
#7: Having too many watchers will slow your app down to a crawl on a desktop machine, and be even worse on a phone. This happens more easily than you'd think and it's fundamentally caused by Angulars reliance on its digest loop. This loop is the essence of how Angular works, and it means that there are tons of applications that cannot ever run efficiently if they're built on Angular.
8#: Because of the way their $scope system works, it is actually literally impossible to tell what the the meaning of ng-model="foo" is by reading the program. It may in fact depend on the order in which the user interacts with elements of the web page. Consider this example: http://jsfiddle.net/7kkxLkxh/ What foo binds to is dependent on which input you type into first. Yes, there are ways to avoid this, but it should have been avoided by either disallowing this construct, or requiring foo to be declared before it is used. (If you miss a var in JS, you get a global - that turned out to be bad language design. Removing the var keyword and effectively deciding on variable scope at runtime is certainly a much worse language design.)
After working on a large Angular project, it is clear to me that there are a lot of ideas in there that are frankly not good. It's sad that there seems to be very little discussion anywhere about the downsides of the various frameworks that are out there.
Re: Mistakes AngularJS Developers Make
#33Point 3 about "Dependency injection" is often not needed. Just use ng-annotate before minify/uglify, and it will convert the code to the array syntax for you. It handles most of the cases, leaving your code without the ugly array stuff. It doesn't work for everything, though, so suddenly it blows up. So if you want to be 100% sure your code works as intended do it manually.
Re: Mistakes AngularJS Developers Make
#34Re: Mistakes AngularJS Developers Make
#35This 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…
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.
Re: Mistakes AngularJS Developers Make
#36I 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.
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.
Re: Mistakes AngularJS Developers Make
#37#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 define that underscore service in? Oops, better make a 5th "common" module, I guess. Just to include something that you could have injected with $window. Notably, the underscore service is also missing that it should be injecting $window. How is he going to test that? Scrap the whole underscore service, and just inject $window where you need something from the global scope.
#9.1 Protractor - Protractor is great. But it's a little hefty for true "unit" tests. Jasmine with `angular-mocks` works a little better for unit testing Controllers and Services, where Protractor is better at testing directives and full end-to-end tests.
and one thing I'd add to this list:
#11 - Overly "DRY" Jasmine tests.
A lot of Angular developers I know are way too fond of drying up their Jasmine tests with nested describe() blocks and lots of beforeEach() clauses. Tests should really be "DAMP" not "DRY".
Re: Mistakes AngularJS Developers Make
#38These 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.
Re: Mistakes AngularJS Developers Make
#39This 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…
Re: Mistakes AngularJS Developers Make
#40It'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…