http://docs.angularjs.org/tutorial
http://docs.angularjs.org/guide/
https://www.youtube.com/user/johnlindquist
http://blog.artlogic.com/2013/03/06/angularjs-for-jquery-developers/
http://www.adobe.com/devnet/html5/articles/getting-started-with-angularjs.html
https://www.youtube.com/angularjs
https://github.com/CaryLandholt/AngularFun
http://railscasts.com/episodes/405-angularjs
https://github.com/yeoman/generator-angular
@knalli says:
Actually, https://groups.google.com/forum/#!forum/angular is the very valuable source of information about AngularJS.
The official docs aren't always up to date, won't reflect both stable (1.0.x) and unstable (1.1.x) and don't contain so much examples (which you will notice after days/weeks).
So, indeed: Using Google the right way is important because Google indices both Groups and Stackoverflow very, very deep. And sometimes, you should look just at https://github.com/angular/angular.js (including isssues and PRs)...
I'm working with AngularJS since October last year when we'd ported our app in a bigger rework process.
And: Don't forget Angular UI http://angular-ui.github.com/
Hints, videos, articles: https://plus.google.com/u/0/+AngularJS/posts
http://pkozlowskios.wordpress.com/2012/08/12/using-jsfiddle-with-angularjs/
http://roytruelove.blogspot.de/2012/09/angularjs-dependency-injection-modules.html
http://onehungrymind.com/angularjs-communicating-between-controllers/
http://www.yearofmoo.com/2013/01/full-spectrum-testing-with-angularjs-and-testacular.html
knalli's article draft: https://gist.github.com/kahlil/5245859#comment-807209
Well, the tutorial should cover it. Actually, it do cover it. However, the problem is to find it.
You've already included one of many articles for jQuery developers which start with AngularJS. The big deal -- two way databinding -- will only works good and perform efficiency if the developer get the idea of AngularJS. Most jQuery developers have the
Tips
(*) Sometimes, a little must-have plugin (i.e. jQuery plugin) is required. All-day standard. And if you don't have the effort to wrap this one into a dedicated directive, you will have some bits of jQuery. But each time you add a non AngularJS resource, you have to invoke the scope-digester. This can be painful.. ("digest already in progress" exceptions).
Scopes
Speaking of scopes, a lot of articles (starting point) show how to use two-way-databinding. Print something in the view, read something from a input into the scope.. and so on. The big deal is to understand, what a scope is.. it is only an object with a hierarchic structure. Just like the scope of JavaScripts.
A common mistake is to use an uninitialized sub scope (so called child scope) either implicit (i.e. e form controller) or explicit (an own directive). If you bind the scope expression
username
to an output (let's say: printing out via<p>{{username}}</p>
) this value could be come from: therootScope
, every child scope between therootScope
and thescope
and thescope
itself. That's fantastic.Both variants outputs an
username
.But if you have an input field, this will be changed. In that case, a value will be assigned to a scope. And if the current scope is actually the
p``s one, this will mean that the
username` will be assigned to this scope. This is okay, but if your working scope is actually scope #3, this could be resulted in unexpected data corruption (actually, it isn't so) or missing data.It is much more better to improve this with a wrapper:
Both variants could output an
user.name
.The first time it sounds very bogus to use sub-modules to wrap data into scopes. However, if you deal with complex data structures, with ajax responses + metadata (think about a list of users + paging data stuff) + edit mask it is more suitable to wrap a model with.. wrappers. A good starting point is to initialize the wrapper object(s) in the corresponding controller of interest. Either they will be changed never again or only in the controller where the scope is definitively the right one.
I modify my example.
If the the scope (p) reads
scope.user.name
it will get the correct one. If the scope (p) writes something intoscope.user
it will applied to the correct one. Still not get it?scope.user = {}
(where scope is p) will not replace the object, but instead of this will create a new one which will be only accessible in therootScope
and the bothscope
(div). Thescope
(p) overloads this with another one. Like this one, our plain old JavaScript:a
is overloaded. Because of scopes are "only" objects in AngularJS, this means that new key will be only available in the current scope. A workingaround is to use$scope.$parentScope
(not recommended) or$rootScoep
(less not recommended). Actually, in this case I would rethink the architecture.Another mistake which is often made: Using functions in views. Just remember: Each expression in the views will be evaluated by AngularJS to determine wether the view should be changed or not. This is proven by a simple test case: Write a very simple demo where something like
{{getUsername()}}
orng-class="{'active' : isUserActive()}"
is used and where this function contains a simpleconsole.log
. It won't be called only once a time. Do not use functions, only properties....
Actually, I wanted to write a short comment only. However this is your requested article, isn't it? Perhaps I should this transform into a real article...
-Jan
(My nick is valid on Twitter, too.)