Problem/Motivation
Did some experimentation now that we have both deserialization and also create, update and delete methods. Based on that experimentation, I think:
* Having a complimentary serializer would be useful. The main use case would be getting a deserialized resource, updating a field on the deserialized object, and then updating the resource in the CMS using updateResource. Drupal won't accept the deserialized version of the resource, so you would need to serialize it before using it in the body of the updateResource method. Doing this would be a lot more convenient if the client provided access to a complimentary serializer for the deserializer that was used.
* I don't think it makes sense at this point to 'automatically' serialize data similar to how we automatically deserialize data. There are too many different libraries in this space (and many are old or not maintained), most have pretty different signatures, and from my testing none of them serialize perfectly for Drupal - you'll need to make a few small tweaks before trying to update a resource in the CMS. If someday there was a serializer library that worked perfectly with Drupal, this could be a different story.
Proposed resolution
* Update the ApiClient Serializer type to also include a serialize property which accepts a serialize function. This function type will need to be pretty open ended as the signatures of these serializers vary quite a bit (for Jsona you have to pass the data in as 'stuff' LOL).
* client.serializer.serialize should be callable, but as of now won't be used automatically internally in the JsonApiClient.
* For sake of example, we should make sure this works with https://github.com/olosegres/jsona (probably the most common option) and https://github.com/andersondanilo/jsonapi-fractal (a good example of a functional alternative with a different signature)
Remaining tasks
* Update the Serializer type.
* Test serializing with Jsona and jsonapi-fractal.
* Add tests.
Update documentation.
API changes
* serializer option may now have a serialize method which will be callable.
Issue fork api_client-3377194
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
brianperryMarking this as postponed as we focus on the vertical slice POC.
Comment #3
brianperryFor 1.0 my guess is that this is what we'll need to focus on:
> Serialization could be relevant when we support non-read operations in 1.0.
Comment #4
brianperryPicking this one up. I'm going to first do some experimentation now that our CRUD methods exist to determine if a serializer would actually be useful. I'll then update the issue accordingly.
Comment #5
brianperryArchiving previous thoughts:
Starting this as a clearing ground for post MVP serializer related thoughts and will convert this to a more organized issue later.
Assumptions:
* For the POC, really what we were after is a deserialization - converting a JSON:API response into a simpler JS object.
* Serialization could be relevant when we support non-read operations in 1.0.
* Deserialization is a common issue for JSON:API responses, but less so for GraphQL.
Questions:
* Should the JSON:API client deserialize by default? Current thought is no.
* Should the serializer option be part of the base class, or the JsonApiClient Class? On the fence about this, but leaning base class.
* Should the JSON:API client ship with a serializer/deserializer? If yes, should we adopt a dependency, or should we create our own?
Libraries
* Jsona https://github.com/olosegres/jsona
* jsonapi-serializer https://github.com/SeyZ/jsonapi-serializer
* js-japi https://github.com/mathematic-inc/ts-japi (serializer only)
* deserialize-json-api https://github.com/weilandia/deserialize-json-api
Comment #7
brianperryComment #8
coby.sher commentedComment #9
pratik_kambleComment #10
pratik_kambleComment #11
pratik_kamble