Selleo Labs spółka z o.o.

I have over eight years of professional experience as a Senior React.js and React Native accomplishing numerous international commercial projects. Recently, I became the Leader of a development team. My Team has in-depth experience in web and mobile projects focusing on Property and HR Management, Fintech and Online Payment Solutions.

Wojciech Bożek

[TOC]

Creating and supporting the **offline mode** varies depending on whether we are dealing with a mobile or a web app.
In the case of a web app, it is rather hard to fetch a page content from the server so this type of app will not open at all without a stable connection.
On the other hand, with a mobile application, we can store the entire code as well as the data (creating the app state based on this data).

We can distinguish two concepts here:

* keeping the data in the application
* optimistically apply actions to send requests to the server

## Redux Persist

For keeping the data stored in the application we can use **redux persist**, which during a process called ‘rehydration’ restores the last known content of the store.
The users can use and modify the store without the need to **fetch fresh data**, especially when the access to it is per-user only.

The second concept is optimistically applying actions, which send requests to our API. Since we are aware of how the application works and how the data should change we can replicate this logic and change the state of the application no matter if the request was fulfilled or not.

Here’s how it looks like:

```
const sendComment = ({ content }) => dispatch => {
 const tempId = _.uniqueId();
 dispatch({
   type: ADD_COMMENT_REQUEST,
   payload: { content, id: templId }
 });
 fetch(`mysuperawesomeAPI.pl/comments`, {
   method: "POST",
   headers: {
     Accept: "application/json",
     "Content-Type": "application/json"
   },
   body: JSON.stringify({
     content
   })
 })
   .then(payload =>
     dispatch({ type: ADD_COMMENT_SUCCESS, payload, tempId })
   )
   .catch(error =>
     dispatch({ type: ADD_COMMENT_FAILURE, tempId, error })
   );
};
```

and a reducer that will handle such action’s creator:

```
const comments = (state = [], action) => {
 switch (action.type) {
   case ADD_COMMENT_REQUEST:
     return [...state, payload];
   case ADD_COMMENT_SUCCESS:
     const tempIndex = _.findIndex(state, {
       id: action.tempId
     });
     return [
       _.slice(state, 0, tempIndex),
       action.payload,
       _.slice(state, tempIndex, state.length - 1)
     ];
   case ADD_COMMENT_FAILURE:
     const tempIndex = _.findIndex(state, {
       id: action.tempId
     });
     if (WE_WANT_TO_DELETE_ELEMENT) {
       return [
         _.slice(state, 0, tempIndex),
         _.slice(state, tempIndex, state.length - 1)
       ];
     }
     if (WE_WANT_TO_NOTIFY_USER_ABOUT_THIS_FACT) {
       return [
         _.slice(state, 0, tempIndex),
         { ...state[tempIndex], error: action.error },
         _.slice(state, tempIndex, state.length - 1)
       ];
     }
     return state;
   default:
     return state;
 }
};
```

## Redux optimist and Redux offline

So to optimistically apply actions means to **change the state of the store based on the available data performed with a request sent in the background**. A library helping to implement this way of managing actions is **redux-optimist**.

A library can restore the previous state of the store the minute the problems with requests occur. The actions should have an additional key ‘optimist’, in which we specify is it a BEGIN/COMMIT/REVERT of the transaction and a transactionID.

An efficiently working offline mode handling should also consider aspects like:

* an attempt to **resend the request** when getting an incorrect reply from the server (for example, timeout)
* **sending requests** only when we detect an internet connection or when our API is up
* **action queuing** - not letting the requests be asynchronous
* **persisting a queue** of actions between the relaunch of the app

**Redux offline** is a complete solution, which implements the above functionalities and additionally allows you to configure:

* **the time period** between requests send to the server when resending requests
* **the number** of failed requests before rollbacking
* **the library** for handling those requests (for example, axios)
* **queue** implementations
* **change** the configuration of **redux-persist**

Problems will have to face:

* usually the need to **rewrite actions and reducers** so they use redux-offline
* sometimes **implementation of business logic** in the front-end (predicting how the server data will change)
* **rollback handling** - we decide how the application will act when a rollback occurs
* **correct detection** of an internet / API connection
* the necessity to **use standard objects** in the action object - forget about callbacks

Using this implementation we can rewrite our action creator to look like this:

```
const addComment = content => dispatch => {
 const tempId = _.uniqueId();
 dispatch({
   type: ADD_COMMENT_REQUEST,
   payload: { content },
   meta: {
     offline: {
       // the network action to execute:
       effect: {
         url: "mysuperawesomeAPI.pl/comments",
         method: "POST",
         json: { content }
       },
       // action to dispatch when effect succeeds:
       commit: { type: ADD_COMMENT_SUCCESS, meta: { tempId } },
       // action to dispatch if network action fails permanently:
       rollback: { type: ADD_COMMENT_FAILURE, meta: { tempId } }
     }
   }
 });
};
```

Everything should work just fine with a basic **configuration of redux-offline**. The store implementation remains practically the same, we only need to change the way of pulling templd (now from the meta.templd key).

However, we need to remember that if the user is unable to open our page he will not be able to download the logic and therefore the website will not load. This is not the case in **ReactNative** where we have access to the application logic right after app open.

For keeping the data stored in the application we can use redux-persist, which during a process called ‘rehydration’ restores the last known content of the store.

CTOs

Founders

Read Our Blog.
Make better products with us.

Knowledge hub

Business

Technology

Explore our latest articles

ReactJS - Persisting State And Handling Offline With Redux

SaaS Founder Starter Academy