backbone-documentmodel
backbone-documentmodel copied to clipboard
icereval
Propagate change event
Something like this is what I was referring to in #8. I tried this out and it is extremely handy for doing things like implementing an "edited" icon on screen for modified but unsaved items.
I wasn't able to run the tests or add a new one because npm install on OS X seems to hang when downloading phantomjs. The CPU hits 100% and doesn't stop.
Sorry for the apparent duplicate. I'm not sure if GitHub offers a way to create a pull request for an existing issue...
My concern adding this is as you stated in your #8 comment, one will not be able to tell if it was the object or the child which fired the event.
The change event currently is designed to only fire on the specific object which it occurred. You can listen for any nested change with the change:* listener. (ex: https://github.com/icereval/backbone-documentmodel#change)
Currently the "nested model events" test case checks specifically for this scenario: https://github.com/icereval/backbone-documentmodel/blob/master/test/documentmodel.js#L1240
If you would like to provide more detail of your use case I'm open to considering this change I just don't want to break expected behavior.
Thanks,
Michael
The use case is having a_singlle_ event that can be used. When I set a sub document I get a ton of smaller adds, removes, and changes. But when using Mongo I don't need to know about individual changes I need to know when the document changed.
It would be trivial to add a parameter to the change event to know what kinds of changes triggered it.
Another possibility is to add a new event type like 'documentChange' - any change, array, or subdocument changes could trigger their own and finally the document change event.
I agree that a single change event on the document would be very useful. Right now, when I'm setting a bunch of values on my document at once (like when I'm initially populating it), I'm having to use underscore's debounce method to only act once on the large number of triggers to the change event.
I would propose that 'change' should fire once on any change to any of it's children. You can test the model's 'changed' attribute to see which attributes or subattributes triggered the change.
