How to make a reactive local resolver for an interface?

[negezor]

I have a local handler that I use to unify components that use the same interface. Previously in Apollo I could just read fragments from the cache over the interface, but in urql I need to make a specifically local resolver to fetch this data from the cache (I don't see any other reasonable way). The interface itself and how it is used:

type Deploy {
    subjectId: ID!
    status: DeployStatus!
}

interface Deployable {
    deploy: Deploy
}

type Task implements Deployable {
    id: ID!
    # ...
}

type Runner implements Deployable {
    id: ID!
    # ...
}

Then I get this on the client for the local resolver

extend type Query {
    deployable(subjectId: ID!): Deploy
}

import { Cache, cacheExchange } from '@urql/exchange-graphcache';

const resolveTypenameByNodeId = (cache: Cache, subjectId: string): string => {
    return cache.resolve({
        id: subjectId,
        __typename: 'Task',
    }, '__typename')
    || cache.resolve({
        id: subjectId,
        __typename: 'Runner',
    }, '__typename');
};

const cache = cacheExchange({
    // ...
    resolvers: {
        Query: {
            deployable: (_, args, cache) => {
                const subjectType = resolveTypenameByNodeId(cache, args.subjectId);

                return cache.resolve({
                    id: args.subjectId,
                    __typename: subjectType,
                }, 'deploy') as string;
            },
        }
    }
});

If the deploy property in the parent is not null everything is reactively updated, even if you put null and then update the data. However, if the property is initially in parent null the data will not be updated reactively.

# If we have data

task {
    id: "subjectId",
    deploy: {
        subjectId: "subjectId",
        status: "DEPLOYED"
    }
}

deployable(subjectId: "subjectId") => {
    subjectId: "subjectId",
    status: "DEPLOYED"
}

updateTask(subjectId: "subjectId")

task {
    id: "subjectId",
    deploy: {
        entityId: "subjectId"
        status: "PENDING"
    }
}

deployable(subjectId: "subjectId") => {
    subjectId: "subjectId",
    status: "PENDING"
}

# If we haven't data

task {
    id: "subjectId",
    deploy: null
}

deployable(subjectId: "subjectId") => null

updateTask(subjectId: "subjectId")

task {
    id: "subjectId",
    deploy: {
        entityId: "subjectId"
        status: "PENDING"
    }
}

deployable(subjectId: "subjectId") => null

All this worked before the 4 major version of urql. Maybe I'm doing something wrong? Is there any way to simplify it? I didn't find the right answer in the documentation.

[JoviDeCroock]

Hmm I wonder if this is because urql isn't adding a dependency when __typename is being requested, it might be worth testing whether it works if you do i.e.

const resolveTypenameByNodeId = (cache: Cache, subjectId: string): string => {
    // Quick resolves to validate our assumption
    cache.resolve({
            id: subjectId,
        __typename: 'Task',
    }, 'id')
    cache.resolve({
            id: subjectId,
        __typename: 'Runner',
    }, 'id')
    return cache.resolve({
        id: subjectId,
        __typename: 'Task',
    }, '__typename')
    || cache.resolve({
        id: subjectId,
        __typename: 'Runner',
    }, '__typename');
};

if so we might need to investigate that condition to see if it can be removed or bypassed.

[negezor]

Maybe I can somehow invalidate the deployable() data so that it returns new data accurately? Because it all worked before the major version of urql v4 was released.

[JoviDeCroock]

The issue with pointing at urqlv4 is that this is a graphCache issue so it doesn't have anything to do with your urql version 😅 I think at this point we need a reproduction in codesandbox or similar

[kitten]

Just to point out something that previously wasn't clear from the code samples you posted, if you return null, the value of the field will literally resolve to be null and you'll never see a cache miss & API request

If you know it shouldn't be null, return undefined instead so that it'll be a cache miss when the value is missing.

We're also soon going to enable resolve to return undefined when a value isn't cached — for now it's not that straightforward to differentiate.

But tl;dr if you have no other query that doesn't use this field to fetch this entity, then you need to allow cache misses by returning undefined instead of null as needed, to tell Graphcache when your resolver has not found a value

[negezor]

Returning undefined instead of null really made the value reactive. Thanks! However, this broke two things in SSR

• The await useQuery() query waits indefinitely. Okay, this can be fixed by removing await.
• If the value of the deploy property is null after reloading with SSR, it is not reactive. However, in some places it remains reactive (the UI component is identical for all cases, it's just in different places)

[kitten]

If the value of the deploy property is null after reloading with SSR, it is not reactive.

This will be the case if you only access __typename. For example, if you were to access deploy on your Deployable then the Deployable becomes a “cache dependency” of the query. However, __typename currently doesn't do the same, and you may have to access another field (like id).

That's basically what @JoviDeCroock pointed out above.
This is silly and we'll remove it.

But you can still get into this case if you access deploy, and the entity that this field points to updates without your field updating (i.e. if you've got deploy: null and a subsequent query only updates the entity that this points to, there's no dependency on the prior query)

However, the resolver basically looks good to me, so I couldn't tell you why you don't get an update after SSR if the above isn't the case.
Additionally, I'm not sure why await useQuery() — I assume you're using Vue? — wouldn't resolve, but that's hard for me to debug without having a reproduction.

Is deploy: null a legal value and you're maybe now always causing a cache miss during SSR? This shouldn't stall await useQuery(...) in practice, but it would cause data: null to be issued.