React and React Native pattern for handling server responses - reactjs

Question

In the past I did lots of native mobile development on both Android (Java) and iOS (ObjC and Swift). For my server-connected apps, one issue that I had to handle properly was the callback that was called after the app made an HTTP request. For example, suppose I have a screen (an Activity in Android or a ViewController in iOS), and inside that I make an HTTP request to a REST server, expecting some data in response. Most textbooks (unfortunately) provide examples of the HTTP response calling a callback method within the Activity or ViewController itself. Yes it seems reasonable at first glance but there is a big problem in apps with multiple Activities or ViewControllers - what happens if the user navigates away from the screen after the request but before the response comes back? In this case, the app destroys the memory of the first Activity or ViewController, so when the response comes back, it tries to call a method on freed memory, resulting in a crash.
What we had to instead was to use a persistent singleton object (like a class that extends Application in Android or use the appdelegate in iOS) as the class that implemented the callback functions. Any screen that wanted to get results had to register for those results (using listeners in Android or using notifications in iOS). If the user navigated away from the screen, the screen's appropriate lifecycle methods would unregister the listener/notification handler in the screen so that there would never be a case where a callback method is called on freed memory.
Now I am starting to use both React (in browsers) and React Native (in mobile apps). I am using the Axios module for handling HTTP requests. Once again, all the examples I see show callbacks in the React component itself rather than any kind of pattern where there is some sort of persistent singleton or global object that handles the responses and dispatches them to any screens that are still active on the display.
So I have several questions as follows:
For React (in a browser), is this a concern? Can/should I just provide a callback on the component itself, and the browser will not have a problem if I navigate away from the screen mid-request? I suspect browser code is pretty robust these days so I doubt it would crash the browser but would it cause any issues with the webapp?
What about React Native? Since this is basically built on top of mobile native code, will I run into this memory crashing problem if I put the callback in the component itself?
If this is a problem, is there a good pattern to use for a central global persistent object to handle callbacks and dispatch the results to any registered components?
Note that I won't be using redux in my code - instead I plan to use a simpler framework (hookstate, hookstate.js.org) that lets me keep track of global state and use it inside components when updated. This seems sortof like a callback system for global state but it isn't quite clear to me the best pattern for incorporating HTTP requests through modules like Axios into it.
Suggestions?

Answer 1

The answer will probably depend heavily on how you are doing state management within your application. However, assuming you are using a version of React Native that supports hooks, something like this might be a useful pattern to get started:
import React, {useState, useEffect} from 'react'
import axios, {CancelToken} from 'axios'
const MyComponent = () => {
const [blah, setBlah] = useState(null)
useEffect(() => {
//Axios comes with support for cancelling. See here
//https://github.com/axios/axios#cancellation
const source = CancelToken.source();
let source = null
axios.get('/some/url', {cancelToken: source.token})
.then(({data}) => {
//If the request is successful, we know the component wasn't unmounted.
//Go ahead and call the state-modifying function.
setBlah(data)
})
.catch((thown) => {
//If something goes wrong, check to see if it is because of a cancel.
//If it is, we probalby don't need to do anything.
if (axios.isCancel(thrown)) {
console.log("Cancelled")
}
else {
//Otherwise, we can handle the error gracefully
}
})
//If you return a function from setEffect, it will be
//executed when the component is about to unmount (componentWillUnmount)
//See https://reactjs.org/docs/hooks-effect.html#example-using-hooks-1
return () => source.cancel()
}, []) //This will only run once (the first time the component renders)
return <pre>{blah}</pre>
}
Essentially, we are using useEffect to trigger the request via Axios. We then utilize Axios' built-in cancel functionality (https://github.com/axios/axios#cancellation). We call the cancel function when the component is unmounted. As a result, the then clause of the axios request won't execute. In this particular case, it doesn't really matter; we are using state internal to the component, so there would be no effect of setBlah running after unmount. However, if say you were using Redux for global state, or some other reducer pattern, it is possible that your then clause would trigger some external action even after unmount.
So, to answer the question of "does it matter"? The answer is, "It depends". If you can keep your state local to the component that issues the request, perhaps not. If, like you allude to, you plan to have some global state and expose ways to modify that state (Redux, or a context that exposes a reducer), then it certainly could. A pattern like this should avoid ever calling the state-modifying function in the event your component is unmounted.
Caveat - I haven't tested this code. Most of it is derived from the links I provided, which hopefully should provide any additional context necessary (or corrections if I got an implementation detail wrong).