unable to override Backbone.Firebase.Model#sync (and friends)

[costa]

It is worth mentioning in the docs, if not actually fixing, that the smart technique used to define #sync (#save, and other data mangement methods) effectively breaks inheritance.
Well for now, I'm going to outsmart the library by assigning #sync in the overridden constructor...

[davideast]

There are two improvements the library could have. The first is being able to customize the Firebase reference before sync. The second is to be able to properly override the sync method. This is a bit tricky because it's different than your XHR model, but I expect these two issues will be tackled in the next big release.

[costa]

The way it is implemented and used, I see no damage in converting the autoSync option into proper subclassing, e.g.: Backbone.Firebase.LiveModel extends Backbone.Firebase.Model. Then, sync should continue to be the entry point of saving data to the server (Firebase in our case).

[davideast]

I've been revisiting the architecture of this library and I agree.

I think autoSync seemed like a good approach initially. However, now I'm seeing that a traditional subclassing approach would be the most ideal.

Using autoSync also requires the prototype of the Collection/Model to be set dynamically. This can cause some confusion when debugging.

I plan on revisiting the architecture to allow for proper overriding of the sync method.

[costa]

@davideast Thanks for you work. I hope I'll be able to help you (with a review at least) after a certain round of work on my projects. I plan to write a post on my hybrid (dual DB) approach which will actually benefit from the architectural changes you mentioned — and then, I will hopefully contribute here.

[mbrevda]

@davideast anything new on this front?