Data Module: Expose State using a GraphQL API

[youknowriad]

This is a POC to trigger a discussion of whether we should continue this way or not. Alternative to #4105 closes #2473

So the idea here is that a module that wants to expose a specific part of its state registers a GraphQL schema describing the exposed data and a GraphQL resolver to fetch this data from the state. ( see editor/state/data.js for an example of a (schema, resolver) pair.

The data module exposes a registerSchema function to register the module's schema/resolver pair.

And a query Higher Order Component is also exposed to fetch data like so:

import gql from 'graphql-tag';
import { query } from '@wordpress/data';
const MY_QUERY = gql`query { editor { post { title } } }`;
const MyComponentWithData = query( MY_QUERY )( props => 
  <div>{ get( props.data, 'editor.post.title', 'no title' ) }</div>
);

[youknowriad]

cc @atimmer

[aduth]

Would these more accurately be mapQueryToProps and mapVariablesToProps ?

Or am I wrong in thinking that these functions would take values from the query result and map them to props for the component?

[youknowriad]

Actually, they are correctly names, these are useful if you want to create custom queries based on props.

I can see something like mapResultToProp being usefull as well. It could be a third optional callback.

Edit In a GraphQL API, this is less important though because you already ask for the data you want, it could be convenient though for "undefined" checks and stuff like that.

[aduth]

In your example, wouldn't you want a mapping function from the query result to the props to pass to the underlying component, like connect's mapStateToProps ? To make the component less dependent on the schema shape?

[youknowriad]

There's a bug in the production build npm run build but not sure why. It looks like it's caused by the webpack UglifyJsPlugin.

[gziolo]

Minor, it might be located next to other HOCs inside @wordpress/components.

[gziolo]

get( props.data, 'editor.post.title', 'no title' )

It would be nice to be able to use it as props.title inside the component. I assumed get is from Lodash, which makes it look like an inlined selector in the current shape. Which leads me to the conclusion that you need to get the same item twice. First in the query resolver and then when applying query HOC.

I know all the benefits of GraphQL, how it can scale well, provides a unified interface and helps to limit the number of requests. I can imagine you even would be able to wrap withApiData with query to unify experience. My biggest concern is that the learning curve might be higher than in case of selectors. I'm especially worried about people coming with jQuery + Backbone background and now suddenly they need to learn ES.Next, React, Redux, GraphQL, etc :)

Do you see benefits of having GraphQL in the core on top of selectors and have the latter exposed for plugin developers? I'm just trying to find a way that satisfies needs of all parties involved here.

[youknowriad]

Do you see benefits of having GraphQL in the core on top of selectors and have the latter exposed for plugin developers? I'm just trying to find a way that satisfies needs of all parties involved here.

No, it will be useless in this case. The advantage of GraphQL is being this discoverable and easy to use API. It certains adds learning curve to people creating data (module creators and advanced plugins that want to use the system to expose their own data), but from a consumer's perspective, which I think is the majority of plugin authors and developpers, its API is even simpler to grasp than having to learn and also find every available selector.

[atimmer]

In your example in the pull request description, the data is accessed using props.data, but in the higher order component, you only set the state. How does this work?

[youknowriad]

Yes, actually a GraphQL result is always like this { data, errors } so we'll end up with these two props.

For convenience, we could add an optional callback to "polish" the props like suggested by @aduth. mapResultsToProps

[youknowriad]

Closing this as I think we should go with the selectors API