-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
I have objects with more than 14 fields :( #7
Comments
The ergonomics of the Elm pipeline decoder package rely pretty heavily on currying a constructor. We could probably do some strange things with functions and get a similar system working but I think I have a better idea. I have a hunch that we could get something working with Intersection Types where we allow function chaining Although TypeScript and Elm solve a similar problem, they have very different type systems and it's been fun to feel the bits where this library diverges from a 1-to-1 clone of Elm's |
@ooesili Just fwiw, this isn't urgent for me. I figured out a workaround by declaring a type in my own code that supports the number of arguments I need (up to 16 now :P), so I have a passable workaround for the time being. Thanks for the response! |
Hey @radix, would you mind elaborating a little bit how your workaround works? I need to support more than 15 fields. |
Maybe this could be helpful https://github.com/darekzak/type-safe-json-decoder. Basically I merged MazeChaZer implementation of object decoder, so kudos to him. |
Hi!
I am in the unfortunate situation of having objects with more than 14 fields, and the
object
function only supports up to that many (at least, in a type-safe way). Does it make sense to just add more type declarations (I hope TS itself doesn't have a limit on the number of type variables...) or should there be some other more incremental API for decoding objects with large number of fields?Elm's Json.Decoder only supports up to 5 fields at a time, but there is another package called
elm-decode-pipeline
which supports a more flexible framework for decoding these large objects. You use a syntax like this:where
decode
andrequired
have these type signatures:however, I have no idea if TypeScript supports the type trickery required for a API like this.
The text was updated successfully, but these errors were encountered: