Fetching a Single User

Welcome back! In the previous lesson, you learned how to create new users using the POST method in a Remix route. Now, let’s look at another common task: fetching a single item, such as a user, by its unique identifier.

In real-world applications, you often need to display details for a specific item. For example, when you click on a user’s name in a list, you expect to see their profile page. To make this work, your backend needs to handle requests for a specific user and return only that user’s data.

In this lesson, you will learn how to set up a dynamic route in Remix to fetch a single user by their ID. This is a key skill for building APIs that support user profiles, product pages, and more.

Before we dive in, let’s quickly remind ourselves of the setup you already have. You have a Remix project with a route for users and a mock array of user data. Here’s a summary of the relevant parts:

// app/lib/data.ts
export const users = [
  { id: 1, name: "Alice", email: "alice@example.com" },
  { id: 2, name: "Bob", email: "bob@example.com" },
  // ...more users
];

// app/routes/api.users.tsx (for POST requests)
import { users } from "~/lib/data";
// ...POST handler code

You do not need to set this up again, but keep in mind that the users array is our mock database for this lesson.

To fetch a single user, we need a way to handle requests like /api/users/2, where 2 is the user’s ID. Remix makes this easy with dynamic route segments.

A dynamic route in Remix uses a dollar sign in the file name to capture part of the URL as a parameter. For example:

app/routes/api.users.$id.tsx

In this case, $id means any request to /api/users/<some-id> will be handled by this file, and the <some-id> part (like 2, 17, or 99) will be available as a parameter named id.

This allows us to write code that responds to requests for any user, not just a specific one.

Let’s look at the code for handling a GET request to fetch a single user by ID. Here is the complete handler:

import { json, type LoaderFunctionArgs } from "@remix-run/node";
import { useLoaderData } from "@remix-run/react";
import { users } from "~/lib/data";

/** GET /api/users/:id — return a single user by ID */
export async function loader({ params }: LoaderFunctionArgs) {
  const id = Number(params.id);
  const user = users.find(u => u.id === id);

  if (!user) {
    return json({ error: "User not found" }, { status: 404 });
  }

  return json(user);
}

Let’s break down what’s happening here:

• We import the users array and the necessary Remix helpers.
• The loader function is called when a GET request is made to /api/users/:id.
• We extract the id from the URL using params.id and convert it to a number with Number.
• We search the users array for a user with a matching id.
• If the user is found, we return their data as JSON.
• If the user is not found, we return a JSON error message with a 404 status.

Even though this loader is short, it’s doing a few important things behind the scenes. Let’s walk through what happens when someone visits /api/users/2.

• Dynamic route: The file name api.users.$id.tsx tells Remix to treat anything after /api/users/ as a dynamic segment and pass it into the loader as params.id.
• Parsing the ID: The value of params.id is a string (e.g., "2"), so we convert it into a number using Number. This is important because the id field in our users array is a number.
• Finding the user: We use .find() to search the array. If the ID matches, we return that user; otherwise, we send a 404.
• Why do we use Number(params.id)?
  • This ensures the string is parsed as a number. This is a best practice to avoid unexpected behavior when working with numeric strings.

Example Request and Output

Suppose you make a GET request to /api/users/2. If user 2 exists, the response will look like:

{
  "id": 2,
  "name": "Bob",
  "email": "bob@example.com"
}

If you request a user who does not exist, like /api/users/99, the response will be:

{
  "error": "User not found"
}

With a status code of 404.

It’s important to handle cases where the requested user does not exist. In the code above, we check if user is undefined (not found) and return a 404 error with a clear message.

This helps clients of your API (like frontend apps) know when they’ve requested something that isn’t there, so they can show a helpful message to the user.

Why is this important?

• It prevents confusion for users and developers.
• It follows best practices for REST APIs.
• It makes your API more reliable and predictable.

💡 Pro Tip: Returning 404 for “not found” and 400 for “bad input” helps frontend developers (and API testers) understand whether the issue was with what they asked for (missing user) or how they asked for it (invalid ID). You’ll see this practice often in robust APIs.

In this lesson, you learned how to fetch a single user by their ID using a dynamic route in Remix. You saw how to:

• Set up a dynamic route with $id in the file name.
• Extract the ID from the URL.
• Find the user in your data.
• Return the user’s data or a 404 error if not found.

Next, you’ll get a chance to practice these skills with hands-on exercises. This will help you get comfortable with dynamic routes and handling single-item requests in your own projects. Good luck!