Build an App With GraphQL, Laravel, and Vue

6.3 Defining Input Types

We are almost ready to send the data to the server in order to save a project. But the first thing we need to do is talk about how we want to send that data, because that is going to affect how we implement it on the server. So let's just start writing code and see where it takes us. We are of course inside of create project and inside of the submit form method. So let's say that we will have a query called saveProject and of course we want to send data with it. So this far we've been sending just very simple pieces of information, like title and description and things like that. And we could take that approach. However, when we get to the point of users, let's think about what we need in order to specify what users are with this particular project. And really the only thing that we need are the IDs, because really no matter what we do, we're going to have to retrieve the actual users from the database. So we're not necessarily do that but in order to use eloquent yeah, we will need to do that. So, we don't need the name, we don't need the email address, we don't need anything, we just need IDs. So let's just write it like this and that's fine. An array is, I was gonna say a little more complex than just a single value. It's more complex than that, but it's not as complex as our tasks, because our tasks are array of objects. And we can have one task, we can have multiple tasks and these are made up of multiple properties. So, taking the approach that we have done before with just passing normal arguments, this isn't going to work for us. Instead, what we need to do is define a more complex type and we do that with input types. So let's think about it like this, instead of sending multiple pieces of information, what if we send just a straight up project, or at least we would call it a project. In which case we would set the title and we will get the title from our state. The same would be true for our description, so we would say this description. And then when it came to the users, as I mentioned, we only need the IDs. So we could get the selected users and we could get just the IDs of those users, and then we would have a tasks. In our tasks are already gonna be as simple as possible, because remember that they are nothing more than just normal objects with title descriptions, text code, and user ID. So the idea is that we would then be creating this new type called project and it would be made up of some simple data, but also some complex data as well. So really we would be looking at two different types and that's exactly what we have to do. We have to create what are called input types on the server. And yes, we already have types available that we could try to shoehorn this into. But there is a distinct difference between the types that we created at the very beginning of this course and then input types, input types are strictly for input. And the types that we have defined already are pretty much for output. We can't use one for both. So what we're going to have to do is create another folder inside of our GraphQL. We're gonna call this inputs and we are going to create two files. The first is going to be projectInput.php. The second is going to be TaskInput.php. We don't really need user input because we aren't a treating user as a complex type as far as sending the data for creating a project. We just have an array of integer values and that's it. So as with just about everything else, let's use one of our existing types as a basis. And we'll go from there. So I'm gonna use the project type as a basis for the project input. Now, of course the namespace is going to be different. So that is going to be inputs, we still need to use our project model. We'll still have GraphQL, we'll still have type, and we will still have this GraphQLType. We wills till extend the GraphQLType, but in this case we're going to call this ProjectInput. And let's go ahead and just change the name attribute. The description will say a project input and we don't need the model. Now, what is very important about this is that we have to set a protected variable called inputObject and we have to set it to true. In that signifying that this type is being used for input. We are defining a type that we are using for input. So then it comes to the fields, and we need to think about the fields that would be coming in as input. Well, first is ID. Well, a new project isn't going to have an ID, but if we were going to edit a project and it'd have an ID. Well, then we might have an ID. So, what we'd want to do then is take off the nonNull, because ID might be null. So, we'll say that it's of type int and it can be null. The next thing is the title. The title needs to be there, so we will leave that alone the same as description. And we don't have manager in this case, because that's going to be set through our PHP, and not JavaScript. And then comes our tasks. Well, we have a task type, is going to be a listOf, and we can't use our normal task here, instead we have to use our task input. And the reason is as I mentioned before, there's a distinct difference between input types. And then what we have been working with which are output types, and it's primarily that thing right there. So in our tasks what we want to use then is our input type for our task. So we're just going to call that task input and then as far as our users are concerned, since we are sending just integers we just have a list of integers. So we will get rid of using this graph type user and instead we will say type int. Now let me make sure this is for the project input and it is, okay. So that's basically it. What we have done now is we've defined a type that we can use, really from the client. Which you will see here in a moment, but let's focus then on our task input. So let's grab from our task type. Let's use that as the basis for our task input. So once again, we will change the namespace to Inputs. We will not need our task model in this case, as far as the attributes are concerned. Well, let's do TaskInput and we will change the name, we'll change the description, and we will get rid of the model because we don't need that. But just like the ProjectInput, we will need to set that protected InputObject to true and then comes the fields. Well, the ID, it's kinda like the project ID, if we are creating a new project then the tasks aren't going to have an ID. So there's no way that this can be not null. But if we are editing a project, then the task that's coming might or might not have an ID. So we're gonna say that to the ID could be null. Then there's the title, there's the description, there's the status code. Of course, all of that is normal, but we don't need project in this case, because remember that this is data coming in. We don't really care about the project because we already have the project information and this task data is just a part of that project. But when it comes to the user, well, we don't have all of the user information because we don't need it in this case, we just need the user ID. So we're going to change the user field to userId, and this is no longer set to any of our own types, but it is instead an integer. And then we no longer need this resolve status code field because the data that is coming from the client has status code. So, since we are inputting more complex data, and once again, let's look at that data. We have an object called a project and that's going to map to that project input, that we just created. It has a title, it has a description, it has a list of users, and has a list of tasks. And these tasks are going to map to the TaskInput type that we just created. The title, the descriptions, statusCode, userId, all of those things are part of just these normal task objects. And so if we had something that was a more complex data, like if we were needing more information about the users, we could create a user input type, and so on and so forth. So now, really, the only question is, how do we write our query? So let's go to our queries and we're going to add that saveProject query. And it's going to look like this, this is just another mutation. We're gonna call it SaveProject. And then we're gonna have a variable called project, but here's where the big difference is. Instead of saying that we have the title and we have the description and we have all of this other stuff, we are going to say that this is of type ProjectInput. Now it's very important, the casing here, well, we haven't named it, have we? No, we need to go to our config. Well, we will do that in a minute. But the casing here is an uppercase p, uppercase c. So it is Pascal Casing, and what we are actually going to do is we are going to define it as lower case p inside of our PHP. But that doesn't matter, it needs to be in with uppercase P. So let's go ahead and finish this. Then we will have a curly braces and then we will call the SaveProject mutation. We'll have an argument called project and we will pass the project to it. So just like that. So very quickly, let's go to our config for our GraphQL and we will add those types there. So these are just normal types or at least they are types that we would just normally put in our types which where are they? There they are and that's it. So we had ProjectsType and we had TaskType. These are in inputs and we had ProjectInput and TaskInput. So, in the next lesson, we are going to write the SaveProject mutation, to where we retrieve that information, or rather receive that information and then we save it in the database.