Single entry node

[hardchor]

Relay (currently) doesn't support connections / array nodes without arguments as entry nodes (see facebook/relay#112 for the rationale).

In terms of the classic use case for relay, where it gets used to resolve the data structure for a given page, that kind of structure (viewer) actually makes sense, as the viewer would be representative of the page you're currently on and would then resolve data starting from that node.

So the current approach for most relay-compatible GraphQL endpoints is to implement a single(ton) viewer node (which sits alongside the node node as the only entry nodes), onto which all other nodes get joined.

[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.

[ghost]

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 🙌