Reuben Cummings

The try/catch is for when `resp` doesn't have `done`. When I ran on my machine, the error I got was `TypeError`. So I guess `catch TypeError` would be better. Do...

Ok. Fine by me.

I'll get to your previous questions shortly. This PR doesn't address your spec. See Issue #56 for that.

Almost. `parseBeforeLocalSave` now returns a promise that you resolved once all the API calls are complete. The `resp` it receives is still regular JSON. And in this use case, the...

As long as you don't remove promise support I'm all for it. In fact, I have a use case where I want to persist storage to json files so this...

+1 having both options is confusing and unnecessary. I also noticed `fetch {remote: false}` works (fetches locally not from server) while `fetch {local: true}` doesn't.

Agreed. If you want to change the dirty model behavior then there should be an explicit option to deal with it. E.g., something like markDirty. @nilbus if you are worried...

I do it with a `fetch` override ``` coffeescript fetch: => $.Deferred((deferred) => super success: deferred.resolve error: deferred.reject).promise() ```

Re #829 Here's what I'm doing... ```python from attr import define, field, fields, validators, make_class @define class One: myattrib: int = field( default=1, validator=validators.instance_of(int), converter=int, ) def create_subclass(name, base, **kwargs):...

Well, the error was with `createItem`. And the following fixes it ``` javascript Sync.prototype.createItem = function(item) { // console.log(item) if (item.id && !_.include(this.storage.destroyIds.values, item.id.toString())) { item.sid = item.id; delete item.id;...