Phil Pluckthun

I'm currently not _super_ inclined to say that this is worth the added internal complexity 😅 It may lead to some confusion across all of our APIs (what doesn't and...

This is currently expected behaviour. The problem is that SSR and Offline storages aren't easily reconcilable. The reason for that being that persistence for Graphcache must typically be asynchronous while...

@oreqizer its unfortunately not that simple. The SSR logic is decoupled and there's a possible mismatch between what your storage has and what the SSR queries deliver. For all of...

There's an important distinction between expected behaviour and unexpected behaviour here though. A loading loop would be unexpected. However, a delay is expected on startup with the `offlineExchange` because it...

I've been thinking about this a little and there is in fact a way to solve this. Hence, I'm writing up a small RFC here to detail on how this...

We probably don't want to always accept promises and also allow for synchronous calls so this can be used in front of a cache exchange as well 🤔 Other than...

Yea, if you always use `fromPromise` then it's very likely that you'll at least introduce a micro-tick delay when calling `Promise.resolve` which means that the result won't ever be available...

There'll be no side effects of it's right in front of the `fetchExchange` admittedly, but I'm more thinking of people who'd like to use it in front of the `cacheExchange`....

cc @JoviDeCroock: As discussed, this now uses `wonka@^6.0.0` which is so far 100% backwards compatible but ported to TypeScript to make external contributions easier and further reduce its bundle size...

I think that'd require us to make the assumption that only one tab is "active" at a time, which isn't necessarily the case with multiple windows, background tasks, timers, etc...