Warning! Documentation is faulty leading to hard to track bugs (onRegister not always called)

Bug

Documentation states

DO NOT USE .configure() INSIDE A COMPONENT

but that’s wrong, you need to do exactly the opposite and you should NOT use configure in root or import the file that runs configure in root! Explanation is below. It seems to work in debug mode and first runs in release mode but sometimes it fails in release mode for consequent runs of the app! I assume when you call .configure the native part connects to the store and gets the token - this happens pretty slow in debug mode and first run thatswhy it’s usually not a problem, meanwhile you can attach your callbacks (onRegister) and it will work. But for consequent runs and in production mode this process runs very fast and the callbacks are called BEFORE you can attach them. Obviously we need to send the token to the backend to be able to push messages to the user from our backend. If you want to send the token to the backend you need your api be ready so you would probably have your onRegister function attached in useEffect/componentDidMount. But if configure is in your root or imported to index.js or App.js and runs immediately it might return and the callback fires BEFORE you attached your onRegister callback. This means you won’t get the token your onRegister is undefined at the time being. This happened in our production apps. Usually it works and it’s hard to track, the problem arises when a user signs out of the app we remove the token from the backend (don’t want to send notifications for a user who signed out). Next time the user opens the app, .configure runs too fast and we don’t get the token. The user logs in and he won’t receive notifications he has no token. The solution is to place .configure in notifservice.js (if you check the example). As PushNotification.configure({ … and call new NotifService(onRegister, onNotif); from your App.js in useEffect or componentDidMount or useEffect dependent on your user logged in this way the registration (and asking for permissions) will only happen when your user is logged in. Tested both on ios and android this works well but doing it like in the example and documentation causes problems! I assume the original library did always launch immediately in the background thatswhy it was needed to place .configure in the root to have it initiated before the native part returns with the token. But I experienced that it’s not a problem to call .configure later. In our current version we call .configure only after a user has logged in and it works both on android & ios the token is always returned correctly. Sorry for the long & tangled description but wanted to let you know what I found right away - there might be others facing the same problem and don’t know what to do.

Environment info

Library version: 8.1.1

Steps To Reproduce

1. Do everything exactly as the documentation tells or use the example.

Describe what you expected to happen:

1. PushNotification.configure should launch only when my app & api is initiated and not in the root

Reproducible sample code

See the documentation and example

[levepic]

I have to correct myself: if you follow the guidelines AND attach your listeners as you naturally and usually do in react (in useffect/componentdidmount) it will lead to the above very hard to track bug. I closely followed the example actually copied it, if you look at it this.notif = new NotifService is placed in the constructor of App. The only change I made I placed new NotifService in useEffect which is an obvious step in react. No matter I used the example and used .configure outside of any component it’s still wrong! That small change leads to the bug which you won’t recognize unless you use the app in production with many users unsubscribing/subsciring again with a token. I think the documentation should warn that you CAN NOT attach your listeners as you usually do in useEffect. The problem is it seems obvious to do so and it works 100% until consequent runs in production when you usually won’t need the token and not recognize the bug.

[levepic]

That makes sense! Thank you for your feedback and clairifing this! I think it would be important to have a warning of this because looking at the only example it seems to be the recommended way and converting the old class component of the example (which probably noone uses for a new code nowadays) to the current functional component raises this very nasty bug.