On launching AngularJS 1.2: what we learned, what we're changing
blog.angularjs.org
blog.angularjs.org
Angular-team: You have an awesome product. Please fix your documentation, and include examples usable with angular-seed, instead of the standalone-examples.
Has the documentation improved with 1.2?
About examples, we can't point enough the awesome work of the Angular-ui team. I think their code is near the state of the art of Angular. But yep, a big complete applications using Angular in which we can digg into would be nice.
In my experience, Code Scalings THE problem you got with your real world application. Restangular helps. A lot. Services are not that useful, Factories even less (but when they are, it's a neat feature), and Providers are simply something internal that we can optionally use if we want do some meta-meta-programming (factories do the first meta).
I hope the guideline for the next release will be to get rid of the over-engineering that makes everything complex when you need to do something UI-dynamic (ever try to attach dynamically a tooltip ?). Sometimes Angular just go on your way and don't want to move.
The things I would want to be changed:
- Remove Providers. that's just redundant with factories, with the only exception as some complex internals we shouldn't use anyway
- Remove $rootScope. It's an internal thing that should not be used.
- Make $q better. It's a pain to use. Really.
- Better control to digests (monitoring, postponing mostly)
- Angular binding with CSS would be awesome. But it needs some work to make a clean separation.
- Directives. Seriously: the way to declare them really should be changed. Returning this starnge object, what the point ? What about Directives Factories for all the multiple ways to declare them, and in last resort only, using the weird object when you need that fine grained control. Mixing all together like the current state is not viable.
I'm not sure I agree with all of your comments.
I find that services are relatively essential building blocks for my applications.
Providers are there so that you can preconfigure your modules. It's a legitimate use case. Take Restangular, for example - it's so useful to you because it's a provider that you can configure for your app.
I can see how $rootScope could be perceived as code smell but after examining how angular uses it internally I'm ok with the way I use it.
Directives are confusing the first time you see them. You need to see a few examples. Though I don't think there's a problem with the api for declaring them. There's a lot to configure - it's mostly optional, but you may well need all of it eventually.
Angular gives you a framework to build on. You can create really amazing components that are totally reusable on your other projects. Sometimes they come in the form of directives, sometimes they're other types of module. Often when you start abstracting that out you'll need to get a bit closer to the metal. Angular provides an api for you to work with in those cases and it's ok to take advantage of that.
Say that you have a dynamically generated form where an input should display a tooltip only in specific cases.
Using tooltip="" will not do the trick, you have to do some sorcery to attach dynamically your tooltip, aKa: using compiler in your controller to replace dynamically the DOM region with the DOM elements returned by $compile and jQuery.
> I find that services are relatively essential building blocks for my applications.
But they doesn't help much against the issue of feature scaling.
Some UI logic just can't be factorized. Some other data handling is to specific to be re-used elsewhere. In a large business application, logic is poor but corner cases are legion. We made the choice to keep our specific logic near the place they are used against using services because that doesn't add any value.
> Providers are there so that you can preconfigure your modules
Again, thats what the rest of the world call 'a factory'. You can perfectly imagine a Factory that register in $injector it's instances. IY think Provider should stay something internal and not be documented as a feature everyone can use. It's not.
> I can see how $rootScope could be perceived as code smell but after examining how angular uses it internally I'm ok with the way I use it.
I am too. But I don't want anyone else than hackers to use it.
> Directives are confusing the first time you see them.
They are confusing because everything is blend together. Separate the different use cases and everything will be simpler. Even if it's the same internal thing (that you can use directly if you need). My point is that if you provide different handlers, noone will ever fear the directives.
> You can create really amazing components that are totally reusable on your other projects.
If only...
In the real world, there is no way my current employer will accept I'll reuse his code for my next project. Only FLOSS libraries can do that.
Its an essential tool for all kinda of hackery which maybe is not the best ways to do things but its the fast way.
I ran into a jqeury popup bug and there was no way to get data inside it without crowbaring the rootScope. For some weird reason it would not accept a controller within, or decorating the popup, depending on where the popup HTML was placed within the HTML file.
Note: I never worked out it was a bug or me not understanding jquery properly. The point is $rootScope can allow corners to be cut in emergency situations.
- What's problematic with $q, compared to any other promises implementation?
- The future of directives has to be as HTML5 web components, though how that'll happen, I have no idea!
Overall I'm super impressed with it, when you know what to do its almost like magic. Callbacks, events? What are those? But like others in this thread - I wish the documentation was better - atleast with examples on more of the doc pages. It has been improving however.
[1] http://docs.angularjs.org/guide/dev_guide.services.$location
Digging into a framework's source code is natural to the latter group, but utterly alien to the former.
Documentation written for the latter group describes mechanisms, design principles, APIs, etc. The former group instead requires examples and step by step tutorials.
Both will call documentation terrible if it doesn't conform to their expectations.