Should enum variants fail on encode or decode? about bs-webapi-incubator HOT 7 CLOSED

Ehhh, cc @bobzhang @rickyvetter @IwanKaramazow. It'd be great to have a good answer for decoding variants and such.

from bs-webapi-incubator.

option was just an example. I'm talking about not throwing, like here

from bs-webapi-incubator.

More context:

I've manually written encode and decode functions for stringly-typed enums, of which there are a lot. Sometimes I raise an exception when the unexpected happens (https://github.com/BuckleTypes/reason-js/blob/master/src/fetch/fetchRe.re#L53-L83), other times I add an extra Unknown variant and wait for it to blow up somewhere else (https://github.com/BuckleTypes/reason-js/blob/master/src/dom/htmlElementRe.re#L7-L21)

from bs-webapi-incubator.

^ might be better to model this as an option or something, if it's not inconvenient. Likewise, I hope bs' encode/decode doesn't throw... please

from bs-webapi-incubator.

To me, an option seems a bit less convenient than just having an Unknown variant in many cases. It's also not always clear what None would mean, since None or Default (encoded as "") are sometimes also actual values. So you might get Some None perhaps.

Then there's a difference between whether the source of the value is from the "system", as e.g. nodeType would be, or if it's user-specified, via an html attribute perhaps. In the former case, unless the spec changes and someone uses an obsolete version of reason-js, it really ought to be an exceptional occurrence to receive an ill-formed string value. In the latter case, when the user might type in whatever they damn well please, there should perhaps be an Unknown variant or be wrapped in an option or something similar.

from bs-webapi-incubator.

I would just like something simpler

external fetchAsync : (_ [@bs.as "async"])  -> string -> t 

This works better with code completion

from bs-webapi-incubator.

@bobzhang That only works for a small subset of use cases though.

Consider nodeType, which is used on Dom.node to express whether it is actually a Dom.element or Dom.document etc. Then it needs to be a variant that can be pattern matched in order to do the right thing. (Or some other way of doing the same thing).

Or consider any of the variants in fetch that's used with several different data structures. Using inline polymorphic variant types would mean a lot of duplication, messy ffi signatures and a much greater risk of a bug sneaking through when the variants need to be altered (These are web specs, they change all the time).

from bs-webapi-incubator.