React: [react-cache] [Question] Feedback and stale-while-revalidate strategy

[nulladdict]

First of all, I am aware that react-cache package is highly experimental and unstable, but I still would like to experiment and express my thoughts on the subject. (skip to the end for the actual question)

I've tried using it in several fun projects, and in my experience current version works pretty well with anything static, e.g. resources that need to be loaded only once, or can be loaded once and updated separately.

However, not all resources are like that, and some of them need cache invalidation. This https://github.com/facebook/react/issues/14783#issuecomment-461860954 mentions that there is no API for invalidation, but you can actually invalidate the resource, using the clever hash function. I've put together a little demo.

The problem with that approach is that invalidations happens "soundly" and will trigger the suspense.

This could be solved by busting the cache only after the preload of the next entry already happened, but there's unfortunately no way to track the preload state of the next entry, since the preload method actually doesn't return the promise it called;

Another way to go around this issue is to have a side effect inside the async resource, that would cause a re-render when completed, thus giving the ability to invalidate the old entry only after the new entry has been completed;

Lastly there’s the ability to create a invalidation method, wrapping a read method in a try-catch block and have custom logic of resolving with a result / awaiting a suspender. This however makes the invalidation async, but it's probably fine, since we only need to invalidate the cache after we already have the initial result and can update the result when the invalidation has already happened.

Since the first approach is basically impossible with current cache package and later two required a lot of custom logic, one would probably be better of writing an entirely custom suspender and cache provider with a required strategy.

Sorry for the long read, thus comes the question:

TLDR: Is react-cache being developed and presented as a low-level API for writing custom resource caching logic OR as an example of writing custom suspenders and cache strategies?

[sibelius]

Cannot read property 'readContext' of undefined when moving to react 16.8.6

anyway to fix this?

[threepointone]

react-cache was an experiment to play with some new ideas, and was never meant to be feature complete (or used in production). In the months since we've released it, we've learnt a lot by developing Suspense and Concurrent mode further, and internal usage has exposed more patterns and constraints for this problem space. As such, react-cache has outlived it's usefulness (for now!). We'll have a lot more to say in the near future, but you can be certain that this is very much top-of-mind for us, and will continue to be the focus for the foreseeable future.

Closing this, thanks for your question.