Input Types

[00:00:00]
>> Scott Moss: Let's talk about Input Types. So I've been talking about these input types. What are they? How are they different? They're literally just like types of arguments. That's it. It's nothing special about them. They work exactly the same way as types do, except you can only use them for arguments.

[00:00:16]
That is the only difference between a type, and input type. They follow the same rules, they have fills that will eventually resolve to scholars, and you can always use this for arguments. That's basically it. All the fields on an input type, eventually have to resolve into a scholar, but they can also be other input types.

[00:00:37]
So, what does that mean. Well, let's make it input type first. So if we wanted to make an input type for pets, let's say we wanna be able to pass in a filter for pets, you can filter based off on the type and the name for some reason.

[00:00:55]
I don't know, you wanna be able to something like that. So, first you would do is the difference going to input type at a type is instead of using the type keyword, you use the input keyword. And you would give it a name. I have a convention that I like to name all my inputs, because they look very much like types.

[00:01:13]
And you could give them the same name of a type, like I could call this input pet. And this would work. But isn't that confusing of a type called pet input called pet, you wouldn't know which ones which. So always put the word input after the name of my input, so I know this is the input types so I'll say like pet input, whatever input.

[00:01:31]
And then from there, it's, it's the same thing as a type. So, I wouldn't be able to filter by a name. So that's optional. So I won't put an exclamation, I want you to filter by a type. And that's optional. And so I won't put a string there, or I won't put an exclamation.

[00:01:48]
And then inside of pets, my other conventions I like to do is, I always like to call my arguments instead of passing in. Multiple arguments like this was just kind of a pain when you get back here to the resolvers. I instead always just pass up one object, and I always call it input, all right?

[00:02:06]
I always just call it input, and you set it to whatever the input type is. And if it's required, you put a bang if not, you don't. In this case, you don't have to give me a filter if you don't want. And then in your resolvers, you always have this looks for input, and it's always gonna be there.

[00:02:19]
That's it. And that's because the name of the key, of the arguments object in your resolvers is the same name as the argument name. And the arguments in the schema, they match and in hand. So pet inputs and object does not have a name and a type. And that's what this is gonna be, inputs going to be an object that has a name and a type.

[00:02:39]
This has passed through the client.
>> Scott Moss: So if I were to put exclamation here, then I would, the client would always have to send me a pet input. I could not do that, and I could put one here. And now the client can optionally send me a pet input, but when they do it better include a name, or it's gonna break.

[00:02:59]
So there is a lot of different scenarios you can do here, to really figure out your input. And again, your resolver is nobody. So, there is no surprises. You're good to go. But these are some of the conventions that I adopted, because what happens is you start to have a lot of crazy invitations.

[00:03:14]
People just start calling these whatever they want, and then you have all these resolvers that. I have like different names, and it's like these words scenarios. So I just decided to call it input and keep it the same pass an object versus, having a whole bunch of other properties in here.

[00:03:32]
Like that.