-
Notifications
You must be signed in to change notification settings - Fork 426
feat(ui): replace sync update with deferred promise pattern #7586
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: fredrik/user-4043-remove-clerk-state-contexts-from-provider-and-rely-on
Are you sure you want to change the base?
feat(ui): replace sync update with deferred promise pattern #7586
Conversation
Replace the flushSync call in BaseRouter's baseNavigate with a deferred promise pattern. This achieves the same guarantee (re-render completes before returning control to the caller) without the performance penalty of synchronously flushing React's update queue. The new approach stores the resolve function in state alongside the new route parts, and an effect resolves the promise after React commits the state update.
|
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
…ider-and-rely-on' into fix/remove-flushsync-baserouter
| setPendingNavigation({ | ||
| routeParts: { path: toURL.pathname, queryString: toURL.search }, | ||
| result: internalNavRes, | ||
| resolve, | ||
| }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens if several baseNavigate get's called before useEffect has a chance to run? I think only the last one would resolve and the others would hang?
Naively, I would append all pending to an array instead and resolve them all in the effect, but I'm not sure that's correct either. 🤔
Summary
Replaces the
flushSynccall inBaseRouter'sbaseNavigatewith a deferred promise pattern.Problem
The current implementation uses
flushSyncto guarantee the re-render happens before returning control to the caller. While this works,flushSynchas performance implications:Solution
Use a deferred promise pattern instead:
Benefits
flushSyncperformance penalty