Cache Exchange with React

[alexnsorensen]

I'm sure this has been asked to death, so here it comes again.
I'm new to Urql (loving it heaps), but I have a question about the Urql cache, in regards to react.

If I have a schema like this:

type ClassUnit {
  id: UUID!
  location: Location!
  name: String!
  paymentMethods: [ClassUnitPaymentMethod!]!
  sessions: [Session!]!
}
type Query {
  classUnit(id: UUID!): ClassUnit!
  classUnits: [ClassUnit!]!
}

If I perform a query like so:

const ListClasses = gql`
  query listMyClasses {
    classUnits {
      id
      location {
        id
        name
      }
    }
}`;
const [classQuery] = useQuery({
  query: Queries.ListClasses,
});

Then in a sub component I have this:

const GetClass = gql`
  query getClass {
    classUnit {
      id
      name
      location {
        id
        name
      }
      sessions {
        id
        dayOfWeek
      }
    }
}`;
const [getClassQuery] = useQuery({
  query: Queries.GetClass,
});

Is it possible in that sub component to do this: return <>{getClassQuery.data.classUnit.location.name}</>; even though the query is still fetching because the list has already loaded the data?

I had a read through the documentation and it looks possible, unless I've completely misunderstood it...

I also tried this:

const myCacheExchange = cacheExchange({
	schema: introspectedSchema,
	resolvers: {
		Query: {
			classUnits: (_, args) => {
				return { __typename: 'ClassUnit', id: args.id };
			},
			classUnit: (_, args) => {
				return { __typename: 'ClassUnit', id: args.id };
			},
		},
	},
});

That doesn't seem to do it however.

Anyway, thanks in advance.

[kitten]

The resolvers is indeed the first step to start with. In the above example however please do note that classUnits is not defined correctly in all likelihood. You've written a resolver that returns the shape of a single entity for what's likely supposed to be a list, which will probably just fail.

The other resolver: classUnit: (_, args) => ({ __typename: 'ClassUnit', id: args.id }) looks just fine.

even though the query is still fetching because the list has already loaded the data?

The important thing to note here is that the two queries' selections won't match. And that's quite a common problem.
There's an important two important concepts to understand here first though, nullability and partial cache results.

When a field is nullable and you use Schema Awareness, it understands that some fields can be left out, just like in error cascading on the API side. This allows fields to be set to null instead of a query not being read from the cache, which creates a partial cache result.

However, in your schema sessions: [Session!]! is not a nullable field. It requires that the list is defined. So, coming back to the selections not matching. When you're going from your list screen (listMyClasses above) to your details screen (getClass above), ClassUnit.sessions is an additional selection.
An additional selection means that once we read this new query from the cache, it'll be missing. However, even with schema awareness, the sessions field has a non-nullable type, so there's no partial result that can be legally generated.

This is mentioned in the docs:

Lastly; a schema contains information on which fields are optional or required. When Graphcache has a schema it knows optional fields that may be left out, and it'll be able to generate "partial results".

What I'd recommend today though, which isn't clear because we haven't updated the documentation in a while (and it does require a large restructure potentially), is that schema awareness isn't necessarily needed in for partial cache results.

That's because you can also use @_required and @_optional for client-controlled nullability: https://commerce.nearform.com/open-source/urql/docs/graphcache/local-directives/#client-controlled-nullability

The @_optional directive on sessions would allow you to tell the cache that you wish to leave this field out of your selection, making it null, if it's not cached. That's a much quicker and intuitive way to trigger partial results.

Do note though that since the field isn't nullable, if you're generating/deriving TypeScript types for your queries, you may want to make sure you're using a tool that understands @_optional and sets that field to be a nullable type.

The alternative way though, if you want to continue using Schema Awareness instead, is to make sessions optional.

[kitten]

Also small side-note on nullability in GraphQL, since that's a topic that's often misunderstood, and I can see you've got a schema that marks basically all of the example fields as non-null.

There's two huge reasons why nullability by default in GraphQL is a thing, which Schema Awareness kind of "exploits":

• Forward Compatibility
• Error Cascading

Forward Compatibility is a nice property in GraphQL, since we don't use versioning with it usually. When a field is nullable, you've got an option to deprecate it and remove its resolver in the future. Since it's nullable, you can guarantee that any client consuming it may not receive a result. If you then go to replace/remove the field, you can always do so safely, knowing that the clients have to expect null. This is great for scenarios where you don't know who's consuming your schema.

Error Cascading is a feature in GraphQL, which allows errors on resolvers to cascade upwards to the first nullable parent field, delivering a partial result from your API when a field cannot be set. This means that an API response is resilient to failure, and you can display partial results/errors even if part of your API is experiencing issues. While this may seem pointless if all data are is coming from the same database, it makes sense to delineate some boundaries by default for lists, for example, where we go from sets of data of one type to another, since errors are isolated at that point.

This is great for Schema Awareness too, since it automatically can exploit this for its null-cascades, when data is missing.