Description:
In the current implementation, calling modal.resolve() is only possible before calling modal.hide(). This is because modal.hide() clears the internal promise array during its execution.
|
delete modalCallbacks[modalId]; |
However, when animations are involved, it’s often desirable to resolve() the modal’s promise after the hide animation has completed. This prevents potential conflicts or visual glitches that might occur if another animation is triggered immediately after the modal starts closing.
Example:
// modal component
const handleClose = () => {
modal.resolve();
modal.hide(); // modal animation started
}
// external call
modal.show().then(() => {
// another animation started in parallel
})
Possible Solution:
- Consider allowing
modal.resolve() to be called after modal.hide() without causing issues.
- Expose a new method, for example
modal.resolveHide(), to handle this use case
Expected behavior (mu5 for example):
// dialog props
{
open: modal.visible,
onClose: () => modal.hide().then(() => {
// resolve show
modal.resolve();
!modal.keepMounted && modal.remove();
}),
TransitionProps: {
onExited: () => {
// animation ended
modal.resolveHide();
},
},
};
};
// external call
modal.show().then(() => {
// another animation started
})
P/s: Am I missing something, and is this behavior already achievable in the current implementation?
Description:
In the current implementation, calling
modal.resolve()is only possible before callingmodal.hide(). This is becausemodal.hide()clears the internal promise array during its execution.nice-modal-react/src/index.tsx
Line 265 in 69050f8
However, when animations are involved, it’s often desirable to resolve() the modal’s promise after the hide animation has completed. This prevents potential conflicts or visual glitches that might occur if another animation is triggered immediately after the modal starts closing.
Example:
Possible Solution:
modal.resolve()to be called aftermodal.hide()without causing issues.modal.resolveHide(), to handle this use caseExpected behavior (mu5 for example):
P/s: Am I missing something, and is this behavior already achievable in the current implementation?