DEV Community: Dimitris Karagiannis

You may not need axios

Dimitris Karagiannis — Sat, 08 Jul 2023 12:09:27 +0000

Axios is an awesome library; it offers you niceties and various built in utilities for handling HTTP requests.

...but you may not need it. The native fetch or XMLHttpRequest APIs may be enough for your current needs.

So, let's go over each of the featured, well, features of axios and see how many of them are unique to axios.

Before we start a little explanation on the verdicts:

You do not need axios for this 👎: Means that this feature is something that is already ready to use out of the box with the native APIs

You may not need axios for this 😐: Means that this feature is something that you can fairly easily implement it yourself with fetch or XMLHttpRequest

You may need axios for this 👍: Means that this feature is something that is not very easy to implement it yourself and as such you may want to reach to axios for it

Make XMLHttpRequests from the browser

Good news, you can do that with both fetch and XMLHttpRequests.

Verdict: You do not need axios for this 👎.

Make http requests from node.js

Node's "equivalent" for XMLHttpRequest is http. Most recent versions of Node have also added support for fetch as well. But if you have to write server code and if you want to write it in Node and if you need some level of parity between the front and back end codebases then having to only learn and use one API (that of axios) may be useful.

Verdict: You may not need axios for this 😐.

Supports the Promise API

fetch is Promise based. It is also pretty trivial to make a Promise wrapper for XMLHttpRequest if you so wish.

Verdict: You do not need axios for this 👎.

Intercept request and response

If you know you will have to do this and you do not want to build this functionality yourself then having a built in way to do it is surely useful.

Verdict: You may need axios for this 👍.

Transform request and response data

Same as above, if you know you will need this and you do not want to built it yourself axios is a good choice.

Verdict: You may need axios for this 👍.

Cancel requests

You can do this with both fetch and XMLHttpRequest

Verdict: You do not need axios for this 👎.

Timeouts

Keeping in mind you can cancel requests with both fetch and XMLHttpRequest it is not so difficult to "timeout" a request using setTimeout. But, as always, if you know you will be requiring this functionality a lot and if you do not want to spent any time at all to implement it yourself then you can use axios I guess. But come on, it's just a setTimeout 😅

Verdict: You may not need axios for this 😐.

Query parameters serialization with support for nested entries

URLSearchParams exists. Yes, if you are using TypeScript it may be a little stingy because it actually requires that you pass a Record<string, string> object (even though passing something like Record<string, number> will also work in reality) but overall it's easy to use and it's a native way to manage your query params.

Verdict: If you use TypeScript and you are ok with having to pass only Record<string, string> objects to URLSearchParams you do not need axios for this 👎.

Automatic request body serialization

While not "automatic", all you need to do when you send a request is to match the data you are sending with the appropriate Content-Type header. Axios can automatically transform plain JS objects to FormData objects if you define the request Content-Type header as multipart/form-data which is nice, but why not just try to send what your API expects?

Verdict: You may not need axios for this 😐.

Posting HTML forms as JSON

This had me quite confused. Posting a form as JSON is not a task that befalls on axios, rather the user, who has to collect the form data and convert them to a suitable format for sending them as application/json instead of multipart/form-data. Really not sure what they mean here, but from what I understand 👇

Verdict: You do not need axios for this 👎.

Automatic JSON data handling in response

Not sure what is automatically handled in the response's JSON data here. If someone knows feel free to chime in the comments.

Verdict: ??

Progress capturing for browsers and node.js with extra info (speed rate, remaining time)

This is hands down one of the best features of axios. While this not very difficult to implement it yourself using XMLHttpRequest, you will not be so lucky if you have chosen to go with fetch and do not want to be mixing them up. If you need this functionality the fact that it's ready to use here out of the box is a godsend; we are not talking about a setTimeout implementation here.

Verdict: You may need axios for this 👍.

Setting bandwidth limits for node.js

This is another one of those things where you probably do not want to implement yourself from scratch, because it is not a trivial implementation. If you need this functionality you will probably appreciate the fact that someone already implemented this for you.

Verdict: You may need axios for this 👍.

