Refactor query timeouts #917
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR refactors internals, specifically how
scheduleStaleTimeout
andscheduleGarbageCollection
works behind the scenes, but leaves the documented public API unaffected. An earlier version was begun in #728, but has been fleshed out here and made sense as it's own PR.The main goal is to remove scheduling of timeouts from the constructor of Query and instead let the consumer creating a new Query mark when timeouts are ready to be scheduled. This is needed to implement hydration, but will also make it easier to remove scheduling of timeouts from the render-phase in
useBaseQuery
as a next step.constructor
query.activateTimeouts()
buildQuery
. This is an undocumented API, so should be okay to change?activateTimeouts
updatedAt
is set to when the timeout is scheduled, which is a sync process). Docs makes no promises about exact details here so this should be fine since the meaning ofstaleTime
is preserved.All tests are passing, I'm open to suggestions for adding new ones if there is something we need to verify further.
I'm not sure about the naming of
activateTimeouts()
, it could also be a more genericinitialize()
that could contain any future side effects for setting up queries. It could also be justrescheduleTimeouts()
which would reflect that it actually schedules those timeouts and that it's is fine to use repeatedly, but that would loose the pretty important semantics that no timeouts will be scheduled until this function is called for the first time.This is just an undocumented internal name though and easy to change, where it's used now I think
activateTimeouts()
makes sense, but I'm very open to suggestions. 😄