-
-
Notifications
You must be signed in to change notification settings - Fork 568
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Single entry node #38
Comments
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 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 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. |
See #49. |
Released in |
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 theviewer
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 thenode
node as the only entry nodes), onto which all other nodes get joined.The text was updated successfully, but these errors were encountered: