. This makes it harder to type response data without writing additional wrappers.

type User = {
  name: string;
  age: number;
}

// This won't work.
fetch<User>('/api/user/42').then(user => {
  
  // `user` will be of `unknown` type.
})

We can create a wrapper-module to avoid this problem.

// Make the `request` function generic
// to specify the return data type:
function request<TResponse>(
  url: string,
  // `RequestInit` is a type for configuring 
  // a `fetch` request. By default, an empty object.
  config: RequestInit = {}
   
// This function is async, it will return a Promise:
): Promise<TResponse> {
    
  // Inside, we call the `fetch` function with 
  // a URL and config given:
  return fetch(url, config)
    // When got a response call a `json` method on it
    .then((response) => response.json())
    // and return the result data.
    .then((data) => data as TResponse);
    
    // We also can use some post-response
    // data-transformations in the last `then` clause.
}


Now we can call this function as we would call 

request<User>('/api/users/42').then(user => {
  // Now, however, a `user` variable has the `User` type.
})

const user = await request<User>('/api/users/42');

 function doesn't handle errors. To solve that we have 2 options:

There are no obligatory rules for this but 

 tells us not to mix those concerns in a single function.

However, we will take a look at both ways. The first one is to handle errors inside of the 

function request<TResponse>(
  url: string, 
  config: RequestInit
): Promise<TResponse> {
  return fetch(url, config)
    .then(response => response.json())
    .then(data => data)
    .catch(error => {
      // Handle the error.
    })
}

 to handle unresolved promises. There is a catch though (no pun intended).

The first issue we can solve making the function 

async function request<TResponse>(
  url: string, 
  config: RequestInit
): Promise<TResponse> {
  try {
    const response = await fetch(url, config);
    return await response.json();
  }
  catch (error) {
    // Handle the error.
  }
}

However, this doesn't solve the second issue with not knowing how to handle the error. We can handle some basic network errors (Page Not Found, Bad Request) but we cannot handle any business-logic errors.

 approach, we can handle errors outside of the 

async function request<TResponse>(
  url: string, 
  config: RequestInit
): Promise<TResponse> {
  const response = await fetch(url, config);
  return await response.json();
}

// Handling errors outside:
(async () => {
  try {
    const user = await request<User>('/api/users/42');
  }
  catch (error) {
    // Handle any error happened.
  }
})()

We can also pre-define some basic request-methods, like 

const api = {
  get: <TResponse>(url: string) => 
  	request<TResponse>(url),
  
  // Using `extends` to set a type constraint:
  post: <TBody extends BodyInit, TResponse>(url: string, body: TBody) => 
  	request<TResponse>(url, { method: 'POST', body }),
}

const user = await api.get<User>('/api/users/42');

<h1 data-node-type="titlePlaceholder" class="titlePlaceholder">How to Use <code>fetch</code> with TypeScript</h1><p>The main problem with <code>fetch</code> function is that it isn't a <a href="https://www.newline.co/@bespoyasov/how-to-use-generics-in-typescript--c9b8f89f" target="_blank" rel="noopener noreferrer nofollow">generic function</a>. This makes it harder to type response data without writing additional wrappers.</p><div style="
          min-height: 256px;
          max-width: 100%;
            "><textarea data-iscodemirror="true" class="d-none" data-mode="text/typescript" data-uniqueid="cm-Dj0Fq" id="cm-Dj0Fq">type User = {
  name: string;
  age: number;
}

// This won't work.
fetch&lt;User&gt;('/api/user/42').then(user =&gt; {
  
  // `user` will be of `unknown` type.
})</textarea></div><p>We can create a wrapper-module to avoid this problem.</p><h2 class="heading-anchor-text" id="wrapper-module"><span>Wrapper Module</span><a class="d-inline heading-anchor" title="Direct link to heading" href="#wrapper-module">#</a></h2><p>Let's create a function <code>request</code> that will handle network requests:</p><div style="
          min-height: 568px;
          max-width: 100%;
            "><textarea data-iscodemirror="true" class="d-none" data-mode="text/typescript" data-uniqueid="cm-71MfT" id="cm-71MfT">// Make the `request` function generic
