If I refactor the content type in Kontent then I have to update the code in multiple places. However, when all of these pages are passing the data to the same component this seems like poor design. Maybe this is because the philosophy behind GraphQL is very page-centric in that you request all of the information you need to render a page in a single request. This summary needs fields from the article type and the standard pattern that I see is for each page/template to have those fields in their queries. I have an article summary component which is used in multiple places (the index page, journal template and tag template).
It is mentioned on the Gatsby documentation but the example isn't clear and does not explain the benefits well.įirst let me set up the problem with an example from this website. It is one of those things that just seems like an obviously strong pattern, but I couldn't find it clearly advocated anywhere. This is a quick guide on a pattern for using fragments inside your React components to avoid duplication. Avatar Colocated Fragment for importing its fields.The use of GraphQL in Gatsby brings many advantages, but it can lead to duplication of query fields across pages and templates.
#GRAPHQL FRAGMENTS HOW TO#
(If you use typescript, There's a "step by step" section on how to generate your prop types automatically based on the Colocated Fragment definition). Finally, this component consumes the data through a user prop, which includes the same fields as the Fragment: id, image and name.(If you use typescript, you can create a new component type to force the inclusion of the fragments attribute). Apollo proposes to export Colocated Fragments using this attribute, however, this is a matter of preference, just make sure that you set a convention.We export the Colocated Fragment by creating a new fragments attribute in the AvatarComponent.There are no explicit rules on how to name Fragments, but to avoid name collisions, A good alternative is to name them the same as the component they are attached to. First we defined a new Fragment called Avatar.There are three important things happening here: This is how it would look like with a Colocated Fragment: This component will render a user's information. Let's use an Avatar component as an example. All it fields will be included in the section/field where this is being called.įragments are useful, but when you combine them with React components, they become powerful.Ī colocated fragment is just like any other fragment, except it is attached to a particular component that uses the fragment's fields.īasically, is "colocate" the Fragment definition next to the component that is gonna consume its information. The way to consume Fragments is through the spread operator followed by the Fragment name. All the fields from the Fragment will be included in the section/field where is being called.Īs you can see, we are naming our Fragment Avatar and we are indicating that it can only be used by User types. Let's suppose we have a GraphQL post query, which returns a post's content, it author's information, and each of the post's comments:Įnter fullscreen mode Exit fullscreen modeĪs you can see, we are naming our Fragment Avatar and we are indicating that it can only be used by User types. In this article, we are going to focus on learning a variation based on the second method, where we colocate our queries next to the parent components that execute them, and with Fragments, we colocate the consumed fields next to the child components consuming them.Ī Fragment can be defined as a reusable unit of information.įragments let you construct sets of fields, and then include them in queries where you need to.
#GRAPHQL FRAGMENTS FULL#
There are multiple ways for organizing your queries, but normally, you'll find a variation of these two methods:
Developers working on a React project, that consumes data from a GraphQL API and wants to find a new way to organize their queries definitions.
0 kommentar(er)
