Dino Stančić

Creating API calls can make a real mess in applications, so we came up with a solution to simplify that problem. In this tutorial, you can find out how we created our solution using Axios for React applications. 

Easier API calls with a wrapper around Axios - Prototyped

Keep reading and discover how did we come up with a solution that can simplify
that problem. 

The most common way to create requests from the frontend application is to use
Axios. As per official Axios documentation [https://axios-http.com/docs/intro],
Axios is a promise-based [https://javascript.info/promise-basics] HTTP Client
for node.js [https://nodejs.org/en/] and the browser. On the server side, it
uses the native node.jshttp module, while on the client (browser) it uses
XMLHttpRequests.

> Axios is straightforward to use, but creating API calls can become messy if you
repeat configuration across multiple files.
We encountered this issue in one of our projects, where API calls had become
complicated and bloated our code. To address this, we created a class-based
wrapper around Axios. This centralized the configuration to a single file,
cleaning up our code. It also standardized how API requests are made, improving
consistency. 

By the end, we had developed a reusable solution that can simplify API calls for
any project, regardless of framework. Keep reading to learn more about our Axios
wrapper and how it streamlined API requests.

Using Axios
Using Axios in a React application is fairly easy. To use it, you just need to
import it, and you’re already set.

import React, { useState, useEffect } from 'react';
import axios from "axios";

const RandomUserName: React.FC = () => {
  const [user, setUser] = useState()

	async function getRandomUser() {
	  try {
	    const data = await axios.get("/api/users/random_user");
	    setUser(data)
	  } catch(err) {
	    console.log("error: ", err);
	  }
	}

  useEffect(getRandomUser, []);

  if (!user || !user.name) return null;

  return <p>{user.name}</p>
}



As you can see in my simplified example, it’s fairly easy to use. Only, if we
were to use it in a real-world application, things could get a bit more
complicated.

Not in a way that it’s complicated to use Axios itself, but the way to configure
it and to keep it consistent for each use. Especially in some big applications
where we have an API call on every page a user visits.

import React from 'react';
import axios from "axios";
import { FormProvider, useForm } from 'react-hook-form';

const CreateRandomUserForm: React.FC = () => {
  const form = useForm<User>();
  
	async function createRandomUser(randomUser: User) {
	  try {
	    await axios.post("/api/users/random_user", randomUser, {
        baseUrl: '<https://some-base-url>',
        beforeRedirect: someBeforeRedirectFunction,
				headers: {
          'Content-Type': 'application/json',
          Authorization: `some token`,
        },
				... // you get the point
			});
	  } catch(err) {
	    console.log("error: ", err);
	  }
	}

  return (
  	<FormProvider {...form}>
		<form onSubmit={form.handleSubmit(createRandomUser)}>
			<UserFormInputs />
		</form>
	</FormProvider>
  );
}


In this “complicated” example, you can see that we’ve added a configuration. Now
imagine if you have more files with API calls that need to add that type of
configuration + some interceptors.

Nonetheless, our code can become bloated if configured incorrectly.

React-wise, we can create a shared hook that’s creating an instance of the Axios
client and then configure it to keep it consistent for every API request. That’s
something similar we’ve come up with.

Our Axios client
In one of the applications we were developing, API calls had become complicated
and bloated our code due to the initial setup. We noticed this issue and wanted
to refactor the code. We developed a class-based solution for making API calls
that can now be reused across most projects, regardless of the framework.

> This led us to create axios-http-client which is also straightforward to
implement. 
You simply define a shareable class, add any necessary configuration, and then
you can reuse it throughout your project. For example:

// http.ts
import { HttpClient, HttpClientConstructor, HttpClientAxiosConfig } from 'axios-http-wrapper';

// Type it for autocomplete.
const httpClientConstructor: HttpClientConstructor = {
  baseUrl: '<http://some.api.url>',
}

const config: HttpClientAxiosConfig<BaseModel> = {
  headers: {
    accept: 'application/json',
  };
}

// HttpClient class can have some BaseModel passed as a generic.
export const MyHttpClient extends HttpClient<BaseModel> {
  constructor(private endpoint?: string) {
    super({
      baseUrl: '<http://some.api.url>',
      endpoint: this.endpoint,
    }, config);

    // If you need to configure some axios interceptors, you can also do this here.
    this.client.interceptors.response.use(
      (response) => response,
      (error) => error,
    );
  }
}


More examples of how to use it can be found on our GitHub repo
[https://github.com/prototypdigital/axios-http-client] or our npm repo
[https://www.npmjs.com/package/axios-http-wrapper]. In this documentation, you
can also find a simplified way to use it in a React application as a hook.

There were two main reasons we created axios-http-client:

 * We wanted to simplify how API requests were created in order to clean up the
   code and make it easier to understand. 
 * We aimed to make API requests more consistent and less prone to errors by
   standardizing the process across the project.

Axios interceptors were left intact so if you need to have some custom logic
before sending a request, or getting a response, you can customize it as you
want. Also, if you have a custom error handling, you can add that logic here.

Conclusion
When setting up API calls, it's easy for the code to become messy and
disorganized if the process is not properly standardized. While this may not be
a major issue for small applications, it can significantly complicate
development on larger projects.

Our axios-http-client aims to address this by providing a simple and reusable
way to make API requests. Feel free to try it out on your next project and let
us know your thoughts. If you have any other questions or run into issues,
please check our GitHub repository
[https://github.com/prototypdigital/axios-http-client].

I'd like to thank our CTO Vlatko Vlahek, who initially suggested developing a
client to simplify API calls. Thanks also to colleague Marko Mrkonjić for
demonstrating how to create a reusable hook for making requests in React
applications. We appreciate the contributions that helped shape this library.

Thank you for your the time to read this blog! Feel free to share your thoughts
about this topic and drop us an email at hello@prototyp.digital
[/detecting-network-state-with-javascript/hello@prototyp.digital].

Development

Streamlining APIs using an Axios Client

In this article, you can learn how to implement the offline status feature and see examples in applications.  

Detecting network state with Javascript - Prototyped



From time to time our devices tend to lose connection to the network due to
numerous reasons. Those issues can range from our Internet service provider
dropping the connection, to us being out of network reach which ultimately
results in the user being offline, even for a brief moment. This could cause a
very bad experience for the user if they don’t understand the network status,
such as requests not showing the desired data, form submitting not doing
anything, loader spinning indefinitely. 

Better UX
While online or offline state detection might seem like a futile or pointless
feature, we think it’s a great user experience where our user knows what’s going
on with their application and in this case, what’s going on with their
connection because there are certain scenarios where users could lose some of
their work.

With applications like Google Docs, there’s a risk that users can’t save a
document they were working on or maybe some important part of that document
without their knowledge and it’s always a good idea to let the users know that
there’s a risk of losing their work. So Google Docs have a nice feature to let
the users know that they’ve lost their internet connection.

Spotify also does a great job of telling its users that they’ve lost their
connection. Since losing an internet connection while listening to some music
won’t result in losing important data like writing some document would, it would
certainly contribute to some bad user experience if users don’t know what has
happened and why is their music not playing. As seen from the image, Spotify
shows a notification near your name with a message about what has happened.

Our application, Propoze [https://propoze.app/], also has network detection.
With Propoze, users can create proposals that they can save as drafts or send to
the clients. Writing proposals takes a considerable amount of time and we didn’t
want our users to lose their work due to network connection issues. A simple
solution we came up with for this kind of problem is that we’re letting our
users know that they have lost their connection and that their changes could be
lost. As seen in the image below we’re showing a toast message that their
settings will be saved next time they come online.

Javascript Navigator attribute
Javascript has implemented a Navigator object that can be retrieved using the 
window.navigator property. The Navigator object has a lot of properties
implemented. Most of the properties are read-only and most are used for checking
different states of the user agent. For example, we can check if a user has
enabled their cookies by checking window.navigator.cookieEnabled property. We
can also detect users' geolocation by checking window.navigator.geolocation 
property.

The property we’re checking for this use case is window.navigator.onLine. With
this property, we’re detecting network changes for our user. Although 
navigator.onLine [https://caniuse.com/online-status] is compatible with all
browsers, this feature behaves differently on some browsers. For Chrome, Safari,
and Firefox, the offline state is detected when the browser can’t connect to a
local area network or a router. In Internet Explorer switching the browser to
offline mode is detected as the offline state.

If you’re using virtualization software you should pay attention to this state
since there’s a risk of getting false positives because some virtualization
software has virtual ethernet adapters that are always “connected”.

Network status listener
One way of detecting a network state is by checking a state of an object in the
simple example below.

// returns true if online, false if offline
const online = window.navigator.onLine;

if (online) {
  console.log("Online :D");
} else {
  console.log("Offline :(");
}


The other way to go is by listening for the events on window.ononline
[https://developer.mozilla.org/en-US/docs/Web/API/Document/ononline] and 
window.onoffline
[https://developer.mozilla.org/en-US/docs/Web/API/Document/onoffline]. They both
fire on window.navigator.onLine state change. window.ononline returns true if
the browser is online and window.onoffline returns true if the browser is
offline. You can do this also by attaching an addEventListener to the window 
object. I found this approach to be more straightforward so I’ve been using it
more.

window.addEventListener("online", () => {
  console.log("Online :D");
});

window.addEventListener("offline", () => {
  console.log("Offline :(");
});


If you need to detect the initial network state you should use
window.navigator.onLine. But if you require to listen for changes in the network
state, you should attach a listener as in the second example.

For this purpose, I’ve created a simple CodePen example in which I’ve
implemented both examples I’ve talked about

You can play with this example and see how it works and maybe implement it in
your next project.


Conclusion

There are several ways of handling users' network state that all represent a
great user experience. Furthermore, a lot of top-tier applications are
mitigating the connection loss so users don’t even seem to notice that their
connection has been lost. At least, some of them just notify their users about
connection problems.

So, if you’re implementing a feature in your application and there is a
possibility of users losing their progress, such as filling in long forms, or
creating and editing some data, that needs to be handled. If that’s the case, I
would recommend implementing this feature of detecting their network state with
the help of a Navigator object and acknowledging them that they could lose their
progress. However this is implemented, it will surely give users a tiny bit of a
better user experience while using your application.


> Thank you for your the time to read this blog! Feel free to share your thoughts
about this topic in the comments or drop us an email at hello@prototyp.digital.

AuthorDino Stančić

Start a Project