question: access to graphcache directly

we have currently implemented a way to getting normalized entities from our graphql queries using a mix or normalizr and @apollo/client readFragment however, we’d like to move to urql for our graphql client.

One major difference that Ive noticed is that readFragment is only available within the graphcache resolver and cannot be access directly (ie: inside a component) whereas apollo exposes client.readFragment directly

Following up on discussions from https://github.com/FormidableLabs/urql/issues/85 and https://github.com/FormidableLabs/urql/issues/317. is there a way to access the cache directly and/or use readFragment directly?

[kitten]

We’ve built-in warnings actually and mechanisms that are very tailored towards a normal query flow, which ensure things like commutative cache updates and consistent cache data towards server data. So to have an escape hatch would not only go against that but would probably require a new API layer and a bunch more code which pushes the bundle size.

We haven’t yet found a lot of use cases that require us to go down this road, especially since GraphQL schemas typically cater for the UI, i.e. direct fragment access should not be necessary if the Query has query fields for all individual types.

I’ll close this for now if that’s alright 😃 but happy to discuss this more in RFCs

[wuweiweiwu]

I see! we’ve briefly explored the fragment approach but failed to find a way to elegantly handle recursive graphql types but i think its worth another try. I agree that its an effective pattern that meshes well with component based ui architectures.

that totally makes sense! as the default document cache cannot unlock a first class fragment api

I wonder if its possible to expose the cache instance as a property somehow like __dangerousDontUseCacheInstance im also happy to contribute sometime to further #317

Thanks for the detailed response! much appreciated!