Right now all GraphQL.Request.Builder.ValueSpec values are NonNull by default, and a nullable function is provided if you want to make nullable ValueSpecs. This was the natural thing to do in Elm, because wrapping the decoder with Json.Decoder.nullable is easy, and doing the reverse is more awkward.
Unfortunately, this choice of default is more error-prone if you aren't somehow validating your queries against your target schema.* If a field is nullable in the schema and you use the default non-null spec for it, the decoder will work as long as the values you encounter happen to be non-null. This can set you up for a nasty surprise in production when your non-null decoder encounters its first null value.
For the next major release, I'd like to switch this around and have nullable as the default. The error condition for using the default incorrectly will then become simply having to deal with an extra Maybe that you didn't have to before.
* Of course, you "should be" validating your queries against your schema, but the package doesn't help with this yet, and in any event the package should be as free of footguns as possible.
Right now all
GraphQL.Request.Builder.ValueSpecvalues areNonNullby default, and anullablefunction is provided if you want to make nullable ValueSpecs. This was the natural thing to do in Elm, because wrapping the decoder withJson.Decoder.nullableis easy, and doing the reverse is more awkward.Unfortunately, this choice of default is more error-prone if you aren't somehow validating your queries against your target schema.* If a field is nullable in the schema and you use the default non-null spec for it, the decoder will work as long as the values you encounter happen to be non-null. This can set you up for a nasty surprise in production when your non-null decoder encounters its first null value.
For the next major release, I'd like to switch this around and have nullable as the default. The error condition for using the default incorrectly will then become simply having to deal with an extra
Maybethat you didn't have to before.* Of course, you "should be" validating your queries against your schema, but the package doesn't help with this yet, and in any event the package should be as free of footguns as possible.