DEV Community: Riku Rouvila

How to use a Github Gist as a free database

Riku Rouvila — Tue, 26 Jan 2021 11:56:37 +0000

Are you looking for a free and quick to set up service to persist (temporary) data? This article is for you. You've probably used gists before, but how about using one as a data storage?

Here's the easiest setup for storing information for small hobby projects. Yeah, it goes without saying – this isn't a real database nor something you should use for production applications. However, for hobby projects, this is an easy and completely free way to store information.

Something worth mentioning is that the data you store in secret gists is available in the public without authentication so this is not a good place to store any secrets.

I'm using this approach in a few of my projects to store not-that-critical information like the channels my chatbot is in or the reminder data of a Reddit reminder bot.

Here's how it works

Create a new secret gist
Create a file called db.json inside of it. Make it an empty object {}.
Get yourself a personal Github access token here. gist is the only scope you should need.

const TOKEN = "YOUR_PERSONAL_ACCESS_TOKEN";
const GIST_ID = "YOUR_GIST_ID";
const GIST_FILENAME = "db.json";

/* 
 * Reads the JSON file inside of the gist
 */
async function getData() {
  const req = await fetch(`https://api.github.com/gists/${GIST_ID}`);
  const gist = await req.json();
  return JSON.parse(gist.files[GIST_FILENAME].content);
}

/* 
 * Puts the data you want to store back into the gist
 */
async function setData(data) {
  const req = await fetch(`https://api.github.com/gists/${GIST_ID}`, {
    method: "PATCH",
    headers: {
      Authorization: `Bearer ${TOKEN}`,
    },
    body: JSON.stringify({
      files: {
        [GIST_FILENAME]: {
          content: JSON.stringify(data),
        },
      },
    }),
  });

  return req.json();
}

What I learned from building a Telegram bot on Next.js

Riku Rouvila — Fri, 25 Dec 2020 17:36:32 +0000

The future is now 🚀 Get yourself a cool sticker T-Shirt without never leaving Telegram. I wanted to try out Telegram Bot API's Payments feature so I built @StickerShirtsBot. It also comes with a frontend app stickershirts.com.

How does it work?

You send a sticker to @StickerShirtsBot, our API generates a mockup image of the result and sends it back to you. After you choose the colour and the size of the shirt you want, the bot sends you an order invoice. You input your address details and pay the order (all inside Telegram). Your order gets sent to Printful, we manually approve it for printing and the printed organic cotton T-Shirt gets automatically sent to you.

Technology

Telegram Payments
Next.js
Vercel
Jimp
Firestore
Google Cloud Storage

Next.js is a great tool for a variety of projects

Next.js might be a bit of an overkill for a chatbot, but I figured having it as an easy, standardised framework for building a function-based REST API is a good idea. Similar to Serverless framework, I like how you can deploy it anywhere and there's everything ready for building a frontend.

In my case, I'm using Telegram API's webhook feature to receive all messages sent to the bot. As most of the development work is done locally, my development bot is registered to push events to my local Next.js through ngrok endpoint.

Vercel's hobby plan might not be enough

Functions in hobby plan can only run for 10 seconds. Generating the mockup image from the sticker usually takes less than that, but there's always a chance for it taking longer. This means that sometimes the requests would fail before the user gets their mockup.

Moving the project over to a team account wasn't trivial either. Instead of a transfer feature, you have to remove the project from your account and import it manually to the new team account

Github Actions are a great companion for Vercel's hobby plan

If you wanna stick to the free hobby plan, you might want to consider an alternative solution for long-running jobs. Github actions is a good option for this.

You probably need a static file storage

Telegram caches images indefinitely, so in an ideal case, I could have generated the images to a /tmp directory temporarily and serve them once to Telegram when it requests the image. Unfortunately in the serverless world, there are no guarantees that the same /tmp directory is available when the request eventually gets made.

I first went with S3, which I then later on discarded for Google's Cloud Storage. For some reason writing to S3 sometimes took over 4 seconds for 200kB files.

