create and add have inconsistent return values #1496

Closed
kav opened this Issue Jul 18, 2012 · 8 comments

Projects

None yet

2 participants

@kav
kav commented Jul 18, 2012

It's really annoying that add doesn't return the fully hydrated model that has been added to the collection. It means a bunch of hoops need to be jump through to get this after an add. Yet create returns the model... Inconsistant and rather annoying.

@braddunbar
Collaborator

Hi @kav! If you need a reference to the model you can always listen for the "add" event or just create it before adding like so:

var model = new Backbone.Model({...});
collection.add(model);

The same goes for groups of models.

var models = _.map([...], function(attrs){ return new Backbone.Model(attrs); });
collection.add(models);

Any reason these won't work for you?

@kav
kav commented Jul 19, 2012

Well it introduces an extra callback into the flow that I otherwise wouldn't need. Thus functions that create outside of a collection can return their model and those that use collections need a callback.

Otherwise it's just inconsistent and thus seems strange. I remember tripping over it a year ago. Now it's getting in the way...

On Wednesday, July 18, 2012 at 6:42 PM, brad dunbar wrote:

Hi @kav! If you need a reference to the model you can always listen for the "add" event or just create it before adding like so:

var model = new Backbone.Model({...});
collection.add(model);

The same goes for groups of models.

var models = _.map([...], function(attrs){ return new Backbone.Model(attrs); });
collection.add(models);

Any reason these won't work for you?


Reply to this email directly or view it on GitHub:
#1496 (comment)

@braddunbar
Collaborator

Thus functions that create outside of a collection can return their model and those that use collections need a callback.

Why would they need a callback?

@kav
kav commented Jul 19, 2012

Sorry was looking at a listen to add based solution. The above won't work because attributes doesn't include an id so their is no guarantee the object returned is the one you created. I could store all the ids and cids from the collection and then intersect them with the post create ids and cid list but that is a massive hack.

@braddunbar
Collaborator

Sorry, I don't quite follow. Would you mind posting some code that illustrates your objective?

@kav
kav commented Jul 20, 2012

I's not so much that I need a workaround. I mean hell I can just change the return value of add in a fork of backbone. It's more that the codebase is inconsistent across the core collection operations for no particular reason. It's a subpar design, and therefore a bug. I'm sure I can work around it but if the return value were switched to match the rest of the core operations the change for anyone relying on current behavior would be trivial (x.add(a).add(b) -> x.add(a); x.add(b)) . Meanwhile any workaround I do (sans forking) is convoluted and rather ugly. Make sense?

@braddunbar
Collaborator

It's more that the codebase is inconsistent across the core collection operations for no particular reason.

I have to disagree. add and create have entirely different purposes and it's perfectly natural that their return values should be different. In particular, create is meant to persist a new model to the server, and add is meant to insert models into a collection. Creating the models before passing them to add is not a workaround for a bug, but the appropriate action given that you need a reference to them.

That said, if you would like to post some code illustrating your situation and the desired API, I'd be glad to take a look at it.

@braddunbar braddunbar closed this Jul 20, 2012
@kav
kav commented Jul 21, 2012

Both of them add models to the collection one also happens to persist to the server. That doesn't make them "entirely different". If you intend to wait on persisting the model then a create before add doesn't make sense at all.

My example is this one
Create case:
model = collection.create(name: "foo");
//Do some stuff with the model

Add case:
model = collection.add(name: "foo");
// Do some stuff with model before persisting but after it goes through initialize and validate
model.save() // whenever you decide to persist

Today
collection = collection.add (name:'foo') // <-- why in the world is this helpful, I already have a collection reference the only reason I might need it is for chaining which hasn't been suggested as a use case at all. On the other hand I don't have a reference to the hydrated model. To get that I need to jump through a bunch of hoops. Why not give me back the thing I don't already have rather than the one I do?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment