ReasonML support

[tanekim88]

ReasonML is an alternate syntax for OCaml. There is already a reason-apollo binding at https://github.com/Gregoirevda/reason-apollo, but I cannot find one for Relay Modern. Would there be any plan for this binding? Thanks in advance!

[kassens]

We're not yet working on this. Building the extraction of graphql literals and compilation shouldn't be too hard. The data binding could probably use JS objects to make the binding smaller.

If anyone's interested, happy to help out with thinking how to do so.

[kassens]

cc @este who was also interested in this.

[zetavg]

I'm also excited to use Relay with ReasonML, by today I spend some time figuring out how to make it possible. Seems that it can be considered with four parts, according to relay-compiler, babel-relay-plugin, relay-runtime and relay-react:

Custom relay-compiler


This is not hard since Relay had already exported its library code as the document mentioned. We can copy the RelayCompilerBin then replace RelayJSModuleParser and RelayFileWriter to have a ReasonML version of relay-compiler.

For the parser, the missing puzzle for me is to get the ast and traverse it to grab and validate the content of graphql tags. Not sure if there's a babylon alternative for ReasonML and I haven't read through the traversal code yet.

On the codegen side, I'm also not sure how (AST builder for ReasonML?) to build the runtime artifacts. But it's easy for the types since we have ReasonablyTyped and I have found work on dealing with types here.

Replace graphql tag by requiring artifacts (i.e. bucklescript-relay-plugin)

Maybe something like this:

type graphQlTag = 
  | GraphQlArtifacts(?)
  | None;

let graphql = (template: string) => None;

/* Written code */
let query = graphql({|
  query ViewerNameQuery_thing {
    viewer {
      name
    }
  }
|});

/* Compiled code */
let query = GraphQlArtifacts(GeneratedViewerName.Query_thing);

It seems to be hard since BuckleScript does not have a pluggable interface to implement custom pre-processors. But well, I think I can still do something dumb like this:

graphql({|
  query ViewerNameQuery_thing {
    viewer {
      name
    }
  }
|});
let query = ViewerNameQuery.thing

BuckleScript bindings for relay-react and relay-runtime

Not too hard, I think. Although the flow types looks quite complicated, we can expose a minimal set of APIs that will be actually used.

Well, I'm a starter of ReasonML (for about one week) and not sure if I can help on this 🤔

[zetavg]

Just learned about PPX syntax extensions, maybe we can use it for a replacement of standalone relay-compiler. With this way the hard part should be to transit graphql, graphql-compiler and relay-compiler into pure, OCaml native-compilable ReasonML.

[tanekim88]

I just found this link:
https://github.com/dwwoelfel/reason-relay-scripts

Do you think I should just use this or would it be better to wait for official relay-reasonml binding?

[orta]

There's been considerable work on the relay compiler (allowing language plugins) coming up in relay 1.5 which can potentially unblock more work towards Reason + Relay at a more fundamental level.

[alloy]

Here’s the work @orta was referencing #2293.

[lpalmes]

I think we could make something like this happen with #2293, i got some ideas to make the compiler generate json artifacts that could be used in native/js code, and maybe generate some records, unions and so on.

[zth]

Out of curiosity, anyone actively looking at this right now? It seems like the perfect match, but not trivial to implement of course. Does Facebook have a stance on this, anything likely to be worked on internally?

[josephsavona]

We have no plans to work on Reason integration w Relay internally, but we're open to changes such as #2293 that help ensure the existing primitives (compiler, runtime, etc) can be reused by the community.

[alloy]

I know @lpalmes actually experimented somewhat, but not sure if he ever continued on it. I’d love to help out with any obstacles that may be left.

[lpalmes]

I started working on a plugin for reason following @alloy typescript plugin. I had a small issue that i never came back to resolve. I have to come back to it, i'll post my work here.

[sibelius]

maybe this could help

https://twitter.com/kgoggin/status/1093198315188113409
https://github.com/kgoggin/graphql-codegen-reason

[kgoggin]

Hi all 👋! I'm the author of the lib @sibelius just linked to, and he asked if I could weigh in on this. Full disclosure: I was an early user of Relay who switched to Apollo so I don't have any experience with Relay Modern. That said, I've got a good bit of experience implementing Reason bindings for Apollo (I've contributed a little to the reason-apollo project and am currently using my own bindings for it that I wrote myself).

Typing Relay's API

Looking at Relay's docs, it seems like the <QueryRenderer/> is not too dissimilar from react-apollo's <Query/>. My approach to using that component in Reason has been to:

1. Write types that map to the JS "types" that I'm binding to. For Apollo, that includes the components' props, the object it returns in its render function, and the various config objects required to create the Apollo client (which looks like it'd correspond to the environment in Relay?)
2. Looking at the JS types, think about how I'd like my types to be modeled in Reason. For instance, mapping any string-based enums to variants, and (usually) changing JS objects to Reason records.
3. Write mapper functions that take the JS type and return the Reason type.

Note that I'm still directly using all the Apollo JS code as-is under the covers - my only work has been to write code on top of it to make the resulting API more Reason-friendly.

Another tip I'd suggest is to not be afraid of having some JS code early on if that makes it easier. For instance, if the root of the component tree is a JS file where you configure the Relay environment so you don't have to mess with those types, that could save you some time early on for a file that you're likely not going to mess with too much (and thus don't benefit from having type-safety all that much).

Typing the actual GraphQL queries

Here's where things get interesting. There are basically two approaches to creating types that correspond to the data you're getting from a GraphQL server:

Typing each Query individually

With this approach, each

graphql`{ query { thing { id } } }`

gets its own type on the Reason side. For the above example it'd be an object/record with a thing field and a nested id field, and that's it. My understanding is that this is what a lot of the TS codegen stuff is doing. It's also the approach that graphql-ppx takes, as well as the reason-apollo lib (which relies heavily on graphql-ppx). That's a great approach that ensures type-safety for the data you're getting back on each request, including ensuring that only the fields you actually requested in the query end up in the type. If that's the approach you want to go for, I'd definitely recommend integrating with graphql-ppx!

1:1 GraphQL:Reason Types

The main downside I see to the above approach is that you end up with a ton of very specific types scattered throughout your code, many of which may share the same underlying GraphQL type. For the project I'm working on, I really wanted to be able to define my Reason types to directly correspond to the GraphQL types so that they could be shared throughout the codebase. It's more clear to be able to say that this component takes a Person.t, and this other component takes list(Person.t) - they both have to do with rendering a Person.

That's why I wrote the plugin for graphql-code-generator - to give me a 1:1 match for all my GraphQL types on the Reason side. The downside to this approach is that if I pass a Person.t to a component that needs a specific field, but I didn't fetch it, my type system has no way of knowing that. I mitigated this by building some checks into the field getters in my codegen code so that you'll get a runtime error letting you know the field you're trying to access isn't there. It's not as great as a type error, but I'm willing to make the tradeoff so that I can share my types :).

Hopefully that info is helpful in thinking through how to approach writing some Relay bindings! Happy to answer any follow-on questions if I can!

[alloy]

@lpalmes It would probably be helpful to just post whatever you have so that anybody interested could take it to completion.