Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

global 'change' doesn't work #28

Closed
cnlevy opened this issue Mar 13, 2013 · 7 comments
Closed

global 'change' doesn't work #28

cnlevy opened this issue Mar 13, 2013 · 7 comments
Assignees
Labels

Comments

@cnlevy
Copy link

cnlevy commented Mar 13, 2013

it is important to note that you can't listen to associated model changes just by having
this.on('change', callback);
You need to listen to this.on('change:associatedModel', callback)

@ghost ghost assigned dhruvaray Mar 13, 2013
@dhruvaray
Copy link
Owner

Can you please give an example or a jsfiddle - which demonstrates the problem you are facing? See this particular test case (highlighted in yellow) which does both change and change:AssociatedModel

@cnlevy
Copy link
Author

cnlevy commented Mar 13, 2013

here is the jsfiddle : http://jsfiddle.net/GV4Tq
I'm talking about the case where you do :
model.get('associatedModel').set(newAttributes)

@dhruvaray
Copy link
Owner

Thanks for clarifying. This is deliberate. The rationale for introducing fully qualified paths was that the path would give you info about which node in the hierarchy has changed and you could get the info about the changed node through the event arguments.

We had deliberated about introducing the global change event - at higher levels of the object graph - a couple of times, but settled for fully qualified paths at the end. While it is not difficult to add the change you want, there are some concerns

  1. It would lead to a proliferation of events. In a deeply nested model, for each layer you would have to introduce at least 2 new events : change + change:attribute-name where attribute-name would not be a fully qualified path, but an immediate attribute of the node at that level.
  2. We would have to simulate the events mentioned in pt#1. When you change an attribute in product, you are not really changing the memory reference to product in item. Consequently we cannot delegate (leverage) Backbone base infrastructure to treat it as a change event. Which means we would have to write more custom code and the compactness of the implementation suffers.
  3. We wouldn't want these events to bubble up the hierarchy beyond one level. As it would lead to potentially duplicate events. (As they would also get converted into fully qualified event names at higher levels)

Nonetheless, I will update the pitfalls section of the documentation to make this explicit.

@cnlevy
Copy link
Author

cnlevy commented Mar 14, 2013

Thank you for this detailed answer, and for maintaining such a useful
extension to Backbone.Model.
In fact I had guessed that feature could be deliberate, but I wanted to
stress this point so others would not fall into the same problems I had run
into.

@dhruvaray
Copy link
Owner

I have updated (4324af7) the pitfalls section of the documentation and cross referenced this issue. I am glad to hear that the extension is useful to your work. If it's possible, do share a URL. I can put up a usage list if I hear from other folks as well. And yes, don't forget to star us if you like the extension!

@dhruvaray
Copy link
Owner

With BB-Associations v0.5.0+, you can now use the nested-change event for global events. See your revised fiddle here. For rationale, you can see the nested-change section in the event catalogue documentation.

@ghhamza
Copy link

ghhamza commented Sep 26, 2014

I just test your last fiddle example using "nested-change" event and it does not work (i use v0.6.2)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants