I can verify this. If the structure of the model is fundamentally changed in a custom serialize method, then the simple lodash.assign if {wait: true} doesn't take that into account.

The only way I can imagine this working in the current form is to create a dummy model with the new attributes, serialize that (using the same serialize method), and merge the objects for the sync request.

Example time. If this is my serialize method:

  serialize() {
    const res = this.getAttributes({props: true}, true);
    const id = res.id;

    forEach(this._children, function(value, key) {
      res[key] = this[key].serialize();
    }, this);

    forEach(this._collections, function(value, key) {
      res[key] = this[key].serialize();
    }, this);

    delete res.id;

    return {
      id,
      attributes: res,
    };
  }

It turns returns an object that looks like this:

{
  "id":"11",
  "attributes": {
    "date_end":null,
    "date_start":1344744000000
  }
}

If I do myModel.save({date_end: 1439586948920}, {wait: true});, the save attributes are added to the outer object, because of the simple lodash.assign

{
  "id":"11",
  "attributes": {
    "date_end":null,
    "date_start":1344744000000
  },
  "date_end":1439586948920
}

I believe this would be solved by #58

Re-open this if it didn't.

@pgilad I cannot reopen, but this issue was not resolved.

The problem is that this line:

        if (options.wait && method !== 'patch') options.attrs = assign(model.serialize(), attrs);

assigns attrs AFTER the model has been serialized. This assumes that the server expects the attributes to exist at the top level. Not all servers do.

In the wait:true situation, options.attrs should be set to a cloned copy of the model which has its attributes changed, and is THEN serialized. This avoids changing the original model until sync, while allowing the modified model to be serialized as the user directs.

I will make a PR if I get to resolving this in my project, but it's currently a lower priority.

Actually started working on this, and the complexity to support all of these simultaneously quickly becomes staggering:

• wait: true
• patch: true
• custom serialize that alters the form of the data

You can do 2 at a time fairly easily, but to do all 3 requires keeping track of the changed attributes (already done by state), and also being aware of way the model is serialized in order to cherry-pick those attributes out of the data.

Not impossible, but possibly ill-advised.

Which brings me to my next point: don't devise APIs that require data attributes to be in a nested object.

Circling back on this so the record is here. I ended up extending AmpersandModel to support JSON-API and just got around to releasing it. I changed save within that extension to respect wait:true, patch:true, and a custom serialize method.

https://github.com/bobholt/ampersand-jsonapi-model

I think the strategy there should work within AmpersandModel. I should hopefully have some time next week to make a PR here that accomplishes the same thing.

Thanks for keeping with this @bobholt, sorry it didn't get reopened. Doing that now.

Thanks @Wrathgar.

Submitted fix for this as #64.