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

Add functions for parsing/serializing the 't_variables' type #220

Open
austindd opened this issue Nov 13, 2020 · 2 comments
Open

Add functions for parsing/serializing the 't_variables' type #220

austindd opened this issue Nov 13, 2020 · 2 comments

Comments

@austindd
Copy link

austindd commented Nov 13, 2020

Right now I have some compelling use cases for generating a record to represent the t_variables type along with functions to parse and serialize that type. The biggest thing for me is writing a server endpoint which decodes the input for a mutation. Right now I have to manually define functions to transform data like Js.Json.t -> Raw.t_variables -> t_variables.

I see that the Operation module type provides the following:

let serializeVariables: t_variables => Raw.t_variables

There is also the makeVariables function, but that doesn't help much because I really need to convert from Js.Json.t, which leaves me writing decoders for that. Ideally we would generate code for the entire round trip between Js.Json.t and t_variables. This has been done for the response type t, so it makes sense to fill in the gap for t_variables.

@jfrolich
Copy link
Collaborator

jfrolich commented Nov 13, 2020

Ah so a parseVariables function? The conversion of Js.Json.t -> Raw.t_variables is zero cost if you are sure the JSON provided are valid arguments to the query. Usually once you have Raw.t_variables you can pass it in a query if the library allows you to pass in raw variables. Can you explain more of the use case? If you are not sure if the arguments are valid, you probably also want a function that validates the JSON and remove all redundant keys and then produce a Raw.t_variables (this is outside of the scope of graphql-ppx I think, and why not go directly to t_variables if you are taking this route?). A parseVariables might make sense but I don't see a compelling use-case for it yet.

@austindd
Copy link
Author

Yeah, I can see why it might not be obvious. Here’s a better description of the use case.

I have dozens of serverless functions written in Reason. The request handler takes a request with a JSON body, which should (in most cases) match the shape of the query/mutation variables sent from the client. In each case, I have to manually parse the JSON body, but it would be nice to have these functions generated by the ppx. I am currently using the module type to infer the appropriate input/response types in my handler function, and using the generated serializer to produce a JSON string for the response. I would like to do the same kind of thing with the input data as well.

I suppose it would be ideal to have the parser function return an option/result type, but I could live with exception-raising as well.

I can post a minimum-viable code snippet later when I’m at my PC of you want.

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

2 participants