I'm on my second quest to understand, really understand, how AngularJS fits together. Forensically decomposing the documentation. It's quite slow going, actually; I find myself relying on the code to explain the documentation about as much as the documentation describes the code.
My current suspicion is that directives do not get the central billing that they deserve. If you come from other backgrounds, the first thing you wonder about is the whole MVC thing.
But then you look at compile phase, link phase and runtime loop. They are dominated by directives and the code that directives set up.
It seems to me that a big design step in AngularJS is to extend HTML into the DSL you wish existed. This is done with directives.
I'm still going through this process so it might well turn out that when I get to other parts of the manual my perspective will change entirely.
I'd love to see some good resources on back-end integration; specifically: best practices to ensure ssl-only cookies/sessions, securing the back-end (authorization, input handling/sanitazion), a suggestion for a safe, reasonably scalable backend (ie: not mongodb, maybe postgres, couchdb over ssl (with certificate verification[1]!), riak or even mysql with a php ajax api in front -- although I'd prefer keeping the range of technologies to a minimum so maybe a nodejs api server with something durable for permanent storage) -- and a suggested organization of the whole app with tests (some reasonable way to map models between the backend DDL/SQL and the angular end would be nice).
I see a lot of demos that throw together a few widgets -- but leave you no closer to anything remotely useful -- because they either include completely unsafe data across domains, or throw things in some kind of globally writeable store that isn't even useful for a public wiki, because there are no way to control anything that goes into the backend.
Does anyone have any good articles/sample projects to recommend?
All that said, I really enjoyed this article -- it does a great job of presenting the parts that angularjs is actually about: the client side.
I just sometimes feel tutorials focus too much on just angularjs - for most apps we want shared persisted data after all, right? (even if you're just sharing it with yourself, on a different client (eg: todo list in desktop browser and on mobile browser)).
[1] I just looked into couchdb again, and I think I'm getting a handle of how one might actually deploy the thing -- but it's a little scary to see that they by default turn off ssl cert validation -- which is just wrong -- when ssl is off by default anyway. Why would anyone enable SSL, but not want secure communication? For the slowdown?
I've got a couple [1] of screencasts [2] that go into detail on the integration side of things; I chose to integrate with Laravel (PHP) and MySQL purely for mass-market appeal but the lessons learned should be widely applicable to any stack:
I'm assuming you're not advocating having postgersql serve up html and javascript, and listen on ssl connections directly from the clients.
So you'll need some middleware, and there's no good reason why you shouldn't be able to keep your model and validation logic in one place - I'm guessing one of the easiest approaches, if you're using an sql database, is to use nodejs for the middleware, sharing as much as possible of validation and model-code between the api server and the client?
I think having to fix three different code-bases on every model change/feature addition is going to be a problem (SQL, PHP/Scala/Ruby/Python, and javascript + bonus fourth language if you use templates...). I'm not saying it can't be done, I'm saying there has to be a better way?
Hey - you might want to add www.thinkster.io to the "extended reading" section, as its regarded as one of the best free comprehensive angularjs resources (and uses many of the egghead videos)
One thing I'm always wondering is how people organize their code in an AngularJS project. The seed project and others have all directives in one file, all services is one etc. This quickly gets messy. Using different files for each, I have to include a lot of js files in the main page. Not sure what to do.
I would recommend using Yeoman for seeding projects. The grunt system it uses will solve the "lots of js files" in main page problem by automatically concatenate files together.
In our project, we created multiple sub-directories underneath the controller and services folders to organize them by business functions. It's fairly easy to re-organize the file structure in an angular projects.
There are a number of common ways of doing it - my favourite being a project called ng-boilerplate [1], which encourages you to create directories based on features, and then place all the files related to a specific feature (tests, javascript/coffeescript, html, css) in the same directory. It uses grunt to compile the various files into a single file as you are coding.
Another good resource is a well made example app called angular-app [2], which includes security, a small backend, some crud pages, etc.
I've got a LinemanJS [1] template [2] that gives you a really lightweight boilerplate and workflow for developing Angular projects; Lineman is like a smaller, focused version of Yeoman that also uses Grunt.
Directives are the game changer. Dreams of dynamic markup come true. There are still a few limitations especially wrt routing/view/state, but that is being actively worked on. It's hard to see a future of the web where angularjs doesn't play a starring role. Get your head around dependency injection and eureeka!
Great link on AngularJS injection. Unfortunately the code shown is also an example of the kind of thing that makes me less-than enthusiastic about a lot of the blogs I see on web apps. Right at the top (of the code) we have:
When https would have worked just fine. Instead, because it's referenced with http, we're basically saying - insert some random code in our page, if there's anyone that can spoof packets.
It's like Microsoft Office Macros all over again -- only much worse.
Later he calls the github api over https -- but (and this is a genuine question, I don't know) -- what would happen if github redirected from https to http? Would it fail, or would we get random insecure data import?:
(Now, redirecting to http would obviously be, well, bad form at least -- but conceivable to stave off slashdotting by an overworked sysadmin, perhaps?).
My current suspicion is that directives do not get the central billing that they deserve. If you come from other backgrounds, the first thing you wonder about is the whole MVC thing.
But then you look at compile phase, link phase and runtime loop. They are dominated by directives and the code that directives set up.
It seems to me that a big design step in AngularJS is to extend HTML into the DSL you wish existed. This is done with directives.
I'm still going through this process so it might well turn out that when I get to other parts of the manual my perspective will change entirely.