5 ms·

AngularJS change detection – draft

73 points by porker 13y ago

brokenparser 13y ago
...but not harder and stronger.
stephen 13y ago
Interesting that Misko himself implemented this in AngularDart first, and then is going to backport to JavaScript.
- saurabhnanda 13y 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 13y ago
Anyone know why real Object.observe() seems to be somewhat stalled? I read somewhere that it had slipped to ES7 -- anyone know why?
- caitp 13y 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 13y ago
Is there any more context to go with this? Definitely looks interesting. How does this compare to FB's React?
saurabhnanda 13y 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.
- SchizoDuckie 13y 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 13y 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 13y 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 :)
- SchizoDuckie 13y 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.

73 points by porker 13y ago

brokenparser 13y ago

...but not harder and stronger.

stephen 13y ago

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

saurabhnanda 13y 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 13y ago

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

caitp 13y 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 13y ago

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

saurabhnanda 13y 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.

SchizoDuckie 13y 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 13y 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 13y 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 :)
SchizoDuckie 13y 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.