Advanced GraphQL, v2

Custom Directives Arguments

Scott Moss

Scott Moss

Superfilter AI
Advanced GraphQL, v2

Check out a free preview of the full Advanced GraphQL, v2 course

The "Custom Directives Arguments" Lesson is part of the full, Advanced GraphQL, v2 course featured in this preview video. Here's what you'd learn in this lesson:

Scott explains that directives can take in arguments. Arguments explain why a directive was added to the schema. In the case of the log directive, the argument sends a message to the user when the user logs in. Directives with log arguments lead to cleaner code.


Transcript from the "Custom Directives Arguments" Lesson

>> If you are to declare multiple instances of this lock and exist on like I wanna say type definition is one maybe,done with all these. So we say type definition, then you would have to come in here and say well, this is what happens when you visit a field definition.

Well, this is what happens when you visit a Type visited type definition. And you will have to make a function for that. So for every single entity or every single node that you can visit on your directive, you'd have to make a function for it. So you can do multiple for one directive.

The other thing is, you can take in arguments on your directives. Just like the deprecated on taken arguments, we can have log taking elements to. So we can say, okay, log takes in, I don't know, a message, and its type is a string. And little known fact about GraphQL, you can use the equals sign in arguments to set a default.

Like that, that's a default. If any input on any argument you can make a default by setting an equal sign like that. It's only a default message and then if I want to get a reference to that argument, all I have to do is I say message equals this.args.

Now your reference to these arguments here. So now you have those arguments. You can do whatever you want with them. This is really cool because now you can come out here and say, cool. I need a message here. And I want to call it, ID here or something like that.

Start this, I didn't even log it because I should log it, Message, like that, Run that. And there you go. You get your message that you pass it as an argument. All right, one last thing I will show you on the rectus. And then you're going to make some.

So this is cool because you can add arguments on your schema level. But what if you wanted to query to pass up arguments to the directors? This is where it gets complicated. So if you want that to happen, then what you need to do is you need to modify your fields RX array in to do a field RX push and need to push in a new argument here.

And the way that this works is basically you have to give it a type of and is the same thing as like creating arguments down here. So you have to give it a type, and you have to give it a name. And you can push those arguments up like that.

So if I say I want a new type, and I want it to be a string, then what you can do is you can go to GraphQL. You can get a GraphQL string type. QL, stream type like that. They say the type is graph qL string. You can give it a name and we can call this one.

I don't know, message called the same thing like that. And now you get this message and there's arguments. And what you can do is now that argument, is not going to be available to the client to pass in an argument for that field, and it's going to be accessible here.

I need to spread that that's why that wasn't working. So the arguments gonna be available inside of here, but because I'm using this is a spread, I got to write them all out. So this is like the route value. This would be the arguments here. In this case, I only wanna get the message.

So I'll say, give me the message. And then everything else is the rest of the stuff. The rest of the arguments is the context. Here's the info. So I'll do that. I'm going to change this to call now. I'm not using an array, and I'm going to past rest, Or I'm sorry, routes, rest context and info to my original resolver.

And now you should have access through this message right here. You should have access to whatever the user passed up, and by default, you can have this method. So basically you will do like some type of, check your message is either going to be whatever they passed up to me, or it's gonna be whatever I defaulted here as message which could be obviously this.args.

So it could be let's say message equals this.args but now you got two messages. I'm gonna rename this one to schema message. There you go. So you can log either the message they sent you or you can do the schema message that you supply by default. All right, so if we tried this, stop this thing.

All right, and if we go here, if I refresh this you can see it tells me I have a message argument now. See that I get autocomplete for a message argument and have that before. So I can say cool. Yeah, I want that message argument. Hello. Cool. That looks good.

And if you go back to our output, it logged the one that I put up. Hello. If I change that to, Yoda and I run that log the one this is Yoda. If I don't say anything it should send it should log the default one that I had on the server, which I forgot what it was.

But let's see what happens, Id here. [BLANK AUDIO]

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