
I have worked on a project called [Supabase-Query](https://github.com/HermanNygaard/supabase-query)
lately which combines React-Query and Supabase,
which I've been writing some integration tests for. In this tutorial,
I'll go through how I tested React and Supabase by using
React Testing Library and Mock Service Worker.

I will use Vite with Vitest for this tutorial, but the concepts can be applied to any framework.
The source code for the final code can be found
[here](https://github.com/HermanNygaard/react-supabase-testing-example).  
If you want to follow along, run these commands:

```
  yarn create vite supabase-testing --template react;
  cd supabase-testing;
  yarn;
  yarn add @supabase/supabase-js;
```

## Writing our todo app

For this app I have a table in Supabase named `todos` with the
columns `id` (autogenerated) and `name` (text).

Now let's write the React code!  
`App.jsx`:

```tsx
import "./App.css";
import { createClient } from "@supabase/supabase-js";
import { useEffect, useState } from "react";
const supabaseUrl = import.meta.env.VITE_SUPABASE_URL;
const supabaseAnonKey = import.meta.env.VITE_SUPABASE_KEY;

const supabase = createClient(supabaseUrl, supabaseAnonKey);

function App() {
  const [todos, setTodos] = useState([]);
  const [loading, setLoading] = useState(true);
  const [inputValue, setInputValue] = useState("");

  useEffect(() => {
    supabase
      .from("todos")
      .select()
      .then((res) => {
        setTodos(res.data);
        setLoading(false);
      });
  }, []);

  async function onSubmit(e) {
    e.preventDefault();
    await supabase.from("todos").insert({ name: inputValue });
    // Revalidate the todos table.
    // Ideally you'd use a server state manager that handles
    // this for you, like supabase-query
    const newTodos = await supabase.from("todos").select();
    setInputValue("");
    setTodos(newTodos.data);
  }

  return (
    <div>
      {loading ? (
        <p>Loading...</p>
      ) : (
        <div>
          {todos?.map((todo) => (
            <p key={todo.id}>{todo.name}</p>
          ))}
        </div>
      )}
      <form onSubmit={onSubmit}>
        <input
          aria-label="Todo name"
          value={inputValue}
          onChange={(e) => setInputValue(e.target.value)}
        />
        <button>Add todo</button>
      </form>
    </div>
  );
}

export default App;
```

This is a simple app that fetches our todos and displays them,
and a form for adding new todos.

Now add a `.env` file in your project root with the variables for your Supabase database:

```
VITE_SUPABASE_URL=https://foobarbaz.supabase.co
VITE_SUPABASE_KEY=eyJhbGciOiJIUzI1NiIsInR5c...
```

By using env variables for the supabase URL, we will
automatically intercept the correct Supabase URL
in our MSW handlers as we'll see in a second.
Feel free to make a dedicated `.env.test` file as well with these variables, but it's not
necessary for this tutorial.

## Setting up the test environment

Let's install the dependencies we need and setup Vitest in our Vite project.

```
yarn add -D vitest @testing-library/jest-dom @testing-library/react jsdom msw
```

Change your `vite.config.js`:

```diff
export default defineConfig({
  plugins: [react()],
+ test: {
+   globals: true,
+   environment: 'jsdom',
+  },
});
```

Globals makes the Vitest functions global, and
jsdom enables HTML in Vitest.

Finally add a `test` script to the `package.json`:

```diff
{
  "scripts": {
    "dev": "vite",
+   "test": "vitest",
    ...
  }
}
```

## Inspecting the Supabase client

To be able to capture the requests the Supabase client makes internally, we can inspect
the network requests being made in our app.
We see that the URL is formatted like this: `{supabaseurl}/rest/v1/{table}`. Great! We now have
a specific URL to intercept for our mock endpoint.
Next let's mock the responses from MSW in the same format which the
Supabase client expects. This is super simple for our table `select()` usage above,
Supabase just expects an array of objects of containing our table rows. With this, let's
write some tests!

## Writing our first test

`App.test.jsx`:

```tsx
import {
  fireEvent,
  render,
  screen,
  waitForElementToBeRemoved,
} from "@testing-library/react";
import { rest } from "msw";
import { setupServer } from "msw/node";
import App from "./App";
import { expect, afterEach } from "vitest";
import "@testing-library/jest-dom";

// The same URL is used when we call Supabase createClient in App.jsx,
// which makes us intercept the right URL in MSW
const SUPABASE_URL = import.meta.env.VITE_SUPABASE_URL;

// Mock todos rows response
const todos = [{ id: 1, name: "Do laundry" }];

const server = setupServer(
  rest.all(`${SUPABASE_URL}/rest/v1/todos`, async (req, res, ctx) => {
    switch (req.method) {
      case "GET":
        return res(ctx.json(todos));
      default:
        return res(ctx.json("Unhandled method"));
    }
  })
);

// Ideally you'd move this to a setupTests file
beforeAll(() => server.listen());
afterEach(() => server.resetHandlers());
afterAll(() => server.close());

test("fetches and displays Todos", async () => {
  render(<App />);
  await waitForElementToBeRemoved(() => screen.queryByText("Loading..."));
  expect(await screen.findByText(todos[0].name)).toBeInTheDocument();
});
```

Here we are creating our server, then in our test waiting for the loading
text to disappear and then asserting that the todo is displayed.

Finally, run your test with `yarn test` and see that it passes as expected! ✅

## Testing insertions

Now let's see how we can write a test for adding a new todo.
Again, let's inspect the network request and see what Supabase does
on insertions. We see that it uses the same endpoint, but with a `POST`
that simply has a JSON body containing our inserted data.
In our case: `{ "name": "New todo" }`.
With this, let's modify our handler to handle POST requests:

```ts
const server = setupServer(
  rest.all(`${SUPABASE_URL}/rest/v1/todos`, async (req, res, ctx) => {
    switch (req.method) {
      case "GET":
        return res(ctx.json(todos));
      case "POST":
        const body = await req.json();
        const newTodo = { ...body, id: 2 };
        todos.push(newTodo);
        return res(ctx.json(newTodo));
      default:
        return res(ctx.json("Unhandled method"));
    }
  })
);
```

Note that we are mutating the todos array above which will affect
tests run after this one if using this variable.
If you want you can reset it to it's initial value with e.g. an `afterEach` function.

Then let's write our test:

```tsx
test("adds a new todo", async () => {
  const newTodoName = "Buy groceries";
  render(<App />);
  const todoNameInput = screen.getByLabelText("Todo name");
  const addTodoButton = screen.getByRole("button");
  // Type in the new todo name and submit the form
  fireEvent.change(todoNameInput, { target: { value: newTodoName } });
  fireEvent.click(addTodoButton);
  // Wait for the new todo to be rendered
  expect(await screen.findByText(newTodoName)).toBeInTheDocument();
});
```

Here we are entering the new todo name in the input, submitting and
asserting that the new todo is rendered.  
Cool! We have now successfully tested that adding a new todo works as expected. 🎉

## Wrapping up

Thats it! Although our example is fairly simple, this should give you a good foundation to
build on for handling more complex scenarios.



Getting a fully functional dark mode is super easy with Tailwind.

First, add this to your `tailwind.config.js` file:

```js
module.exports = {
  ...
  darkMode: "class",
};
```

Then add global light/dark styles to your index stylesheet in your app:
(hint: put this in the same file where you have the `@tailwind base` config,
if you are using next.js, it's the stylesheet being imported in `_app.jsx` and for create-react-app `index.js`)

```css
@tailwind base;
@tailwind components;
@tailwind utilities;

@layer base {
  body {
    @apply bg-white dark:bg-slate-800 text-black dark:text-white;
  }
}
```

Now for the fun part, let's implement the logic and a toggle button looking like this:

<DarkmodeSwitch />
[If you just want to skip to the final code, click here](#full-code)

Let's create a new component called `DarkmodeSwitch`:

```jsx
export function DarkmodeSwitch() {
  const [isDarkMode, setIsDarkMode] = useState(false);
  return <button>{isDarkMode ? "Dark mode" : "Light mode"}</button>;
}
```

Add an onClick handler to toggle between the modes, let's also store it in localStorage for later.

```jsx
const handleClick = () => {
  if (isDarkMode) {
    window.document.documentElement.classList.remove("dark");
    localStorage.setItem("theme", "light");
  } else {
    localStorage.setItem("theme", "dark");
    window.document.documentElement.classList.add("dark");
  }
  setIsDarkMode(!isDarkMode);
};
```

Add an useEffect to initially check what our users stored preference is:

```jsx
useEffect(() => {
  const theme = localStorage.getItem("theme");
  if (theme === "dark") {
    window.document.documentElement.classList.add("dark");
    setIsDarkMode(true);
  }
}, []);
```

Finally let's add some cool icons and styling, and we get our finished code:

## Full code

```jsx
import { useEffect, useState } from "react";

const Moon = () => (
  <svg
    xmlns="http://www.w3.org/2000/svg"
    className="h-5 w-5"
    viewBox="0 0 20 20"
    fill="currentColor"
  >
    <path d="M17.293 13.293A8 8 0 016.707 2.707a8.001 8.001 0 1010.586 10.586z" />
  </svg>
);

const Sun = () => (
  <svg
    xmlns="http://www.w3.org/2000/svg"
    className="h-5 w-5"
    viewBox="0 0 20 20"
    fill="currentColor"
  >
    <path
      fillRule="evenodd"
      d="M10 2a1 1 0 011 1v1a1 1 0 11-2 0V3a1 1 0 011-1zm4 8a4 4 0 11-8 0 4 4 0 018 0zm-.464 4.95l.707.707a1 1 0 001.414-1.414l-.707-.707a1 1 0 00-1.414 1.414zm2.12-10.607a1 1 0 010 1.414l-.706.707a1 1 0 11-1.414-1.414l.707-.707a1 1 0 011.414 0zM17 11a1 1 0 100-2h-1a1 1 0 100 2h1zm-7 4a1 1 0 011 1v1a1 1 0 11-2 0v-1a1 1 0 011-1zM5.05 6.464A1 1 0 106.465 5.05l-.708-.707a1 1 0 00-1.414 1.414l.707.707zm1.414 8.486l-.707.707a1 1 0 01-1.414-1.414l.707-.707a1 1 0 011.414 1.414zM4 11a1 1 0 100-2H3a1 1 0 000 2h1z"
      clipRule="evenodd"
    />
  </svg>
);

export function DarkmodeSwitch() {
  const [isDarkMode, setIsDarkMode] = useState(false);

  useEffect(() => {
    const theme = localStorage.getItem("theme");
    if (theme === "dark") {
      window.document.documentElement.classList.add("dark");
      setIsDarkMode(true);
    }
  }, []);

  const handleClick = () => {
    if (isDarkMode) {
      window.document.documentElement.classList.remove("dark");
      localStorage.setItem("theme", "light");
    } else {
      localStorage.setItem("theme", "dark");
      window.document.documentElement.classList.add("dark");
    }
    setIsDarkMode(!isDarkMode);
  };

  return (
    <button
      className="text-gray-400 hover:bg-slate-200 p-2 flex items-center justify-center rounded-md dark:hover:bg-slate-700"
      onClick={handleClick}
      aria-label={`Toggle ${isDarkMode ? "light" : "dark"} mode`}
    >
      {isDarkMode ? <Sun /> : <Moon />}
    </button>
  );
}
```

[The source code can also be found here](https://github.com/HermanNygaard/nygaard.dev/blob/main/src/components/DarkmodeSwitch.tsx)

## Wrapping up

Thats it! We could improve this further by on default use the preferred browser theme, and also avoiding a flash of light
if using SSG/SRR, but this should get you pretty far for now.
[I also recommend this brilliant post by joshwcomeu](https://www.joshwcomeau.com/react/dark-mode/)



Storing all your configs in a single place makes changing between Macs a breeze.
In this article I'll explain how I store my dotfiles for easy version control and some of the tools I use.
For now it's the bare necessities but it gets the job done.  
[My dotfiles can be found here](https://github.com/HermanNygaard/dotfiles) (feel free to fork it!)

## Symlinking with GNU Stow

Stow is a neat little program that creates symlinks to my home directory from `~/.dotfiles` by structuring
files the same way you would in your home directory:

```
~ /.dotfiles/
  - zsh/.zshrc
  - nvim/.config/nvim
```

As you can see the directory names (zsh, nvim) are just used to help you organize your dotfiles,
while the content inside is what will get symlinked to your ~ directory.  
An example:  
Zsh saves it's config directly under your home dir, `~/.zshrc`, while nvim saves its config
under `~/.config/nvim` which is why we use `.config` as the second part of the path.

After running `stow zsh && stow nvim` ~ will have these symlinks:

```
~ /
 - .zshrc
 - .config/nvim
```

This way one can easily edit and version control dotfiles in the ` ~/.dotfiles/` directory.

## Homebrew and Brewfile

To manage my packages I use Homebrew.
All installed packages can be stored in a `Brewfile`, a file with all your brew packages listed.
The command `brew bundle dump --describe` will create a Brewfile. The `describe` flag adds a short comment over
each line describing what the package does.  
Then run `brew bundle` to install all packages.  
By having a `.Brewfile` in your ~ directory it will be used as a global file,
which is convenient so you can run `bundle` or `bundle dump` anywhere with the `--global` flag.

Some apps I have in my Brewfile and recommend are:

- Rectangle, my favorite window manager for macOS
- iTerm, terminal emulator

## Visual Studio Code

For VS Code it seems like the easiest option simply is to use the Settings Sync feature in VS Code.
I would prefer a config file that you could dump all settings and extensions into, but couldn't
find an easy way to do this.

## Setup script

In the README I have a simple script you can run from a brand new Mac:

```bash
# Installs git
xcode-select --install
git clone https://github.com/HermanNygaard/dotfiles.git ~/.dotfiles
cd ~/.dotfiles; source setup.sh
```

Here is the `setup.sh` script, which installs all Brew packages as well as ohmyzsh:

```
#!/usr/bin/env zsh

echo ">>>>>Installing homebrew"
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)" </dev/null ## /dev/null skips pressing enter for the installation
brew bundle --file=~/.dotfiles/homebrew/.Brewfile

sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"
```

## Future endeavours

As my time was fairly limited when setting this up I still have some things left I want to look into:

- Create a simple script to run stow on all my directories in the setup script
- Native MacOS settings
- iTerm settings



Hello and welcome!  
I mainly made this blog to learn more about MDX and Tailwind, as well as a place for
myself to index and look back on for recaps on topics I found interesting,
such as [dotfiles for macOS](/blog/macos-dotfiles).

## Tech

The site uses Next.js with SSG and MDX to generate the posts and corresponding routes
directly from markdown files in the source code. It uses Tailwind for styling
and is for the time being hosted on Vercel.  
[Source can be found here](https://github.com/HermanNygaard/nygaard.dev)


Blog