In Ember when you call destroyRecord on the model. In the network layer, Rest Api Method delete is invoked and your model’s id is passed in your params, I believe everyone knows this stuff.
Let’s dig deeper, what happens after you call the object method destroy a record or delete the record. To understand more let me define a term, I and many others might have used this one, internalmodel, In general internalmodel is a term which is defined by the ember-data, it is a Model class defined internally never suggested to use in application code. Now the question is why do we need to understand about internal-model, well whenever an object is created ember generates an internal model of the object like a basic structure.
When model’s deleteRecord is called the first operation invoked is deleteRecord function of the internal model, it changes the state of the model to deleted.uncommitted. After deleting the internalmodel (that is changing its state as mentioned above), generally the next is to save the state or persistent state of the model to backend layer.
Something interesting, save method, is only a filter for your model and call next step of actions. It itself cannot do anything. So what is this filter and what are these actions which are called. In general, when you invoke save on model, how can ember understand whether to create a record, update a record or a delete record? It is not viable to have to save function do all the jobs, It is best if it can pass on the baton on to something which is related to the model.
The save function on the basis of the states assigned (need to look into different states of the internal model) in the internal model it calls to update, delete and create functions which are related to the model.
I believe now you are thinking that the above three functions will be common for every model and it will be ajax request. I also thought the same but no, why is another interesting question? I think it is conventions. Ember design follows conventions over configurations. Whenever one of the function is called, the name of the model is used to search for a file in adapter folder to load the file and call its corresponding function, yes it is adapters which is our house gate. I believe most of you understand what an adapter is I will not be covering this.
Now you might be asking me a question, in my entire time in Navyug I have never written an adapter or only specified an application adapter, how come my application is working fine. It should break when it trying to load the adapter of a particular model, but it doesn’t. Well ember is smart if it doesn’t see the corresponding model’s adapter, it will take the application adapter if it doesn’t find the application adapter it uses internal model adapter defined by the ember-data.
Generally many people don’t use an individual model adapter, they use a common adapter. The individual model adapter is normally used if you want to override the existing operations, the create, update and delete operations.
Below I have added an example of the method overriding for delete function
/* adapters/user-category-activity-mapping-report.coffee */
import ApplicationAdapter from 'frontend-upgrade/adapters/application'
userCategorActivityMappingAdapter = ApplicationAdapter.extend(
deleteRecord: (store, type, snapshot)->
id = snapshot._attributes.activityHash
@ajax(this.buildURL(type.modelName, id, snapshot, 'deleteRecord'), "DELETE"))
export default userCategorActivityMappingAdapter
In the above example, I have a model which is a JSON object created on the basis of clubbing together all objects which have common activity_hash in the backend, for me deleting this single object is equivalent to deleting all the records with the same activity_hash in the backend.
Instead of sending the randomly generated id to delete, I need to send the activity_hash to delete all the bunch of objects in backend after deleting success callback is called as similar as before. Similarly, you can modify create, update functions of your model to accommodate extra variables.
I hope this article was useful.