With a union, we can define a new type that lists out the different possible object types it can resolve to. When we want to give a field more flexibility to return one object type or another without any intersection, we can use a union. Let's see how we can represent this using unions. But we might want a way to query distinctly for this or that, without explicitly declaring shared fields between objects. Interfaces are great for grouping commonality between object types. And best of all, we can use just one query to ask for precisely the data we need-right down to the last detail of each fruit or vegetable! We can benefit from the organizational power of the Produce interface, without limiting the way we query data with separate fields for Fruit and Vegetable. ![]() Within the body of the fragment, we can define exactly the fields we'd normally place within the query.įragments let us fully utilize the power of the graph, by specifying conditionally which types should be queried for particular fields. Finally, we specify the object type the set of fields in the fragment applies to using on and the object type's name. ![]() Named fragments are defined using the fragment keyword, followed by a name we'll use to refer to the fragment anywhere we'd like to use it. (We'll refer to a fragment within the body of the query, so wherever we define it needs to be accessible!) They're a good tool to use when we want to simplify the appearance of our queries or cut down on repeated syntax.įragments should be defined alongside the query using them, whether that's in an Apollo Sandbox or in the frontend code of an application. Fragmentsįragments let us define a set of query fields that we can save and use in more than one place. This doesn't mean that our query has to leave out any fields exclusive either to Fruit or Vegetable-we simply need to specify additional syntax to help GraphQL understand which implementing type we'd like to apply the field to. It's invalid to include this field when we're potentially querying for Vegetable data as well. An error occurs when we try to ask for hasEdibleSeeds here because it exists exclusively on the Fruit type. Recall that availableProduce should return a list of Produce objects each object resolves with data that can be represented by one of the implementing types, Fruit or Vegetable. When we query for fruits, for example, we know that we'll get back a list of objects that fit the Fruit type! If this sounds redundant, it's because most of the time we already know what kind of data we've just queried for. (Note that _typename starts with two underscores!) In other words, it identifies the object type that represents an object of data. This field, _typename, is a meta-field that helps us understand the type of thing we're dealing with when we receive data. To understand what object types have been used to fulfill the data in a query, we can use a field that GraphQL provides for every single object type in our schema. We can accomplish this with the _typename field. ![]() When we're working with a particular object of data, we need to start by understanding which of the implementing types represents it. So how do we include those unique fields as well? How can we use GraphQL to ask for additional details from the Fruit and Vegetable types in the same query? We can see the fields that are unique to each of them listed in Sandbox as well. The following two sections under "Implementations" detailed the interface's implementing types-namely, Fruit and Vegetable. This collection makes it easy to query for information that's common between all types belonging to the Produce interface-like id, name, and price! First, we saw the fields that exist on the Produce interface. When you clicked into the availableProduce field on the Stall type, you probably saw a lot of field information.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |