DEV Community: vova ushenko

Building reusable components, using Typescript, React and Styled-Components

vova ushenko — Thu, 28 Oct 2021 13:54:19 +0000

Motivation

Being able to build a solid component system that can be seamlessly reused in many projects is absolutely crucial for modern web-development. Precisely for this reason, I would love to walk you through the process of construction of several components that are ready for the challenges of today's dynamic Web landscape. 🚀

We will be building not only beautiful, but also highly-dynamic components that have different states for different scenarios. Which in turn will allow us to seamlessly build dynamic web applications. 🚀

Remark

This article is particularly aimed at beginners and those who want to familiarize themselves with Typescript, React, styled components and how to glue it all together. However, even seasoned developers might learn a trick or two, so stay tuned! 🚀

Content

Today we will start our journey from a relatively simple button. component, will build it using Typescript and styled-components.

Syllabus of today's article

We will learn a few cool tricks about:
⭐ Isomorphic components in React
⭐ How to use Typescript with React and styled-components effectively
⭐ Using custom props with styled-components

Sneak Peak

Here's how our button will look at the end.

I've also built a component sandbox where you can just play around with all the components.

Feel free to visit my components sandbox and look at the
final results of our today's work.

🚀🚀🚀 Enough words, let’s build the button 🚀🚀🚀

Let’s firstly plan what we want to achieve and program purely on interfaces! So let’s start from the Button’s interface (what kind of props it will receive):

In the simplest approximation, it will look like :



interface ButtonProps {
 isLoading?: boolean;
 isCompleted?: boolean;
 disabled?: boolean;
 children: ReactNode;
}

Where, the isLoading flag will be indicating whether we are fetching something or carrying out some operation - basically the loading variant of the button.

isCompleted flag - indicates whether some operation (async or not) is successfully completed.

Disabled - indicates whether the button is disabled, and finally children prop indicates what will be wrapped and displayed in the button, be it some text or icon.

💡 Let’s think about what we can also add to the interface! The button will be receiving some onClick actions, and we will definitely need to keep this in mind and add this to the interface.



interface ButtonProps {
 isLoading?: boolean;
 isCompleted?: boolean;
 disabled?: boolean;
 children: ReactNode;

 onClick: () => void; // 💡 added onClick support
}

This kind of works, but, and this is a big BUT - this is super inconvenient and mechanical.

Let’s imagine that we would want to add more and more standard button props (aria labels for example), so we would end up constantly reflecting this in the interface.

We can do way better

💡 Not only can we do this automatically, but we can also preserve all the Typescript type safety and code-hinting by simply extending already existing standard interfaces.

So, let’s continue our interface programming.



interface ButtonProps extends React.ComponentPropsWithoutRef<'button'> {
 isLoading?: boolean;
 isCompleted?: boolean;
 disabled?: boolean;
 children: ReactNode;
}

💡 Notice how our interface extends React.ComponentPropsWithoutRef with the ‘button’ generic.

This simply means that our button will be able to get onClick and all standard native button props - automatically. Which is cool!

Alternatives to this approach

Actually there are several ways to perform this trick with type extension. You can also end up doing something like this (also valid):



interface Props extends ButtonHTMLAttributes<HTMLButtonElement> {
 isLoading?: boolean;
 isCompleted?: boolean;
 disabled?: boolean;
 children: ReactNode;
}

Or even like this



const Button: React.FunctionComponent<
 React.DetailedHTMLProps<
   React.ButtonHTMLAttributes<HTMLButtonElement>,
   HTMLButtonElement
 > & { 💡💡💡 OUR CUSTOM PROPS GO HERE💡💡💡 }
> = ({ title, children, style, ...rest }) => {
 return <button {...rest}>{title ?? children}</button>};

🚀 The same spiel!

Approach that we will employ 👷

Although there are many ways of achieving this task, we will use the first variant when we extend React.ComponentPropsWithoutRef and here is why.

By doing so we can achieve the nifty 💡 flexibility 💡 of our component.

Let’s imagine the case when we have an external link <a></a> to some resource and it should be styled like this button component, but it should have all the native link props.

