Observer on objects

Hi,

It seems that observers don't work with a 'path' like the documentation says. Here's my example: http://jsfiddle.net/xyzsL/2/

As I understand it, the output should be:
item.foo changed
foo changed
item.foo changed
foo changed
But only a 'foo changed' is fired after the second 'set' is called.

Can someone explain please?

Comments

  • edited June 2014
    I think you meant notifyObservers instead of notifyObserver, so "foo changed" will appear the appropriate amount of times. Please refer to the response from @clinuz‌ below for a good example and explanation regarding observation of native objects. Thanks for pointing this out!
  • Hi @SebT‌, thank you for your question. Check out my updated example http://jsfiddle.net/xyzsL/5/. I have some comments that I hope will be helpful.

    TL;DR - you can't observe changes of a path to a non-observable (native) object directly.
  • @clinuz,
    Is the API for the datalayer going to have breaking changes in it for 2.5? Because in 2.4, the example in observersupport for the observers block uses an object, and in your fiddle you use an array.

    Also browsing through the latest changes in github, it seems like the whole thing is being redone.

    Just wondering if I am going to have to rewrite a ton of code to upgrade to 2.5/nightly.
  • @chrisvanhooser‌, excellent questions!

    If you look at the original fiddle that @SebT‌ posted he was using the 'block' pattern (2.4) for declaring arbitrary observers against the same (nightly) enyo that mine is using. My example is the newer pattern that will be the blessed way moving forward but in 2.5 the previous pattern is still supported but deprecated. There are several reasons for the change and the same is true for the 'computed block' pattern as well. Think of it more like the components or bindings arrays. Now they all can be. Maybe in the future even more things can come in-tune with the change as well.

    The 'breaking' changes are being kept to a minimum. Most things are backward compatible (and we are testing against much existing code to ensure that) and we will document the changes and supply migration notes. So far in our testing, even the breaking changes are minimal impact so the term probably sounds more extreme than it really is. Just know that care is being taken to change only what must really be changed in order to achieve our greater long-term goals and attempt to provide a more consistent, performant and extensible API for our data-layer classes and how they interact. Most of the other changes in the core are normalizations for performance or greater extensibility options, or a move to make our methods more ECMA 262 compliant (as possible) for the platforms we support.
  • Thank you very much for your detailed help.
Sign In or Register to comment.