Give the Telegram bot a try and tell me what you think!

How to trigger a Github action with an HTTP request

Riku Rouvila — Fri, 06 Nov 2020 17:49:27 +0000

1. Create a new action with `repository_dispatch` trigger

Make sure your action is set to trigger on repository_dispatch event. This is the same event used when triggering the action through the UI.

name: Node.js CI

on:
  repository_dispatch:
  schedule:
    - cron: '5 12 * * 0'

jobs:
  build:
    runs-on: ubuntu-latest

2. Get yourself a personal access token to use the Github API

You can create one here: https://github.com/settings/tokens

Make sure you add repo and workflow permissions

3. Create the HTTP request

https://docs.github.com/en/free-pro-team@latest/rest/reference/actions#create-a-workflow-dispatch-event

POST https://api.github.com/repos/<username>/<repo>/dispatches
Authorization: Bearer <Your personal access token here>

{"event_type": "hello"}

cURL

curl --request POST \
  --url 'https://api.github.com/repos/<USERNAME>/<REPO>/dispatches' \
  --header 'authorization: Bearer <TOKEN>' \
  --data '{"event_type": "hello"}'

Sources

Which technologies would you choose for your next web project?

Riku Rouvila — Sat, 08 Aug 2020 17:16:32 +0000

So you're building an app consisting of a UI and potentially an API as well. What are some excellent default technology choices that are easy to use, scalable and in line with the technology used by the rest of the industry?

In this article, I'll go through some technology choices that I'd pick for my next JavaScript project. Leave a comment and let me know how your stack would look like 😍

1. 🏰 Language - TypeScript

It's worth it. Everyone struggles with it at first, and you may even question if it's worth the (temporary) productivity loss. Very few would go back to writing plain JavaScript after they are fluent with it. It makes reading and writing code a lot easier + you get safety against human errors from the compiler.

2. 🦄 React + Next.js

React is a well-documented, battle-tested and an industry-standard library for building user interfaces in the web. There's a massive ecosystem around it and most UI components you can find already implemented from npm.

I often hear people asking if there's a good boilerplate out there for web projects. Kind of like create-react-app, but with a backend. Next.js does precisely this and more.

Next.js includes the following out of the box, pre-configured and ready to rock:

Routing
Static site rendering
Server-side rendering
Bundle splitting

One of the things I really enjoy about Next.js is the fact that API endpoints are defined as plain functions – just like you'd do with the Serverless framework or similar. I think this is huge. Next.js is easiest deployed to http://now.sh/, but nothing is stopping you from deploying it to AWS for instance. There's actually a Serverless component meant for precisely this.

You get so many benefits using Next.js as a project boilerplate that it's tough to argue why you wouldn't use it.

3. 🚢 Data storage - PostgreSQL

Choosing a database should always be done based on the structure and relations of the data you intend to store and how it's accessed and manipulated. That being said, in many cases, PostgreSQL is a great place to start.

For a Node.js client, I'd recommend
https://github.com/adelsz/pgtyped

Writing SQL queries to .sql files is way nicer than using an ORM or a query builder such as Knex + you get TypeScript types that always match the schema you have in your database.

4. 👮‍♂️ Input validation - Yup or Zod

https://github.com/jquense/yup
https://github.com/vriad/zod

You can get by with no input validation library. However, as your application gets more and more API endpoints that modify your data, it's good to find an abstraction you can share throughout the codebase to validate user input. Both of these validation libraries support TypeScript, which will make your life a lot easier. As we're living in the age of TypeScript, your compiler can do some of that validation before you deploy your app.

5. 🎨 Styling - styled-jsx or Tailwind

6. 🔐 Authentication & Authorisation - Auth0

7. 📝 Logging & Error management - Sentry

8. 🧪 Testing - Jest, react-testing-library and Cypress

What else? What would you do differently? Leave a comment and let me know!

Practical advanced TypeScript - Writing a function wrapper

Riku Rouvila — Sat, 08 Aug 2020 16:54:06 +0000

