Extending Ember Data States


Hey there,

I’ve been trying to figure out how to extend Ember Data states for some time now. The problem is that I need to add an event to a particular state, specifically I need to add loadedData to the state rootState.loaded.updated.uncommitted and also perhaps rootState.loaded.created.uncommitted.

The main problem I’ve encountered is that all of these variables are defined in a closure in the compiled ember-data source, which means I can’t simply access and extend the objects. I’ve been trying to figure out how to do this and the solution I have currently is to copy all the necessary parts of the closure and recreate the object, then reopen DS.StateManger and set states to the new recreated object.

This all seems very un-Ember-like as there is almost always a way to hook into and extend Ember objects. Is there a cleaner way of doing this?

A related StackOverflow post is here and the code I am currently using which works is gisted here.


I’d like to work on making it easier to extend, I am adding modifyRecord for PATCH, sounds like a good open source project. Ember Data doesn’t want PATCH, but the ability to add your own PATCH or whatever through events and the Adapters seems needed.


Ember data doesn’t want PATCH? I thought Ember data was supposed to converge with JSON API in the near future, and JSON API specifies PATCH with application/json-patch+json to update resources. Am I mistaken?


I do believe that the ActiveModelAdapter is going to conform to JSON api at some point, though I’m not sure when and I haven’t gotten confirmation from the ED team.

@svanderbleek: I imagine you would be able to add patch by extending the RESTAdapter/ActiveModelAdapter. My post is actually irrelevant now as ED has dropped the old state system and the new one is much more streamlined (though I’m still having issues getting validations to work, but that’s a different topic…)

JSON API roadmap

@samg I’m just basing it on github issues. But I don’t want the JSON API PATCH, I’m following the non-idempotent PATCH spec, so I still use PUT for idempotent updates. Maybe I’m just a weirdo.

@pzuraq That wouldn’t work for me because then I can’t differentiate between my PUT and PATCH.