Skip to content
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

Open
radix opened this issue Jun 9, 2017 · 6 comments
Open

I have objects with more than 14 fields :( #7

radix opened this issue Jun 9, 2017 · 6 comments

Comments

@radix
Copy link
Contributor

radix commented Jun 9, 2017

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:

decode User
  |> required "id" int
  |> required "email" string
  |> optional "name" string ""

where decode and required have these type signatures:

decode : a -> Decoder a
required : String -> Decoder a -> Decoder (a -> b) -> Decoder b

however, I have no idea if TypeScript supports the type trickery required for a API like this.

@ooesili
Copy link
Owner

ooesili commented Jun 10, 2017

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 like().this().maybe() to incrementally & generic types together to build the final result. I'll give it a go tomorrow after I get some rest.

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 Json.Decode

@radix
Copy link
Contributor Author

radix commented Jun 10, 2017

@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!

@joanllenas
Copy link

Hey @radix, would you mind elaborating a little bit how your workaround works? I need to support more than 15 fields.
Thanks!

@darekzak
Copy link

darekzak commented Mar 7, 2018

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.

@radix
Copy link
Contributor Author

radix commented Mar 7, 2018

@joanllenas
Copy link

Thanks @darekzak @radix for you quick responses,
I'll check and see which option better suits my needs.
Cheers

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants