[lewisl9029]

I really like the simplicity of the core library and this approach of starting from a simple core and building on top of it with the same primitive for extensibility as the one you offer to users.

Apollo has also been moving in this direction with composable links, but in a zig-zaggy way since it's still got some baggage from its days as a monolithic library, and recent decisions to move local state management into core seems to be backtracking from that effort somewhat, so it's great to see some competition in this area that really approaches extensibility as a first class citizen rather than an afterthought.

With that said, I'd love to see an officially supported normalizing cache implementation as well, in addition to the simple document cache Urql currently provides as a default:

https://formidable.com/open-source/urql/docs/basics/#code-cl...

Apollo and Relay's normalizing cache helps ensure a single source of truth for every piece of server data, which is incredibly valuable for non-trivial apps that have the same pieces of data fetched in multiple places that would otherwise have to be manually kept in sync, which anyone who has ever tried to do so can tell you is generally extremely tedious, error prone, and likely a frequent contributor to user-facing bugs. That to me is by far the most compelling value prop of GraphQL clients like Apollo and Relay. It'd be great if I didn't have to choose between automatic normalization and a more flexible extensibility model (fwiw, I'd choose the former).

[philplckthun]

Cheers! I'm happy to say that a normalising cache is indeed in progress and we're planning to finish it soon https://github.com/kitten/urql exchange-graphcache

We've got the cache itself done but are just figuring out the API for its customisability in terms of cache resolvers and such