Open agrosner opened 2 years ago
Does this mean that we'll be receiving data by using toFlow()
and not execute()
as it'll start returning 2 responses by quering just once ?
@naveenfunk yes that would make sense and is already the case when using CacheAndNetwork
with the normalized cache
Thanks. when are you guys planning on taking this feature request or should i check Normalized cache for achieving this
I'd certainly like to cache the previous output and still reach out for the latest - this way the UI can reactively update if the data changes in any meaningful way.
behaviour ?
@naveenfunk the normalized cache already has CacheAndNetwork
so it may fit your immediate need already. Compared to an http cache, it also has the advantage of data deduplication and the ability to observe data changes (i.e. use it as the source of truth), at the cost of a higher cpu footprint.
@BoD One more question. I tried NETWORK_FIRST http cache policy and it doesn't seems to get cached data when i turn internet connection off. the app never gets callback from apollo lib and the app stucks on loading state.
Hi @naveenfunk, this should work. One thing I can think of is sometimes it takes a while before the network stack is seen as offline (I've noticed it in particular with the emulator). In any case if you can reproduce it systematically, mind opening a specific ticket with more details? Thanks!
Thanks @BoD . It works better in real device. If needed will surely create a ticket. Thanks a lot man
Use case To replicate the convenient functionality of using the normalized cache, the
HttpCache
should also support this option. Currently, it only supportsCacheFirst
, orNetworkFirst
, which means we only ever receive one response, if its in the cache.Currently, what this means, is if, we use
HttpCache
without a timeout specified, the cache never expires. It never hits the network again after it receives the initial response, unless I set an explicit timeout. I'd certainly like to cache the previous output and still reach out for the latest - this way the UI can reactively update if the data changes in any meaningful way.A workaround is to send two queries - 1 for initial cache, then a second one with cache disabled on that request.
Describe the solution you'd like
Ideally, using
watch()
on our queries, we could receive multiple results. 1 for cache (if it exists), then 1 for the network (if we have a network connection).Add the
CacheAndNetwork
option to theHttpFetchPolicy
. Optionally, merge the two enums so they are both equally supported in each cache type.