Possible Unhandled Promise Rejection
SteffeyDev opened this issue · 7 comments
After debugging my app for a while, I tracked down this warning:
"Possible Unhandled Promise Rejection (id: x):" (x increments)
to this line:
firestack.database.ref('events').orderByChild('ministryID').equalTo(i.toString()).on('value', this.handleEventUpdate.bind(this));
The code functions ok, but the warning makes me nervous. I know that the warning is not triggered in handleEventUpdate, but something about this line causes the error and I don't know how to catch the error and print it out. Any ideas?
I have the same problem and my code works only when I mount the component for the first time. If I navigate elsewhere and then come back, I get the "Possible Unhandled Promise Rejection" and nothing will load from the database.
Anybody has an idea on what can cause this ?
I think I'm starting to understand what's happening. A long as I navigate through my app via react-native-router-flux, componentWillUnmount is never called, so I cant turn off Firebase's listener, so, somehow, something is considering it doesn't have to do the fetching (or the rendering ?) job again.
If I just "close" the component with Actions.pop(), then componentWillUnmount is called, then I can do itemsRef.off('value'), then turn it on again on the next call, then it works fine. My problem is that my navigation is not compatible with that process.
A work around can be to call this.itemsRef.once('value') on componentWillMount, then this.itemsRef.on('value') on componentDidMount. It might be the normal way to proceed although I have an ugly feeling about this because in the end the listener is never removed.
A cleaner way is to use {type: 'replace'} or {type: 'reset'} (if you dont care about history / the android backbutton etc.) in RNRF - i.e Actions.whateverroute({type: 'replace'}). The default visual effect is ugly but you get what you want : componentWillUnmount is called and then you can have itemsRef.off('value') fired at will.
Seems the OP was looking for something like the ES6 construct to trap promise failures? The ".then().catch()" construct reliably solves yellowbox warnings on promise objects (on iOS iPhone simulator anyway).
Firestack source code shows "promisify". Runtime promise objects might mean we need to trap a promise failure. I'm guessing this is when we cannot insure our request returns with a response (?). Something like:
firestack.database.ref('events') .then((eventRef) => { eventRef.orderByChild('ministryID').equalTo(i.toString()).on('value', this.handleEventUpdate.bind(this)) } .catch((err) => { alert('Error: listenForAuth event failed.', err) });
Thanks for the responses, @nearodney do you know that promises like that work or are you just guessing? can't tell from your response. I've moved to just calling .once but that is obviously not ideal, I may try this again when I get the change. @philohelp I'm not using any sort of router so so honestly not quite sure what you're talking about, and hoping that it doesn't apply to me. I know the views I'm using aren't unmounting until the application closes.
Also, I didn't specify in the original question, but the main reason that the errors were bothering me is because after I made that call for the first time, even if no events in the database were changed, that warning would come up about once every second, so after a few minutes running my code I would have a few hundred warnings, and no idea what was running once a second that would through that.
I'm experiencing this warning as well. Not sure what's causing it. I'll post back if I discover the issue.
Does anyone know if this repo is still being maintained?
@SteffeyDev Looks like mine a is different issue. I usually do console.disableYellowBox = true; until I fond the solution.
@philohelp - were you able to solve this issue ? I am running into exact same issue as you described above. :(