You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using hide_as_child_json_when means that the API returns null to mean two different things 1. If the relation doesn't exist, 2. Some arbitrary clause e.g. The relation isn't "public".
I think hide_as_child_json_when should return something other than null or not include that key in the JSON at all.
Here's a concrete example of why this is weird:
I GET all of an upcoming show's artworks. This returns null for partner in each of them because the gallery isn't public.
I click "feature artwork" which PUTs the JSON I just got with feature_eligible set to true.
This also PUTS partner: null which removes the relationship to the gallery... now the gallery thinks the artwork was deleted.
To work around this the client has to know or assume null can mean multiple things and compensate by manipulating the fetched JSON to not sync the partner field unless the user explicitly breaks that relationship.
It's not hard to work around, but I thought this was an odd design decision.
The text was updated successfully, but these errors were encountered:
Using
hide_as_child_json_when
means that the API returns null to mean two different things 1. If the relation doesn't exist, 2. Some arbitrary clause e.g. The relation isn't "public".I think
hide_as_child_json_when
should return something other than null or not include that key in the JSON at all.Here's a concrete example of why this is weird:
partner
in each of them because the gallery isn't public.feature_eligible
set to true.partner: null
which removes the relationship to the gallery... now the gallery thinks the artwork was deleted.To work around this the client has to know or assume null can mean multiple things and compensate by manipulating the fetched JSON to not sync the
partner
field unless the user explicitly breaks that relationship.It's not hard to work around, but I thought this was an odd design decision.
The text was updated successfully, but these errors were encountered: