.webp)
Introduction
Having worked with React for a while, I am currently building a medium-sized React Native application in my free time, simply to try out the platform and because I truly love building mobile apps with minimum effort. Mobile apps require you to cover things that may be easily overlooked if you are even a bit careless.
One of the expectations is that some users may use your application in offline mode. How does your app behave when a user is traveling on a plane (airplane mode) or the underground (no signal)? Does it show an infinite loader? Can the user still use the app seamlessly?
Having an offline first-class citizen app is very important for a great user experience. You may have heard about (or used) NetInfo module, which comes shipped in with React Native and provides a handful of methods to get the network connection status on the device. The API is pretty basic and it may be sufficient for small apps but its usage gets cumbersome as your app grows.
When that happens, you’ll find yourself repeating code in the two following scenarios:
- Inside Component’s render: rendering one thing or another depending on whether I have internet connection or not
- Inside your business logic: grabbing connection state and conditionally fetching data
Besides that, NetInfo presents another downside. Its API allows you to detect network connectivity, but it does not guarantee you can exchange data with a remote server even though it reports you are connected. This scenario could occur inside an airport where there are a lot of available networks that you could connect to, though forcing you to go through an extra step (like filling a form) in order to gain internet access.
As I was trying to find a more compact solution to this problem, react-native-offline was born. I’ll elaborate on the different parts of the library in the context of the app I was building.
Components utilities
There are occasions when you would want to hide or change content on the screen depending on whether there is internet connection or not. Let’s analyze a couple of examples based on an events app.
Let’s say we would like to know all the events for a particular day. If there is no internet connection, we will instead show to the user a text message stating we are in offline mode. In this case, the library provides you with a Higher Order Component utility that passes the connection state down as a prop. You’d use it the following way:
Let’s think now of a slightly different scenario. Imagine an events detail page where you can rsvp and also check the event location through a map. In case of a lack of connection and assuming we are persisting our data, the user should still be able to check event details, but we’d like to tweak the screen content a bit by preventing the user from performing network dependent actions.
In this case, our goal is to disable the rsvp buttons, hide the map (assuming we have a service to get the geolocation coordinates based on the address) and, in addition, show a SnackBar at the bottom to inform the user that some of the functionalities on that screen may be disabled.
If we wanna keep the rendering of the screen in one file, a Higher Order Component won’t work. In such a case the library provides a function as a child component (a.k.a. rendering callback) as a convenience.
You should take into account that since <rte-code>ConnectivityRenderer<rte-code> gives you this power at render time, you typically can’t optimize them using <rte-code>shouldComponentUpdate<rte-code> without hindering your composition ability, so it’s recommended to use it on leaf components in your tree.
Redux integration
For medium and large apps redux is by far the current de facto solution for managing your application state. The library provides a nice integration, by offering three features that leverage offline capabilities in your redux store: a reducer, a middleware and an offline queue system. You can use all of them or just the ones that suits your needs.
Reducer
It allows you to centralize the connection status in your redux store. Basically it supplies a network reducer that listens to internal actions dispatched when the connection status changes. The configuration is pretty straightforward.
Middleware
Before diving in, let me provide you with a bit of context. In my application I chose redux-saga as the library for managing side effects and network calls and I got to the point where I had around 20 sagas with the following pattern:
Do you see the repetitive parts? It boils down to grabbing the connection state, the if/else structure for fetching data and dispatching a specific action to handle the offline situation. I live with DRY in mind, so that was annoying me. How could we get rid of that repetition? You guessed it, redux middleware to the rescue.
Redux middleware is the game changer that allows you to place code that sits in between your dispatched actions and the moment they reach the reducer. It’s the perfect place to anticipate the loss of connection and prevent the action from going through the reducer. That way, we have that logic defined in one place only and can clean up a bit our side effects code.
The API exposes a function, createNetworkMiddleware, that returns a redux middleware which you can later apply using applyMiddleware utility from redux:
All parameters are optional and, by default, it will look at your fetch actions types following the redux convention, but you can either provide your own regular expressions and/or any additional action types involving a network call that you are interested to observe. To do that you can use the actionTypesparameter and set it to, for example, AUTHORISE_USER or RELOAD_LIST.
For thunks, the configuration differs. First, you need to make sure of using a named function declaration instead of an anonymous arrow function. Lastly, set interceptInOffline property to true in your thunk as you can see in the below example:
If we attempt to fetch internet resources and happen to be offline, the middleware will stop and prevent the action from going through the rest of the middleware chain, dispatching instead an action of type @@network-connectivity/FETCH_OFFLINE_MODE whose payload contains useful information about “what you attempted to do”.
With this middleware applied to redux, the previous saga would result in:
Isn’t that neat? :) Now you just have to import that action type from the library and listen to it inside your reducers.
Worth saying that the same reduction of code would apply to libraries such as redux-observable or redux-thunk.
Offline queue
Last but not least, the middleware interoperates with an offline queue in order to keep track of actions that failed to be dispatched due to the lack of connection. There are two possible configurations:
- Retry an action
- Dismiss an action from the queue based on a different action dispatched
To enable queuing in your redux actions you need to use the <rte-code>meta<rte-code> property, which provides <rte-code>retry<rte-code> and <rte-code>dismiss<rte-code> options.
If you set <rte-code>retry: true<rte-code>, the action will be added to the queue and will be automatically re-dispatched when the connection is back again.
However, there are cases where the action queued is no longer relevant. One scenario is navigation actions that involve replacing the entire screen content. For that, the <rte-code>dismiss<rte-code> option is quite handy and you can use it to provide an array of action types that, in case of being dispatched, will dismiss and remove the queued action.
Detecting internet access
We stated before that <rte-code>NetInfo<rte-code> carried the limitation of being only able to detect network connectivity, lacking a way to determine whether we have internet access or not.
To solve that problem, the library takes a step further and covers the ground by pinging a remote server using a http HEAD request, in order to make sure the new connection state is not a false positive. By default, it’s configured to ping google.com with a timeout of 3 seconds, but you can customise both remote server and timeout as you wish. Those parameters can be passed to component utilities and your redux store.
Wrapping up
It’s been a pleasant journey to shape up my first open source library and I am happy to see that other people use it in their projects too. Following the best practices, the library has also almost 100% test coverage in the business logic and is fully typed with Flow. The README.md contains all the instructions to set up the library, full API documentation and some useful examples.
Go ahead, check react-native-offline on GitHub, give it a try, and let me know your thoughts by leaving a comment or opening up issues. PRs are also welcome!
If you liked this article, please recommend it to others. Also, discover services offered by our React Native development company.
