Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Supporting methods on model instances #227

Closed
chadwithuhc opened this issue Nov 6, 2014 · 9 comments
Closed

Supporting methods on model instances #227

chadwithuhc opened this issue Nov 6, 2014 · 9 comments
Assignees

Comments

@chadwithuhc
Copy link

I would like to see the same save(), destroy(), etc. on the returned item instances by default. Is there currently a reason why they aren't?

// Example code
ModelName.find(1).then(function (item) {
  item.destroy();
});

For the mean time I am adding them with defineResource().

var Model = DS.defineResource({
    name: 'subjects',
    methods: {
      destroy: function () {
        return Model.destroy(this.id);
      }
    }
  });
@jmdobry
Copy link
Member

jmdobry commented Nov 7, 2014

Sorry I haven't documented this better, but I already added save and update to the default instance methods, though they are named DSSave and DSUpdate to avoid stomping on any save or update methods developers might want to add.

I haven't added DSDestroy yet, but I will. I will also add DSRefresh. I'll use this issue to remind me to do that.

Example:

var user = User.inject({ id: 1 });

user.DSUpdate({ name: 'john' }).then(function (user) {
  user; // { id: 1, name: 'john' }
});

@jmdobry jmdobry added the feature label Nov 7, 2014
@jmdobry jmdobry self-assigned this Nov 7, 2014
@chadwithuhc
Copy link
Author

I'd prefer it to be the simple method names save, update, destroy, etc. instead of the DS ones. You could put them on the prototype and let theirs override it.

It just seems weird to have it .save() in one place and .DSSave() in another.

@jmdobry
Copy link
Member

jmdobry commented Nov 7, 2014

It's a valid point.

However, I made it a point to namespace anything I put on the instance prototype (read: get out of the developer's way) to avoid any potential naming conflicts with something a developer wants to do. That's how it will be going forward. :)

@jmdobry jmdobry closed this as completed in 17d8df0 Nov 7, 2014
@chadwithuhc
Copy link
Author

Thanks for knocking this out so fast @jmdobry ! Got the updates in my repo now and they're great.

@jmdobry jmdobry added the done label Nov 8, 2014
@mrrooijen
Copy link

@jmdobry any plans to add DSLoadRelations?

organization.DSLoadRelations(["membership", "user"])

Less verbose than:

DS.loadRelations("organization", organization.id, ["membership", "user"])

And doesn't require injection of the DS dependency, plus would be more consistent with the other methods such as DSSave, DSUpdate, DSDestroy, DSRefresh, etc.

@jmdobry
Copy link
Member

jmdobry commented Nov 9, 2014

Forgot about that one. I will add it.

@mrrooijen
Copy link

@jmdobry awesome, thanks! :)

@ghelton
Copy link

ghelton commented Jan 9, 2015

Is it possible to add DSEject as well?

@jmdobry
Copy link
Member

jmdobry commented Jan 9, 2015

Sure

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

No branches or pull requests

4 participants