Conversation
|
@mhallin How can I push it forward? |
|
Thanks for this. It looks like it basically flips the default of converting |
|
Yes. |
|
I'm a bit weary about this since it changes behaviour in a way that might break clients, so it might be better to just bite the bullet and introduce either |
|
But with that change we’ll have correct behaviour matching the BuckleScript implementation (None is undefined) and GraphQL nullable in arguments is undefined not null, without need for API change. Since we’re not 1.x I think we should think about it as breaking change and make major release (so since we’re 0.x a minor change). Maybe it’s good idea to talk about it on Discord and gather feedback from the users and also ask in reason-apollo because a lot of peoples comes from there. /cc @Gregoirevda |
|
In short, would this PR avoid to have graphql server yelling if we send None value in a mutation when undefined is supposed to be accepted? |
|
@MoOx In JSON there is not undefined AFAIK. Right now we send |
|
@MoOx I've ported this fix into baransu/graphql_ppx_re if you need it. |
It turns out there is a way to filter out null values before generating variables JSON without breaking the API. Implementation allows to
NonetoJs.Json.nullwhich is not compatible with GraphQL spec but later we filter that values out before creatingJs.Json.object_. It doesn't force usage ofJs.Nullablenoroption(option(t))so it's not API breaking change. The whole implementation is done in BuckleScript related code and I'm not sure if those changes should be applied to the native part as well.Should fix: #26 and #59