I wish they'd discuss stuff like this and I wish that MongoDB did not store primary keys on _id field.
I blame myself though.
It is also clear from the discussion that there are dissenting opinions -- we are constantly iterating and welcome issues and pull requests to make features work even better. The best way to influence AngularJS is to send a pull request.
I belive this should have been in an earlier RC or Beta. This way, more people would have tested ot, ir got a chance to read changelog (I follow the blog and check each beta release). If that window was missed, it should have gone for the next major release.
What I see is that Google announced AngularDart (http://news.dartlang.org/2013/11/angular-announces-angularda...). Dart has _ prefix for private fields. Then AngularJS team goes ahead and forces the same on the JS implementation.
Seems that there is always some political reason to mess with things at Google.
MyObject.prototype.id = function(){return this._id;};
Which gives you: leagues/{{ league.id() }}
I've previously worked with Backbone.js, and found that many things in Backbone where I've had to manually develop are readily available in Angular.
Moving from Backbone to Angular has made the code much cleaner, and smaller in size. Whereas in Backbone, the code slowly became a mess with all the event listening and event triggering (probably my fault), in Angular, that has all been abstracted for the most part.
Great work guys!
Now if the documentation would improve in some of the grayer areas, I would be really happy. Wish I knew enough to contribute.
FWIW I'm only speaking from personal experience and in your case lots of $watch might be necessary.
edit (bringing text from comment up a level):
If you are building apps for people other than yourself, then having a banner to notify them it won't work is better than a blank page.
A typical banner that I make includes the following things:
- Positioned at the top via CSS and sticks there
- Includes a link to http://www.enable-javascript.com
- Includes a tracking image so I can see how many people are coming without JS enabled
If you have a white page like this blog does, people will think your site is broken and bounce... and may never come back.
A typical banner that I make includes the following things:
- Positioned at the top via CSS and sticks there
- Includes a link to http://www.enable-javascript.com
- Includes a tracking image so I can see how many people are coming without JS enabled
If you have a white page like this blog does, people will think your site is broken and bounce... and may never come back.
http://blog.angularjs.org/2013/11/angularjs-120-timely-deliv...
I was expecting a) a blog post, and b) from the .html-ending a hypertext document, maybe with text and images?
What possible reason could there be for this to be "an app"? It's a blog, it's for reading -- and you already need a reader to access it -- why would you implement a (new) rendering engine?
Ok, I can see an argument for adding comments via javascript and a service, or for posting blog posts and doing admin stuff. But the other reasons (user tracking etc) for having this as "an app" only detracts from the readers experience.
Does anyone know what's the rationale behind the separation of ngRoute? It's less than 4KB and less than 2KB when gzipped. I don't think it's worth the "pain" of having to remember to add another source file.
Also looking forward to seeing new Angular features being worked on again!