Add tests to document behavior of Codec.nullableField
and Code.maybeField
#17
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Thank you @dillonkearns for creating elm-ts-interop and also this nice package.
I created this PR to document a behavior that was unexpected to me:
I had expected that
nullableField
returns anErr
when the field exists but the decoder fails. But it returns anOk Nothing
.The generated TS type seems like it should not hide the error message
{ f : number | null }
when passing{ f: "string"}
.I'm not sure if this is the intended behavior or a bug, so I first wanted to add the tests and then ask for your opinion.
Would you be open to an addition of a codec with this documentation? Or changing the behavior of
nullableField
?null
the decoder will returnNothing
.Nothing
then the resulting object will contain the field with anull
value.It seems related to miniBill/elm-codec#9 (comment) and it might also very well be the case that you are not interested in changing the behavior because it breaks backwards compatibility or because you want to stay close to minibills codec implementation.