After a PATCH, do not update DOM with server response!


Hey there everybody.

We are working on a application with auto-save functionality, and we are currently facing some issues while updating some fields in a slow server.

As our project is strictly confidential, i will illustrate this problem with the following example:

What is happening:

There is a product page with a configuration of a product with the following fields:

Name: ‘Nexus 5’ | Category: ‘cellphones’ | On Sale: true

If i change the Name field to ‘iPad’ and quickly change the Category to ‘tablets’ (while the Name request is not yet fullfiled): Due to the auto-saving functionality, when the Name’s request is fullfiled, the category returns to ‘cellphones’, and only when the Category’s request finish, it updates back to ‘tablets’.

This is happening because all this items belongs to the same model of the same product, and when a request is fullfiled, Ember updates all values with the server’s response - and in this case, category wasn’t updated yet, so returned to the previous value.

##What i need:

Well, something that comes to mind that might resolve this problem is to set Ember to not update the data with the server’s response after a PATCH… I just need to know if it is possible, and how to do it…

Does anyone there know how to do this?

Thank you very much!




I think it can be resolved with some serializer, but i just don’t know how to do it;


Are you looking for something like a one-way computed property? Basically update the original, without mutation.


Hey @VodkaMD .

I don’t know if One Way Binding is what i am looking for, since i need to get the data from server and then make updates (PATCH) when the input is changed. The problem is that when i make a PATCH, Ember gets the response to update all the items from the record… The problem in my case lies in this response update.

I was wondering if is there some configuration to disable it, since my entire application runs with this auto-save functionality, and… to update each field individually to solve this problem would be quite labour.