Protected routes with loaders in Remix - Step-by-Step Execution

Concept Flow - Protected routes with loaders

User requests protected route

↓

Loader runs on server

↓

Check user authentication

↓

Return data

↓

Render protected [Render login page

When a user visits a protected route, the loader runs first to check if the user is authenticated. If yes, it returns data and renders the protected page. If not, it redirects to login.

Execution Sample

Remix

import { redirect, json } from '@remix-run/node';

export async function loader({ request }) {
  const user = await getUser(request);
  if (!user) {
    return redirect('/login');
  }
  return json({ user });
}

This loader checks if a user is logged in; if not, it redirects to login, else it returns user data.

Execution Table

Step	Action	User Authenticated?	Result	Next
1	Loader starts with request	Unknown	Check user session	Check user authentication
2	Check user authentication	Yes	Return user data	Render protected component
3	Render protected component	Yes	Show protected page	End
4	Check user authentication	No	Redirect to /login	Render login page
5	Render login page	No	Show login form	End

💡 Execution stops after rendering either the protected page or the login page based on authentication.

Variable Tracker

Variable	Start	After Step 2	After Step 4	Final
user	undefined	user object	null	user object or null
result	undefined	json({ user })	redirect('/login')	json or redirect response

Key Moments - 2 Insights

Why does the loader redirect instead of rendering the protected component when the user is not authenticated?

Because in the execution_table at Step 4, when user is No, the loader returns a redirect response which tells Remix to send the user to the login page instead of rendering the protected route.

What happens if the loader returns user data?

As shown in Step 2 and 3 of the execution_table, returning user data allows the protected component to render with that data, showing the protected page.

Visual Quiz - 3 Questions

Look at the execution_table, what is the result at Step 2 when the user is authenticated?

A Return user data

B Redirect to /login

C Show login form

D Check user session

💡 Hint

Check the 'Result' column at Step 2 in the execution_table.

At which step does the loader decide to redirect the user to the login page?

A Step 1

B Step 3

C Step 4

D Step 5

💡 Hint

Look at the 'Action' and 'Result' columns in the execution_table for the redirect action.

If the user variable is null, what will the loader return according to variable_tracker?

A json({ user })

B redirect('/login')

C undefined

D Render protected component

💡 Hint

See the 'user' and 'result' values in variable_tracker after Step 4.

Concept Snapshot

Protected routes use loaders to check user login.
Loader runs on server before rendering.
If user not logged in, loader redirects to login.
If logged in, loader returns data for page.
This protects pages from unauthorized access.

Full Transcript

When a user visits a protected route in Remix, the loader function runs first on the server. It checks if the user is authenticated by looking up the user session. If the user is logged in, the loader returns user data which the page uses to render the protected content. If the user is not logged in, the loader returns a redirect response to send the user to the login page. This way, unauthorized users cannot see protected pages. The loader acts as a gatekeeper before the page renders. This flow ensures security and a smooth user experience.

Practice

1. What is the main purpose of using a loader in a protected route in Remix?

easy

A. To check if the user is authorized before showing the page

B. To style the page with CSS

C. To fetch data after the page is rendered

D. To handle button clicks on the page

Solution

1. Step 1: Understand the role of loaders in Remix

   Loaders run before the page renders and can check user permissions.

2. Step 2: Identify the purpose of protected routes

   Protected routes restrict access to authorized users only, so loaders check authorization.

3. Final Answer:

   To check if the user is authorized before showing the page -> Option A

4. Quick Check:

   Loader checks authorization = To check if the user is authorized before showing the page [OK]

Hint: Loaders run before page render to check access [OK]

Common Mistakes:

• Thinking loaders style pages
• Assuming loaders run after rendering
• Confusing loaders with event handlers

2. Which of the following is the correct way to redirect unauthorized users inside a Remix loader?

easy

A. navigate('/login')

B. return redirect('/login')

C. throw redirect('/login')

D. window.location.href = '/login'

Solution

1. Step 1: Recall Remix loader redirect syntax

   In Remix loaders, you use throw redirect() to redirect users.

2. Step 2: Compare options

   throw redirect('/login') uses throw redirect('/login'), which is the correct Remix pattern.

3. Final Answer:

   throw redirect('/login') -> Option C

4. Quick Check:

   Use throw redirect() in loaders = throw redirect('/login') [OK]

Hint: Use throw redirect() inside loaders for redirects [OK]

Common Mistakes:

• Using return redirect() instead of throw
• Using client-side navigation methods in loaders
• Trying to set window.location in server code

3. Given this loader code in Remix, what happens if the user is not logged in?

import { redirect } from '@remix-run/node';

export async function loader({ request }) {
  const user = await getUser(request);
  if (!user) {
    throw redirect('/login');
  }
  return { user };
}

medium

A. The loader returns null and the page is blank

B. The user sees the protected page with user data

C. The page shows an error message but stays on the same URL

D. The user is redirected to the /login page

Solution

1. Step 1: Analyze the loader logic

   If user is falsy (not logged in), the loader throws redirect('/login').

2. Step 2: Understand Remix redirect behavior

   Throwing redirect sends the browser to the specified URL before rendering the page.

3. Final Answer:

   The user is redirected to the /login page -> Option D

4. Quick Check:

   Throw redirect sends user away = The user is redirected to the /login page [OK]

Hint: Throw redirect sends user to new page before render [OK]

Common Mistakes:

• Thinking user sees protected page anyway
• Assuming error message shows instead of redirect
• Believing loader returns null means blank page

4. Identify the error in this Remix loader for a protected route:

import { redirect } from '@remix-run/node';

export async function loader({ request }) {
  const user = await getUser(request);
  if (!user) {
    return redirect('/login');
  }
  return { user };
}

medium

A. Missing await before getUser(request)

B. Using return redirect() instead of throw redirect() causes a runtime error

C. Loader should not return user data

D. redirect should be imported from '@remix-run/react'

Solution

1. Step 1: Check redirect usage in loader

   In Remix loaders, you must throw redirect(), not return it.

2. Step 2: Understand consequences of return redirect()

   Returning redirect() does not stop loader execution properly and causes errors.

3. Final Answer:

   Using return redirect() instead of throw redirect() causes a runtime error -> Option B

4. Quick Check:

   Throw redirect required in loaders = Using return redirect() instead of throw redirect() causes a runtime error [OK]

Hint: Always throw redirect() in loaders, never return it [OK]

Common Mistakes:

• Returning redirect() instead of throwing
• Importing redirect from wrong package
• Forgetting async/await on getUser

5. You want to protect a route so only logged-in users can access it. You also want to fetch user profile data in the loader. Which is the best way to write the loader?

import { redirect } from '@remix-run/node';

export async function loader({ request }) {
  const user = await getUser(request);
  if (!user) {
    throw redirect('/login');
  }
  const profile = await getUserProfile(user.id);
  return { user, profile };
}

hard

A. This loader correctly protects the route and fetches profile data

B. You should fetch profile data before checking user to avoid errors

C. You must return redirect('/login') instead of throwing it

D. Loaders cannot fetch multiple data items; split into two loaders

Solution

1. Step 1: Check authorization logic

   The loader checks if user exists, and throws redirect if not, protecting the route.

2. Step 2: Confirm data fetching after authorization

   Fetching profile after confirming user is safe and logical.

3. Step 3: Validate return structure

   Returning both user and profile data together is valid and useful for the page.

4. Final Answer:

   This loader correctly protects the route and fetches profile data -> Option A

5. Quick Check:

   Check user, throw redirect, then fetch data = This loader correctly protects the route and fetches profile data [OK]

Hint: Check user first, then fetch data, throw redirect if unauthorized [OK]

Common Mistakes:

• Fetching data before checking user
• Returning redirect instead of throwing
• Splitting data fetching unnecessarily