// to specify the return data type:
function request&lt;TResponse&gt;(
  url: string,
  // `RequestInit` is a type for configuring 
  // a `fetch` request. By default, an empty object.
  config: RequestInit = {}
   
// This function is async, it will return a Promise:
): Promise&lt;TResponse&gt; {
    
  // Inside, we call the `fetch` function with 
  // a URL and config given:
  return fetch(url, config)
    // When got a response call a `json` method on it
    .then((response) =&gt; response.json())
    // and return the result data.
    .then((data) =&gt; data as TResponse);
    
    // We also can use some post-response
    // data-transformations in the last `then` clause.
}
</textarea></div><p>Now we can call this function as we would call <code>fetch</code>:</p><div style="
          min-height: 88px;
          max-width: 100%;
            "><textarea data-iscodemirror="true" class="d-none" data-mode="text/typescript" data-uniqueid="cm-PF3N8" id="cm-PF3N8">request&lt;User&gt;('/api/users/42').then(user =&gt; {
  // Now, however, a `user` variable has the `User` type.
})</textarea></div><p>Or, since it is an <code>async</code> function we can use <code>await</code>:</p><div style="
          min-height: 40px;
          max-width: 100%;
            "><textarea data-iscodemirror="true" class="d-none" data-mode="text/typescript" data-uniqueid="cm-cLGul" id="cm-cLGul">const user = await request&lt;User&gt;('/api/users/42');</textarea></div><h2 class="heading-anchor-text" id="error-handling"><span>Error Handling</span><a class="d-inline heading-anchor" title="Direct link to heading" href="#error-handling">#</a></h2><p>Right now the <code>request</code> function doesn't handle errors. To solve that we have 2 options:</p><ul><li><p>Handle errors inside of the <code>request</code> function;</p></li><li><p>Let another module handle errors.</p></li></ul><p>There are no obligatory rules for this but <a href="https://en.wikipedia.org/wiki/Single-responsibility_principle" target="_blank" rel="noopener noreferrer nofollow">Single Responsibility Principle</a> tells us not to mix those concerns in a single function.</p><p>However, we will take a look at both ways. The first one is to handle errors inside of the <code>request</code> function:</p><div style="
          min-height: 280px;
          max-width: 100%;
            "><textarea data-iscodemirror="true" class="d-none" data-mode="text/typescript" data-uniqueid="cm-oR02A" id="cm-oR02A">function request&lt;TResponse&gt;(
  url: string, 
  config: RequestInit
): Promise&lt;TResponse&gt; {
  return fetch(url, config)
    .then(response =&gt; response.json())
    .then(data =&gt; data)
    .catch(error =&gt; {
      // Handle the error.
    })
}</textarea></div><p>We can use <code>catch</code> to handle unresolved promises. There is a catch though (no pun intended).</p><ul><li><p>We can pass incorrect arguments to <code>fetch</code> and error will arise before the very first <code>then</code>;</p></li><li><p>We may even not know how to handle an error in <code>catch</code> yet ¯\_(ツ)_/¯ </p></li></ul><p>The first issue we can solve making the function <code>async</code> and using <code>try-catch</code>:</p><div style="
          min-height: 304px;
          max-width: 100%;
            "><textarea data-iscodemirror="true" class="d-none" data-mode="javascript" data-uniqueid="cm-5Xf60" id="cm-5Xf60">async function request&lt;TResponse&gt;(
  url: string, 
  config: RequestInit
): Promise&lt;TResponse&gt; {
  try {
    const response = await fetch(url, config);
    return await response.json();
  }
  catch (error) {
    // Handle the error.
  }
}</textarea></div><p>However, this doesn't solve the second issue with not knowing how to handle the error. We can handle some basic network errors (Page Not Found, Bad Request) but we cannot handle any business-logic errors.</p><p>With <code>async/await</code> approach, we can handle errors outside of the <code>request</code> function:</p><div style="
          min-height: 424px;
          max-width: 100%;
            "><textarea data-iscodemirror="true" class="d-none" data-mode="javascript" data-uniqueid="cm-bIcpb" id="cm-bIcpb">async function request&lt;TResponse&gt;(
  url: string, 
  config: RequestInit
): Promise&lt;TResponse&gt; {
  const response = await fetch(url, config);
  return await response.json();
}

