Check out a free preview of the full Server-Side GraphQL in Next.js course

The "Union Types" Lesson is part of the full, Server-Side GraphQL in Next.js course featured in this preview video. Here's what you'd learn in this lesson:

Scott explains the concept of unions in GraphQL and provides an example of a search result where different types of objects can be returned. Scott demonstrates how to define a union type and incorporate it into the query object. He also discusses the syntax for querying fields on union types and how to determine the type of a union object using the "__typename" field.


Transcript from the "Union Types" Lesson

>> Scott Moss: Yeah, interfaces are cool. Unions are very similar interfaces. You can think of unions as like, it's like an or type. It's like, I'm gonna create a type that can be one of these, and none of those have to share fields, that's the difference between a union and interface.

Interface is like, I need to create a type, and which other object types can implement. So therefore there's gonna be at least one field that they share. A union type is like no, none of these types have to share any common fields, but the union type could be either one of them.

So it's a great example is always a search result. Like imagine if you had a search bar on your app that can return many different types of things that aren't the same shape. So if you have a global search on your app where you can search for people.

Let's say your Twitter, you can search for people, you can search for tweets, you can search for retweets, you can search for whatever other entities Twitter has, all in that one search bar, and none of those things have common fields. You would make a union for that because that one search result can be any one of those types, right?

So let's check that out. So we go back to our code. I can make a union and I'll just say, search results. That's literally like the most common place that I used it. So here is a search result. And then let's just make some types here. I'll just do the Twitter example that I talked about, so we have a tweet.

And it has some content on it, that's a string. And then we have a profile, it has a username on it, that's a string. I wanna make these required. I'm making most of these required so that the mock schema thing that we're using actually return something. They don't always have to be required, I realized if you don't do the required on the mock schemas, sometime it'll return it, sometimes it won't, because it doesn't have to.

So just to force it to return some real stuff, I make it require it. So let's say we have those two things. And I can say a union is gonna be a tweet or a profile like that, right? And then I need to add that to my query object, so I'll go make a query, I will make a query called Search.

And it's gonna return a search result, required, or, I guess, in this case, an array of search results, right? So let's go back make sure we didn't break anything. Looks good, get rid of that query. I'm gonna go back, make a query, make a search result query. And very similar to what we had with the interface, we kind of get a branch here.

The difference is with the interface up here it showed the common fields. But because these don't have common fields and don't need to, there are no common fields. So we can do that, we can do that. But you will notice is that the syntax is the same. We still do inline fragment to say, okay, I wanna do a search, which is gonna return a search result, but for a tweet, I wanna get this, and for a profile, I wanna get this.

So if it was an interface, there'd be some common fields up here that you might have. There are no common fields, so there are none there. On the union, every single field Statement in your query is gonna be within a inlife fragment because none of them are common, right?

I don't know, let's say you know, all tweets have IDs, right? All tweets have IDs and then all profiles have IDs. So you might think those are common fields, but,
>> Scott Moss: They're not. Let me go here, right? It's not gonna show, even though they're both IDs of type ID, same everything, they're not common fields because it's not an interface.

They're completely isolated, yes.
>> Participant: If both of those types in here had a common interface that would contain the IDE then would that.
>> Scott Moss: That's advanced. So you're saying we make a union of these two types, but these types also shared an interface. Yes, in that case, they should resolve, I don't think I've ever built something that's done, So let's say you have a tweet account and a Facebook account.

>> Participant: So.
>> Scott Moss: Let's try it, I'm curious. So you implement Entity, implements Entity. Well, I guess if you think about it, it really comes to,- before we run it, what I think is gonna happen is, it really comes down to this. Because we're bypassing, here when we make a union, the union knows nothing about the entity, it's completely bypassing.

So I think it's still gonna be the same result even though they implement the same thing. I think you would have to do this, you'd have to say entity, but at that point you don't really need a union.
>> Participant: You're right.
>> Scott Moss: Unless you had another thing here that did not implement the entity, and then you can do that.

So let's see, let's run that. But I think it's gonna be the same actually.
>> Scott Moss: Yeah, it's the same, it bypasses that. But if I did Entity, and then let's just make an, what do we have here? Do we have something that doesn't implement? Yeah, let's add a character, that makes sense, right?

So we'll do that. And if we go back here, yeah, it's just, what is it say? Union type searches can only include object types, so you can't include interfaces. So I guess they thought about that. I guess that would be like cyclic, maybe, or there's no syntax for it on the query that would make sense, so maybe they couldn't do it, yes, Mark.

What was the introspection string to get the type? Something with an underscore, underscore at the beginning? Yeah, I'll show that in one second. So, what you can do in the query, if you wanna get the type of something you can just do _ _type name. I can't do it well here I would have to do it inside of here, I'll to say _ _, type name.

So _ _type name gives you the type of something. So if I run this, you can see that the type of this one is called tweet. If I did it here, it's also, this one's gonna be called profile.
>> Scott Moss: We're gonna be using this when we make the resolvers, this is gonna come in handy for sure.

But this is how you would resolve that. Or on the front end if you wanted to know like, is this a person, if you wanna show us you have a different. This example for a search result, you would probably show a different component in the list depending on what object this was.

So this is the boolean and what you would check you would map over all of this. You'd say if,search result.type name equals profile, render the profile component, pass the data in. If type name equals tweet, render the tweet component and pass in the data, right, that's how you would do that.

So it's very seamless, you don't have to do any processing after you get the data cuz all the information you need is here.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now