AngularJS change detection – draft

https://docs.google.com/document/d/10W46qDNO8Dl0Uye3QX0oUDPYAwaPl0qNy73TVLjd1WI/preview?sle=true&pli=1#heading=h.xgjl2srtytjt

by porker • 12 years ago

73 15 12 years ago

docs.google.com

brokenparser• 12 years ago

...but not harder and stronger.

stephen• 12 years ago

Interesting that Misko himself implemented this in AngularDart first, and then is going to backport to JavaScript.

saurabhnanda2• 12 years ago

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).

haberman• 12 years ago

Anyone know why real Object.observe() seems to be somewhat stalled? I read somewhere that it had slipped to ES7 -- anyone know why?

caitp2• 12 years ago

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.

craigching• 12 years ago

Is there any more context to go with this? Definitely looks interesting. How does this compare to FB's React?

saurabhnanda2• 12 years ago

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.

SchizoDuckie3• 12 years ago

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.

pavlov• 12 years ago

My experience with Cocoa is that "change detection" (called "key-value observing" in Obj-C land) is a bit of a wild goose chase.

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.

omegaworks• 12 years ago

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 :)

SchizoDuckie3• 12 years ago

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.

latchkey• 12 years ago

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.

lucisferre• 12 years ago

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.

AngularJS change detection – draft

Related Stories