
Have you ever started implementing a design only to realize some states were missing? You then went back to your designer to ask, "what should we show if this happens?" I experienced this firsthand many times. The issue is often the same one. When we plan new interfaces, we only think about the happy path.

You should consider five primary UX states when you work on a new interface. Let's see what they are.

## Loading state

Things don't magically appear on the page. They need to be fetched; usually, it takes some time. This is the state that is shown when the app is loading. In most cases, you can implement a simple loading animation and reuse it everywhere. In other cases, you might want a different strategy for each component. Talk to your team and decide.

![](/primary-ux-states/1.png)

## Error state

Well, things don't always go as planned. Nothing to worry about as long as you have a good backup plan. Remember that a good error message informs the user of what happened and gives clear instructions on what to do next. In most cases, a simple reload will fix the problem. It's also a good idea to add some logging about errors so you know when your users are experiencing them.

![](/primary-ux-states/2.png)

## Empty or Initial state

Imagine that your user just onboarded on your project management tool. They go to the list of projects and see… _nothing!_ This case happens quite a lot if you think about it. You want to use the occasion to teach your user how to use your app. A simple button or a link to initiate a new activity will do the trick most of the time.

![](/primary-ux-states/3.png)

## 404 state

This state might sound the same as the Empty state, but it's, in fact, different. The Empty state is shown when the user searches for something and gets back an empty list. The 404 state is shown when the user asks for something that doesn't exist.

![](/primary-ux-states/4.png)

## Ready state

I'm sure you're familiar with this state because it's the one you always get from designers. It's also the one that you show in your marketing materials. This is the state shown when the app is ready to be used. All the data has been loaded, and no errors occurred.

---

That's it. These are the states that you need. _Write them down_ so you don’t forget them, and make sure they are well-defined for every component you work on, regardless if they are small as a button or as big as a page.


The Five Primary UX States


If, in JavaScript, you need an array with values from 1 to N, how do you do it? There's the good old `for` loop. But I used to do something like this:

```js
Array(10)
  .fill()
  .map((_, i) => i + 1);
```

It works, but I don't like it. The `fill` method feels hacky to me. Luckily, there is a better way to do it using [`Array.from()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/from).

`Array.from()` takes an array-like value and returns an array:

```js
Array.from("hello"); // ['h', 'e', 'l', 'l', 'o']
```

Surprisingly, passing an object with a `length` property also works:

```js
Array.from({ length: 3 }); // [undefined, undefined, undefined]
```

This is equivalent to `Array(3).fill()`.

But that's not all! We can also pass a map function as a second argument:

```js
Array.from({ length: 3 }, (_, i) => i + 1); // [1, 2, 3]
```

Of course, you can modify the map function to do whatever you want. For example, you can list the power of 2:

```js
Array.from({ length: 3 }, (_, i) => 2 ** i); // [1, 2, 4]
```

## Counting from 0

What if we want to count from 0 instead of 1? We can use another approach and make the code even simpler:

```js
[...Array(3).keys()]; // [0, 1, 2]
```

The three dots `...` are the [spread operator](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax). t takes an iterable, an array in this case, and spreads it into a list of values.

## Using it with React

I found myself using this technique a few times while working with React.

For example, when creating a loading skeleton:

```jsx
function BlogSkeleton() {
  return (
    <div>
      {[...Array(3).keys()].map((_, i) => (
        <PostSkeleton key={i} />
      ))}
    </div>
  );
}
```

I could achieve the same result by writing `PostSkeleton` three times but sometimes you don't know beforehand how many items you need to render.

## The future: Iterator.range

There's another option that feels more idiomatic to me. It's not available yet, it's currently at stage 2 of the TC39 process. It's called `Iterator.range` and it works like this:

```js
[...Iterator.range(1, 4)]; // [1, 2, 3]
```

You can even add a step argument:

```js
[...Iterator.range(1, 10, 2)]; // [1, 3, 5, 7, 9]
```

As I said, it's not supported by all browser yet. But you can learn more about it at the official [proposal repository](https://github.com/tc39/proposal-iterator.range).


Creating an Array Containing Values 1 to N in JavaScript