We also don't want to lose any type safety.

The first reflex is to build a separate link component and just borrow some button styles or class. But, we've got...

Polymorphic Components in React

With built-in polymorphism in React we can employ a way better strategy!
We can use nifty ‘as’ prop to render our component however we want, be it a link or our standard button!

❗ However, with Typescript this can be quite painful, since we have some limiting type rigor.

Let’s again program on interfaces a little, and see how this problem can be solved!

I’ve already written one article on dynamic typing in Typescript (in the context of api calls).

💡 Here we will follow exactly the same approach - we will use generics!

Here’s the solution:



type ButtonProps<T extends ElementType> = {
 renderAs?: T;
 isLoading?: boolean;
 isCompleted?: boolean;
 disabled?: boolean;
 children: ReactNode;
} & ComponentPropsWithoutRef<T>; // 💡&💡 means that we simply add some type or interface to our props

Let’s understand it.

1️⃣ We pass generic to the props which extends ElementType (ButtonProps<T extends ElementType>). Element Type is a nifty React utility type - which essentially means that we will be using any valid HTML element or React Component (if we will specify invalid HTML element, an error will be thrown).

2️⃣ Next we pass this generic to the props and specify in renderAs?: T that the button will be rendered “as” this generic.

3️⃣ Finally we add & ComponentPropsWithoutRef to get all native HTML element props right out of the box.

To make this super clear, if we will specify renderAs = ‘button’ we will automatically get all standard button props, whereas if ‘a’ will be specified, we will get link props (such as href). Cool!

🚀🚀 We have our interface and now we are ready to proceed and prepare the scaffold for the button. 🚀🚀

Scaffold

Let's create two files.

UltimateButton.styles.tsx for the styles.



import styled from 'styled-components';

export const BTN = styled.button``;
```

UltimateButton.tsx for the component.

```typescript
import React, { ComponentPropsWithoutRef, ElementType, ReactNode } from 'react';
import * as Styled from './UltimateButton.styles';

type ButtonProps<T extends ElementType> = {
 renderAs?: T;
 isLoading?: boolean;
 isCompleted?: boolean;
 disabled?: boolean;
 children: ReactNode;
} & ComponentPropsWithoutRef<T>;

// 💡 In generic the HTML type of component will be specified. And by default it is button
const UltimateButton = <T extends ElementType = 'button'>({
 renderAs,
 isLoading,
 isCompleted,
 children,
 ...rest
}: ButtonProps<T>): JSX.Element => {
 return (
   <Styled.BTN
     as={renderAs}
     isLoading={isLoading}
     isCompleted={isCompleted}
     {...rest}
   >
     {children}
   </Styled.BTN>
 );
};

export default UltimateButton;