Typing a wrapper function for fetch

A while back, I needed a function that would behave like fetch does, but so it would always have specific headers set to make it easier for the consumer. I also wanted to have the possibility to add more defaults as I go and to create variations of this function as some of our API endpoints were returning JSON and some plain text.

For this, I decided to create a function, that would accept the fetch function as an argument and would return a new instance of said function with given defaults pre-applied.

const fetchWithJSONHeaders = applyDefaults(fetch, {
  headers: {
    "Content-Type": "application/json"
  }
});

const fetchWithTextHeaders = applyDefaults(fetch, {
  headers: {
    "Content-Type": "application/text"
  }
});

// Fetch JSON content
const response = await fetchWithJSONHeaders("/users", {
  method: "GET" 
});

Function type as a parameter type

So let's start from figuring out how we could use window.fetch's signature as a parameter type of the function.

function applyDefaults(fetchFn: /* ??? */, ...)

Nothing stops you from just defining the type manually:

function applyDefaults(fetchFn: (url: string, options: object) => Promise<any>, ...)

However there's a downside – you now have a new type to keep up to date with changes in fetch's signature. It's can also be a bit difficult to make it exactly how fetch's signature is.

Luckily for us, TypeScript comes with a built-in typeof operator that you can use precisely for this.

function applyDefaults(fetchFn: typeof fetch, ...)

So now we have our first parameter solved 🏆 Now your function only accepts functions that have the precisely same signature as fetch.

Reading function parameter types

Onto the second parameter. You want the parameter to accept all the options fetch would accept. Let's take a look at how window.fetch is typed:

function fetch(input: RequestInfo, init?: RequestInit | undefined): Promise<Response>

How this we see, that there exists a type RequestInit that we could use for our function as well

function applyDefaults(fetchFn: typeof fetch, defaults: RequestInit)

Using the underlying types directly like this is in most cases the best way to go.

In rare cases, the underlying types aren't exposed from the library. What shall we do then? Maybe we could also use the typeof operator here too and combine it with a TypeScript's built-in type Parameters. Parameters becomes useful whenever you want to extract the type of parameters from a function type:

type FetchParams = Parameters<typeof fetch>

// Is now equal to
type FetchParams = [RequestInfo, (RequestInit | undefined)?]

So the way you would use this in your function definition would be Parameters<typeof fetch>[1]. [1] here is just a way for you to pick the second type from the tuple type you got from Parameters.

So here it is in all of its beauty:

function applyDefaults(fetchFn: typeof fetch, defaults: Parameters<typeof fetch>[1])

Turning optional required

Looking good 😎 There's just one issue tho – the defaults parameter is now optional, as you're picking it directly from fetch. With fetch, you do not always need to define options for the request, but in our case, it doesn't make sense to have it as an optional parameter.

So here's how our type definition looks like at the moment:

function applyDefaults(fetchFn: typeof fetch, defaults: RequestInit | undefined)

How can we turn an optional parameter into a required one? The built-in Required type is there exactly for this.

function applyDefaults(fetchFn: typeof fetch, defaults: Required<Parameters<typeof fetch>[1]>)

And your function definition is done!

You can see the full function definition here:
https://www.typescriptlang.org/play?#code/GYVwdgxgLglg9mABAQwA6oDYE8AiBTYZEDKAZwApg8oIALAMTAC5EotU85hEqbaAaRABMCREqRYAFZACdkAW2p4ZpADxsOXHtToA+ANoBGALoBKRAG8AUIkQzqIGUnIA6N7IDmExNLmKoymoanNy8euYAvLqINrbafOSepPoADMaC5BZuLiKExGSC2UlGxgC+pqYA3FalVlZAA

Why early returns make your code easier to understand

Riku Rouvila — Sun, 26 Jul 2020 12:12:12 +0000

Quite often, I come across if statements starting from the very beginning of the function and stretching to the end.

function upload(file) {
  if (file.size < 9999999) {
    const directory = getStorageDirectory()

    /*
     * ...
     */

    return saveFile(directory + file.name);
  } else {
    throw new Error('File too large')
  }
}

The intention of these if-statements is clear. You want to validate the received input. However, the physical structure of the code used for this constraint is not optimal as it takes over way more area than it should be responsible for. Having to indent the whole function body because of this is a clear symptom of something being off.

Also, having the start of the structure so far away from the end of it is almost like reading a very long sentence. By the time you get to the end, you've already forgotten what was said in the beginning.

From this:

function upload(file) {
  if (file.size < 9999999) {
    if (file.name.length > 5) { 
      if (file.format === 'jpeg') {
        saveFile('jpegs/' + file.name);
      } else {
        saveFile('others/' + file.name);
      }
    }
  }
}

To this:

function upload(file) {
  if (file.size >= 9999999) {
    return;
  }

  if (file.name.length <= 5) {
    return;
  }

  if (file.format === 'jpeg') {
    saveFile('jpegs/' + file.name);
    return;
  }

  saveFile('others/' + file.name);
}

Explanation

1. Always avoid nesting if statements

In most cases, it's not needed. Often it's a sign that conditions should be either flipped (take a look at what happens to if (file.size < 9999999)) or combined.

1.1. Define parameter boundaries early, maximise happy code

Notice also that by doing this, we can draw a line between dangerous code, where we're unsure about the validity of our parameters and the happy code where we know the input is always valid. Happy code is easier to both read and write, and we aim to maximise the amount of it.

1.2. Validate as soon as you can

In this example, we would ideally want to validate the file parameter before it hits this function. That way we could drop the if statements altogether. We could do this, for example, in the function calling this function. Or even the function calling that one. Ideally, we wouldn't have invalid files in our application at all!

👍 As a rule of thumb:
Validate user-inputted parameters as soon as they reach your code.

function upload(file) {
-   if (file.size < 9999999) {
-     /* 1. */
-     if (file.name.length > 5) { 
-       if (file.format === 'jpeg') {
-         saveFile('jpegs/' + file.name);
-       /* 2. */
-       } else {
-         saveFile('others/' + file.name);
-       }
-     }
+   if (file.size >= 9999999) {
+     return;
+   }
+   
+   if (file.name.length <= 5) { 
+     return
+   }
+   if (file.format === 'jpeg') {
+     saveFile('jpegs/' + file.name);
+   /* 2. */
+   } else {
+     saveFile('others/' + file.name);
  }
}

function upload(file) {
  if (file.size >= 9999999) {
    return;
  }

  if (file.name.length <= 5) { 
    return
  }
  if (file.format === 'jpeg') {
    saveFile('jpegs/' + file.name);
  /* 2. */
  } else {
    saveFile('others/' + file.name);
  }
}

2. else is often unnecessary

In this case, getting rid of else by returning from the first branch gets rid of 1 level of indentation. Some linters also complain about this, because the code will be unreachable.

function upload(file) {
  if (file.size >= 9999999) {
    return;
  }

  if (file.name.length <= 5) { 
    return
  }

  if (file.format === 'jpeg') {
    saveFile('jpegs/' + file.name);
- } else {
-   saveFile('others/' + file.name);
+   return;
  }
+   
+  saveFile('others/' + file.name);
}

Why I say it's often unnecessary is that there are cases where it can be argued using else improves readability.

Consider:

if (user) {
  res.send(200)
} else {
  res.send(404)
}

if (user) {
  res.send(200)
  return
} 
res.send(404)

Which one do you prefer? The latter one indeed saves you one indent but adds a return statement that only has the purpose of stopping the function from running.

On useless try-catches, being overly defensive, I/O boundaries and variable scope

Riku Rouvila — Sun, 26 Jul 2020 12:10:21 +0000

Starting point:

async function getUsers() {
  try {
    return await db.select('SELECT * FROM app_users')
  } catch(err) {
    throw err; /* 1. */
  }
}

async function main() {
  try {
    const users = await getUsers()
    console.log(`Ya! We have ${users.length} users!`) /* 2. */
  } catch(err) {
    console.error('Something went wrong..')
  }
}

End result:

function getUsers() {
  return db.select('SELECT * FROM app_users')
}

async function main() {
  let users
  try {
    users = await getUsers()
  } catch(err) {
    console.error('Something went wrong..')
    return
  }
  console.log(`Ya! We have ${users.length} users!`) /* 2. */
}

Step by step

1. If the catch block only rethrows the error, the whole try-catch structure is useless

- async function getUsers() {
-   try {
-     return await db.select('SELECT * FROM app_users')
-   } catch(err) {
-     throw err; /* 1. */
-   }
+ function getUsers() {
+   return db.select('SELECT * FROM app_users')
}

It might be that you used to have some logic inside the catch block, but you removed it and forgot to clean after yourself. Being overprotective with try-catch statements is analogous to if-statements where something is compared to a boolean.

if(variable === true) {

In other words, redundant. Our goal should be to care as little as possible about thrown exceptions and to push exception handling as far up the call stack (as early in execution) as possible. Ideally, our application wouldn't have any try-catch statements.

The theory behind this might be that exception handling is an indicator of side-effects. Because side-effects should be done only at the I/O boundaries of the program, these things would also wrap together quite nicely. Need to clarify my own thinking about this.

1.1 Never await as part of the return expression

With JS promises:

return await db.select('SELECT * FROM app_users')

is the same as:

return db.select('SELECT * FROM app_users')

so I guess we're mostly talking about a syntactical error. This discussion could be expanded to other similar wrapper values, especially lazy ones and how pulling out the value without reason gives less control to the calling function. Now you can get rid of the async keyword as well.

2. The only things allowed in `try {}` block are things that can throw

async function main() {
+   let users
    try {
-     const users = getUsers()
-     console.log(`Ya! We have ${users.length} users!`) /* 2. */
+     users = getUsers()
    } catch(err) {
      console.error('Something went wrong..')
+     return
    }
+   console.log(`Ya! We have ${users.length} users!`) 
}

Don't put anything else in there. console.log can't throw so it needs to be outside. The reason for this is that the reader of your code cannot know which line of code can actually cause an exception. And yeah, of course, they can go into the function definition and have a look, but we don't want to force the reader to do that. Quite the opposite actually: our aim is to write such code that the reader could understand it only by looking at the directory structure.

Of course, by doing this we have to declare the variable outside try {}s scope, which is admittedly ugly and I do not like it either. It's a small cosmetic sacrifice we do for better readability.

React Hook for showing custom "Add to home screen" prompt

Riku Rouvila — Sun, 26 Jul 2020 12:06:00 +0000

Demo:
Twitter

const [prompt, promptToInstall] = useAddToHomescreenPrompt();

Listens for beforeinstallprompt event, which notifies you when the browser would have shown the default dialog,
intercepts it and lets you take over and show the prompt whenever you please.

Browser support and requirements

Add to Home Screen

Browser support is still quite lacking. At the time of writing, only Chrome (Desktop + Android) is supported.

Implementation

import * as React from "react";

interface IBeforeInstallPromptEvent extends Event {
  readonly platforms: string[];
  readonly userChoice: Promise<{
    outcome: "accepted" | "dismissed";
    platform: string;
  }>;
  prompt(): Promise<void>;
}

export function useAddToHomescreenPrompt(): [
  IBeforeInstallPromptEvent | null,
  () => void
] {
  const [prompt, setState] = React.useState<IBeforeInstallPromptEvent | null>(
    null
  );

  const promptToInstall = () => {
    if (prompt) {
      return prompt.prompt();
    }
    return Promise.reject(
      new Error(
        'Tried installing before browser sent "beforeinstallprompt" event'
      )
    );
  };

  React.useEffect(() => {
    const ready = (e: IBeforeInstallPromptEvent) => {
      e.preventDefault();
      setState(e);
    };

    window.addEventListener("beforeinstallprompt", ready as any);

    return () => {
      window.removeEventListener("beforeinstallprompt", ready as any);
    };
  }, []);

  return [prompt, promptToInstall];
}

Example component

import * as React from "react";
import { useAddToHomescreenPrompt } from "./useAddToHomescreenPrompt";

export function ExampleComponent() {
  const [prompt, promptToInstall] = useAddToHomescreenPrompt();
  const [isVisible, setVisibleState] = React.useState(false);

  const hide = () => setVisibleState(false);

  React.useEffect(
    () => {
      if (prompt) {
        setVisibleState(true);
      }
    },
    [prompt]
  );

  if (!isVisible) {
    return <div />;
  }

  return (
    <div onClick={hide}>
      <button onClick={hide}>Close</button>
      Hello! Wanna add to homescreen?
      <button onClick={promptToInstall}>Add to homescreen</button>
    </div>
  );
}

Clean and reusable data fetching in React components

Riku Rouvila — Fri, 24 Jul 2020 16:47:26 +0000

Move as much of the request logic to custom hooks as you can. Use SWR or implement your own hook for requesting data.

Feels as if you're copy and pasting?

Fetching data in React components requires a lot of moving parts – you need to create a side effect, then request the data, then set the response to state (with information whether the request succeeded or if it's still loading) and only then you can use the data in the rendering phase of your component.

This feels like a lot of code (and repetition) to do such a frequent task.

import * as React from "react";
import { useState, useCallback, useEffect } from "react";
import axios from "axios";
import "./styles.css";

const Example = () => {
  const [error, setError] = useState(null);
  const [isLoaded, setIsLoaded] = useState(false);
  const [items, setItems] = useState([]);

  const fetchItems = useCallback(() => {
    axios
      .get("https://jsonplaceholder.typicode.com/todos")
      .then(response => {
        setIsLoaded(true);
        setItems(response.data);
      })
      .catch(error => {
        setError(error);
      });
  }, []);

  useEffect(() => {
    fetchItems();
  }, [fetchItems]);

  if (error !== null) {
    return <div>Error: {error.message}</div>;
  } else if (!isLoaded) {
    return <div>Loading...</div>;
  } else {
    return (
      <div>
        {items.map(item => (
          <div>{item.id}</div>
        ))}
      </div>
    );
  }
};

export default Example;

That's quite a lot 😓

So how could it be made differently? A good idea would be to move the generic parts to a separate module/function from where all components could use them. I'd say the shared concerns here are:

Is the data loaded / loading?
Was the request successful?
How will the data be fetched?

So what if we could move handling all of those concerns out of this component altogether? Then our code would look more like this:

const Example = () => {
  const { data, error, isLoaded } = useApiRequest(
    "https://jsonplaceholder.typicode.com/todos"
  );

  if (error !== null) {
    return <div>Error: {error.message}</div>;
  }
  if (!isLoaded) {
    return <div>Loading...</div>;
  }
  return (
    <div>
      {data.map(item => (
        <div>{item.id}</div>
      ))}
    </div>
  );
};

This how your components should look like ☝️

How does useApiRequest hook work?

You can achieve this with many libraries such as SWR. You can also implement the hook yourself, which might be a good idea, especially if you haven't implemented a custom hook before or are just familiarizing yourself with the use of hooks. Having an understanding of how libraries work internally will help you see them as less magical and more logical.

Your own custom hook could look as simple as this:

const useApiRequest = url => {
  const [data, setData] = useState([]);
  const [isLoaded, setIsLoaded] = useState(false);
  const [error, setError] = useState(null);

  useEffect(() => {
    const fetchData = () => {
      axios
        .get(url)
        .then(response => {
          setIsLoaded(true);
          setData(response.data);
        })
        .catch(error => {
          setError(error);
        });
    };
    fetchData();
  }, [url]);

  return { error, isLoaded, data };
};

So basically almost all the code you used to have in your component, now extracted from there and brought to a new function. Now all you need to do in your component is

const { data, error, isLoaded } = useApiRequest(
  "https://jsonplaceholder.typicode.com/todos"
);

A full code example with refactored data fetching can be found from here: https://codesandbox.io/s/long-frost-qziu4?file=/src/App.js

Enjoy!

How to easily read all data from a ReadableStream?

Riku Rouvila — Wed, 15 Jul 2020 11:12:29 +0000

const chunks = [];
for await (let chunk of readable) {
  chunks.push(chunk);
}
console.log(Buffer.concat(chunks));

Async iterator requires Node.js >=10.0.

So, for example, reading a file would be as easy as:

const fs = require("fs");

async function readFile(filename) {
  const readable = fs.createReadStream(filename);
  const chunks = [];
  for await (let chunk of readable) {
    chunks.push(chunk);
  }
  console.log(Buffer.concat(chunks).toString());
}

readFile("./tsconfig.json");

Which state management library to use with React?

Riku Rouvila — Tue, 14 Jul 2020 22:22:23 +0000

I'd start by not using any state management library. You can use React's built-in state management as long as you're not using the same state in 2 parts of your app. You can ship small apps without having to choose any.

Naturally, the need for sharing state arises sooner or later. This is a good time to consider Recoil. It's easy to learn and doesn't take over your whole codebase. It's also pretty great with TypeScript.

I'd also check out xstate.

What I've tried since React first came out

Flux
Reflux
Redux
Using my own contexts with the hook API
Recoil

Show different error message in React based on fetch status code

Riku Rouvila — Tue, 14 Jul 2020 21:56:05 +0000

So you want to show a different error message in React based on the HTTP status code you got? Try this:

import * as React from "react";

class InvalidRequestError extends Error {
  readonly type = "InvalidRequestError" as const;
}
class UnexpectedError extends Error {
  readonly type = "UnexpectedError" as const;
}

type ResponseError = UnexpectedError | InvalidRequestError;

export default function App() {
  const [error, setError] = React.useState<ResponseError>();

  React.useEffect(() => {
    async function doRequest() {
      const response = await fetch("https://httpstat.us/400");
      if (response.ok) {
        // Store response body normally
        return;
      }
      if (response.status === 400) {
        setError(new InvalidRequestError());
      } else {
        setError(new UnexpectedError());
      }
    }
    doRequest();
  }, []);

  return (
    <div className="App">
      <h1>Error</h1>
      <h2>Status type was: {error && error.type}</h2>
      {error && error.type === "InvalidRequestError"
        ? "Invalid request"
        : "Unexpected error"}
    </div>
  );
}

Why not just store the status code in the component's state?

You totally can. This is just an abstraction one level higher from that. The goal later on for me is to move these fetch-calls to a new module – a module that would only talk in terms of domain language, so:

export async function getUser(id: number) : Promise<User> {
  const response = await fetch("https://api.example.com/user/" + id);
  if (response.ok) {
    // Return the found user object
    return;
  }
  if (response.status === 404) {
    throw new UserNotFound();
  } else {
    throw new UnexpectedError();
  }
}

See what happens here? The caller of this function doesn't (and shouldn't) know anything about HTTP or where the user was gotten from. It could've come through WebSockets for all we know. This means the caller wouldn't have access to the HTTP statuses anymore either, which is a good thing so our HTTP layer doesn't leak to our view layer.

So our first example would turn into something like this

import * as React from "react";
import { getUser, ResponseError } from "./services/users";

export default function App() {
  const [error, setError] = React.useState<ResponseError>();

  React.useEffect(() => {
    async function doRequest() {
      try {
        const user = await getUser(123);  
        // Store the user normally
      } catch (error) {
        setError(error)
      }
    }
    doRequest();
  }, []);

  return (
    <div className="App">
      <h1>Error</h1>
      <h2>Status type was: {error && error.type}</h2>
      {error && error.type === "InvalidRequestError"
        ? "Invalid request"
        : "Unexpected error"}
    </div>
  );
}