Client-Side GraphQL in React

Apollo Directives

Scott Moss

Scott Moss

Superfilter AI
Client-Side GraphQL in React

Check out a free preview of the full Client-Side GraphQL in React course

The "Apollo Directives" Lesson is part of the full, Client-Side GraphQL in React course featured in this preview video. Here's what you'd learn in this lesson:

Scott describes the different directives that exist on the client side, namely `skip` and `include`. Experimental directives that need third party to function such as defer and live are mentioned.


Transcript from the "Apollo Directives" Lesson

>> Speaker 2: How many directives, I just mean for client records out of the box, how many other directives are out of the box?
>> Scott Moss: So the question was, how many other directors are out of the box? Depends on what you're using and it depends on what we're talking about.

Are we talking client side or are talking server side? Client side, out of the box, purely graph qL spec. There are a few directors that I could think of that definitely come to mind. There's going to be a, and this is client side, there's going to be a skip directive, there's going to be a include directive.

And these directors take arguments which allow you to say, you can basically say, I wanna skip this field if a certain variable, and when I'm talking variable, I'm literally talking variables, so you have to have variables, if a certain variable is passed or not. So I wanna skip this field if newPet is passed.

Or I wanna include this field if newPet is not passed, something like that. So I know skip and include does that. Those, I know, are in graphql. You also have things that are experimental and or have custom third party support, like defer. You have something called Live, and that's just for client side.

Server side, on a server schema, which looks very much like this type of schema, you might have something like deprecated, which basically will allow you to deprecate a field to let a developer know that this field is no longer needed. You can put a reason there, you can have something like reason, and you can put a reason here why it's deprecated.

And then that will show in graphql tools or grapql playground to let you know that this field is deprecated and you no longer need to use it. And the reason might be is because we use birthday instead, we don't use age anymore. And that's the type of scenario where people can get around from having to version their graphql schema, you don't have to make a new version.

Some people still do make versions, like version two, version three. But if you just do it that way, you just deprecate fields and add new fields, you never have to version your schema, nothing ever changes, you're still good to go and you're fine. That's the approach that I take.

As long as you got the resolvers and you deprecate it, people will stop using it, and then you can just add more. Other ones include out of the box. I can't think of any other ones, but I mean, one, they're not too difficult to make yourself, especially on the server side and two, there are tons of third party ones that you can use.

So I'm pretty sure there's a whole library that just gives you a bag full of directives. Where's that? There you go, a collection of custom directives. This one gives you tons of directives like camelCase, capitalize, kebabCase, lowerCase, trim, all this crazy stuff that you can do, let me show you an example of it.

So, like that.
>> Scott Moss: I think these are mostly all server site directives, and you can pass arguments up to them via inputs, via your queries, and stuff like that. But yeah, there's tons of them and people are now starting to really take advantage of directives. Before, it was really hard, you couldn't really do it, but frameworks like Apollo make it easy to make the directives now.

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