Spinner stuck if combined with an alert.
cristianoccazinsp opened this issue · comments
Spinner/modal getting stuck is still an issue that happens more often than one would want. The timeout fix is really not appropriate if you are showing the spinner automatically through redux state changes, or from other components.
On the react native side, they claim to have this issue fixed already.
I wonder if this line is the culprit. Completely removing the modal component before the UI/Native has time to dismiss it might be causing issues?
https://github.com/joinspontaneous/react-native-loading-spinner-overlay/blob/master/index.js#L139
Otherwise, any other ideas on how to fix/improve this? I'm even considering adding random delays to the modal dismiss call, but that's definitely ugly as hell.
Did you try removing/changing what happens with L139? Let me know if you fixed it and we can get it patched here. Feel free to submit PR.
That didn't work, neither some other stuff I have tried. However, the culprit is really the cancelable flag: https://github.com/joinspontaneous/react-native-loading-spinner-overlay/blob/master/index.js#L111
IOS can't seem to render properly an alert and modal at the same time, so when the new alert fires, the request close method of the modal is also fired. Not handling this close request pretty much makes the modal stuck, but handling it will close the modal defeating its purpose.
My question is, in what other cases does IOS fire the request close event? Not like IOS has a back button? Can we just close and re-open the modal if it's not cancelable? This would only be for iOS ofc.
Tried something like this, it seemed to have worked at first, but it didn't. I can't tell if the issue happens less often with it, of if it makes no difference at all.
_handleOnRequestClose() {
if (this.props.cancelable) {
this.close();
}
else if(IS_IOS){
this.close();
setTimeout(()=> {
this.setState({visible: true});
}, 10);
}
}
Will do more testing later.
Update: Nope, it's not this neither... Sigh.
Same problem here
Isn't this cause by classic "view is not in the window hierarchy" ios error? If you open up the xcode you can see the warning;)
Well, I'm quite sure it must not be the best way but my workaround for now is wrapping the showAlert in a setTimeout of 500 so it gives the right amount of time to close the spinner in order to open the alert... if any of you find a more "right" way to fix it we all appreciate.. cheers
Yesterday I tried out wrapping up MBProgressHUD (https://github.com/jdg/MBProgressHUD) with a react native bridge so that I can use within react native view. So far seems working fine with Alert component without colliding. I will post a gist or sample code once I have tested with more devices.
Technically you can or you can use MBProgressHUD version for Android too, which is awesome. Those modules are pretty popular!. Here is a sample implementation and works perfectly well with Alerts and also look and feel is super neat.
Here is a sample implementation. I will create a node module soon...
https://gist.github.com/samithaf/83efbc7b6d86448d0e4e426c68b29985
Got the same issue, have to do the workaround as tattivitorino's comment. Hope this will be fixed soon
Same issue here. But it only stucks on iOS.
Well, I'm quite sure it must not be the best way but my workaround for now is wrapping the showAlert in a setTimeout of 500 so it gives the right amount of time to close the spinner in order to open the alert... if any of you find a more "right" way to fix it we all appreciate.. cheers
And this works well. Thanks @tattivitorino, Hope some fix to this issue.
Same issue when using with react-native-root-toast
RN is super buggy and I stopped using it, something native as you mentioned (MBProgressHUD) would probably do the trick