cache entry lifecycle: api experiments

[phryneas]

as a follow-up to #215, some different experiments on how an API could look like & be used, asking for feedback.

final PR will be against RTK repo

[codesandbox-ci[bot]]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit cdc1cacca6cd42a7b2bdd12c66540ac11c7d5d33:

Sandbox	Source
React	Configuration
React Typescript	Configuration
rtk-query-demo	Configuration
svelte-app-rtk-simplequery-demo	Configuration

[github-actions[bot]]

size-limit report 📦

Path	Size
ESM full	10.55 KB (+2.41% 🔺)
ESM full (React)	11.94 KB (+2.14% 🔺)
createApi + setupListeners	9.57 KB (+2.68% 🔺)
createApi (React) + setupListeners	10.84 KB (+2.37% 🔺)
fetchBaseQuery	701 B (0%)
retry	278 B (0%)
ApiProvider	400 B (0%)
CJS minfied	16.1 KB (+1.73% 🔺)
CJS React minfied	17.78 KB (+1.51% 🔺)

[netlify[bot]]

Deploy preview for rtk-query-docs ready!

Built with commit cdc1cacca6cd42a7b2bdd12c66540ac11c7d5d33

https://deploy-preview-223--rtk-query-docs.netlify.app

[phryneas]

Quoting myself from chat to add to a potential open discussion here:

Personally I think #3 is quite nice because it gives you the control to delay it a bit and wait for actual values from the first request to be in the store before updating a "pending" request. Otoh, #1 could also just add more lifecycles and #2 could just trigger later for the same result.

3 is a bit risky if the firstValueResolved promise never resolves. We could cancel it by throwing, but what if nobody listened for it? Might be a memory leak :thinking:

Or we just .catch on the promise returned by cacheEntryAdded3 itself and dispose of any rejected firstValueResolved that way while re-throwing the rest

So, kinda still a fan of #3

[phryneas]

This is on the integration branch right now, closing it here.