-
Notifications
You must be signed in to change notification settings - Fork 962
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
Support asynchronous blocking #545
Comments
You can pass a custom
where you'd replace The If you need to pass a more complicated object inside My preferred async callback approach is to change the state inside the component that contains
where |
This seems to be an overly global solution to me... I need something more local, say, block transition for one page only. Moreover it could be UI-free thing, for example, do XHR and do not allow user to leave the page while this XHR is pending. |
The problem with a general async blocking function is that it doesn't work for the The current API needs to be reworked to accommodate both use cases:
|
@mjackson I see now from where it is all coming :) makes sense. I was solving first case, so maybe for that we can have separate Promise-based API? |
Any news about this? |
The proposed solution doesn't work? any work around this? |
You should not rely on |
It's really hard to implement asynchronous procedure that should delay navigation.
It would be great if blocker function could return
Promise
(if it's resolved navigation should proceed, if rejected — stopped) or afunction
that can accept an argument callback so thatcallback(true)
will resume nav.In this case
result
in https://github.com/ReactTraining/history/blob/master/modules/createTransitionManager.js#L26 treatment should be a bit different.Change is super small and should not break anything. I propose 2 options (I have made a pull request #546 with scenario 2 because it's more user friendly):
1. Less changes: use
getUserConfirmation
to handle string and any other object results2. More user friendly: handle
Promise
right there in transition confirmationI personally would prefer option 2 because in this case all handling can be done locally in component w/o need to configure extra
getUserConfirmation
in some other files:or
The text was updated successfully, but these errors were encountered: