Collection.add creates new model about backbonefire HOT 4 CLOSED

Hi Jens,

That's a good point about the object references being lost. It does seem like it could be confusing if you expected your object to survive intact.

This pattern isn't limited to Backfire. Everything in Backbone Collections is relative to the ID. If you attempt to add an object and it already exists in the list, for instance, your op can fail silently, or your data could be merged into an existing object--there are no guarantees the object will survive the call to add.

It will also help to keep in mind Firebase's synchronized environment. When you perform an add operation, the add must travel to the Firebase instance, who is the real authority on data state, and back . If that data already exists (remember we're in a real-time environment) then the add may never be called (it could also result in an update event instead). This is pretty well inline with Backbone's documentation on Collection.add.

That said, this is an excellent point and deserves some consideration; well worth keeping in mind during future versions.

from backbonefire.

Hi!

Let me start by trying to ease my grumpy, two hour debugging this issue, self from yesterday. Backbone + Firebase is really cool for the real time app I'm trying to build!

I'll just clarify where I think this deviates from the standard Backbone.Collection.add() behavior. When adding a model that already exists to a Backbone.Collection, the model is indeed silently merged or ignored depending on add-options. However, when adding a model that did not previously exist in the collection, it is actually added to the collection.

The use case I'm pursuing is when adding a new model, but editing it before saving it in the collection. How I usually go about this is I create a model and then I put up the edit view and when done editing I save the model and add it to the collection. If at any time I cancel editing, I just throw away the model. This is to avoid having the model show up in list views, etc before it's done. In the Firebase, realtime environment, I'd like to do the same thing (it's actually even more important, I don't want the model to show up on the other clients before I have made my first edit and eg given it a name). I still want to use my model editing ui so I need a model or I must have different implementations for saved and non-saved models.

What I would like is for a model added to a collection with no id to receive an id (as it does now) and get added to the collection. This is similar to doing Backbone.Collection.add() and the model.save() in classic Backbone. One way to do this would be to use a local lookup-table for the models, this way you register the model in the local lookup when it gets an id and then save it to Firebase. When the Firebase server pushes the model back to you it will be added to the collection and at that point, you check the lookup for a model with the same id, if one exists, you add it to the collection and update it with the new attributes instead of creating a new object. This is basically how eg Backbone-relational handles keeping canonical models on the client side.

If you agree that this is an interesting approach, I could make a pull request implementing this!

from backbonefire.

Just bumped up against this problem as well. If I keep a reference to the model that is returned from Collection.create() it does not notify the collection of any further changes to it. I get what @katowulf is saying about having to let Firebase have authority over the data... and the async nature of the firebase push so I came up with a hacky way around. My workaround now is to bind to the collection's add event with once() and then save the reference to that model as my newly created model. Now any changes I make to this model trigger all the events on the collection that I expected.

This may only be a temporary fix however, since it really doesn't ensure that the new model that I pickup is the same model I just added in a situation where many users are adding objects to the same reference list.

from backbonefire.

I'm still having trouble telling how this is different from the default Backbone behavior. From what I can tell, the only cases where the object pointer could be changed would be if the model had a toJSON method (i.e. it gets called in this._parseModels()) or if Backbone.Collection.prototype._prepareModel is not returning the same reference.

The former case seems unlikely and the latter case would mean that Backbone.Firebase behaves exactly the same as any other Backbone collection's create method in this case.

from backbonefire.