Standalone type parsers

[wokalski]

It'd be useful to have standalone type parsers so that one can define such parser wherever they want to parse an object of a given GraphQL type. I took a very simple approach of generating a parser for a type name in #14 . It was promising however it yielded huge objects which took forever to compile.

Later I thought about using type names for simple types and inline fragments for objects. It's not ideal since we might want to generate a recursive parser however I think it's good enough for most use cases. Generating such parsers should not be too challenging. For simple types one could take the approach from #14 and for Objects it's possible to parse the fragment using Document.inline_fragment and then call directly to unify_selection_set. The second case involves some internal refactorings but should be pretty straightforward.

[baransu]

@wokalski What would be the case of such parsers for other case than scalars? Can you provide some use case?

For me, it would be useful to be able to provide parsers for custom scalar types like Long used by Sangria server. I had a few cases when Js.Json.t was handled incorrectly producing runtime errors. One place to define such would be much better.

[wokalski]

@baransu to be honest I don't remember what was the use case I had when I experimented with it. The premise was to be able to take an existing GraphQL type from the schema, say SomeType and do something along these lines:

let parser = [%graphql.parser "[SomeType!]!"]
let listOfSomeTypeObjects = parser(somejson)