Relay: Incoming Relay 2 API

[pvolok]

Hi. I'm working on GraphQL support for Flow. It should make Flow validate queries/fragments against schema and convert them to js types.

This tool must be framework agnostic, but should support all major libraries like Relay and Apollo. I saw Greg's and Joe's talks on how the new Relay is going to be different, but there are not many details. I understand that API is not stable yet, but I'd design the tool according to current ideas about Relay.

For example, it's not clear how fragment spreads will resolve fragment by it's name. Or how can custom directives alter the query result.

Can you give any info about the new Relay API?

cc @wincent

[wincent]

Great to hear that you're working on that. Given that GraphQL has rich type information, using Flow to bring that information into JavaScript is a great idea. I have vague awareness of some projects in the ecosystem that are trying to leverage the type info in the schema in related ways to improve developer experience by powering better autocomplete in IDEs and so forth. Likewise, at Facebook, we had an intern project earlier this year where we build a tool that generates Flow types for fragments that developers can import and use; this sounds similar to what you're proposing here. We have no concrete plans to share the project at this time (but nor do we have plans _not_ to share it); sorry to be non-commital but we're not actively working on the Flow type project so I don't have any knowledge about how/when/if it will be part of our open source efforts.

it's not clear how fragment spreads will resolve fragment by it's name

At the moment we are employing a convention that names all fragments in the form ModuleName_propertyName (eg. ProfileEditButton_viewer). Given this convention, we can map back and forth between Relay 1 style fragment references (${ProfileEditButton.getFragment('viewer')}) and Relay 2 style fragment spreads (...ProfileEditButton_viewer).

The compiler itself operates on a corpus consisting of all the documents in the project, so it effectively has a global map of fragment names to fragment definitions.

how can custom directives alter the query result

Custom directives do not directly alter the result as it is returned by the server. In fact, the directives are stripped by the compiler and they are not sent to the server (that is, they don't appear in the version of the query that gets persisted on the server). Instead, the directives are used as guidance for the compiler. Note that it's likely that we'll drop support for @arguments and @argumentDefinitions directives, at least in the short-term: in our experimentation in porting apps to the new APIs, we've tried to do so without the new directives, in order to see what development feels like without them, and it turns out that we've been able to get pretty far.

We'll be communicating a status update at some point (we already have a draft that is circulating internally), so my advice to you would be to proceed based on what is currently in Relay in the meantime. There is too much uncertainty to try and catch the moving target of what will and might be in the future, so it's best to shoot for what is known/shipped. I hope this helps.

[proProbe]

@wincent Would be great to see a tool that would actually generate the flowtypes based on fragments. Our project is currently doing this by hand and sure, it makes understanding the code a bit better but takes time when creating the types and when updating the schema. Hopefully generating the flowtypes would lessen the time needed on this!

[gaetansnl]

@wincent

in our experimentation in porting apps to the new APIs, we've tried to do so without the new directives, in order to see what development feels like without them, and it turns out that we've been able to get pretty far.

Is this still true ? I'm wondering that because we find very difficult to build our app without these directives. It seems they will stay in the API ?

[wincent]

@pulse14; @arguments and @argumentDefinitions are no longer considered "experimental" as of 9afd76498942ef8c7c8.