Repository navigation
Conversation
|
Could you give a quick explanation for the switch from promises to async generators? I only quickly read the code, so maybe it should be obvious and I didn't see it. |
Hi @Sheraff The original To support global blocking state and functionality, there needs to be a blocking step in between, where the navigation is paused but not yet resolved. To allow "history" to fire some kind of block events — and expose the ability to resolve that same awaited promise globally (i.e. provide the There might be other ways to approach this, but I found async generators to be an effective solution for this case. |
|
@nizans thank you for this. looking at the discord discussion, it seems there are an item or two that you still want to add on to this PR, maybe we should mark this as draft until those have been added in? |
|
Thanks @nlynzaad I’ve just pushed a commit that adds the Quick explanation: |
|
View your CI Pipeline Execution ↗ for commit e8c83b359b200739461b41ca65dfe95b18008459 ☁️ Nx Cloud last updated this comment at |
0438630 to
990fcff
Compare
fix: standardize 'DISMISS_BLOCK' action naming in history module clean empty line proceedAll functionality and example global blocking
|
Thanks for the work on this. The global blocking use case can still be still useful, but the implementation is now far behind main and needs a fresh design around the current history and framework contracts. I’ve opened #7783 to track that work, including the browser-navigation and multi-blocker behavior. If you'd like to continue that work, it's welcomed! |
|
@LadyBluenotes thanks I reworked this around and created a new PR |
This PR introduces a global “blocker” state in and the callbacks needed to continue (
proceed) or cancel (reset) a blocked navigation globally, to be consumed directly from the router state.This enables controlling the blocking status out side the context of the
useBlockerthat was used to initiate the block.The per-route
useBlockerAPI remains unchanged—it now also updates the router-level state.Discussed previously here.
This change adds
BLOCKandDISMISS-BLOCKactions to the history notify function.where the
BLOCKaction holds a ref to the current awaited promise resolver thats currently blocking the navigation, which is then consumed through the router state.Why?
I needed a single, root-level modal that appears whenever any navigation is blocked (unsaved changes, etc.), instead of re-instantiating the modal wherever
useBlockeris used.I expected the router to expose some global blocking state, this PR attempts to provide this functionality.
A short example of the usage:
A runnable demo is available in examples/global-blocking-state.
Any feedback is appreciated!