```

Since we already thought in great detail over the Button’s interface. I think everything should be very self-explanatory.

❗ Please note, in the Button’s generic `<T extends ElementType = 'button'>` we specify the default value of ‘button’. So, if generic will not be specified, this will be our default. ❗

###Testing the Scaffold###
Let’s test our button in the wild. We will render it as `button` and as `link`, and as a button with href prop(this case should error out).


![Testing Button](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/i7jjo2fenqwttfwzyrfe.png)

⭐ Please note, in the first case we haven’t specified “renderAs” and the button defaulted to the behavior of the button. It receives native onClick, even though it does not have it in the interface.

⭐ In the second case, we specified “render as a” and now the button is rendered as a link and accepts all the semantic link props without any errors ( we specified href, target and rel).

⭐ Finally, in the third case we render a button, but we use “href” prop and this case will error out. Which is great. Also, errors will be thrown if we will specify some incompatible tags that do not exist.


🖌️ Great! Now we can proceed to styling and making our button - beautiful!

### Styling 🖌️###

As I’ve already mentioned, in this series we will be using styled components. 

We want to build a really versatile component with a ton of states. In this case, I do enjoy creating separate styles for each of those states, which will pay-off in readability and maintainability.

In styled-components we can use `css` for this case. 

Here’s how the initial styles backbone looks like.

![Styles scaffold](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/w9xlkk3rv8u0rs85482b.png)

These styles styling states live separate of each other, which will allow us seamlessly add new states without any styling issues.

💡 In `buttonCustomProps` we will initialize our CSS custom props aka CSS variables. This actually addresses one of the biggest styled-component’s weaknesses - re-injection classes and re-rendering in the case when some of the styled props have changed. 

![Custom props](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7rhgueqte9fne6twtwma.png)
You can read about this in great detail in this [fantastic article](https://www.joshwcomeau.com/css/styled-components/). Thanks Josh! 

💡Please note, we set initial custom props to the above hard-coded values, or we can use also use global styled theme provider (if we use one) as we did with --mainBg on the 3rd line. We can also pass these custom props as style object to address the performance limitations of styled components (if we are concerned with them of course).

###Default styles###
Let’s consume these variables and add default styles.
![Default styles](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4v13isx33a8x6xry558r.png)

Nothing fancy.

We first reset default button styles with “all:unset” and then gradually construct what we want to be our default button.

🌶️ In order to make our button a little more spicy, I added a small 3d-effect using :before and linear gradient with a sophisticated border radius (will add cool 3d effect).

Then we can add all these good things to our Styled Button. 

![Styled Button Styling](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/dovlso901ov8l5p81mku.png)

And here’s the result of our hard word - our default button! Looks kind of cool, isn’t it?

![Default button look](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rmyfeyd1zapp1cjvipg2.png)

###Button States###

We already have set the foundation! Let’s enhance it with multiple states and looks!

Essentially the button should support the following states : hovered, focused, disabled, loading, active and completed.

Also, it would be great, if it would be easy to add even more custom states (if need be) without and styling problems.

Let's start with introducing a separate interface for styled props that our styled component will receive.

![Styled Props](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1lo214mbzkdbih6xhxbs.png)

Let’s firstly deal with native button states - focused, active, hovered and disabled.

I think that we must separate these native states from custom one’s. More particularly, when we hover over the button we want to apply hovered styles, but when it is in a loading or disabled state we don’t want to do this.

Since in styled components we can use the full power of Javascript, this can be accomplished in many ways.

I would prefer to manage states like this...

![Button State Management](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/p2rxcsos065a31x2fnxj.png)

💡 Notice, we receive `isLoading` and `isCompleted` from the passed props and then we also use standard css pseudo-classes `:hover, :focus, :active and :disabled` to apply different styles to different states.


💫 Now we are ready to add some fill the placeholders of states with some styles.

###1️⃣ Hovered button###
Super simple. We will not be using any super sophisticated styles today, but I encourage you to experiment and be as creative as possible.
![Hovered Button](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/cwd1z26uxu4clsbozpr3.png)

###2️⃣ Focused button###

We will add more visibility and prominence for those who navigate our website using the keyboard.
![Focused button](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/df5gpowedhvw3u3tolhd.png)

We use nifty `:focus-visible` [pseudo-class](https://css-tricks.com/almanac/selectors/f/focus-visible/) to apply our styles only when the button has focus, but this focus is not triggered by a click. This will greatly enhance the element’s accessibility and will not interfere with the button’s design.

When the button is focused (through TAB) it will look something like this. 

![Focused button look](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/crgb1g9ybl8y6zrke4qk.png)


###3️⃣ Disabled button###
![Disabled button](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5fobcmkq2aobxmcsghqo.png)

###4️⃣ Active button###

By clicking on the button and triggering this state, I want to emphasize its spicy 🌶️ 3D effect. 

![Active button](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/s2ymkc2mifq4bxc159oj.png)

On click, an initial 3D gradient in :before will be hidden, and mirrored gradient will be added to :after.

###5️⃣ Completed button###

This state will be used to indicate a successful finish of some operation, which in turn will make user experience far smoother.

In our case we will not go crazy. Just add good old green appealing color (however in your projects, I encourage you to go crazy).

![Completed button](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zstakq2lvc7b4a461j3e.png)

You can also play with the content of the button depending on the state of this flag (isCompleted).

For instance...
![Using isCompleted](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qidqqnz2r65zj66cw6jq.png)


###6️⃣ Let’s finally tackle the big beast - loading state###

It would be cool to add some loading animation,and not just a boring spinner that is used in 90% of component libraries.

Let's add a repeating linear gradient and liven it with some animation.

In styled components, for animations we can borrow `keyframes` or write plain old css. Depends on your preference.

![Loading keyframes](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/y8z3ww5vfgzwfwalw8dz.png)

And here’s our loading button styles.

![Loading button styles](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/d1q2938k5o3qvf5z363a.png)
💡 In `:before` we add wide gradient and simply animate its transition on X axis. As simple as that!


###Wrapping up###
Oof! That was a lot of work! 
I hope you enjoyed this whole rodeo and learned something useful.

Let’s wrap up. 

🏆 We've built a polymorphic component that can be used as a button and link.
🏆 We've nicely separated styles of different component states from each other and now can add even more states without any problems.

🎊  If you enjoyed what we've done, consider giving article a like and subscribing to [my github](https://github.com/vovaushenko) for more updates! 🎊   

Cheers!

🪟 Windows 11 inspired portfolio 🪟

vova ushenko — Sat, 02 Oct 2021 18:19:47 +0000

👋Hi there and Happy Hacktoberfest 2021 fellow developers! 🎊
I hope you're doing fantastic!

In the past, I was powerfully impressed by a portfolio that was built like a simple OS. So, this basically has always been my small dream to build a portfolio-app that visually mimics an operating system.

Recently, I had some free time and I finally decided to turn this plan into reality. So, I started working on 🪟 Windows-11 inspired portfolio ✨.

You can try it out here: https://www.vovacodes.ca/
GitHub: https://github.com/vovaushenko/vovacodes

This is a Next.js app built from scratch, that has a small backend powered by MongoDB. It is fully written in TypeScript, so if you're learning it, you could explore the GitHub repo 💥

In a nutshell the stack is -
⭐ Next.js,
⭐ React,
⭐ Styled-Components,
⭐ Redux
⭐ Mongo DB.

The app has a design and component system powered by
💜 Storybook 💜

This is not only an OS-looking app but also beautiful slides about me, which can be found by navigating and using the OS.

The App has a ton of cool features (for instance you can leave me a comment and later it will be displayed with a nice random avatar in a flying carousel). So, leave a comment!😉 I would be happy to hear from You! 🙌

Essentially, it has a lot of nifty features, so consider exploring it and let me know what is your favorite one!✨

❗ Notice, on mobile only portfolio part will be shown

PS. I Use Arch BTW

Happy Hacktoberfest 2021 Again! Wish you all the best!

Cheers! 🤙

At a glance :

Keep in mind, this is a work in progress! More features to come (and bugs tackled 😄)

🪝 Building custom "useTypedFetch" hook in React with TypeScript

vova ushenko — Wed, 29 Sep 2021 11:24:29 +0000

Asynchronous interactions are the bread-and-butter of modern JavaScript programming. Let’s see how we can abstract away all the heavy lifting and boilerplate of data fetching in a custom useTypedFetch hook 🪝.

✨ This article is particularly aimed at beginners and those who want to familiarize themselves with async TypeScript a little better and maybe start using it with React.

Motivation

Since it might be tricky to work with dynamic types of data in TypeScript (and almost all api calls, per se, are purely dynamic), we want to build a flexible tool that will adapt to any kind of an api response and will do this dynamically.

Additionally, it would be great to make this hook "http-client-agnostic". Put simply, this hook should get a standardized input (url, method, headers etc) and should seamlessly work with different types of http-clients (fetch, axios etc). This will allow us to easily migrate from one http-client solution to another(if need be) without rewriting hundreds of api calls and thousands of line of code.

❗Note : This is for learning and academic purposes only. In production, I would advise to rely on established solutions and libraries.

Foundation

Let’s start from the brain of our fetching logic - fetch client or request function. It should be able to make all types of calls (‘GET’, ‘PUT’, ‘POST’, ‘DELETE’, etc). It’s single responsibility should be just making calls using native fetch or axios (or some other library). By delegating all calls in our app to this one fetch client, we can make our app far more robust, since calls will not be diluted all over the project(and when we will decide to migrate to some other fetching library or solution this will be super easy).

Let’s start from the interface of our fetch-client function.
If we use native fetch, we can automatically make a “GET” request by only specifying “url”. Other params are optional. So let’s mimic standard fetch interface

interface RequestConfig {
 url: string; 
 method?: string;
 headers?: Record<string, string>; //💡 “?” - specifies optional field
 data?: Record<string, string | number>;    
}

💡 Notice, headers and data use nifty Record utility which actually constructs an object type, whose property keys are of first type specified in generic( in our example - string) and values are specified by second type in generic.

For simplicity’s sake, we will not include a list of all possible params.
❗ In “headers” and “data” we will be specifying config objects to be added to headers and body

For instance,

headers: {
     'Content-Type': 'application/json',
   }

Global Fetch Function

Now we are ready to build our global request function, it takes an object with interface RequestConfig and returns a promise as all async functions do:

export const makeFetchRequest = ({
 url = '/',
 method = 'get',
 data,
 headers,
}: RequestConfig): Promise<Response> => {
 return fetch(url, { method, headers, body: JSON.stringify(data) });
};

💡 Notice that the input params have RequestConfig type which we will soon use for another variant using “axios”. This current implementation is based on native “fetch”. Additionally we specified in the generic of returned promise - <Response> which is a native fetch response (IDE will provide useful hints).

Here how it looks under the hood...

/** This Fetch API interface represents the response to a request. */
interface Response extends Body {
   readonly headers: Headers;
   readonly ok: boolean;
   readonly redirected: boolean;
   readonly status: number;
   readonly statusText: string;
   readonly type: ResponseType;
   readonly url: string;
   clone(): Response;
}

We’re half way through! 🍾

As you might have noticed, all our accomplishments have nothing to do with React (which is great). Because we could abstract away our fetch logic even from the framework and later re-use or consume it in other frameworks ( if we use micro-frontend architecture with many frameworks).

Let’s now get back to the React land and think about the basic state of our useTypedFetch hook.

In its simplest implementation, it should receive a url and request options and hopefully return some data, error and loading indicators after making some api call.

Since we already created an interface for our makeFetchRequest function, let’s re-use it!

Here is our useFetch Function initial signature

export const useTypedFetch = ({ url }: RequestConfig) => {
// ⭐ api response data will be stored here!
 const [fetchedData, setFetchedData] = useState<any>(null);
// ⭐ loading flag
 const [isLoading, setIsLoading] = useState<boolean>(false); 
// ⭐ errors piece of state
 const [error, setError] = useState<any>(null);

 /*
   🌠 Some magic happens here 🌠
 */

 return { fetchedData, isLoading, error };
};

💡 The biggest problem with async operations is that we don’t know what the type of an api response we will get beforehand. So we cannot hard-code it here in useTypedFetch.
❗ We also want to make this hook adaptable to any kind of API (and not resort to any type or cumbersome type narrowing with unknown)

Sounds really complicated to create a function that will use a type that we don’t know beforehand, but the solution is really simple - generics 💡.

Let’s start from the type of what we will actually get from useTypedFetch

We will call this type very simply - UseTypedFetchReturn

type UseTypedFetchReturn<T> = {
 data: T | null;
 isLoading: boolean;
 error: string | null;
};

Generic <T> will be added at useTypedFetch function’s call-time and we will be able to specify it and receive all the type safety and hinting support of TypeScript. Which makes me happy! 🤗

Let’s implement this in the hook

// ❗Notice we put `<T>` before function's param list
export const useTypedFetch = <T>({
 url,
 headers,
 method,
 data,
}: RequestConfig): UseFetcherReturn<T> => {
 //⭐ We also use T in generic of fetchedData, since it essentially what we will get from an API
 const [fetchedData, setFetchedData] = useState<T | null>(null);
 const [isLoading, setIsLoading] = useState<boolean>(false);
 const [error, setError] = useState<string | null>(null);

 /*
   🌠 Some magic will soon happen here, be patient 🌠
 */

 return { data: fetchedData, isLoading, error };
};

💡 Generic <T> that is added before the function will specify our API response data type (which we can get from our backend libs or specify on our own). We can use any name instead of <T>, for instance <SomeCoolGenericType>.

💡 Notice that at this stage we firstly specify this generic type before the hook and then “consume” it in the hook’s return type UseFetcherReturn<T> and in local data state useState<T | null>(null). Essentially, we construct our whole “type-flow” based on this specified type. Sweet! 🤗

✨ Voila, now we can specify any type before each fetch call in useTypedFetch and get all the Typescript hints and benefits dynamically.✨

Now we are ready to actually fetch

Let’s add useEffect and update our hook’s pseudocode

export const useTypedFetch = <T,>({
 url,
 headers,
 method,
 data,
}: RequestConfig): UseTypedFetchReturn<T> => {
 const [fetchedData, setFetchedData] = useState<T | null>(null);
 const [isLoading, setIsLoading] = useState<boolean>(false);
 const [error, setError] = useState<string | null>(null);
 return { data: fetchedData, isLoading, error };
};
 useEffect(() => {
   try {
     setLoading(true);
     const data = makeSomeRequest();
     setFetchedData(data);
     setIsLoading(false);
   } catch (error) {
     setIsLoading(false);
     doSomethingWithError();
     setError(error);
   }
 }, []);

We probably will makeSomeRequest(), and if everything will be OK, we will store api response data in the local state and return it ready for further consumption from the hook. Otherwise we will doSomethingWithError() (be it a second call, abort, log error or simply store error in the local state and return it).

💡 However, I really want to abstract the logic of makeSomeRequest() away from the hook (like we did with makeFetchRequest ) and create a helper function. Let’s name it “fetcher”.

In this helper we will use our main fetch-client “makeFetchRequest”, and it will look like:

export const fetcher = async <T,>({
 url,
 method,
 headers,
 data,
}: RequestConfig): Promise<T> => {
 // ⭐ make api call
 const apiResponse = await makeFetchRequest({ url, method, headers, data });
 // ⭐ call json() to transform a Response stream into usable JSON
 const apiData: T  = await apiResponse.json();
 return apiData;
};

💡 Notice we again re-use the RequestConfig interface and use generic to specify what will be returned. Fetcher is an async function, so it obviously returns a promise.

Let’s get back to the hook and integrate this fetcher helper.

export const useTypedFetch = <T,>({
 url,
 headers,
 method,
 data,
}: RequestConfig): UseTypedFetchReturn<T> => {
 const [fetchedData, setFetchedData] = useState<T | null>(null);
 const [isLoading, setIsLoading] = useState<boolean>(false);
 const [error, setError] = useState<string | null>(null);

 useEffect(() => {
   //⭐ we use IIFE to automatically invoke fetcher
   (async () => {
     try {
       setIsLoading(true);
       const res = await fetcher<T>({ url });
       setFetchedData(res);
       setIsLoading(false);
     } catch (err) {
       setIsLoading(false);
       //⭐ here we can narrow the type of error (if for instance we have our own custom error class or do something else)
       if (err instanceof Error) {
         setError(err.message);
       }
     }
   })();
 }, [url]);

 return { data: fetchedData, isLoading, error };
};

✨ Now we can use this hook with any kind of an API and get all the type safety and convenient hinting along the way. ✨

Using the hook

Let’s get back to React land and make several api calls. We will test our hook with GET and POST requests. We will use https://jsonplaceholder.typicode.com/ as our mock backend API.

You could play around with the working example on CodePen

In a nutshell, we specify types of Todo and Post which will be returned from API stored in arrays.

1️⃣ We make GET calls to API/todos and API/posts to get data.

2️⃣ We also make a POST call to store a new post.

3️⃣ We also use this data to render basic JSX.

/**
* INTERFACES OF https://jsonplaceholder.typicode.com/
*/
interface Todo {
 userId: number;
 id: number;
 title: string;
 completed: boolean;
}
interface Post {
 userId: number;
 id: number;
 title: string;
 body: string;
}

const API = 'https://jsonplaceholder.typicode.com';

function App() {
 //⭐ Example of making GET call to get array of Todos
 const {
   data: todos,
   error,
   isLoading,
 } = useTypedFetch<Todo[]>({
   url: `${API}/todos`,
 });
 //⭐ Example of making GET call to get array of Posts
 const { data: posts } = useTypedFetch<Post[]>({
   url: `${API}/posts`,
 });
 //⭐ Example of making POST request to create a new post, no pun intended
 const { data: postData } = useTypedFetch<Post>({
   url: `${API}/posts`,
   method: 'POST',
   data: { title: 'foo', body: 'bar', userId: 1 },
   headers: {
     'Content-type': 'application/json; charset=UTF-8',
   },
 });

 return (
   <Container>
     {todos?.slice(0, 3).map((todo) => (
       <article>
         <h2>{todo.title}</h2>
         <p>{todo.completed}</p>
       </article>
     ))}
     {posts?.slice(0, 3).map((post) => (
       <article>
         <h2>{post.title}</h2>
         <p>{post.body}</p>
       </article>
     ))}

     <article>
       Here is our newly POST-ed post
       {JSON.stringify(postData, null, 2)}
     </article>

     {error && <h1>{error}</h1>}
   </Container>
 );
}

I think everything is pretty basic and self-explanatory. Please notice that in the generic of useTypedFetch we specify what kind of data shape we are expecting and right away in the code we will get useful code completion and hinting. Which makes me happy 😍

Using with axios

Finally! Let’s enhance our hook with variability. So far, we’ve constructed it on top of fetch. Let’s add axios!

Our initial step was to specify the interface of request configuration and axios already did all the heavy-lifting and provides AxiosRequstConfig interface.

Let’s build our global request function.

export const makeAxiosRequest = <T,>({
 url = '/',
 method = 'get',
 data,
 headers,
}: AxiosRequestConfig): AxiosPromise<T> => {
 return axios({ url, method, data, headers });
};

💡 As you might have noticed it looks like our initial makeFetchRequest function. Of course it has built-in axios interfaces and it uses axios as the http-client. But it takes exactly the same params as input, which is great!

Let’s add a axios fetcher function, like previously with “fetcher”.


const axiosFetcher = async <T,>({
 url,
 method,
 headers,
 data,
}: AxiosRequestConfig): Promise<T> => {
 const { data: apiData } = await makeAxiosRequest<T>({
   url,
   method,
   headers,
   data,
 });
 return apiData;
};

💡 If you will compare it with our initial fetcher, you will notice that it takes exactly the same input and produces exactly the same output! We now actually have two options in our useTypedFetch, we can use either fetch or axios ✨!

Let’s see this in the hook

export const useTypedFetch = <T,>({
 url,
 headers,
 method,
 data,
}: RequestConfig): UseTypedFetchReturn<T> => {
 const [fetchedData, setFetchedData] = useState<T | null>(null);
 const [isLoading, setIsLoading] = useState<boolean>(false);
 const [error, setError] = useState<string | null>(null);

 useEffect(() => {
   (async () => {
     try {
       setIsLoading(true);
       // ⭐⭐⭐ Both res1 and res2 return 
       //the same response of the same type! 
       //Now we can have a flexibility to use either
       // fetch or axios ⭐⭐⭐
       const res1 = await axiosFetcher<T>({ url, headers, method, data });
       const res2 = await fetcher<T>({ url, headers, method, data });
       setFetchedData(res1);
       setIsLoading(false);
     } catch (err) {
       setIsLoading(false);

       if (err instanceof Error) {
         setError(err.message);
       }
     }
   })();
 }, []);

 return { data: fetchedData, isLoading, error };
};

🍾 That’s it guys! Hope you enjoyed this simple overview and learned something new!

Cheers! 🙌

You can find the code used in this blogpost at the following sandbox URL: https://codepen.io/vovaushenko/pen/bGRQbRE