AngularJS 1.2.0: timely-delivery(blog.angularjs.org)
blog.angularjs.org
AngularJS 1.2.0: timely-delivery
http://blog.angularjs.org/2013/11/angularjs-120-timely-delivery.html
63 コメント
This change was discussed: https://github.com/angular/angular.js/pull/4509
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.
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.
You are right it was. But most people do not track all issues of all projects they depend on. While I'd love to do that, there's simply not much time.
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.
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.
Many other languages and projects use underscores to indicate private properties, in particular Google's Closure. I also have no idea how standardizing on _ in names meaning private would do anything to push Dart in some hidden, evil agenda.
I think the change is reasonable, limiting AngularJS' expression to leak less information into the templates is a good idea IMHO, as described in particular with the new controller syntax.
Disclosure: I work at Google, but I have not been involved in this discussion at all.
I think the change is reasonable, limiting AngularJS' expression to leak less information into the templates is a good idea IMHO, as described in particular with the new controller syntax.
Disclosure: I work at Google, but I have not been involved in this discussion at all.
I pay pretty close attention to the issues in the repo, but I apparently missed this. I am also a regular in #angularjs, and never seen it discussed there either, so while the discussion was public, I think it caught almost everyone by surprise.
I'm running into a similar issue and fairly new to angular. In fact, the tutorial I followed even set up the server calls to use the _id field when looking at a specific model (ie leagues/{{ league._id }} ). What's the proper way to go about fixing this?
You can always create functions that refer to the private element:
MyObject.prototype.id = function(){return this._id;};
Which gives you: leagues/{{ league.id() }}
MyObject.prototype.id = function(){return this._id;};
Which gives you: leagues/{{ league.id() }}
so what the point of introducing a "private" access modifier that doesnt exist in javascript since one can still access privates? looks like pure politics within google.
A breaking change like that shoved at the latest minute? you bet it is.
A breaking change like that shoved at the latest minute? you bet it is.
> shoved at the latest minute
The pull request was opened 3 weeks ago with plenty of discussion.
The pull request was opened 3 weeks ago with plenty of discussion.
3 weeks of discussion for a breaking change is "last minute" in my book
why didnt you think about having this feature optional? class based controllers are optional yet,because of them you introduce a feature that affect function based controllers ?
> why didnt you think about having this feature optional?
Opt-in security features aren't very useful.
> class based controllers are optional yet,because of them you introduce a feature that affect function based controllers ?
That's how competing constraints work out sometimes.
We're always looking to improve though. The code is open source, so feel free to submit a PR or fork it if you disagree. :)
Opt-in security features aren't very useful.
> class based controllers are optional yet,because of them you introduce a feature that affect function based controllers ?
That's how competing constraints work out sometimes.
We're always looking to improve though. The code is open source, so feel free to submit a PR or fork it if you disagree. :)
Don't use 1.2.0 until it's reverted or write a getter.
Never send DB output directly to frontend, send object, filled by only necessary values from DB output. Otherwise you'll meet security issues and these "_" prefixes will be smalles part of your problems.
I do that. It's not about sending them directly. It's the underlying field name. I just keep _id fields as _id fields when I prepare data for output.
I'm really impressed with Angular.
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!
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!
I'm really impressed as well, especially how helpful and outreaching the developers/contributors are on sites like StackOverflow.
Now if the documentation would improve in some of the grayer areas, I would be really happy. Wish I knew enough to contribute.
Now if the documentation would improve in some of the grayer areas, I would be really happy. Wish I knew enough to contribute.
We've been steadily working on improving the docs, and rolling out significantly improvements on a regular basis. Is there any particular part of the docs that still ails you?
I like the new search bar a lot. it appears to be searching within the pages themselves. so all pages are already in memory ?
http://docs.angularjs.org/api/ng.directive:ngRepeat
I search "ng-val"...
http://docs.angularjs.org/api/ng.directive:ngRepeat
I search "ng-val"...
I've done one project with ember and was very happy with it but I'm now working on a project where I only need parts of the page to be controlled by the framework. So far I'm loving the way angular integrates with the dom but once you get back to the controllers/directives it suddenly feels like I have to do a whole lot more work than with ember. The main difference seems to be that you have to manage updates yourself i.e. use $watch or trigger them yourself by binding to js event. At this point I'm kind of wishing their was an embular project ( :) ) that integrated with the dom the way angular does but had ember's awesome binding/computed properties...
Can you give an example of where you've had to use $watch? Usually too many $watch is an indication that you could improve your app's architecture, e.g. by abstracting into directives.
FWIW I'm only speaking from personal experience and in your case lots of $watch might be necessary.
FWIW I'm only speaking from personal experience and in your case lots of $watch might be necessary.
A good example is where I have a list of items which is filtered by a select[1]. I have the select wired up to the controller with a two-way binding and the controller watches for changes to the binding and filters the list accordingly. Maybe this isn't an idiomatic way to do it?
[1] http://plnkr.co/edit/ykfblPHlwkBJyMeObFyV?p=preview
[1] http://plnkr.co/edit/ykfblPHlwkBJyMeObFyV?p=preview
Here's your example without a watch: http://plnkr.co/edit/GCv7bQALiOTgJ0npavwi?p=preview
That looks interesting, so does the filter reevaluate automatically when any of the variables used in the expression change?
edit: and thanks a lot for taking the time to look at it!
edit: and thanks a lot for taking the time to look at it!
Ah, so I see that anything associated to the scope is reavaluated whenever anything else in the scope changes. Here's a further modification based on yours that keeps the criteria on the controller.
[1] http://plnkr.co/edit/JYyUvyh30e5L9KwVjDW2?p=preview
[2] http://plnkr.co/edit/ffYb14JjgSip5BTITILS?p=preview
edit: much happier with this version than the one I started with, thanks
edit: added example [2] which doesn't require a watch but still uses the service to do the filtering (because in my app it's actually an ajax call)
[1] http://plnkr.co/edit/JYyUvyh30e5L9KwVjDW2?p=preview
[2] http://plnkr.co/edit/ffYb14JjgSip5BTITILS?p=preview
edit: much happier with this version than the one I started with, thanks
edit: added example [2] which doesn't require a watch but still uses the service to do the filtering (because in my app it's actually an ajax call)
I haven't had to use $watch except to integrate with jQuery plugins for fancy widgets (and wish I could get rid of those). For everything else, two-way binding in Angular works very well.
From my vague understanding, I've heard knockout described as similar to your desired "embular"
I've actually just inherited a giant mess of knockoutthat i was looking to replace with angular. I have to admit that I was actually expecting angular to handle this kind of stuff so I'm a little disappointed in that respect. Angular does seem to have plenty of benefits but I thin i'll give knockout a full review before(maybe it just needs to be structured better).
With Javascript disabled the page is completely blank.
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.
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.
Not sure what you were expecting. AngularJS apps aren't usually built with a noJS fallback in mind.
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.
Well, from the url:
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.
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.
Its Blogger -- doing it this way allows them to cache the viewer across their thousands of blogs, and load only the content.
Well, if they just served html, they'd still only need to serve the content (and the viewer, the web browser, would indeed be cached in the form of an installed application on the end user's system).
The content can be served as a JSON object containing just the post and the metadata. If you scale up to millions of requests, suddenly you're saving a lot of bandwidth by not sending the same header, sidebar, footer etc everytime.
1) You could send the sidebar, footer etc as json, and the content as html. [edit: an by json I mean javascript ;-) or a combination of a script-tag with a fancy-nav.js, and then pull in any additional elements via json/javascript urls]
2) "lot of bandwidth" - I doubt it. It's only the embedded html you'd have to resend -- and that gets compressed with the rest of the main html document. Everything else (images, css, javascript) gets cached via normal request caching.
2) "lot of bandwidth" - I doubt it. It's only the embedded html you'd have to resend -- and that gets compressed with the rest of the main html document. Everything else (images, css, javascript) gets cached via normal request caching.
Just send binary (that next?)
Well if the fallback is ng-cloak with the css I guess he got it :)
Well, I just figured out that these "blogs" (edit: blogger.com blogs) at least provide rss -- doesn't really work in w3m (it downloads the xml, rather than doing som magic and try to render it) -- but at least for me this "design" is far superior to the bloated javascript mess that they try to get you to use:
http://blog.angularjs.org/feeds/posts/default?alt=rss
http://blog.angularjs.org/feeds/posts/default?alt=rss
We've been using rc versions in production code too. As they've mentioned many times when they say unstable it doesn't mean that it was likely to break, simply that they are free to change the API if they need too.
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.
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.
Probably because most projects will use uirouter: https://github.com/angular-ui/ui-router
They want to split in lot of optional modules, it's just the beginning. IMO it's a good idea. For your problem, perhaps they should add a custom build/download tool like jQueryUI.
I think it's a great idea as well. Would like to see jqLite come out as well and be a separate project. Then those using jquery don't pay for jqLite, and even beter, for a quick landing page I'd be inclined to use jqLite naked for a nice tiny footprint.
what is your build process? (angular noob here)but I would assume your dependency resolution takes care of this.
(this sounds to me like build vs real issue)
Great timing. The angular based project I've been working on for the past 6 months just had a soft launch the other day. Being able to tell the powers that be that we are no longer on the unstable branch will ease a few minds.
Nice guys! I've been tracking the rc's with Ionic Framework (http://ionicframework.com/) and just updated to the final. I've especially loved ngAnimate and ngTouch which have been really solid.
I noticed that Angular was likely to release this morning since all the issues for the milestone was finally cleared out - looking forward to moving to 1.2 stable from 1.2 rc2 (we're using rc2 in production code!).
Also looking forward to seeing new Angular features being worked on again!
Also looking forward to seeing new Angular features being worked on again!
I'm using rc3 in production right now so I'm looking forward to testing this out upgrading.
I just wrote a yeoman generator to bootstrap a phonegap application with angular 1.2.0 : https://github.com/dsimard/generator-angular-phonegap
Here is a video showing how to bootstrap an angular-phonegap application in 6 commands : http://www.youtube.com/watch?v=UXkLu7q4tq4
Great timing, I'm starting the new version of an angular web app. Having a production version of 1.2 on day one is great!
Any advice for upgrading to 1.2 from 1.0.x? Is it worth going via 1.1.x first?
Sweet, looks like some major changes to the compilation in this one.
AngularJS is being one of the coolest thing since Node.js
In terms of cool it still has a lot of ground to cover to catch horsejs
Dude, seriously, what's this? Random horse tips using google voice? I can't even understand those tips lol
Sarcasm. Don't worry, it's new. You'll catch on.
So exciting. Great work guys :)
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.