11–20 of 74 posts
Point 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.
I've never understood the pattern of separating out services, controllers and directives into different modules. Your post controller is probably going to need your post service, so why put them in separate modules? Makes more sense to have a post module with your WYSIWYG directive, post service, post controller, etc. Every time I see it I just wonder aloud, what problem did you think this solved?
I look at them as a way to extract those building blocks that support the business logic in your app such as a data store or driving app state through routes (whether you roll out your own or use third party libraries). Even if you rely on third party libraries to fill those gaps, I like having my controllers/services/directives not to depend directly on them. For example, in the last year I've transitioned from ng-routes, to ui-router and finally settled with dotJEM/angular-routing [1]. Something similar happened when using $resource, then switched to Restangular, to finally use a thin data store on top of $http [2].
Having that code in a separate layer helped identifying service boundaries within the app and made it easier to replace them when needed.
[1] https://github.com/dotJEM/angular-routing
[2] Something similar to the following implementation: https://github.com/vicentereig/hola-apps/blob/master/app/ass...
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?
There might be some way to load them into $templateCache on build, but that would kill lazy loading
I have seen people make Angular charts, and they use deep value type watches that kill performance. It is fine for angular to watch a massive array with time series data, but use a reference watch, and swap out the array when the data changes.
People talk about the scalability of Angular's dirty checking, but in my experience the number of watches should be roughly the number of interactive elements in the user interface. Since there are limits to how much interface a human brain can process, the theoretical problems of dirty checking are not real problems in practice. If you have more than 2000 interactive elements on a page, then you probably have a different problem, not an angular problem.
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?
Not mentioned: Coding things so that your site content is invisible to the Google search engine. Which is ironic considering Google's support of Angular
What is happening in the first example is that the ng-bind directive is creating a new entry on the child scope, called "user", which overwrites the reference to the property defined in the parent scope. When you ng-bind an attribute of an object, your child scope is not changing the reference to the original object, so both scopes will show updates.
Example fiddle: http://jsfiddle.net/02f4o7u9/1/