// Handling errors outside:
(async () =&gt; {
  try {
    const user = await request&lt;User&gt;('/api/users/42');
  }
  catch (error) {
    // Handle any error happened.
  }
})()</textarea></div><h2 class="heading-anchor-text" id="api-module"><span><code>API</code> Module</span><a class="d-inline heading-anchor" title="Direct link to heading" href="#api-module">#</a></h2><p>We can also pre-define some basic request-methods, like <code>get</code> and <code>post</code>:</p><div style="
          min-height: 208px;
          max-width: 100%;
            "><textarea data-iscodemirror="true" class="d-none" data-mode="text/typescript" data-uniqueid="cm-Ytqhv" id="cm-Ytqhv">const api = {
  get: &lt;TResponse&gt;(url: string) =&gt; 
  	request&lt;TResponse&gt;(url),
  
  // Using `extends` to set a type constraint:
  post: &lt;TBody extends BodyInit, TResponse&gt;(url: string, body: TBody) =&gt; 
  	request&lt;TResponse&gt;(url, { method: 'POST', body }),
}</textarea></div><p>We will use them like this:</p><div style="
          min-height: 40px;
          max-width: 100%;
            "><textarea data-iscodemirror="true" class="d-none" data-mode="text/typescript" data-uniqueid="cm-xVVau" id="cm-xVVau">const user = await api.get&lt;User&gt;('/api/users/42');</textarea></div><h2 class="heading-anchor-text" id="key-takeaways"><span>Key Takeaways</span><a class="d-inline heading-anchor" title="Direct link to heading" href="#key-takeaways">#</a></h2><ul><li><p>The <code>fetch</code> function is not generic. </p></li><li><p>To type the response result we need to create a wrapper generic-function ourselves.</p></li><li><p>We can handle errors in that same wrapper or outside. Either approach has pros and cons.</p></li><li><p>We can use <code>then</code> as well as <code>await</code> with Promise-based functions but <code>await</code> is a bit more convenient when it comes to error handling.</p></li></ul><h2 class="heading-anchor-text" id="sources"><span>Sources</span><a class="d-inline heading-anchor" title="Direct link to heading" href="#sources">#</a></h2><ul><li><p><a href="https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API" target="_blank" rel="noopener noreferrer nofollow">Fetch API</a></p></li><li><p><a href="https://www.newline.co/@bespoyasov/how-to-use-generics-in-typescript--c9b8f89f" target="_blank" rel="noopener noreferrer nofollow">How to User Generics in TypeScript</a></p></li><li><p><a href="https://en.wikipedia.org/wiki/Single-responsibility_principle" target="_blank" rel="noopener noreferrer nofollow">Single Responsibility Principle</a></p></li></ul><p></p>

AUTHOR

Alex Bespoyasov

The main problem with fetch function is that it isn't a generic function. This makes it harder to type response data without writing additional wrappers. We can create a wrapper-module to avoid this problem. Let's create a function request that will handle network requests:

Learn

The newline Guide to Building Your First GraphQL Server with Node and TypeScript

Teach

Amelia Wattenberger

Author of Fullstack D3

Community

Free Tools

How to Use fetch with TypeScript

Tags

Responses (8)

Free AI Career Tools

AI Job Listings

ATS Resume Checker

Startup Perks

Masterclasses

Tutorials

Fullstack React with TypeScript