Profile picture of Josh Console

Senior Director of Engineering

Josh Console

One valuable feature of Apollo Client is 

 fields.  These fields are redacted from an operation that is sent to the server by an application, and then computed and added to the server response to generate the final result.  The 

 clearly explain how to leverage this feature for local state management, but it's less clear on how to derive 

 local-only fields solely from other fields on the operation result.

Suppose we have an operation that queries for the current user.

const USER_QUERY = gql`
  query User {
    user {
      id
      firstName
      lastName
      department {
        id
        name
      }
    }
  }
`;

We use the result of this operation in some 

 component to render a display name in the format of 

As time goes on, we find ourselves using this same 

 format in numerous places throughout our application, duplicating the same logic each time.

We consider how best to reuse this formatted name across our application.  Our first thought might be a server-side resolver, but this isn't always feasible.  We might want to make use of client-side data - local time, for example - or maybe our calculation will use fields from a variety of subgraphs that are difficult to federate between.  Our next thought is a React component, but this won't work very well either.  We want a consistent 

 for our displayName, but usage or styling might vary considerably depending on context.  What about a hook, then? Maybe a 

 hook that encapsulates the query and display logic?  Better, but inelegant: we'll probably find ourselves invoking both the 

 hook in the same components, over and over.  What we'd really like is not logic 

 from the query result, but rather logic 

The first requirement for a local-only field is a corresponding field policy with a 

 function in our cache. (Technically, a field policy could be omitted in favor of reading to and writing from the cache, but we'll save that for another post.)

const cache = new InMemoryCache({
  typePolicies: {
    User: {
      fields: {
        displayName: {
          read(_) {
            return null;  // We'll implement this soon
          }
        }
      }
    }
  }
});

 function is the existing field value, which will be undefined for local-only fields since by definition they do not yet exist.

The other requirement for a local-only field is to add it to the operation with the 

 directive.  This directs Apollo Client to strip the field from the server request and then restore it to the result, with the value computed by the 

const USER_QUERY = gql`
  query User {
    user {
      id
      firstName
      lastName
      displayName @client
      department {
        id
        name
      }
    }
  }
`;

 hook, but of course, it always returns null right now.  Our desired format requires three fields from the server response: the user 

, a helper provided by the second "options" argument of the 

 function.  This helper will provide the requested value (if it exists) from the parent object of the field by default, or from another object if it's included as the second argument.  This helper will also resolve normalized references, allowing us to conveniently nest 

 invocations.  Note that we can't really force the operation to include the fields on which the local-only field is dependent, and thus 

 always has the potential to return a value of undefined (even if it's a non-nullable field).

Now, it's trivial to use this formatted display name anywhere in our application - it's just another field on our query data!

const BlogPost = () => {
  const { data } = useQuery(USER_QUERY);

  return (
    <div>
      <BlogTitle />
      <p>Written by {data.displayName}</p>
      <BlogContent />
    </div>
  );
}

Bonus: Local-only fields with GraphQL Code Generation

It's trivial to include local-only fields if you're using 

, too.). All you need to do is extend the type to which you're adding the local-only field in your client-side schema file.

const typeDefs = gql`
  extend type User {
    # Don't forget to return a default value
    # in the event a field dependency is undefined
    # if the local-only field is non-nullable
    displayName: String!
  }
`;

Computing Apollo Client local-only fields purely from other operation fields.

Computed local-only fields in Apollo Client

A seemingly common complaint regarding NestJS and TypeScript is the absence of interfaces in runtime code (since interfaces are removed during transpilation). This limitation prevents the use of constructor-based dependency injection and instead necessitates use of the 

 decorator. That decorator requires us to associate some "real" JavaScript token with the interface to resolve the dependency - often just a string of the interface name:

/* IAnimal.ts */
export interface IAnimal {
  speak(): string;
}

/* animal.service.ts */
export class Dog implements IAnimal {
  speak() {
    return "Woof";
  }
}

/* animal.module.ts */
@Module({
  providers: [{
    provide: "IAnimal",
    useClass: Dog,
  }]
})
export class AnimalModule

/* client.ts */
export class Client {
  constructor(@Inject("IAnimal") private animal: IAnimal) {}

  // Later...
  this.animal.speak();
}

This approach is adequate, but the "IAnimal" magic string is a little fragile and not actually associated with the interface. A modest improvement can be made by exporting a token with the interface:

/* IAnimal.ts */
export interface IAnimal {
  speak(): string;
}

export const IAnimalToken = "IAnimal";
// or slightly better...
export const IAnimalToken = Symbol("IAnimal");

/* animal.module.ts */
@Module({
  providers: [{
    provide: IAnimalToken,
    useClass: Dog,
  }]
})
export class AnimalModule

/* client.ts */
export class Client {
  constructor(@Inject(IAnimalToken) private animal: IAnimal) {}

  // Later...
  this.animal.speak();
}

At least now the token reference is consistent. Still, manually injecting tokens like this can be cumbersome and conceptually unsatisfying. What we would really like is a true JavaScript object in the place of the interface, which we can reference universally at runtime. What we would really like is...an abstract class!

/* IAnimal.ts */
export abstract class IAnimal {
    abstract speak(): string;
}

/* animal.service.ts */
// You can implement an abstract class without extending it!
export class Dog implements IAnimal {
  speak() {
    return "Woof";
  }
}

/* animal.module.ts */
@Module({
  providers: [{
    provide: IAnimal,
    useClass: Dog,
  }]
})
export class AnimalModule

/* client.ts */
export class Client {
  constructor(private animal: IAnimal) {}

  // Later...
  this.animal.speak();
}

Now a single, "real" JavaScript reference is used throughout the application to resolve the dependency. Whether or not the minor inconvenience of token-based dependency injection justifies this usage of abstract classes is a separate question. If you're feeling lazy, though, this is a convenient option!

NestJS logo with a cat in the background

TypeScript interfaces don't have meaning at runtime so NestJS can't use them as tokens for DI. Learn how to use abstract classes to fill that gap.

Josh Console

Computed local-only fields in Apollo Client

NestJS Dependency Injection with Abstract Classes