Client side support for protecting against XSRF

All this does is read a CSRF related cookie from your environment and pass it along with the request headers (ref). Not something you cannot do yourself easily, but automating this is nice.

Verdict: You may not need axios for this 😐.

Overall

I guess the point I want to make with this post is to always weight your needs and your options and decide based on them. If your needs change then reconsider your options and change them if needed.

Do not use a tool blindly just because you saw it in a StackOverflow answer or a tutorial or simply because it's the flavour of the month.

This is not something specific to axios. I like axios, I have used it a lot during my career, I do not have any problem with it; it's a fine tool that does what it does very well. Axios is just a nice case to analyse in this way.

Thank you for reading 🎉

Working with React context providers in Typescript

Dimitris Karagiannis — Thu, 19 Mar 2020 13:48:06 +0000

Disclaimer 📣
This post was originally a part of my other article, but, since it became quite big, I decided to break it into its own mini post.

Say we have a simple provider that takes an axios instance as a prop and provides it to the rest of the application via context

import React from 'react';

const AxiosContext = React.createContext(undefined);

function AxiosProvider(props) {
  const { children, axiosInstance } = props;

  return (
    <AxiosContext.Provider value={axiosInstance}>
      {children}
    </AxiosContext.Provider>
  );
}

const useAxios = () => React.useContext(AxiosContext);

export { AxiosProvider, useAxios };

So, let's write this in TS:

import { AxiosInstance } from 'axios';
import React, { ReactNode } from 'react';

const AxiosContext = React.createContext(undefined);

export type Props = {
  children: ReactNode;
  axiosInstance: AxiosInstance;
};

function AxiosProvider(props: Props) {
  const { children, axiosInstance } = props;

  return (
    <AxiosContext.Provider value={axiosInstance}>
      {children}
    </AxiosContext.Provider>
  );
}

const useAxios = () => React.useContext(AxiosContext);

export { AxiosProvider, useAxios };

All is well now, right? We defined the Props type, so we are good to go. Well, not exactly. This will not work right away, because when we did

const AxiosContext = React.createContext(undefined);

we implicitly set the type of the provider value to undefined and thus doing

return (
    <AxiosContext.Provider value={axiosInstance}>

will throw a TS error, since the value we are passing is of AxiosInstance type, according to our Props type declaration, but is also undefined according to the context initialisation.

To fix this we declare a new type like this

export type ContextValue = undefined | AxiosInstance;

which can be further broken into

export type ProviderValue = AxiosInstance; // since you know this is what the provider will be passing

export type DefaultValue = undefined;

export type ContextValue = DefaultValue | ProviderValue;

and then declare the type during the context initialisation like this:

const AxiosContext = React.createContext<ContextValue>(undefined);

Now we let TS know that the context value can either be undefined (the default value) or an AxiosInstance (which is what will actually be returned by your provider). Now everything is ok then? Not yet, hang in there.

Because, now if we use the useAxios hook inside another component and try to use the value it returns, we will get a TS error telling us that the return value of useAxios can be undefined since this is how we defined it when we initialised the AxiosContext. How do we tackle this problem? We'll take a two-pronged approach.

A development time solution

As the programmer, we know that when we use the useAxios hook, the value it will return will never be undefined. It will always be of type ProviderValue since we know that we are using the hook inside a component that is a child of the AxiosProvider (because this is how we must use context hooks in order for them to work).

So, the fix here is simple, and it's a type assertion. When we use the useAxios hook, we should always assert that its type is of ProviderValue like so

import { useAxios, ProviderValue } from '<Path_to_AxiosProvider>'

function SomeComponent() {
  const axiosInstance = useAxios() as ProviderValue;
  // Do something with the axiosInstance object
}

and TS now knows that this is in fact an axios instance object.

A runtime approach

The above solution just solves the issue during development. But what happens if a new developer comes along, who they don't know that in order to use a React context value the component using it must be a child of the Provider component? This is a case where the assertion we made above stops being true during runtime and the whole app crashes because we try to access stuff on an axiosInstance that is undefined.

We could add a

if(axiosInstance === undefined) {
   throw new Error('The component using the the context must be a descendant of the context provider')
}

right after we do const axiosInstance = useAxios() but in that case the type assertion we did earlier is useless and we also need to be writing this runtime check every time we make use of useAxios.

The solution I've come up with for this is the following:

Use a Proxy as the default context value

Proxies are very useful in that they allow you to completely define the behaviour of a proxied object.

To elaborate, remember how we initialise our context, currently:

const AxiosContext = React.createContext<ContextValue>(undefined);

So, what if instead of undefined we initialised the context with a Proxy of a random axios instance object? like so

const AxiosContext = React.createContext<ContextValue>(
  new Proxy(axios.create())
);

Our types definition can now also change to this:

type ProviderValue = AxiosInstance; 

type DefaultValue = AxiosInstance;

type ContextValue = DefaultValue | ProviderValue;

But this is still not enough. We want the app to throw in case the default context is used, with an appropriate error message (and we do not want to do this check every time we use the useAxios hook, because we are lazy)

So, we simply define what we want to happen if the application code tries to access any members of this proxied axios instance that we return as a default context value:

const AxiosContext = React.createContext<ContextValue>(
  new Proxy(axios.create(), {
    apply: () => {
      throw new Error('You must wrap your component in an AxiosProvider');
    },
    get: () => {
      throw new Error('You must wrap your component in an AxiosProvider');
    },
  })
);

apply handles the behaviour when we try to call any methods from the proxied axios instance object and get handles the behaviour when we try to access any of its properties.

In conclusion

With the above approach we both keep Typescript satisfied and we also need to write the least code possible: Just a type assertion when we use the context hook and define the default context value as a proxy which throws if any code tries to access it.

Thanks for reading! 🎉

Tips for migrating a React app to Typescript

Dimitris Karagiannis — Thu, 19 Mar 2020 13:47:17 +0000

So, I've been working on a company project for almost half a year now. After feature development was finished and work on it slowed down, I decided I wanted to take the next step, which I did not dare take 6 months back, and write (or in this case "migrate") the project to Typescript.

These are all the things I learned in the process and, in retrospect, I wish I knew when I was starting the migration.

Disclaimer 📣

This post assumes you are a beginner with TS but its purpose is not to teach you TS. Its purpose is to give some advice to the next person who wants to try something similar and make their lives easier.
This post assumes that you are working on a CRA project and most of the setup and configuration is already been taken care for you. However most of the advice could be applied on any React project.
This post is based on my experience with migrating a moderately big codebase to TS.

Before you begin ⚙️

Set `allowJs` in your tsconfig to `true`

That's all. This will ensure that you are not drowning in red the moment you enable the type checker and will allow you to migrate gradually; letting you keep your existing .js files, until their time comes.

Create a `global.d.ts` file in your `src` directory

This will come in handy, since you most likely will want to augment or extend the types of existing libraries you are using.

Create a `custom.d.ts` file in your `src` directory

You will need this, in order to be able to import files that are not code modules, such as image files, .json files, etc. To help you get started, just add this inside your custom.d.ts file:

declare module '*.svg' {
  import React = require('react');
  export const ReactComponent: React.FunctionComponent<React.SVGProps<SVGSVGElement>>;
  const src: string;
  export default src;
}

declare module '*.json' {
  const content: object;
  export default content;
}

Et voila, now you can import .svg and .json files inside your code modules without TS throwing errors at you.

Should you want to enable `noImplicitAny` and `no-explicit-any` do it before you start

noImplicitAny is a compiler option which will raise errors on expressions and declarations with an implied any type.

no-explicit-any is an eslint rule that doesn't allow you to define anything as any type.

If you do enable these options, the unknown type will be your friend.

These options should ideally be enabled from the get go. No matter what, do not enable them during the migration process. I made that mistake and ended up suddenly having to spend lots and lots of time resolving quite an amount of errors that I "inflicted" upon myself. Can be quite disheartening while you are still in the middle of the migration.

Setup your `eslint` config for use with TS

I happened to have an issue with eslint's default no-unused-vars rule and TS. Turns out there is a specific no-unused-vars rule for TS. Enable this and disable the default one

Settle on how you will be defining your types

Will you be using interfaces or types? Will you be writing your types inside the code file or as a separate file? I advise that you settle on these details before you start because you don't want to change you mind halfway there and have to retrofix all the files you have already worked on.

My advice is use types unless an interface is absolutely necessary and keep your type definitions separate from the component files themselves.

The system I applied was the following:

If the file is a React component file, create a separate types.d.ts file in the same directory and put all the type definitions there. Except for the Props type definition; I keep that in the component file itself, since it is handy to have the props definition readily available.
If the file is not a React component type, declarations go along with the code. No separate types.d.ts file. That is unless the types are so many that make the code file really messy, then they are taken out in their own file.

Read the documentation

Seriously. At least read some of the important parts, such as:

Basic types
Generics
Advanced types - Especially how intersections and unions work, because they do not map exactly 1:1 with the mathematical definition of unions and intersections
Type compatibility
Utility types - Those are very handy, give them a look to, at least, know of their existence.
Release notes - I have found that sometimes things mentioned in the release notes of a new version are not mentioned in the docs. For example this very handy assertion function functionality which was added in version 3.7 and AFAIK is not mentioned anywhere in the docs.

Prepare to start being more thorough when you code

Typescript will eventually lead you to be more thorough with some assumptions you make while coding. Assumptions for which, in your mind, know to be correct for your code, are not enough for TS. Typescript will always be asking to validate those assumptions by writing some more code, mostly in the form of

if (notCondition) { 
  throw new Error()
}

// Otherwise all is well

You'll get used to it, and eventually it will come to you naturally.

Get ready to be wrong

Accept the fact that 99.999% of times the TS compiler will be right and you will be wrong 😅

On with the actual migration 🚀

Start small

When you make the transition from JS to TS you want to start small. See that directory with your utility functions? They are by far the simplest things you can start migrating over to TS.

Once you migrate a simple function see where this function is used, what other files import it (the compiler will probably let you know, by throwing some errors at you at this point).

Proceed with migrating those files, and repeat the process, essentially climbing up (down?) the dependency tree. If you reach a file that is far too complex for this stage of the migration don't be afraid to put a @ts-nocheck directive at the first line of it, and migrate it at a later time.

Do not be afraid to do type assertions

Type assertions in TS are like type casting in other languages. In essence you are telling the TS compiler that you know better, and a specific variable, even though it could possibly be of many types, cannot be anything else other than a specific type in this case. Sometimes you do in fact know better. But only sometimes 😅

I have found this to be useful when working with React hooks that provide some context value. Context values start with a "default" value when you initialise the Context, which may not always be compatible with the actual value passed to the provider. More on that in this post.

Custom type guards and assertion functions are also very useful in helping you help TS make the correct type assertions

Do not use the provided `FC` type for React components

I highly encourage you to not define React components like this

const Comp = FC<Props>(props) => { .... }

I found its usage to be more of a bother than anything, since it makes some rather arbitrary assumptions about your components (like always having children props and not working very well with PropTypes) and in general takes away some of the control you have over defining your components the way you want. Use

function Comp(props: Props) { .... }

instead. TS is smart enough to infer the return type itself, and for all intents and purposes this is a valid React component, which you can use in any case where a React component is expected by the compiler.

Keep your `PropTypes`

While TS is very useful in making sure you are not making any type related mistakes during development time, PropTypes are very useful in letting you know of type related mistakes during runtime. How can you have type related errors during runtime, if you are using TS for development, you ask? Consider this scenario:

You have defined your API response type in TS as bringing back a field which is supposed to be a number. You have also defined your relevant PropTypes field as such. All is well.

Now, imagine if your API returns a string instead of a number in that field. Had you removed the PropTypes you would never realise the error early, until the app crashed at some point. With PropTypes you will get a very useful warning in the browser console if any such mismatch ever occurs.

If you work on an ejected CRA project, or otherwise you have access to the babelrc file, know that a plugin exists that can automatically convert your TS types to PropTypes, so that you don't have to manually update both.

Export all your types

Even if you don't end up importing all of them in other files, make a habit of exporting them since you never know when you may need a type which is defined in another module.

Do not be afraid to use generics

TS generics can be really helpful and you can have generic React components as well. For example

// Comp.tsx
type Props<T> = {
  result: T;
}

function Comp<T>(props: Props<T>) {
// T can also be used inside the function body too, if needed
}


// OtherComp.tsx
type SomeType = ...

function OtherComp() {
  return (
    <Comp<SomeType> someProp={...}>
      <SomeContent />
    </Comp>
  )
}

In my experience, if a React component is an abstraction over some thing, then it's safe to assume that this component's type definition will be a generic.

Read the type definitions of libraries you use

When in doubt always read the type definitions for the libraries you use. This will also help you on how you should define your own component types for usage with components from external libraries.

You don't always have to define the return types

TS is (mostly) smart enough that it will correctly infer the type of the return values of functions. Personally, I like to define return values too, but that's because I have some kind of OCD 😅

Do note that there may be times that you'll have to strictly define the return value for things to work correctly.

Make type definitions for your API responses

They will help you immensely, since it's more than likely that you will be using server provided data in parts of your application

Learn to read TS compiler errors

TS errors can be intimidating, however there is a "cheat" in how to read them. Always read the first and the last few lines of the error message. If you still don't make sense do read the whole error, but usually just reading those lines will give you the information you need to make sense of the error.

Random Typescript tip ✅

Do `(TypeA | TypeB)[]` don't `TypeA[] | TypeB[]`

When you have an array whose type may be either an array of TypeA or an array of TypeB declare it as

const arr: (TypeA | TypeB)[]

instead of

const arr: TypeA[] | TypeB[]

There is a subtle difference between those 2 declarations and the second one will lead to errors if you try to .map() over the arr

Closing words

The fact that you decided to migrate your app instead of writing it in TS from the start, may conceal the merits of having used TS at the beginning, since your whole code base is already laid out.

However you will see the merits once you continue development and now all your new code will have to abide by the TS rules.

Remember, your code is now quite a lot more thorough with handling error cases.

This, combined with some proper tests, will ensure that your code is as robust as it can be.

Thank you for reading! 🎉

DEV Community: Dimitris Karagiannis

You may not need axios

Make XMLHttpRequests from the browser

Make http requests from node.js

Supports the Promise API

Intercept request and response

Transform request and response data

Cancel requests

Timeouts

Query parameters serialization with support for nested entries

Automatic request body serialization

Posting HTML forms as JSON

Automatic JSON data handling in response

Progress capturing for browsers and node.js with extra info (speed rate, remaining time)

Setting bandwidth limits for node.js

Client side support for protecting against XSRF

Overall

Working with React context providers in Typescript

A development time solution

A runtime approach

In conclusion

Tips for migrating a React app to Typescript

Disclaimer 📣

Before you begin ⚙️

Set allowJs in your tsconfig to true

Create a global.d.ts file in your src directory

Create a custom.d.ts file in your src directory

Should you want to enable noImplicitAny and no-explicit-any do it before you start

Setup your eslint config for use with TS

Settle on how you will be defining your types

Read the documentation

Prepare to start being more thorough when you code

Get ready to be wrong

On with the actual migration 🚀

Start small

Do not be afraid to do type assertions

Do not use the provided FC type for React components

Keep your PropTypes

Export all your types

Do not be afraid to use generics

Read the type definitions of libraries you use

You don't always have to define the return types

Make type definitions for your API responses

Learn to read TS compiler errors

Random Typescript tip ✅

Do (TypeA | TypeB)[] don't TypeA[] | TypeB[]

Closing words

Set `allowJs` in your tsconfig to `true`

Create a `global.d.ts` file in your `src` directory

Create a `custom.d.ts` file in your `src` directory

Should you want to enable `noImplicitAny` and `no-explicit-any` do it before you start

Setup your `eslint` config for use with TS

Do not use the provided `FC` type for React components

Keep your `PropTypes`

Do `(TypeA | TypeB)[]` don't `TypeA[] | TypeB[]`