I discovered a neat trick I while reading [TypeScript](https://www.typescriptlang.org/)'s source code.

[.NET](https://dotnet.microsoft.com/en-us/) developers call it _FlagsAttribute_.

```ts
enum ColorFlags {
  None = 0,
  Red = 1 << 0,
  Yellow = 1 << 1,
  Purple = 1 << 2,
  Blue = 1 << 3,
  Brown = 1 << 4,
}
```

This little snippet has a lot going on, so let's unpack it

The `<<` symbol is the [left shift operator](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Left_shift). It takes the binary representation of the value on the left and shifts every bit N-times where N is the number on the right.

```ts
const a = 5; // 00000101
a << 1 === 10; // 00001010
a << 2 === 20; // 00010100
a << 3 === 40; // 00101000
```

If we use `1` as the left operand, something interesting happens: we get the powers of two. This means that the binary representation of the number will have only one bit set to `1`, and the rest will be zero.

```ts
1 << 0; // 00000001
1 << 1; // 00000010
1 << 2; // 00000100
1 << 3; // 00001000
```

This means that the initial snippet could be rewritten as this:

```ts
enum ColorFlags {
  None = 0,
  Red = 1,
  Yellow = 2,
  Purple = 4,
  Blue = 8,
  Brown = 16,
}
```

The question is: why do this?

Imagine we want to allow only some colors to be used and that the list of allowed colors is dynamic—perhaps passed as a configuration object. Then, we can use the [bitwise OR](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Bitwise_OR) `|` operator to code this:

```ts
const AllowedColors = ColorFlags.Red | ColorFlags.Yellow | ColorFlags.Blue;
// 0001 | 0010 | 1000 = 1011
```

Let's say that we get a `color` as a parameter, and we want to do something if this color is `Red`, but _only if_ `Red` is one of the allowed colors. We can now do this:

```ts
if ((AllowedColors & color) === ColorFlags.Red) {
  // do something
}
```

If color is allowed, the [bitwise AND](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Bitwise_AND) `&` will return its code; otherwise, it will return zero, which we mapped to the value `None` in our enum.

---

Here you can see this technique being used in TypeScript's codebase: [types.ts](https://github.com/microsoft/TypeScript/blob/f218a562bfb417ecec263fc96d7a7a71abf96268/src/compiler/types.ts#L787)


FlagsAttribute in TypeScript


Lately, I have been experimenting with [React Query](https://react-query.tanstack.com/) for data synchronization with React, and I find it excellent.

Take a look at a basic example:

```tsx
function Example() {
  const { data } = useQuery("repositoryData", () => getRepository());

  return <div>The name is {data?.name}</div>;
}
```

I want to show you not this but the way I define the `getRepository` query function.

Here is its definition:

```ts
const GetRepositoryRequest = z.void();
const GetRepositoryResponse = z.object({ name: z.string().min(1) });
export const getRepository = api<
  z.infer<typeof GetRepositoryRequest>,
  z.infer<typeof GetRepositoryResponse>
>({
  method: HTTPMethod.GET,
  path: "/repository",
  requestSchema: GetRepositoryRequest,
  responseSchema: GetRepositoryResponse,
});
```

Yes, it looks complex at first, but it really isn't.

First, we are using [Zod](https://zod.js.org/) to define the request and response schemas. We will use these to validate the data that we're sending to and from the API. Why this, you ask? Simply because we have no guarantee on what data the API will return, and it's good to validate it before we use it.

After request and response are defined, we create the query function. I'm using an `api` function that I will explain later. The `api` method is typed with a [generic](https://www.typescriptlang.org/docs/handbook/2/generics.html) that accepts two arguments: the type of the request and the type of the response. Here we're using Zod's [type inference](https://github.com/colinhacks/zod#type-inference), so we don't have to duplicate the type definition. We're getting both runtime validation and TypeScript type checking at the price of one.

The rest is self-explanatory. We're passing the method using the HTTPMethod enum, the path and the request and response schemas defined before.

Ok, so what does the `api` method look like? Something like this:

```ts
import axios from "axios";
import env, { isProduction, EnvName } from "utils/env";
import type { z } from "zod";

export enum HTTPMethod {
  GET = "GET",
  POST = "POST",
}

export enum HTTPStatusCode {
  OK = 200,
}

export default function api<Request, Response>({
  method,
  path,
  requestSchema,
  responseSchema,
}: {
  method: HTTPMethod;
  path: string;
  requestSchema: z.ZodType<Request>;
  responseSchema: z.ZodType<Response>;
}): (data: Request) => Promise<Response> {
  return function (requestData: Request) {
    requestSchema.parse(requestData);

    async function apiCall() {
      const response = await axios({
        baseURL: process.env.API_URL,
        method,
        url: path,
        [method === HTTPMethod.GET ? "params" : "data"]: requestData,
      });

      if (process.env.NODE_ENV === EnvName.PRODUCTION) {
        responseSchema.safeParseAsync(response.data).then((result) => {
          if (!result.success) {
            // TODO: Send error to sentry or other error reporting service
          }
        });

        return response.data as Response;
      }

      return responseSchema.parse(response.data);
    }

    return apiCall();
  };
}
```

As you can see, `api` validates both your request and response data and makes the call to the API.

The validation of the response happens asynchronously in production but synchronously in development. This is because we don't want to block the UI while we're validating the data.

---

I have been using this approach for a while now, and it works really well for me. The added bonus is that all my queries are defined in one place, and I can read them to know what my API looks like. Plus, I can spot breaking changes in the backend and quickly fix them.


Effective Query Functions for React Query with Zod


One thing I've seen people struggling with when it comes to testing a web
application is what to test and how. This post explains the approach I follow at
work and for my projects.

The examples will be based on React Testing Library, but the same concepts apply
just as well to any other frontend technology.

## You already know how to test

The first thing to understand is that you already know how to test. In fact, if
you have developed any application, you have tested it.

Do you remember when you were learning how to code, and you wrote your first
program? Chances are it looked something like this:

```js
console.log("Hello, world!");
```

You then executed your script, and sure enough, you read "Hello, world!" in the
console. That was a test. You were testing that your program was working as
expected.

If you think about it, that's what you still do for every program you create.
You write some code and then execute it to make sure it works.

Now imagine you get a bug report. Apparently, some feature stopped working. What
do you do first? You try to reproduce the bug by using your application. Again,
you are manually testing.

Manually testing is a very effective way to ensure your software is working.
Interacting with a portion of your application gives you confidence that it
works.

Of course, manual tests have a big problem: you need a person to run them. Even
a small application can quickly become hard to test manually. On top of that,
consider that you must "run" all your tests every time you introduce a small
change.

This is where testing libraries come into play. For me, these tools are a way to
automate the way I would manually test my application.

## An example

Let's go through a more concrete example to understand what I mean by
"automating the way I would manually test."

Suppose we are working on a simple currency converter application like this one:

<iframe style="width: 100%;" src="https://currency-converter-delta.vercel.app/"></iframe>
<button onClick="f=document.querySelector('iframe');f.src=f.src">Reload app</button>

You can find the complete code
[here](https://github.com/Gpx/currency-converter).

Let's not get into the code just yet. What we should ask ourselves now is "How
would I manually test this app?" I would do something like this:

1. Check that we see a loading message until the app is ready
2. Check that we see the initial conversion for 1 Euro to Dollars
3. Change the amount and see that the conversion is updated
4. Change the currency and see that the conversion is updated

I think this makes for a reasonable test case. What we need to do now is trying
to automate it. I'm going to do that using React Testing Library, but the same
principles apply to most testing tools.

```jsx
test("basic conversion", async () => {
  render(<App />);
  // 1. Check that we see a loading message until the app is ready
  // 2. Check that we see the initial conversion for 1 Euro to Dollars
  // 3. Change the amount and see that the conversion is updated
  // 4. Change the currency and see that the conversion is updated
});
```

This is our basic setup that doesn't do much at the moment. Let's implement the
first step.

```jsx
test("basic conversion", async () => {
  render(<App />);
  // 1. Check that we see a loading message until the app is ready
  expect(screen.getByText("Loading...")).toBeInTheDocument();
  await waitForElementToBeRemoved(() => screen.getByText("Loading..."));

  // 2. Check that we see the initial conversion for 1 Euro to Dollars
  // 3. Change the amount and see that the conversion is updated
  // 4. Change the currency and see that the conversion is updated
});
```

Don't worry if you are not familiar with the particular API I'm using. The
important concept to get is that we're simulating what a user would do. First,
checking that the loading message is on the page and then waiting for it do
disappear.

Let's move on to step two:

```jsx
test("basic conversion", async () => {
  render(<App />);
  // 1. Check that we see a loading message until the app is ready
  expect(screen.getByText("Loading...")).toBeInTheDocument();
  await waitForElementToBeRemoved(() => screen.getByText("Loading..."));

  // 2. Check that we see the initial conversion for 1 Euro to Dollars
  const input = screen.getByDisplayValue("1");
  expect(screen.getByText(/1.08/)).toBeInTheDocument();

  // 3. Change the amount and see that the conversion is updated
  // 4. Change the currency and see that the conversion is updated
});
```

Here we are getting the input and checking that the converted value is on the
page.

Step three and four are quite similar so we can group them:

```jsx
test("basic conversion", async () => {
  render(<App />);
  // 1. Check that we see a loading message until the app is ready
  expect(screen.getByText("Loading...")).toBeInTheDocument();
  await waitForElementToBeRemoved(() => screen.getByText("Loading..."));

  // 2. Check that we see the initial conversion for 1 Euro to Dollars
  const input = screen.getByDisplayValue("1");
  expect(screen.getByText(/1.08/)).toBeInTheDocument();

  // 3. Change the amount and see that the conversion is updated
  fireEvent.change(input, { target: { value: "2" } });
  expect(screen.getByText(/2.16/)).toBeInTheDocument();

  // 4. Change the currency and see that the conversion is updated
  const select = screen.getByDisplayValue("USD");
  fireEvent.change(select, { target: { value: "RUB" } });
  expect(screen.getByText(/137.94/)).toBeInTheDocument();
});
```

And that's about it. We automated what a user would do to test this app. Notice
that the test knows nothing about the implementation details. We didn't have to
read the source code. This app could have been written in any frontend
framework, and the test would be the same.

There's only one last step missing. Our code is fetching the conversion rates.
It's always better not to make any real network calls in the tests, so we're
going to mock it. You can find a longer explanation on how to do that
[here](https://www.polvara.me/posts/how-to-test-asynchronous-methods/).

```jsx
import fetchRates from "./fetchRates";
jest.mock("./fetchRates");

test("basic conversion", async () => {
  fetchRates.mockResolvedValueOnce({ RUB: 68.9685, USD: 1.0816 });
  render(<App />);

  // 1. Check that we see a loading message until the app is ready
  expect(screen.getByText("Loading...")).toBeInTheDocument();
  await waitForElementToBeRemoved(() => screen.getByText("Loading..."));

  // 2. Check that we see the initial conversion for 1 Euro to Dollars
  const input = screen.getByDisplayValue("1");
  expect(screen.getByText(/1.08/)).toBeInTheDocument();

  // 3. Change the amount and see that the conversion is updated
  fireEvent.change(input, { target: { value: "2" } });
  expect(screen.getByText(/2.16/)).toBeInTheDocument();

  // 4. Change the currency and see that the conversion is updated
  const select = screen.getByDisplayValue("USD");
  fireEvent.change(select, { target: { value: "RUB" } });
  expect(screen.getByText(/137.94/)).toBeInTheDocument();

  expect(fetchRates).toHaveBeenCalledWith();
  expect(fetchRates).toHaveBeenCalledTimes(1);
});
```

## Units and integrations don't matter that much

At this point, people usually have two kinds of reactions. Some are hooked and
start writing tests this way—if you are, welcome to the club.

The second kind of reaction is usually a generic fear about the lack of unit
tests, namely the fact that these kinds of tests look more like integration,
end-to-end, or feature tests. For some people, you need to have 100% test
coverage with unit tests before you can do anything else.

If you are in this second category, allow me to tell you that in most
applications, 100% unit test coverage is not needed. It is usually a bad
practice.

Please don't take me wrong, unit tests can be useful for some occasions, but
writing higher-level tests is almost always better. The reason we write tests is
to make sure our app works. Writing a test that simulates a user interacting
with your app is what will give you the most confidence.

Unit tests are just checking that a small portion of your software is doing what
it's supposed to do. You can have 100% coverage with unit tests, but that gives
you no guarantee that the single parts are working well together.

## Why not E2E tests then?

If tests that simulate the user are so great, why not only writing end-to-end
tests (also known as browser tests or Selenium tests)? These are tests that run
inside a browser and connect to a real API.

E2E tests are great because they test your application in a real browser
environment. They have two drawbacks, though. They are slow to run, and they are
usually unstable.

To run them, you have to start a browser, run your application, and potentially
start your backend too. There are many more parts involved, and This leads to a
higher risk of something going wrong.

In general, I write E2E tests only to cover critical features and only the happy
paths (no errors, no edge cases).

## Conclusions

To sum it up, here's my strategy when it comes to testing:

1. Manually test my code
2. Write a test to simulate the way I manually test
3. Add an E2E test if the feature is critical


Ciao!

Like what you see? Follow me!

Or