In this article I want to compare two possible ways to define how a rendering and its associated data are serialized: Rendering Contents Resolver vs Component GraphQL Query.
JSS allows you to configure a Rendering Contents Resolver on each rendering, which determines how a rendering and its associated data are serialized. Rendering Contents Resolvers are configured in /sitecore/system/Modules/Layout Service/Rendering Contents Resolvers. By default, JSS provides:
- Datasource Resolver - The default behavior, serializes the rendering's datasource item;
- Datasource Item Children Resolver - Serializes the children of the datasource item;
- Context Item Resolver - Serializes the context item instead of the datasource item;
- Context Item Children Resolver - Serializes the children of the context item;
- Folder Filter Resolver - Serializes the descendants of the datasource item, excluding folders.
With GraphQL, the format of the route data returned for a specific component by the Sitecore Layout Service can be modified into the result of a GraphQL query. This means that you can define a GraphQL query that defines the data you require to power a frontend component, and then receive the data from that query back as a property (i.e. props.fields for a React component). This gives you tight control over getting only what data you need, and also gives you the power of GraphQL if you require advanced data sources such as child items or CRM data.
When to use GraphQL
- Your component requires more data than that available in your datasource template fields presented in GraphQL schema;
- The datasource template contains extra fields that you do not need to render;
- You do not wish to have any client-side GraphQL libraries such as Apollo (integrated requires no additional dependency other than JSS).
Let’s have a took at the following example:
1. have created a Json Rendering with a default Rendering Content Resolver which serializes the rendering's datasource item if it is set:
2. I have created a simple template that I am going to use as a datasource for rendering above.
3. I have created an item based on the previously created template and аilled in fields with sample values.
4. Finally, I have added the rendering to the Home page, chosen the currently created item as a datasource and requested the page from the LayouServece. I got the following serialized rendering data:
The result above is a Layout Service default behaviour. The datasource fields are serialized to the JSON fields object.
Now I have added the Component GraphQL Query to the rendering created on Step 1. To make things more interesting, I have extended the expected datasource data with additional fields such a Title from the context item and some dictionaries.
IMPORTANT: Once the Component GraphQL Query field has any value, the Rendering Content Resolver is not utilized any more. By default, the rendering data can be serialized in only one of two ways. If you need to use both of them in the same time, please have a look at the following article: How to use GraphQL query and Rendering Contents Resolver together
Result of the GraphQL query execution is below:
You can mention that the data above is something that can’t be achieved by Rendering Content Resolvers available by default. That means, if we want to achieve the same result without GraphQL, we have to implement a custom Rendering Content Resolver. I have prepared an example of code that you can use to achieve similar results:
The code above looks more difficult than GraphQL query: you need to keep Field IDs, you need to care about Experience Editor mode and add an additional editable property in case of editing mode. Also, the example doesn’t have a code to prepare dictionary data. Then, when you want to make any changes, you need to build a project, deploy an assembly to a webroot, wait until an Application Poll will be restarted. It takes much longer in comparison with a GraphQL query, which you can easily update, publish a rendering and get a result almost immediately.
From my point of view, it makes sense to use GraphQL query, when you don’t need to do any manipulations or calculations with data stored in Sitecore. If you need at least one condition on the preparing data logic, it is a point to think about a custom Rendering Content Resolver.
