feat: add backwards compatible polymorphic resource support #359
Conversation
|
Thanks for the PR. I’m on a trip for the next two weeks so unless someone else jumps in there will be a bit of a delay in looking this over. Just wanted to let you know I see the PR! |
doomspork
changed the title
lib/jsonapi/view.ex
Outdated
| @@ -140,10 +140,12 @@ defmodule JSONAPI.View do | |||
| @type options :: keyword() | |||
| @type resource_id :: String.t() | |||
| @type resource_type :: String.t() | |||
| @type polymorphic_resource :: boolean() | |||
There was a problem hiding this comment.
This doesn't get used best I can tell. I'd also argue that aliasing the boolean type to polymorphic_resource doesn't add clarity if used in a type spec (the statement "this is a value of type polymorphic_resource" almost sounds like it is describing a polymorphic resource instead of a boolean indicating whether a resource is polymorphic).
lib/jsonapi/view.ex
Outdated
| def fields, do: raise("Need to implement fields/0") | ||
|
|
||
| @impl View | ||
| def polymorphic_fields(_data), do: nil |
There was a problem hiding this comment.
The type of this callback does not include nil (same for the other new callback).
There was a problem hiding this comment.
If in practice this function just gets ignored whenever @polymorphic_resource is false, may as well return [] (which fits its type spec) instead of nil.
There was a problem hiding this comment.
An alternative design might be explicitly allow nil and avoid the need for the @polymorphic_type boolean by instead defining the resource_type/1 function to be polymorphic_type(data) if it isn't nil and otherwise type(). Having the @polymorphic_type boolean is probably the better option, though.
nduitz
force-pushed
the
polymorphic_resources
branch
from
ee95988 to
fa2d880
Compare
|
Hey there, |
|
Hey there :) |
|
Hey! Sorry, I kept not thinking of this PR when I had time to look at it because it had been removed from my review queue after my previous comments. I've added it back into my queue so I should get this reviewed in the next few (week) days. |
Hey there,
I tried my best to add support for polymorphic resources.
The idea is to allow the user to infer resource specifics from the given data.
Currently this only allows
typeandfieldsto be polymorphic. I will probably implement relationships as well.Additionally I only tested it to work as a relation with an api endpoint of its own - quite frankly there are some things that are not possible:
The
QueryParserfetchesview.fields()at a moment where no data is present, thus inference is not possible.This is my first time really working with a behaviour, my approach on implementing a backwards compatible solution felt a bit clunky, so any feedback is very welcome. :)