Is there a way to check whether a given object is a masked fragment (is of type FragmentOf<typeof someFragment>)

[dkokotov]

I have been slowly transitioning my codebase to use gql.tada, which has certainly improved the DX. In particular I've liked fragment masking approach a lot.

Previously I had a bunch of hand-written types for various entity shapes and react components which would accept those types. Because it takes a while to migrate all code to gql.tada approach, it would be nice to change some of those components to where they support passing in either a masked fragment or the hand-written type. This way the component can be used as-is both from new code that uses gql.tada and fragment-masking and old code that is still using raw graphql-request client and hand-written types.

Something like this:

interface Car {
   make: string;
   numDoors: number;
}

const carFragment = graphql(`
    fragment CarInfo on Entity {
        make
        numDoors
    }
`);

interface CarInfoProps {
    car: Car | FragmentOf<typeof carFragment>;
}

export const CarInfo = ({
    car: maybeCarData
}: CarInfoProps) => {
        const car = isFragment(maybeCarData)
           ? readFragment(carFragment, maybeCarData)
           : maybeCarData;
        return <div>{car.make}: {car.numWheels}</div>
}

I would like to be implement isFragment as a type guard function. Ideally it could be generic, but non-generic is also ok.

I could not figure out how to do it generically, but my non-generic attempt was:

function isFragment(
    data: Car | FragmentOf<typeof carFragment>
): data is FragmentOf<typeof carFragment> {
    return data.hasOwnProperty($tada.fragmentRefs);
}

This satisfied the type checker, but at runtime gave an error of Cannot read properties of undefined (reading 'fragmentRefs'). Looking at the code, I think $tada is only exported as a type, so maybe there is no way to get the actual underlying symbol?

Any suggestions?

I could potentially invert the check and test for properties of Car but that seemed less nice and would certainly make it more difficult to come up with a generic version of this.

Another possibility of course is to not do this and unmask the fragment in the parent component for new code. And I may do that, but I am now curious if the idea I had is doable.