electric-sql / electric-sql/pglite

[Discussion] `useLiveQuery` with cached results.

Open
#545 1 comment 0 reactions 0 assignees View on GitHub
enhancement question
Dominant language
TypeScript
Stars
16k
Forks
442
Avg merge
20h 19m
Merged PRs (30d)
7

Description

Building a little bit on https://github.com/electric-sql/pglite/issues/544, I propose an optional mechanism for `useLiveQuery` to re-use the previous query results when re-rendering a component.

My use case was as follows:

- two screens in an app
- the first screen loads some listings using a live query
- navigate to the second screen
- navigate back to the first

Even with a small query, if I use the IDB filesystem, I get a noticeable flash of missing content -> content when I navigate back to the first screen. Because useLiveQuery always starts `undefined` and then async populates the results.

What I'd like is, in this type of circumstance, is to be able to say "hey, live query, cache the query results and use the latest cache as the default when rendering". This way, the user sees content immediately when navigating back to the page.

There may be downsides when the content underneath the live query has changed, such as listings jumping around. But this can be mitigated by (1) being an optional mechanism or (2) possibly considering ways to invalidate the cache on changes.

I imagine that this could be implemented using an option, such as `{cacheResults: true}`. Or it could possibly be a special value for `default` if using option syntax to implement #544, such as `{default: live.CACHE}`.

***

I guess the other approach here is to be able to keep the liveQuery going behind the component lifecycle.

I.e.: instead of teardown on unmount, somehow mark the query as having a ttl in the background and then using the same instance of a live query when re-rendering with the same key. This could provide the best of both worlds, in that results are instant and uptodate when navigating back.

Perhaps we would need a `queryKey` or perhaps we can dedupe by the actual query string and params anyway? Perhaps we would need an `unMountedTTL` or something? If we found a way, it would perhaps be similar to the idea that shape subscriptions go on in the background unless explicitly stopped.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.