#feature add support for fragment update

[krunaldodiya]

Hi, this is insane, almost alternative to Redux, Apollo client for GraphQL, but still I have used Apollo client a lot and there is a feature called updateFragment, so after mutation, yes we can Refetch Query and also can do Optimistic updates, but imagine a huge api backend with 100+ api endpoints and 20+ api has the same reference of may be user or post, then we have to update or refetch all api query after that mutation if we change user's name or post's title, but using fragment we can store normalized data collection

{users: {1: {name:"john do"}}, posts: {1: {title:"cool post"}}} 

and only updates that fragment which will be reactive

how about

type Post ={
  id: string;
  title: string;
  owner: User
}

type User = {
    id: string;
    name: string;
    posts: [Post]
}

cost [mutation, {data}] = useMutation('get_auth_user', async() => {
// async api function
}, {payload: User}) 

// user will pass payload to detect the structure of response

[tannerlinsley]

Trust me I’ve thought of this and actually designed a few proofs around it, but at the end of the day without a schema to know how and where normalization happens, normalizing data actually becomes near impossible to do automatically or at least is very cumbersome to the library api and users of it. I’ll keep this in mind, but for now I don’t think we’ll be exploring normalization in the core api yet. I’d love to keep discussion how you think this could happen though.
On Apr 18, 2020, 7:59 PM -0600, kunal dodiya notifications@github.com, wrote:

Hi, this is insane, almost alternative to Redux, Apollo client for GraphQL, but still I have used Apollo client a lot and there is a feature called updateFragment, so after mutation, yes we can Refetch Query and also can do Optimistic updates, but imagine a huge api backend with 100+ api endpoints and 20+ api has the same reference of may be user or post, then we have to update or refetch all api query after that mutation if we change user's name or post's title, but using fragment we can store normalized data collection
{users: {1: {name:"john do"}}, posts: {1: {title:"cool post"}}}
and only updates that fragment which will be reactive
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

[krunaldodiya]

I have built working prototype of this feature, may be you can have a look, not perfect but will give some idea

https://github.com/krunaldodiya/useApi

you can debug using built in react devtools

[tannerlinsley]

Yeah, this looks pretty good. Its' very very close to the proofs that I architected when exploring this idea. Maybe now that React Query is relatively polished, I'll go back and look at those proofs again.

[andrewluetgers]

Please revisit this, don't even care if its integrated with reactQuery directly or somehow separate but hooks into it. I have used a simple schema of id key and updated date key to do this in other contexts. Another interesting thing that can be done depending on api is to then only request changes after the updated id.

[tarikyildizci]

After doing a lot of REST stuff I needed to use graphQL for a project, and chose tanstack query because the DX doesn't come close with Relay or Apollo. But this is the only thing keeping the system from leveraging graphql's fragment system. Without something like refetchable fragments, I have to write separate queries, and then it just looks like a rest endpoint called /graphql. I can't imagine how you'd achieve refetchable fragments, but it would help a lot.