Any plans on adding useFragment() hook and/or subscribing to a fragment change?

[dko-slapdash]

Hi.

There is useQuery(), but there is no useFragment() which would allow to watch some fragment in the cache and re-render accordingly.

• This hook useFragment is supported in Relay: https://github.com/relay-tools/relay-hooks/blob/master/useFragment.md
• Some people implement work-arounds to achieve the same using hacks with client-only resolvers: https://github.com/abhiaiyer91/apollo-fragment

An example use-case would be the following:

const UserFragment = gql`
  fragment UserFragment on User {
    id
    name
  }
`;

const userFragment = gql`
  query User($id: ID!) {
    viewer {
      user(id: $id) {
        ...UserFragment
      }
    }
  }
  ${UserFragment}
`;

function MyComponent({ id }) {
  // If the user is already somewhere in the cache (most likely it is!),
  // return its data immediately.
  const { data } = useFragment(UserFragment, id);
  // In case the user is not in the cache yet, query it explicitly by ID
  // from some parametrized field.
  useQuery(userFragment, { id });
  // Render the user's name fetched by useFragment.
  return <div>{data?.name}</div>;
  // Next time if the user's name changes in the cache, useFragment will
  // trigger re-rendering again.
}

[wgottschalk]

I think this would be really useful to help with data masking

[rajington]

could this be the same as (rough code):

const useFragment = (fragment, id) => useApolloClient().readFragment({ id, fragment })

?

[dminkovsky]

@rajington it's close except readFragment doesn't return an Observable so the result won't update when the store data changes.

[itdhsc]

Is there any solution to observe a fragment change in the cache?

[benjamn]

Here's our tracking issue for the implementation of useFragment in Apollo Client v3.5 (the next minor version).

Is there any solution to observe a fragment change in the cache?

To answer @itdhsc's question, yes, but useEffect complicates things, so it's better to keep the details hidden behind an abstraction like useFragment.

I should have a PR open soon using my useFragment-hook branch.

[danReynolds]

I was playing around with an implementation earlier this week here: NerdWalletOSS/apollo-cache-policies#33 for useFragment and a collection filter useFragmentWhere. If folks have feedback/suggestions feel free to take a look

[gen1lee]

Why not to add useEntity also?

const entity = useEntity(User:${id})

[danReynolds]

Why not to add useEntity also?

const entity = useEntity(User:${id})

I think because you still need to specify a fragment to indicate which fields you want to read. For performance it's inefficient to return all fields by default. Then if you need to pass a fragment anyways, you can just use useFragment.

[gen1lee]

@danReynolds for performance it is much more inefficient to map entity into fragment, I guess problem here could be with proper typing in typescript.

[danReynolds]

@danReynolds for performance it is much more inefficient to map entity into fragment, I guess problem here could be with proper typing in typescript.

I was thinking of performance related to the reactive changes. If you return the entire object, Apollo will think you're dependent on all of those fields so if any of them change, your component or other places where you're subscribed to that object will update.

The reactive part of Apollo client is built around invalidation based on field dependencies

[clayne11]

I am definitely very interested in this API at the apolloCache layer which is necessary for this to work at the React hook layer.

We have a bunch of cases (ie regulatory requirements) where we want to fire analytics / auditing events when entities change in the cache. This would be a super powerful pattern.

Either being able to watchFragment similar to watchQuery or something like this:

apollo.watchTypes({
  // __typename
  Trip: {
    onAdd: (trip) => {
      // ... do something
    },
    onUpdate: (oldTrip, newTrip) => {
      // ... do something
    },
    onDelete: (trip) => {
      // ... do something
    },
  }
})

[danReynolds]

I am definitely very interested in this API at the apolloCache layer which is necessary for this to work at the React hook layer.

We have a bunch of cases (ie regulatory requirements) where we want to fire analytics / auditing events when entities change in the cache. This would be a super powerful pattern.

Either being able to watchFragment similar to watchQuery or something like this:

apollo.watchTypes({

  // __typename

  Trip: {

    onAdd: (trip) => {

      // ... do something

    },

    onUpdate: (oldTrip, newTrip) => {

      // ... do something

    },

    onDelete: (trip) => {

      // ... do something

    },

  }

})

Yea that's what I made https://github.com/NerdWalletOSS/apollo-cache-policies for a while back initially.

[clayne11]

@danReynolds that looks interesting and solves some of my goals, but not all of them. Also would love to see this on native as well.