GraphQL Data Provider Component

The primary purpose of the data provider is to allow execution of additional GraphQL queries, and to feed the results of these queries to the data provider's children components. This will cause its child components to receive data from this provider's queries, rather than from the page-level query.

Additionally, it has properties that allow you to control how the data is fetched, including the ability to automatically paginate and fetch multiple pages of a connection. Use this component if you:

• Aim to utilize information from a different GraphQL query for specific component(s) on the page.
• Want to use the same query but with different variables. (E.G. you might want to show 'related products' on a products page)
• Have hit the complexity limit and you need to split up your GraphQL query.
• Want to use a GraphQL query based on the results of your page level query. (e.g. You want to use data from a related entity, but it is not directly linked in the GraphQL schema so you need a second query. An example could be payments related to an order.)
• Want to fetch all data from a connection at once. This can be useful if you have a component that allows for filtering or sorting data on the client side.

About the Auto Pagination Feature

As mentioned before, the data provider is capable of automatically paginating up to one connection (IE a list of items) in the provided query. Internally, the the data provider will make multiple graphql queries to fetch the list of items until it either hits the max limit or there are no pages of data left to retrieve. 

To use this feature, use the path property to tell the data provider the path to the entity that you want to automatically paginate. The feature will be automatically enabled if it detects that the path points to a connection. (Refer to the configuration example for a sample usage of this).

As this component is capable of loading large amounts of data at once, you can also control the behavior of how its children are displayed while the data is being fetched. It is capable of rendering its children and re-rendering as more data arrives, or it can wait until all data is loaded before rendering its children. See the

`loadingBehavior`

The pagination feature takes into account pagination variables in the query. For example, if

`first: 20`

Setting first can cause the number of results fetched to go over the configured max limit when this limit is not a multiple of the page size.

The actual pagination variable names follow the same conventions as the List Component, documented under Sort Order and Page Size. For example, use

`orders_first`

`after`

`before`

This component is capable of fetching up to 1000 results of a graphql entity for the first connection in the query.

Data

The results of the graphql query will be passed to its children components through the data prop. This will replace the data that the component usually gets from the page level query.

Additionally, the data prop will also have an additional field named

`dataProviderState`

• A value in a template to show different things from a manifest level. For example, multiple Conditional components could be used to swap between components depending on the value of

  `dataProviderState`

  .
• A value at the code level by a custom component to fine-tune the behaviour of the component depending on the state of its data.

The

`dataProviderState`

Limitations and Known Issues

The Data Provider component currently doesn't work well with the List Component's ability to paginate. The List Component was designed to show one page of results at a time, whereas the Data Provider was designed to fetch a lot of data at once. When using the data provider with the list, all data fetched by the data provider will be displayed by the list, which may not be a good user experience if the list of items is too large. Additionally, none of the list's pagination features will work as intended. 

Anywhere