RFC: JSON Patch support for Ember Data#5
Conversation
pixelhandler
changed the title
pixelhandler
changed the title
|
+1 |
1 similar comment
|
+1 |
|
+1 |
6 similar comments
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
👍 |
|
+1 |
|
OMG. +1. |
|
+1 |
3 similar comments
|
+1 |
|
+1 |
|
👍 |
|
Want :) |
|
+1 |
1 similar comment
|
👍 |
There was a problem hiding this comment.
IMO, models shouldn't know about data exchange mechanisms with the server. We'd entangle models with adapters with servers, which would lead to highly coupled code.
In my opinion, we should add a new method in the store such as bulkSave that would trigger yet another method in the adapter, patch. Adapters without this method mean they don't support this and regular createRecord / updateRecord would be used.
The adapter's patch method would receive a special object called DirtyRecords (or along those lines), which would yield an array of all records that are pending save in the store. Adapter would craft a JSON Patch request based on that object.
There was a problem hiding this comment.
@kurko I understand your concern. My intention is that a model can trigger an event on the store service such as attributeChanged then the service/adapter can do what it wants, e.g. perhaps call a patch method. This is an example of one way that I've implemented this behavior to patch a change in as close to real time as possible - https://github.com/pixelhandler/ember-jsonapi-resources/blob/master/README.md#resource-services and here - https://github.com/pixelhandler/ember-jsonapi-resources/wiki/Services#collaborators
I really enjoyed this behavior when I tried out ember-orbit with json-patch. So I've borrowed that behavior for my own persistence needs as well.
|
+1 |
4 similar comments
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
Yes please! |
|
All of these +1 don't add anything. Your interaction will be much more effective if you, for instance, reply to my comment above about coupling models with servers. |
|
@kurko this chrome extension is a godsend... Github +1s |
|
@kurko I'm not sure I understand why. Also, there is a button 'Add a line note' to your comment. Is this what you mean? Is it better to add '+1' there instead? |
|
@jeremytm I'm suggesting you to elaborate on why you agree or disagree with #5 (comment), which looks like a blocker IMO. |
|
I think like myself, many us here just want to show support for adding PATCH capabilities into Ember Data - assuming that the brilliant minds behind it will know how to work through any obstacles and blocks - and land on the best implementation. Any developer knows the features that are requested most are the ones that receive attention, so that's the goal here from these +1's I think. What's the next step? (I do agree with your statement btw, that models should only know what they need to know and nothing more). Does someone start a new thread with an evolved implementation suggestion? Then we all jump over there with our +1's? |
|
@jeremytm this is the 5th PR on this RFC repo (this weekend I created the 69th PR), and has not had any attention/response from the Ember Data team. Not so much as a "no that's not a good idea" or any response with an alternative solution. I expect that I will just continue to develop my own custom solutions for data persistence. Here is my story and path forward for my data persistence needs: http://pixelhandler.com/posts/my-battle-with-data-persistence-in-ember-apps and the repo I am now using for JSON API - https://github.com/pixelhandler/ember-jsonapi-resources I may implement JSON PATCH on that project once my backend is ready for it. I ran with JSON Patch on personal project for about a year and really enjoyed it. For me, the JSON API spec is really the main driver for a solid client-server solution for Ember apps. Ember Data is also using the format for JSON API as well. The Ember Orbit project did have JSON Patch support but I'm not sure if that will continue. About a year ago, I spoke with one of the Ember Data team members and doubts about JSON Patch were raised concerning enforcement of an order of patch operations. (I think that the Orbit.js project did address that concern internally.) In an application with lots of read/write activity timestamps may be necessary to enforce the order of operations when processing a batch of operations. I really like the idea of using the test operation to validate that each current operation is valid on the server side. |
|
@pixelhandler - let me address the questions you raised about Orbit and Ember-Orbit. Orbit internally uses JSON Patch operations to transform sources and emit notifications that sources have transformed. This is still the case and I don't expect this to change. Furthermore, Orbit has a So to recap, Orbit is fully committed to continuing to support JSON Patch operations internally and will also support the final form of the JSON Patch extension that lands in JSON API. Now that we've finalized JSON API 1.0, I'm devoting almost all my OSS time to stabilizing and refining Orbit and Ember-Orbit. It would be a massive duplication of effort to enable the same internal and external communication mechanisms in Ember Data. I'm open for discussions with the Ember Data team regarding collaboration options between our projects. |
|
👍 +1 |
|
JSON API 1.0 requires PATCH requests for updates, and it looks like in Ember data 1.13, using the JSONAPIAdapter, it's sending out PATCH requests for all updates by default - just for anyone else who ends up here, and has the ability to use JSON API 1.0 for their backend. |
|
Nice discussion, thanks everyone. Closing this, it doesn't need to be a thing in Ember Data, cheers. |
Clarify taking addresses of globals in globals
Update 0000-ember-new-lang.md
20 participants
Rendered
@machty suggested that I add the proposal I posted on the discuss forum to this repo, see: http://discuss.emberjs.com/t/json-patch-support-for-ember-data/6078 ( json patch support rfc )
"Extend Ember Data Model prototypes to have individual 'updatable' properties. Model instances can receive patch operations in response to updating or deleting records (PUT or DELETE requests) by pushing partial changes into the store (DS.Store#update). Create mixins for Model, Adapter & Serializer prototypes which support using a JSON Patch rfc6902 format in payloads sent as responses in order to apply partial updates."