Skip to content

Review, define, and document RTKQ intended timing behavior and invariants #3801

Open
@markerikson

Description

@markerikson

I think one of our biggest issues atm is that we don't have actual documented specifications and intent for how RTKQ should behave with timing-related aspects. We've got code, and we've got a decent amount of tests, but there isn't anything written down that says "here's what we intend this to do".

Areas I'm thinking about:

  • Timing of queries, mutations, and invalidations
  • All the logic around returning promises from thunks and when those resolve
  • ????

I think we need to take some time to document the current behavior, and then discuss what we want to have happen.

It would probably help to write out a number of use cases (such as some of the ones described in #2203 and #3105 ), and decide at a high level how we'd want to handle them.

We should also review the cache lifecycles behavior as well, like how they don't run if there's a cache hit (and what might make sense in that case).

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions