AngularJS change detection – draft(docs.google.com)
docs.google.com
AngularJS change detection – draft
https://docs.google.com/document/d/10W46qDNO8Dl0Uye3QX0oUDPYAwaPl0qNy73TVLjd1WI/preview?sle=true&pli=1#heading=h.xgjl2srtytjt
15 comments
Then you should really look more into how angularjs works.
The whole thing works so beautiful because there's a global digestion cycle which captures all the changed events within one 'loop', processes the changes, and then kicks off the next cycle, like with a game's heartbeat.
Also, the way you need to set up things with angular makes sure this works perfectly. you need to work with models, controllers, services and directives, which all have a well thought out way of accessing, watching and broadcasting changes.
Things start to break when you start using jquery and just randomly do shit with the DOM outside of angular's scope, but that's one of the reasons why i'm rewriting stuff to work without jquery.
I think angular is the best way forward for the web since the invention of XHR requests actually.
Also, the way you need to set up things with angular makes sure this works perfectly. you need to work with models, controllers, services and directives, which all have a well thought out way of accessing, watching and broadcasting changes.
Things start to break when you start using jquery and just randomly do shit with the DOM outside of angular's scope, but that's one of the reasons why i'm rewriting stuff to work without jquery.
I think angular is the best way forward for the web since the invention of XHR requests actually.
I can't agree more. I'm just now rewriting a portion of my webapp to be a single page app using angular. I'm blown away at how it simple it is to do some really complicated stuff. This is entirely the result of how it forces me to properly organize my code. For example, when I open up a bootstrap tooltip/popover, I wanted to disable all the buttons on the page. It was as simple as invalidating the ng-form and this just works across many directives and modules (assuming you pass the form through the scope). Doing this the old way with jquery would have been a nightmare.
At first I resisted the templates. I kept trying to use Handlebars to render things cause that is what I was used to. Then I realized that the 2 way data binding (ng-repeat with track by) is just magical. I can take a json blob received from an ajax call and set that on a property on the scope. My template just magically updates only the dom elements that changed. By the way, coffeescript is perfect for the templates because you can just embed them in """ ... """ blocks.
My code is also now organized so much more cleanly. The way directive components are organized forces me to think about reuse. It makes it so much easier to see the dependencies between things and create distinct levels of separation. This allows you to make components that can be moved around easily in case you change the flow of your application or just want to display something on another screen.
My buddy and I came up with a way of taking large cyclical object graph blobs of json and de-duplicating the objects for transfer over the wire. This ends up working perfectly with the aforementioned data binding to minimize the amount of json on the wire, while still retaining our complete object model. https://github.com/jsog/jsog
I'm kicking myself for not picking this up earlier.
At first I resisted the templates. I kept trying to use Handlebars to render things cause that is what I was used to. Then I realized that the 2 way data binding (ng-repeat with track by) is just magical. I can take a json blob received from an ajax call and set that on a property on the scope. My template just magically updates only the dom elements that changed. By the way, coffeescript is perfect for the templates because you can just embed them in """ ... """ blocks.
My code is also now organized so much more cleanly. The way directive components are organized forces me to think about reuse. It makes it so much easier to see the dependencies between things and create distinct levels of separation. This allows you to make components that can be moved around easily in case you change the flow of your application or just want to display something on another screen.
My buddy and I came up with a way of taking large cyclical object graph blobs of json and de-duplicating the objects for transfer over the wire. This ends up working perfectly with the aforementioned data binding to minimize the amount of json on the wire, while still retaining our complete object model. https://github.com/jsog/jsog
I'm kicking myself for not picking this up earlier.
I'm glad you're finding Angular is working well for you!
You may be (okay, considering what this article is about, you probably are) aware of this, but we're making an effort to drastically improve the performance of the dirty-checking algorithm. Miško wrote a draft paper (you know this, I know) regarding the dirty-checking implementation, and there's an implementation of it in Angular.dart.
I've been working on porting the Angular.dart implementation over to ES6 for the next iteration of AngularJS over the past couple of days, and it's actually pretty challenging, so I'm reaching out to people who are interested for help:
The repository is at http://github.com/caitp/watchtower.js, and will probably be moved into the angular org once it's a bit more fleshed out.
Some things I'm looking for is assistance in improving the tests, and implementing a high quality performance test, possibly using our benchpress library (http://github.com/angular/benchpress). I also would greatly appreciate hearing from people who are a bit more involved/experienced with ES6 might be able to offer some suggestions on how to organize the code, because Dart does not translate 1:1 into ES6, so some help there would be a big deal.
Anyone who is interested in contributing in some fashion, please, you're more than welcome to. We want AngularJS 2.0 to be super-fast, and the more help with this, the better.
You may be (okay, considering what this article is about, you probably are) aware of this, but we're making an effort to drastically improve the performance of the dirty-checking algorithm. Miško wrote a draft paper (you know this, I know) regarding the dirty-checking implementation, and there's an implementation of it in Angular.dart.
I've been working on porting the Angular.dart implementation over to ES6 for the next iteration of AngularJS over the past couple of days, and it's actually pretty challenging, so I'm reaching out to people who are interested for help:
The repository is at http://github.com/caitp/watchtower.js, and will probably be moved into the angular org once it's a bit more fleshed out.
Some things I'm looking for is assistance in improving the tests, and implementing a high quality performance test, possibly using our benchpress library (http://github.com/angular/benchpress). I also would greatly appreciate hearing from people who are a bit more involved/experienced with ES6 might be able to offer some suggestions on how to organize the code, because Dart does not translate 1:1 into ES6, so some help there would be a big deal.
Anyone who is interested in contributing in some fashion, please, you're more than welcome to. We want AngularJS 2.0 to be super-fast, and the more help with this, the better.
Also : Angular.element is really powerful. I'm using it in my chrome extension to parse both RSS and HTML and return objects. Services are an amazing way of working. The web is really my API now.
https://github.com/SchizoDuckie/seriesguide-chrome/blob/angu...
https://github.com/SchizoDuckie/seriesguide-chrome/blob/angu...
(See it in action in a chrome extension: https://chrome.google.com/webstore/detail/seriesguide-chrome... )
https://github.com/SchizoDuckie/seriesguide-chrome/blob/angu...
https://github.com/SchizoDuckie/seriesguide-chrome/blob/angu...
(See it in action in a chrome extension: https://chrome.google.com/webstore/detail/seriesguide-chrome... )
At some point you do need some separation between watched bindings and pure logic, that's what the services are for. And quite often people are going to violate those principles of separation until they find out it's a really bad idea.
However the fact that it can be done wrong and get someone into trouble doesn't change the fact that data-binding between the controller and the view is also very useful.
However the fact that it can be done wrong and get someone into trouble doesn't change the fact that data-binding between the controller and the view is also very useful.
I think it's useful for rapid prototyping; the developer doesn't need to explicitly define change firing if the change sets are small and easy to handle on a key-by-key basis.
It would be nice if the framework allowed for both paradigms in a clean way. A developer should be able to quickly and safely insert indirection into the change event firing process later in development as an optimization.
If Angular provides this facility, sign me up :)
It would be nice if the framework allowed for both paradigms in a clean way. A developer should be able to quickly and safely insert indirection into the change event firing process later in development as an optimization.
If Angular provides this facility, sign me up :)
Interesting that Misko himself implemented this in AngularDart first, and then is going to backport to JavaScript.
Ouch! I was dreading this from the day AngularDart was announced. I don't want AngularJS to be a second-class citizen within the Angular world -- my startup now depends on it!
Btw, what's the benefit of Dart? I never really understood (or bothered to find out, for that matter).
Btw, what's the benefit of Dart? I never really understood (or bothered to find out, for that matter).
Anyone know why real Object.observe() seems to be somewhat stalled? I read somewhere that it had slipped to ES7 -- anyone know why?
I'm not seeing it in the latest Harmony draft, but it is already available in some implementations, and polyfills tend to have it.
(one of) The issue(s) which is coming up for us WRT O.o is that current implementations don't seem to work well with computed properties (IE es5 getter/setter functions), which is possibly a point of contention in the draft. Better to ask someone who is seriously paying attention to that stuff, though.
(one of) The issue(s) which is coming up for us WRT O.o is that current implementations don't seem to work well with computed properties (IE es5 getter/setter functions), which is possibly a point of contention in the draft. Better to ask someone who is seriously paying attention to that stuff, though.
Can anyone explain why/how the following statement is true?
We can then change the slow field read from current.obj[current.field] to current.getter(current.obj) which triples the performance.My guess would be that the array access method first parses the whole object as an array, breaking optimisations made possible with JIT compiling, whereas getters and setters are preoptimized because they're the actual standard way of accessing object properties.
Is there any more context to go with this? Definitely looks interesting. How does this compare to FB's React?
...but not harder and stronger.
At a distance, the notion seems appealing. But when you try to build anything larger than a simple form UI, you start to realize that maybe it's not such a good idea to have anyone, anywhere, listening to changes on any old property and doing who knows what.
There are two problems with automatic change notifications: timing and context. Usually there is a something else (e.g. a controller) that is actually doing the property change on a model object. This controller is much better positioned to inform others about the change than the model itself. The controller knows the context, and it can decide whether the notification should go out instantly or perhaps after a bunch of other stuff. The controller can also make this context information available to the listeners, which is often invaluable... But a plain old "this key just changed, ho hum" doesn't let you do any of that.