Support for exchange-graph

[mgrip]

Would be great if, when using the normalized exchange graph cache, the devtools reflected the normalized cache (ie showing the resources in cache, key'd by id). Not sure if this would be work done as part of this repo or the exchange graph project (I'm guessing this would be quite a bit of work), but figured I'd open this for discussion at least

[sofiapoh]

You would already be able to see if a field was served from the cache (including the normalized cache) in the devtools inside the Explorer view. I know it also shows results beyond what's in the cache and it was a deliberate choice as with urql's exchange architecture anyone could write their own cache and we wanted something that works beyond our normalized one.

A filter to highlight fields that are results from the cache might be nice though! I'll give this a bit more thought.

[mgrip]

A filter like what you're describing would be super helpful! Thanks for the response @sofiapoh, excited to see how this develops. Have been really happy w/ the dev experience of urql in general so far 🎉

[disbelief]

As a new urql user coming from the Apollo ecosystem, this is a major missing piece in the urql system. I relied heavily on the cache inspection tab of the Apollo dev tools, particularly for making sure my custom mutation updaters worked as expected, and also just to help debug the state of my application. From my perspective this would be a super useful and worthwhile feature to support!

[andyrichardson]

@disbelief are you able to give us more info on your use case?

The current steps required to see the state of the cache would be something like:

• Go to explorer pane
• Look for a query that returns the expected datatype
• Expand the query to find the specific data

All the functionality of a normalized representation should be here - but it would be useful to understand use cases where (correct me if I'm wrong) it sounds like it's hard to find a particular cache entry.

[disbelief]

@andyrichardson coming from the apollo world, their devtools permit you to view and search the entire normalized cache. So for example if there's a specific "User" that is reused across multiple queries/fragments, there is one canonical version of that object stored in the cache, to be referenced everywhere it's in use.

From what I can see in the urql devtools, you're only able to view specific queries that have been cached. Perhaps this is a misunderstanding on my part, or a difference between the caching behaviour between the two libraries?

[andyrichardson]

there is one canonical version of that object stored in the cache

Yup our graphcache works in a similar fashion - but that's just one of our caching implementations.

Our default cache, for example, is much more naive and instead caches by request and refetches queries when invalidation takes place.

you're only able to view specific queries that have been cached

No specificity that I'm aware of - maybe that's a bug? All queries should be present in the cache explorer.

If you can provide a user journey similar to my example above (see bullet points) that would massively help me understand what use case there is where a particular data entry needs to be inspected in the cache explorer, but the source query is not known.