Comments (13)
The behaviour of serialization is that if the relationship's attributes are populated (not just an id
but an object), the data is supposed to be included
.
To keep this behaviour on deserialize, if the included
key is set, it considers that the relationship's data was populated, so it will set all the attributes in an object.
Maybe a test is missing to check if the included data only contains "resource identifier object" (only type
and id
attributes). In such case, the result will be the same as if the included data is not set on input data for the relationship.
Exemple:
{ id: 1, name: 'randomname', roles: 1 }
from json-api-serializer.
The reason why I am asking is because I would like to use it with ObjectionJS's graphInsert (https://vincit.github.io/objection.js/#graph-inserts). This requires the relation to be an array of resource identifier objects.
Would it make sense to add a check to see if the relationship is an array of "resource identifier objects" on deserialization? (i.e. if it contains type
and id
it should deserialize the relationship to an array of objects instead of an array of ID's, independent of the included
property)
from json-api-serializer.
Each ORM is different and has specifics needs.
What about having an option transform
that takes a function to transform each data after deserialization ?
In such case every specifics needs should be code here...
from json-api-serializer.
@mattiloh I think you have already worked with Objection.js. Any thougths ?
Thanks
from json-api-serializer.
I understand that the ORM implementation should not be the concern of this serializer. However, imo it does not make sense to deserialize a resource identifier object to a simple ID if it is not in included
.
This change already solves the 'problem':
https://github.com/stefanvanherwijnen/json-api-serializer/commit/228f152d3b6a8e349c9cbea46f4e865cdb0d95b4
So the question is: what is the correct way to deserialize a relation? The serialize example in the README also shows this problem: the array of strings in photos and the array of objects in comments are both serialized to the same result (resource identifier objects). So I guess there should be an option to specify the deserialization such that one can get both results.
Edit:
Something like this: https://github.com/stefanvanherwijnen/json-api-serializer/commit/6e09d8ff64086685c759871e6f7d04856bf46122
from json-api-serializer.
Hi @stefanvanherwijnen!
Yes, we use Objection.js with this deserializer, but I never used the graph-insert so far. We probably should give it a try in the future, because it seems to be a great feature.
Regarding your proposal: I can see that it could make sense for to-many relationships, because they are normally saved as dedicated rows in other tables (at least in relational databases). But belongs-to-one relationships are normally saved as single ids on the resource itself (e.g. a team
relation of a user
resource might be saved in the foreign key column team_id
). Since this deserializer is resolving these values to ids only, it works great in such cases.
If we would just apply your proposed changes, the serialization of all belongs-to-one relationships would break and needed a refactor. A has-one relationship on the other hand could work fine with your proposed changes.
I don't have a definitive opinion on this yet (since I didn't have the time to dive deeper today), but after these first thoughts, I would be careful with hard-coding a behavior that is working fine with one specific ORM.
I think @danivek's idea of a transform
option could be a good idea, since it allows to adjust the output to any ORM. Maybe it could also be a deserializer
option of a relationship
?
E.g.
Serializer.register("user", {
...
relationships: {
team: {
type: 'teams',
deserializer: data => data,
}
}
});
from json-api-serializer.
@mattiloh
You are right about the toMany relationship. I had not thought of it, but for a belongsTo relation, an array of keys is indeed the right way, in contrast to the toMany relation. So both options should be available in the end.
Did you have a look at:
https://github.com/stefanvanherwijnen/json-api-serializer/commit/6e09d8ff64086685c759871e6f7d04856bf46122
?
My first suggestion would indeed break the correct behaviour of deserializing to an array, but with this one can choose the deserialization behaviour.
Thanks for the feedback.
from json-api-serializer.
Yes, I had a look at stefanvanherwijnen@6e09d8f.
But I think a generic deserialize
option for relationships would be more flexible and provide a clean API.
Serializer.register("user", {
relationships: {
team: {
type: 'teams',
deserialize: data => ({ id: data.id })
}
}
});
It allows you to do what you need without being opinionated about the default output for objects. I think it's possible that somebody else in the future would like the deserialized object to look different from your proposal.
Do you think that would solve your problem?
At @danivek, what's your opinion on this? You imagined a transform
option. Did you imagine it to be like the proposed deserialize
?
from json-api-serializer.
Thanks, I think this would be a good solution. It should solve my problem and the added flexibility is indeed a better choice.
If @danivek agrees I can create a PR for your proposal if you don't have time yourself.
from json-api-serializer.
I agree with @mattiloh for having a more flexible API.
I imagined a transform
option that has the same goal as deserialize
, except that to be even more generic, it will apply on the whole data and not only on each relationship's data.
Anyway, deserialize
option on relationship is still an acceptable solution for me.
from json-api-serializer.
This seems to work:
https://github.com/stefanvanherwijnen/json-api-serializer/commit/f4e3e1b966159a7418e2acb9b5bcd7476fec28e0
With regards to a transform
function: wouldn't that collide with the JSON API spec? I think this problem only exists for relationship data, so if one could transform other data as well it might not be compliant with the specification (except for e.g. case conversion, but that is already implemented).
from json-api-serializer.
@mattiloh @danivek
Any feedback on the deserialize
functionality in my fork? Anything missing or should I make a PR?
from json-api-serializer.
@stefanvanherwijnen It's ok for me.
from json-api-serializer.
Related Issues (20)
- ObjectID (mongodb) should be serialized with .toString() and not treated as an object HOT 2
- Support extracting error class names into the 'title' field of JSON API errors HOT 1
- Error when try to deserialise an included relationship with `alternativeKey` HOT 3
- ErrorMaximum call stack size exceeded if `included` has cross references
- Would you be interested in a conversion to Typescript? HOT 2
- Error instance serialization missing properties HOT 1
- ValidationError: beforeSerialize is not allowed HOT 2
- Incorrectly deserializing relationship when alternativeKey is set from default and relationship data is not in the included array HOT 2
- Case conversion breaks on non-alphanumeric strings
- Unintended object in attributes HOT 2
- Is there an option to remove undefined properties? HOT 1
- The result after serialize will not have `included` if the input doesn't have attributes HOT 5
- Error thrown when relationship is not registered HOT 5
- Having no attributes in the relation data does not add relation to included array
- Use a cache for converting to snake/camel/kebab case HOT 1
- bug: When installed in Angular project, it throws error since it is searching for `fs` HOT 3
- Relationships do not work with ES2015 classes
- bug: Duplicated models from includes are removed from response HOT 1
- Support serialization of only meta HOT 2
- Support for relationship data serialization? HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from json-api-serializer.