Single entry node about crystal

[calebmer]

Could you give me a quick example (pseudo code maybe) of how Relay would use this field? Also, would there be a deprecation plan for this? As it may eventually get removed as Relay removes this constraint?

The only reason I hesitate is I want a definitive resource to refer people to if they have questions about the viewer field, maybe a documentation article would be nice? 😊

Otherwise, its super easy to do.

Sure, there's plenty of examples around. https://facebook.github.io/relay/docs/api-reference-relay-container.html gives a simple use case.

In routing (using react-router-relay):

const viewerQueries = {
  viewer: () => Relay.QL`query { viewer }`,
};

const routes = (
  <Route component={App}>
    <Route path="/" component={Home} queries={viewerQueries} />
    <Route path="/users" component={Users} queries={viewerQueries} />
    <Route path="*" component={NotFound} />
  </Route>
);

In a component:

// ...
export default Relay.createContainer(Home, {
  fragments: {
    viewer: () => Relay.QL`
      fragment on User {
        users {
            // ...
            ${UsersTable.getFragment('users')}
          }
        }
      }
    `,
  },
});

This allows you to re-use viewerQueries for each container / top-level component, without having to know what the underlying data structure is beforehand.

As I said, this kind of approach makes perfect sense for view-driven GraphQL consumers like Relay, and I doubt there'll be a deprecation path necessary (even though there is talk about removing that restriction on the issue I posted above).

Now, I appreciate that this approach won't be required by normal GraphQL consumers that aren't necessarily view-driven (though there still is benefits to building up a graph query from a single entry node), so we should be careful not to break existing implementations.

[calebmer]

See #49.

[calebmer]

Released in 1.5.0 🙌