Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Collection.create() with wait: true triggers Collection.parse() #2824

Closed
thrar opened this Issue · 8 comments

3 participants

@thrar

Since version 1.1, calling

myCollection.create( {} , { wait: true } );

triggers a call to myCollection.parse() once the server's response is returned. According to the documentation, it looks like parse should only be called in reaction to fetch().

Additionally, the parameters to this parse() call seem to be different: When calling parse() via fetch(), the first parameter contains the raw data of the response, i.e. an array of JS objects. When parse() is triggered from create(), the first parameter contains the newly created model.

As a workaround, it's possible to set parse: false when calling create(), this will prevent the call to parse().

@j03w

collection.create shouldn't call parse unless you specifically set parse: true when you call the function. code here. As you see, collection.create will call collection.add which simply call collection.set. If you don't pass in parse: true then this should not get called

model.parse get called though since collection.create calls model.save

Am I missing something?

@thrar

The call to parse() only happens when you set wait: true.

@thrar

I understand what you're trying to point out, but unfortunately the actual behavior seems to be different:

class MyCollection extends Backbone.Collection
  url: "some/url/here" # this has to be a valid URL with a readable server response, since we're waiting for it

  parse: -> console.log "called parse"

new MyCollection().create {}, wait: true

This results in "called parse" printed to the log.
Note that without wait: true, parse isn't called.

You can use the Coffeescript compiler from http://coffeescript.org/ to compile the above to JS.

@j03w

You're right, options.parse is being set to true in model.save apparently. Although, I think it has been working like that since 0.9.10 from this commit

@thrar

Not sure if I'm reading the code correctly, but doesn't that refer to Model.save() calling Model.parse()?
On model level that's correct as far as I know because there we actually have raw model data that we can parse.

On collection level, when creating a model, using Collection.create(), all we have is raw data for that one model. Collection.parse() expects raw collection data, i.e. typically an array. When creating a model, we don't have any such data.

Calling Collection.parse() is new behavior. I've been using Backbone 1.0 for months and it was never called during create(). As mentioned before, it seems that Collection.parse() in this situation is actually called with the model as the first parameter, not with any kind of raw data as it would normally be.

@j03w

You are right about it is being updated on 1.1… commit

If you have wait: true then the model is being added to collection in success callback. That success callback is being called from inside model.save callback. At that point options.parse will have been set to true if it isn't set to anything before.

Doesn't seem like an intentional behaviour to me.

I think it is more intuitive to have options preserved in collection.create scope right?

options.success = function(model, resp)

in Collection.prototype.create should fix the issue I think

@thrar

Makes sense to me. Any actions taken on collection level as a consequence of Collection.create() (i.e. add() and the success callback) should receive the same options as the call to create() itself.

Your proposed change fixes the issue for me.

@jashkenas
Owner
options.success = function(model, resp)

Ok -- makes sense. Anyone else have an opinion on this proposed fix?

@jashkenas jashkenas closed this in 9280d85
@jridgewell jridgewell referenced this issue from a commit in jridgewell/backbone
@jridgewell jridgewell Collection#set shouldn't parse
Fixes #3636, #2824.

Reverts #1407.
f3ea07e
@jridgewell jridgewell referenced this issue from a commit in jridgewell/backbone
@jridgewell jridgewell Collection#set shouldn't parse
Fixes #3636, #2824.

Reverts #1407.
42638bb
@jridgewell jridgewell referenced this issue from a commit in jridgewell/backbone
@jridgewell jridgewell Collection#set shouldn't parse
Fixes #3636, #2824.

Reverts #1407.
415c3a7
@jridgewell jridgewell referenced this issue from a commit in jridgewell/backbone
@jridgewell jridgewell Collection#set shouldn't parse
Fixes #3636, #2824.

Reverts #1407.
7557f68
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.