Include 'linked' member for json-api collections #692
Conversation
|
I agree with this but only if we pass |
|
@kurko I'll add the include handling and update the PR |
|
@ggordon I need this next week. Just out of curiosity, do you think you'll be able to add it anytime soon? |
|
@kurko I plan on working on it tomorrow. |
ggordon
force-pushed
the
linked_for_jsonapi_collection
branch
from
46b7580 to
f014b3e
Compare
| def render_resource_with_include | ||
| with_json_api_adapter do | ||
| setup_post | ||
| render json: @post, include: 'author,comments' |
There was a problem hiding this comment.
Initially, I believed it should be include: [:author, :comments] instead of strings because we need to whitelist these types, then we'd have to call .join(",") again.
However, we also need to support include=comments,comments.author (sublevels), which would invalidate the idea with symbols above. I don't know how we should express that, though. Perhaps include: [:author, [:comments, :author]]? Do you have any idea?
There was a problem hiding this comment.
Is the whitelist the list of associations that are always included? Where would that be specified, in the controller or the serializer?
I made it a String since that's what would be coming in from params[:include], but if whitelist is specified in controller/action, then I'll need to do something else.
There was a problem hiding this comment.
After some thought, I'm ok with include: 'author,comments'.
|
This is awesome! Really good job here 👍 To proceed, I believe we should include support for sublevel associations first (e.g |
| unless options[:embed] == :ids | ||
| @hash[:linked][name] ||= [] | ||
| @hash[:linked][name] += serializers.map { |item| attributes_for_serializer(item, options) } | ||
| unless serializers.none? || @options[:embed] == :ids |
There was a problem hiding this comment.
I think that include should override embed: :ids and show the association in the linked hash. cc @guilleiguaran
There was a problem hiding this comment.
Yes, when include is used any other rule for inclusion/exclusion of resources in linked section should be ignored
An endpoint MAY also support custom inclusion of linked resources based upon an include request parameter. This parameter should specify the path to one or more resources relative to the primary resource. If this parameter is used, ONLY the requested linked resources should be returned alongside the primary resource(s).
|
@kurko Does this seem right? {
"posts": {
"title": "New Post",
"body": "Body",
"id": "1",
"links": {
"comments": [
"1",
"2"
],
"author": "1"
}
},
"linked": {
"authors": [
{
"id": "2",
"name": "Anonymous"
}
]
}
} |
|
@ggordon yeah, this seems weird, but I'd stick with the spec. Personally, I don't think I'd ever call |
The options passed to the render are partitioned into adapter options and serializer options. 'include' and 'root' are sent to the adapter, not sure what options would go directly to serializer, but leaving this in until I understand that better.
ggordon
force-pushed
the
linked_for_jsonapi_collection
branch
from
f014b3e to
d5bae0c
Compare
Include 'linked' member for json-api collections
Include top-level 'linked' member when using JSON-API adapter. Needed to pass the hash to the elements in the collection, using the options hash worked, but I'm open to suggestions.