feat(editor): Pre-fetch classified roads as soon as we have a USRN #5942
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Removed vultr server and associated DNS entries |
DafyddLlyr
commented
Dec 19, 2025
| queryFn: () => getClassifiedRoads(usrn), | ||
| enabled: shouldFetchRoads, | ||
| refetchOnWindowFocus: false, | ||
| staleTime: Infinity, |
Contributor
Author
There was a problem hiding this comment.
staleTime as well as the queryKey must match for there to be a cache hit.
Infinity in this context seems appropriate - it just means "don't refetch for this key (USRN) again this browser session". If a user refreshes, or does a save and return, it will refetch.
jessicamcinchak
approved these changes
Jan 7, 2026
Member
jessicamcinchak
left a comment
jessicamcinchak
left a comment
There was a problem hiding this comment.
Simple and so effective, great work !
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
What does this PR do?
Once an applicant has a USRN, prefetch the
/roadsrequest in the background. This will result in less overall wait time for an applicant, as the (often long-running) request is running quietly in the background whilst they navigate throughPropertyInformationandDrawBoundary.Context
This is one of the very nice benefits of the switch to TanstackQuery!
As this request can take ~25s (e.g. https://api.editor.planx.dev/roads?usrn=20499403), even if they only spend a few seconds each on the
PropertyInformationandDrawBoundarycomponents this is still less time spent waiting at a loading screen.Why not also do this for the Planning Data query?
We certainly could, but the complexity to reward ratio here is a little off here in my opinion.
Most requests to planning data take ~400ms which is pretty quick - this is our max time saving possible. The point as which we can prefetch can also be much later as we need the
siteBoundaryfor this. For all "happy paths" (where a user accepts a title boundary) we can prefetch at the same spot. The complexity here though is that unhappy paths will invalidate the prefetched query - if the user amend their geom, the request will re-fire anyway once they reach planning constraints.Having said this though, it could be nice to have Planning Constraints be basically instant...! 🪄
To test...
FindProperty, search address/roads?...query can be seen as startedPlanningConstraints/roads?...query is not retriggered, but information is still displayed from prior query ✅Screen.Recording.2025-12-19.at.13.34.25.mov