Transcript from the "Interfaces & Unions Solution" Lesson
>> Scott Moss: That was a really good exercise. I think that was one of my favorite ones because interfaces and unions are crazy but they're also pretty legit. So, let's walk through this solution of how I might have solved it. So, let me check out to lesson-3-solution here and see what we got.
[00:00:28] So for the actual GraphQL part let's check out the task. So here's what I did for the interface. So for the task.graphQL, I decided to make a interface and I think the instructions it did say interface, and obviously I did this one because all these fields are so similar to a task.
[00:00:52] And a couple reasons you could've found this out was one, it's in the description. It was in the instructions there but if you go look at the task.model, you can kinda see, like, a lot of these fields are actually lined up with the fields on grapheQL itself.
>> Scott Moss: So if you look at the task model there's a name, there's a name.
[00:01:15] There is a project, there's a project. There's a status that is a enum type, and there's a status here that's also enum type IMAGO. So a lot of it lines up. So, if we were going to make multiple tasks based off tasks, we know that they have similar fields.
[00:01:34] So, that's kind of how you know that this is an interface where it's starting to line up the same way as a database. So that's the interface here, and then as far as the types that implement that interface, we have the dev task and the design task. Before up here on the task type, they were filled to have comments on them.
[00:01:51] So this one's for dev, this one's for design. Those were the specific fields that you would have had to add on the dev task and the design task. So you got this repo one here, and you got this design, or this assetUrl here for DesignTask. And if you do some due diligence, and you looked up what this Repo one was, did anyone actually get this working?
>> Student: I did.
>> Scott Moss: Did you see what it does?
>> Student: I have no idea what Repo does.
>> Scott Moss: All right, okay, yeah, that one does some call to GitHub and resolves things for you, and we'll get to that later but yeah if you looked into it you might have answered the problem.
[00:02:31] Any questions on the task interface? No, all right, and then for the resolvers for the task interface we had to make the result type what's basically, its pretty simple, there's a type property on a task. It's either dev or design and we know that to be true because if we go to task.ql, it's using a task type enom which is either dev or design.
[00:02:56] So we know task needs to be a type of design or a type of dev and that's how we're able to split off that interface to different types. So, that's all I'm checking here. Let me look at the type. If it is Dev, return DevTask. If it's design, return design tasks.
[00:03:14] Done, and then for the search, I think you had an option here to do interface or union. I chose union. Did anyone choose interface here? Why not? Because I did the search example with a union? [LAUGH] Are you always going to do it like that, yeah I got to make sense.
[00:03:35] Yeah you could have done a union here but it's probably better to do a search here because you got this project, which if you squint at it, it will have similar fields as these other two, but it is not the same. I think the only thing that our project has that is similar is the ID of the name like that's it, maybe the description.
[00:03:54] I do not know the types of descriptions. Yeah, they do, okay. Yeah, there are some similarities there, but the task has some many other things associated with it and you don't want to make another interface that implements a Project, a DevTask, and a DesignTask. You have to write all those over again, when you can just write this union on one line.
[00:04:15] That's the other difference between unions too. Look how easy this was to implement, because I don't have to declare common fields, but you gotta note the difference between the two when you query, which is what I'll show you in a minute. So we're under the search. We're gonna pass the search result non, no, or an array that's not no.
[00:04:33] And then as far as the resolver, for the resolve type, there's basically just two levels here. If there is a type then we know it's a task and if it is a task then it either has to be a dev task or a design task. If there is no type then it's a project and that's the logic there.
[00:04:53] Did anybody do something different here? I mean, there's a lot of fields on the task so I'm sure you could have done a lot of different things.
>> Student2: I actually did string manipulation on the type.
>> Student3: I considered that.
>> Scott Moss: Yeah, you could do that. [LAUGH] Whatever works.
[00:05:10] Cuz you have the whole object here, cool so we're able to run this.
>> Scott Moss: I think I got some stuff in the database here, let's check it out.
>> Scott Moss: And we do a search.
>> Scott Moss: And name, yeah. This one actually does do a real search. I don't know if I have anything in here but that, let's see.
[00:05:49] So because we used a union, I can't type in any common fields here, all right? So that's the difference. If we used an interface and had common fields, I can type them in right now and they would show up, but we did a union, so there are no common fields.
[00:06:02] So you immediately have to do a fragment. That's the other difference too. So, even though our project has a name and a dev task has a name, I can't just come up here and say name, because I didn't declare those common, with an interface. I did a union.
[00:06:27] So they're all different, even though they're the same. That could be helpful, it could also not be helpful because a name on a project might be a stream, but a name on a DevTask might be an object. So, how do you know? So, that's why I said it could be helpful, it could also not be helpful, it really depends on how you monitor your data.
[00:06:46] It can get pretty crazy. So yeah do that. I don't have anything called MVP.