This comes up often when working on a React Native app that uses push notifications to notify of data changes in the backend. Say your app has lots of different screens to display information retrieved on-demand from a backend database. The app also receives periodic push notifications to alert it that something on the backend has changed. When a notification is received, the app may need to refresh the data displayed on the screen depending on which screen is being shown and what data is affected.
I have not found an effective way to do this through state changes. The basic conundrum is separation of concerns. The background notification handler should only be concerned about processing the incoming notifications and doing any required mapping of notification data for consumption by the app. The data management layer (using redux actions and reducers) should only be concerned about how to retrieve and store data as instructed by the screens that need it. The screens should only be concerned about what data needs to be retrieved and how to display it.
When a push notification is received, a decision needs to be made about what data needs to be refreshed. That decision usually depends on which screen is being shown. Which screen is being shown is something the push notification handler and data management layers shouldn't be concerned about.
Yes, you could update state with information about each received notification and let the active screen handle it, but then you have to add logic to every screen to check that state and clear it so it doesn't linger. The far simpler way to handle this is for the push notifications handler to simply publish an event that such and such data has changed, and then screens subscribe to the events with which they are concerned and take the appropriate action.
Is this approach frowned upon by React Native "purists"?
question from:
https://stackoverflow.com/questions/65921900/is-using-custom-app-events-in-react-native-frowned-upon 与恶龙缠斗过久,自身亦成为恶龙；凝视深渊过久,深渊将回以凝视…
