Also, not a compile-time check, but one other thing I like to do is add fuzz
tests
<http://package.elm-lang.org/packages/elm-community/elm-test/latest/Test#fuzz>
that verify that my encoders and decoders are actually inverses of each
other. I create fuzzers for all of my types, and have a generic jsonRoundTrips
<https://github.com/opensolid/geometry/blob/master/tests/Generic.elm#L22>test
that takes a fuzzer, an encode function and decode function. It checks that
for every value produced by the fuzzer, encoding the value and then
decoding succeeds and gives you back the original value. Then the compiler
can tell you about any problems in your decoder (since it will force you to
provide a value for each field in your record when constructing it), and
the tests will tell you about any problems in your encoder (since if you
forget a field when encoding, then decoding will fail). Not to mention that
the test will also catch other silly errors like Encode.object [ (
"firstName", Encode.string person.firstName ), ( "lastName", Encode.string
person.firstName ) ].
On Friday, 7 April 2017 10:24:23 UTC-4, Ian Mackenzie wrote:
>
> You could change the signature instead of the definition:
>
> accountToJson : { id : Int, name : String } -> Json.Encode.Value
> accountToJson act = Json.Encode.object
> [ ("id", Json.Encode.int act.id)
> , ("name", Json.Encode.string act.name)
> ]
>
> For example, https://ellie-app.com/RcvWmTyWFga1/0 triggers a compile
> error but if you remove the address field then the encoder compiles again.
>
> On Friday, 7 April 2017 08:48:25 UTC-4, Andres Riofrio wrote:
>>
>> For example, I have the following code:
>>
>> type alias Account =
>> { id : Int
>> , name : String }
>>
>> -- ... in another module ...
>>
>> accountToJson : Account -> Json.Encode.Value
>> accountToJson act = Json.Encode.object
>> [ ("id", Json.Encode.int act.id)
>> , ("name", Json.Encode.string act.name)
>> ]
>>
>> If I add a field to Account, I'd like the compiler to make sure it won't
>> be skipped in the output JSON. The way I have written the encoder, the
>> compiler will happily let me skip the field in the serialized version of my
>> data.
>>
>> I thought about using destructuring like so:
>>
>> accountToJson : Account -> Json.Encode.Value
>> accountToJson {id, name} = Json.Encode.object
>> [ ("id", Json.Encode.int id)
>> , ("name", Json.Encode.string name)
>> ]
>>
>>
>>
>> But according to the documentation
>> <http://elm-lang.org/docs/records#pattern-matching>, this will compile
>> fine even if Account gains a new record.
>>
>> Any ideas on how to add this bit of type-safety to my application?
>>
>
--
You received this message because you are subscribed to the Google Groups "Elm
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
