Coder Legion - Recent posts tagged react-router

The easiest way to test React Router v7 apps

Mon, 15 Jun 2026 16:50:54 +0000

You wrote a React Router v7 route. It has a loader, an action, a form, some interactivity. Now you want to test it. The official docs hand you two paths and neither one covers the case you actually have.

Path one is createRoutesStub plus @testing-library/react, running in a terminal-based test runner. It works for small reusable components that consume router hooks. The docs explicitly warn against using it for full route components with the framework-mode Route.* types: "not designed for (and is arguably incompatible with) direct testing of Route components". So if you want to test the actual route the user is going to load, this path stops short.

Path two is Playwright or Cypress. The docs themselves point you there for route-level tests: "we recommend you do that via an Integration/E2E test... against a running application". That works, but you've left your dev loop, you've added a separate test stack, and the feedback cycle gets long. It's QA-shaped, not developer-shaped.

There's a middle path. Use the same createRoutesStub the docs recommend for components, but render it inside the real browser, in the real dev server, against the real DOM, with the dev loop still attached. That's what TWD does. The framework's own utility, in the right environment.

That's the TWD sidebar on the left, the app on the right. The sidebar is running real createRoutesStub tests against the live page. No jsdom, no headless Chrome, no separate process.

Setup

Install:

npm install --save-dev twd-js
npx twd-js init public --save

Add the Vite plugin:

// vite.config.ts
import { reactRouter } from '@react-router/dev/vite'
import { defineConfig } from 'vite'
import { twd } from 'twd-js/vite-plugin'

export default defineConfig({
  plugins: [
    reactRouter(),
    twd({ testFilePattern: '/**/*.twd.test.{ts,tsx}' }),
  ],
})

There's one SSR-mode workaround you'll hit exactly once. React Router v7 framework mode does not use a Vite-served index.html. The framework's own middleware renders HTML from app/root.tsx, and Vite's transformIndexHtml hook never fires for that HTML. The plugin can't auto-inject its sidebar bootstrap script. The fix is one dev-only block in app/root.tsx:

<head>
  <Meta />
  <Links />
  {import.meta.env.DEV && (
    <script type="module" src="/@id/virtual:twd/init" />
  )}
</head>

The plugin still registers the virtual module. Vite still serves it at /@id/.... You're just pointing your SSR'd template at it yourself. The import.meta.env.DEV guard keeps the tag out of production.

Run npm run dev. Sidebar on the left, your app on the right.

A fallback `/testing` route

createRoutesStub builds a tiny in-memory router. To mount it, you need a DOM container and a React root. The cleanest way is a dedicated route that exists only as a mounting point for tests:

// app/routes/testing-page.tsx
export default function TestPage() {
  return <div data-testid="testing-page" style={{ minHeight: '100vh' }} />
}

Add it to your route table at /testing. Then a small utility navigates to it and hands you a fresh root in beforeEach:

// app/twd-tests/utils.ts
import { createRoot } from 'react-dom/client'
import { twd, screenDomGlobal } from 'twd-js'

let root: ReturnType<typeof createRoot> | undefined

export async function setupReactRoot() {
  if (root) { root.unmount(); root = undefined }
  await twd.visit('/testing')
  const container = await screenDomGlobal.findByTestId('testing-page')
  root = createRoot(container)
  return root
}

That's the whole harness. One route, seven lines of utility. The cost is small and you reuse it across every test.

Writing a route-level test

This is the test the official docs say not to write with createRoutesStub. In TWD it works, because the stub is rendering into the same real document your app lives in. Full Route.* types, full hooks, real DOM.

// app/twd-tests/todoList.twd.test.tsx
import { twd, expect, userEvent, screenDom } from 'twd-js'
import { describe, it, beforeEach } from 'twd-js/runner'
import {
  createRoutesStub,
  useLoaderData,
  useParams,
  useMatches,
} from 'react-router'
import TodoListPage from '~/routes/todolist'
import todoListMock from './mocks/todoList.json'
import { setupReactRoot } from './utils'

describe('Todo List page', () => {
  let root: Awaited<ReturnType<typeof setupReactRoot>>

  beforeEach(async () => {
    root = await setupReactRoot()
  })

  it('renders todos from the loader', async () => {
    const Stub = createRoutesStub([
      {
        path: '/',
        Component: () => {
          const loaderData = useLoaderData()
          const params = useParams()
          const matches = useMatches() as any
          return (
            <TodoListPage
              loaderData={loaderData}
              params={params}
              matches={matches}
            />
          )
        },
        loader() {
          return { todos: todoListMock }
        },
      },
    ])

    root.render(<Stub />)
    await twd.wait(300)

    const firstTodoTitle = await screenDom.getByText('Learn TWD')
    twd.should(firstTodoTitle, 'be.visible')

    const firstTodoDate = await screenDom.getByText('Date: 2024-12-20')
    twd.should(firstTodoDate, 'be.visible')
  })

  it('submits the create-todo action with the right payload', async () => {
    let payload: Record<string, string> | null = null
    const Stub = createRoutesStub([
      {
        path: '/todos',
        Component: /* same wrapper */ () => null,
        loader() { return { todos: [] } },
        async action({ request }) {
          const formData = await request.formData()
          payload = Object.fromEntries(formData) as Record<string, string>
          return null
        },
      },
    ])

    root.render(<Stub initialEntries={['/todos']} />)

    const titleInput = await screenDom.getByLabelText('Title')
    await userEvent.type(titleInput, 'Test Todo')

    const submitButton = await screenDom.getByRole('button', { name: 'Create Todo' })
    await userEvent.click(submitButton)

    expect(payload).to.deep.equal({ title: 'Test Todo' /* ... */ })
  })
})

The pattern is exactly the one the official docs show. The wrapper component pulls useLoaderData / useParams / useMatches and forwards them as props. The stub provides a loader and (optionally) an action. You render, you interact, you assert. The only difference from the docs example is where it runs.

Backend tests: any runner works

Framework mode splits the route in two: the loader and action are server-side, the component is client-side. The two halves get tested by different tools, and the backend half is the easier one.

loader and action are async functions that take a Request and a context. They have no DOM, no router, no rendering. Test them with whatever your project already uses: vitest, jest, node's built-in test runner, anything. Here it is in vitest as one example:

// app/routes/todolist.test.ts
import { describe, it, expect, vi } from 'vitest'
import { loader, action } from './todolist'
import * as api from '~/api/todos'

it('loader returns todos from the api layer', async () => {
  vi.spyOn(api, 'fetchTodos').mockResolvedValue([
    { id: '1', title: 'Learn TWD', description: '', date: '2024-12-20' },
  ])

  const result = await loader({
    request: new Request('http://test/todos'),
    params: {},
    context: new Map() as any,
  })

  expect(result.todos).toHaveLength(1)
})

Whatever runner you pick, the test boots in milliseconds and runs anywhere Node runs. It's a function call.

Two suites, one per layer. When the backend test fails, the loader broke. When the TWD test fails, the rendering broke. You stop debugging the wrong layer.

Why this works: same utility, different environment

createRoutesStub is a great piece of API. The official docs scope it to non-route components for a fair reason: mounting a full route component into jsdom is genuinely brittle, because framework-mode Route.* types, auto-imports, and the dev loop weren't built for a synthetic DOM. You can spend more time wrestling the harness than writing the test.

TWD changes one thing about that picture. The test runs inside your real Vite dev server, in the real browser tab where your app already runs. Auto-imports resolve. Types match runtime. The dev loop is still there. With the surrounding environment in place, the same createRoutesStub scales up to route-level components without fighting anything.

That change pulls a few extras along with it. The sidebar is part of your dev loop, not a separate thing you switch into. The same tab where you're building the page runs the tests. The DOM you're testing is the DOM you're using. Click around manually, run a test, watch the assertion render in real time, fix it, re-run. No context switch, no second window, no headless screenshot to interpret.

Try it

Sample repo: BRIKEV/twd-react-router. React Router v7 in framework mode, a todo list with loader and action, the harness route wired up, GitHub Actions CI configured against a json-server backend (the part most sample repos forget).
Docs: twd.dev

npm install --save-dev twd-js
npx twd-js init public --save

Add the plugin to vite.config.ts, drop the <script> tag into app/root.tsx, add the /testing route, write your first .twd.test.tsx. The sidebar opens itself.

React Router Data Mode: Part 6 - Actions, forms and mutations

Mon, 28 Jul 2025 20:31:27 +0000

We continue with the sixth part of this series on React Router Data Mode. This time, we'll talk about actions: one of the key pieces for data handling that React Router offers.

If you're coming from the previous post, you can continue with your project as is. But if you prefer to start fresh or make sure you're at the exact point, run the following commands:

# Repository link https://github.com/kevinccbsg/react-router-tutorial-devto
git reset --hard
git clean -d -f
git checkout 05-action-create-contact

What is an action?

An action is a function that we can associate with a route, and it's responsible for performing data mutations. The interesting part is that, once completed, React Router automatically revalidates the UI data without us having to handle that process manually.

In our contacts project, we'll start by creating a new contact using an action. You'll see that when you do this, the list updates automatically without needing to write extra logic.

Handling forms

In src/pages/ContactForm.tsx, we replace the <form> tag with the <Form> component from react-router, which is responsible for triggering the corresponding action on submit.

It's also important to specify the method (for example, POST):

<Form className="space-y-4" method="POST">

This component will execute the action defined in the corresponding route. To do this, we configure the action in src/AppRoutes.tsx.

An example taken from the official documentation would be:

import { createBrowserRouter } from "react-router";
import { someApi } from "./api";

let router = createBrowserRouter([
  {
    path: "/projects/:projectId",
    Component: Project,
    action: async ({ request }) => {
      let formData = await request.formData();
      let title = formData.get("title");
      let project = await someApi.updateProject({ title });
      return project;
    },
  },
]);

Just like we did with loaders, it's recommended to extract the action to a separate file.

Create src/pages/actions.tsx with the following:

import { ActionFunctionArgs } from "react-router";

export const newContactAction = async ({ request }: ActionFunctionArgs) => {
  console.log('Calling the action');
  return null;
};

This function receives an object with ActionFunctionArgs. We'll focus on request, although you can also access the route's params.

Note: an action must always return something, either null or a redirect (which we'll see later).

In src/AppRoutes.tsx, configure the action in the contacts/new route like this:

{
  path: "contacts/new",
  action: newContactAction,
  Component: ContactForm,
}

When you test the form on the web, you should see the console.log in your console, indicating that the action executed correctly.

Getting form data

We use request.formData() to capture the data, since our inputs are already properly labeled with name.

const formData = await request.formData();
const newContact = {
  firstName: formData.get('firstName') as string,
  lastName: formData.get('lastName') as string,
  username: formData.get('username') as string,
  email: formData.get('email') as string,
  phone: formData.get('phone') as string,
  avatar: formData.get('avatar') as string || undefined,
};

Also, we validate that the method is POST:

const method = request.method.toUpperCase();
if (method === 'POST') {
  // create the contact
}
return null;

Final action

The complete code for our action would look like this:

import { ActionFunctionArgs } from "react-router";
import { createContact } from "@/api/contacts";

interface NewContact {
  firstName: string;
  lastName: string;
  username: string;
  email: string;
  phone: string;
  avatar?: string;
}

export const newContactAction = async ({ request }: ActionFunctionArgs) => {
  const formData = await request.formData();
  const method = request.method.toUpperCase();
  
  if (method === 'POST') {
    const newContact: NewContact = {
      firstName: formData.get('firstName') as string,
      lastName: formData.get('lastName') as string,
      username: formData.get('username') as string,
      email: formData.get('email') as string,
      phone: formData.get('phone') as string,
      avatar: formData.get('avatar') as string || undefined,
    };
    await createContact(newContact);
  }

  return null;
};

When you create a new contact, it will automatically appear in the sidebar.

Redirect after creation

Now let's improve the experience by redirecting directly to the new contact's page. We use the redirect helper from react-router right after creating the contact:

import { ActionFunctionArgs, redirect } from "react-router";
import { createContact } from "@/api/contacts";

interface NewContact {
  firstName: string;
  lastName: string;
  username: string;
  email: string;
  phone: string;
  avatar?: string;
}

export const newContactAction = async ({ request }: ActionFunctionArgs) => {
  const formData = await request.formData();
  const method = request.method.toUpperCase();
  
  if (method === 'POST') {
    const newContact: NewContact = {
      firstName: formData.get('firstName') as string,
      lastName: formData.get('lastName') as string,
      username: formData.get('username') as string,
      email: formData.get('email') as string,
      phone: formData.get('phone') as string,
      avatar: formData.get('avatar') as string || undefined,
    };
    const newContactResponse = await createContact(newContact);
    return redirect(`/contacts/${newContactResponse.id}`);
  }

  return null;
};

Handling loading state

To manage the form state while it's submitting or loading, we use the useNavigation hook provided by React Router. This hook gives us information about the current navigation, and we use it to know if we're submitting the form or waiting for the UI to update after the redirect.

const navigation = useNavigation();

With this, we have access to the current navigation state, which can be "idle", "submitting", or "loading".

Then we create two variables to detect if we're submitting this particular form (not any other) or if we're waiting for the view to reload after completion:

const isSubmitting = navigation.state === 'submitting' && navigation.formAction === '/contacts/new';
const isLoading = navigation.state === 'loading' && navigation.formAction === '/contacts/new';

This is important because there may be other routes or forms in the app, and we don't want to disable the button if it's not this form being used.

Finally, we combine both states to know if the button should be disabled:

const disabled = isSubmitting || isLoading;

This way, we prevent the user from submitting multiple times while the contact is being created or the UI is updating.

Here's the result:

import { Button } from '@/components/ui/button';
import { Input } from '@/components/ui/input';
import { Label } from '@/components/ui/label';
import { Form, useNavigation } from 'react-router';

const ContactForm = () => {
  const navigation = useNavigation();
  const isSubmitting = navigation.state === 'submitting' && navigation.formAction === '/contacts/new';
  const isLoading = navigation.state === 'loading' && navigation.formAction === '/contacts/new';
  const disabled = isSubmitting || isLoading;
  return (
    <div className="max-w-md mx-auto">
      <h1 className="text-2xl font-bold mb-4">Create New Contact</h1>
      <Form className="space-y-4" method="POST">
        {/* your fields */}
        <Button type="submit" disabled={disabled }>
          {disabled ? 'Creating...' : 'Create Contact'}
        </Button>
      </Form>
    </div>
  );
};

export default ContactForm;

With this, we achieve a better UX and prevent unnecessary multiple submits.

Conclusion

That's it for this sixth part, where we've created an action, handled the form, redirected after submit, and managed loading state.

You might be wondering: what about validation? What if I have multiple actions on the same page, like editing or deleting contacts?

We'll cover all that in the next part: how to handle multiple actions, validations, and actions that don't depend on a <Form>.

See you in the next one!

React Router Data Mode: Part 5 - Refactor, useParams and NavLink

Mon, 28 Jul 2025 07:18:15 +0000

We continue with the fifth part of this series on React Router Data Mode. This time, it will be a brief post where we’ll do some refactors, review the useParams hook, and improve navigation with NavLink.

If you’re coming from the previous post, you can continue with your project as is. But if you prefer to start fresh or make sure you’re at the exact point, run the following commands:

# Repository link https://github.com/kevinccbsg/react-router-tutorial-devto
git reset --hard
git clean -d -f
git checkout 04-refactor-sidebar-detail

Refactor

Let’s start by improving the detail view.

Create src/components/ContactCard/ContactCard.tsx:

import { Form } from "react-router";
import { Star, StarOff } from "lucide-react";
import { Button } from "@/components/ui/button";
import { Avatar, AvatarFallback, AvatarImage } from "@/components/ui/avatar";
import { Card, CardContent } from "@/components/ui/card";

interface Contact {
  id: string;
  name: string;
  username: string;
  favorite: boolean;
  avatar?: string;
}

export default function ContactCard({ avatar, name, username, favorite, id }: Contact) {
  return (
    <Card className="max-w-md mx-auto">
      <CardContent className="flex flex-col items-center gap-4 p-6">
        <Avatar className="w-32 h-32">
          <AvatarImage src={avatar || undefined} />
          <AvatarFallback>{name[0]}</AvatarFallback>
        </Avatar>
        <div className="text-center">
          <h2 className="text-xl font-bold">{name}</h2>
          {username && (
            <p className="text-sm text-muted-foreground">{username}</p>
          )}
        </div>
        <div className="flex gap-2">
          <Form method="DELETE">
            <input type="hidden" name="id" value={id} />
            <Button type="submit" variant="destructive">Delete</Button>
          </Form>
          <Form method="PATCH">
            <input type="hidden" name="id" value={id} />
            <input type="hidden" name="favorite" value={String(!favorite)} />
            <Button type="submit" variant="ghost">
              {favorite ? <Star className="w-4 h-4" /> : <StarOff className="w-4 h-4" />}
            </Button>
          </Form>
        </div>
      </CardContent>
    </Card>
  )
}

Then update the detail page src/pages/ContactDetail.tsx to use this new component:

import { useParams, useRouteLoaderData } from "react-router";
import { loadContacts } from "./loader";
import ContactCard from "@/components/ContactCard/ContactCard";

const ContactDetail = () => {
  const { contactId } = useParams<{ contactId: string }>(); // Needs TS type annotation
  const routeData = useRouteLoaderData<typeof loadContacts>("root");
  if (!routeData) {
    return <div>Loading...</div>;
  }

  const { contacts } = routeData;
  
  // Find the contact locally (outside the store)
  const contact = contacts.find((c) => c.id === contactId);

  if (!contact) {
    return <div>Contact not found</div>;
  }
  return (
    <ContactCard
      avatar={contact.avatar}
      name={`${contact.firstName} ${contact.lastName}`}
      username={contact.username}
      favorite={contact.favorite}
      id={contact.id}
    />
  );
}

export default ContactDetail;

Now create the component src/components/Sidebar/Sidebar.tsx:

import { Input } from "@/components/ui/input"
import { Button } from "@/components/ui/button"
import { ScrollArea } from "@/components/ui/scroll-area"
import { Link } from "react-router"
import { useState } from "react";

interface Contact {
  id: string;
  name: string;
}

export default function Sidebar({ contacts }: { contacts: Contact[] }) {
  const [search, setSearch] = useState("");

  const handlesearchChange = (e: React.ChangeEvent<HTMLInputElement>) => {
    setSearch(e.target.value);
  };

  const filteredContacts = contacts.filter(contact =>
    contact.name.toLowerCase().includes(search.toLowerCase())
  );

  return (
    <>
      <Input placeholder="Search..." className="mb-2" value={search} onChange={handlesearchChange} />
      <Button className="w-full" variant="secondary" asChild>
        <Link to="/contacts/new" viewTransition>
          New
        </Link>
      </Button>
      <ScrollArea className="flex-1">
        <div className="flex flex-col gap-1 mt-4">
          {filteredContacts.map(contact => (
            <Button
              key={contact.id}
              className="justify-start"
              asChild
            >
              <Link to={`/contacts/${contact.id}`} viewTransition>
                {contact.name}
              </Link>
            </Button>
          ))}
        </div>
      </ScrollArea>
    </>
  )
}

This component already includes local search, although that won’t be the focus of this post.
The important thing here is navigation.

Update the main page pages/contacts.tsx:

import { Outlet, useLoaderData } from "react-router";
import { loadContacts } from "./loader";
import Sidebar from "@/components/Sidebar/Sidebar";

const ContactsPage = () => {
  const { contacts } = useLoaderData<typeof loadContacts>();
  return (
    <div className="h-screen grid grid-cols-[300px_1fr]">
      {/* Sidebar */}
      <div className="border-r p-4 flex flex-col gap-4">
        <Sidebar contacts={contacts.map(contact => ({
          id: contact.id,
          name: `${contact.firstName} ${contact.lastName}`,
        }))} />
      </div>
      {/* Detail View */}
      <div className="p-8">
        <Outlet />
      </div>
    </div>
  );
};

export default ContactsPage;

How do we mark the active link?

To correctly indicate which contact is selected, we use the useParams hook:

const { contactId } = useParams<{ contactId: string }>();

And with that, adjust the button in the contact list:

<Button
  key={contact.id}
  className="justify-start"
  variant={contact.id === contactId ? "default" : "ghost"}
  asChild
>
  <Link to={`/contacts/${contact.id}`} viewTransition>
    {contact.name}
  </Link>
</Button>

With this change, the active contact is now correctly shown in the list.

What about NavLink?

React Router also includes the component https://reactrouter.com/api/components/NavLink#props, which extends Link with improvements for the active and pending states.

Specifically:

It automatically applies classes to the link when it’s active or pending.
It adds the attribute aria-current="page" when the link represents the current route.

In our case, since we use ShadCN’s Button, we don’t take advantage of NavLink’s CSS classes, but we can benefit from its accessibility support (aria-current), which is a good practice for navigations like this.

<Button
  key={contact.id}
  className="justify-start"
  variant={contact.id === contactId ? "default" : "ghost"}
  asChild
>
  <NavLink to={`/contacts/${contact.id}`} viewTransition>
    {contact.name}
  </NavLink>
</Button>

And that’s it for this part. In the next post we’ll dive into actions, another interesting concept inherited from Remix, which will allow us to start making mutations within the app

React Router Data Mode: Part 4 - Routes with parameters, useRouteLoaderData and useParams

Wed, 23 Jul 2025 08:30:33 +0000

We continue with the fourth part of this series on React Router data mode. This time, we’ll dive deeper into loaders, first by adding a contact detail screen and then exploring hooks like useRouteLoaderData and useParams.

If you’re coming from the previous post, you can continue with your project as is. But if you prefer to start fresh or make sure you’re at the exact point, run the following commands:

# Repository link https://github.com/kevinccbsg/react-router-tutorial-devto
git reset --hard
git clean -d -f
git checkout 03-loaders-detail-page

A quick recap

So far, we only have the / and contacts/new routes, but we’re missing something key: a detail page for each contact. This page will live inside the root route /, so we need to:

Create the new page.
Add a nested route with a parameter.
Review our links.

1. Create the page

Create src/pages/ContactDetail.tsx, for now with a very basic design. In the next part, we’ll improve the UI:


const contact = {
  firstName: 'John',
  username: 'john_doe',
};

const ContactDetail = () => {
  return (
    <div>
      <h2>Contact Detail</h2>
      <p>{contact.firstName}</p>
      <p>{contact.username}</p>
    </div>
  );
}

export default ContactDetail;

2. Create the nested route

We want the route to change according to the contact: contacts/:contactId. We won’t use query params like ?id=123, because we’re not filtering a list, but accessing an individual resource.

const AppRoutes = createBrowserRouter([
  {
    path: "/",
    loader: loadContacts,
    HydrateFallback: ContactsSkeletonPage,
    Component: ContactsPage,
    children: [
      {
        path: "contacts/:contactId",
        Component: ContactDetail,
      },
      {
        path: "contacts/new",
        Component: ContactForm,
      },
    ],
  },
  ... // the other routes
]);

3. Review our links

Our links were already well defined:

<Link to={`/contacts/${contact.id}`} viewTransition>
  {contact.firstName} {contact.lastName}
</Link>

However, now we can see that when selecting each contact, the URL changes but the content remains the same. This is because our page always shows the same content. We need to add our loader.

Add the loader for the detail

Right now, no matter which contact we select, the same content is always shown. We need a loader to load the correct contact.

Create a new method in src/pages/loader.ts. This time, we’ll need to access params to get the contactId.

export const loadContactDetail = async ({ params }: LoaderFunctionArgs) => {
  const contactId = params.contactId;
  /*
  Here we validate that contactId exists.
  We’ll cover 404 error handling or invalid responses in
  another post
  */
  if (!contactId) {
    throw new Error("Contact ID is required");
  }
  const contact = await fetchContactById(contactId);
  return { contact };
};

Also update the function in src/api/contacts.ts to simulate a delay:

export const fetchContactById = async (id: string) => {
  const response = await api.get<Contact>(`/contacts/${id}`);
  await delay(500); // Simulate network delay
  return response.data;
};

Now, connect everything in the routes:

const AppRoutes = createBrowserRouter([
  {
    path: "/",
    loader: loadContacts,
    HydrateFallback: ContactsSkeletonPage,
    Component: ContactsPage,
    children: [
      {
        path: "contacts/:contactId",
        loader: loadContactDetail,
        Component: ContactDetail,
      },
      {
        path: "contacts/new",
        Component: ContactForm,
      },
    ],
  },
  ...
]);

And in the component:

import { useLoaderData } from "react-router";
import { loadContactDetail } from "./loader";

const ContactDetail = () => {
  const { contact } = useLoaderData<typeof loadContactDetail>();
  return (
    <div>
      <h2>Contact Detail</h2>
      <p>{contact.firstName}</p>
      <p>{contact.username}</p>
    </div>
  );
}

export default ContactDetail;

With this, we now have our functional detail screen using loaders.

But didn’t we already have that data in another loader?

Our detail screen lives inside the main route /, which already loads all contacts. Does it make sense to make another API call just to show a contact we already have?

We can avoid this by using the useRouteLoaderData hook.

Using useRouteLoaderData

This hook lets you access the data from a loader. In our case, the root route (/).

First, give that route an id and remove the loader from the detail:

const AppRoutes = createBrowserRouter([
  {
    path: "/",
    loader: loadContacts,
    id: "root",
    HydrateFallback: ContactsSkeletonPage,
    Component: ContactsPage,
    children: [
      {
        path: "contacts/:contactId",
        Component: ContactDetail,
      },
      {
        path: "contacts/new",
        Component: ContactForm,
      },
    ],
  },
  ...
]);

And in the component:

import { useRouteLoaderData } from "react-router";
import { loadContacts } from "./loader";

const ContactDetail = () => {
  const routeData = useRouteLoaderData<typeof loadContacts>("root");
  if (!routeData) {
    return <div>Loading...</div>;
  }
  const contact = routeData.contacts[0]; // For simplicity, show the first one
  return (
    <div>
      <h2>Contact Detail</h2>
      <p>{contact.firstName}</p>
      <p>{contact.username}</p>
    </div>
  );
}

export default ContactDetail;

As you can see, we use useRouteLoaderData with the ID "root" to access the data already loaded by the root route’s loader. We also add typeof loadContacts so TypeScript gives us autocomplete and type checking. It’s important to validate that the data exists, since on the first load it might not be available. That’s why we show a fallback (Loading...) in the meantime.

But we need to know which contact to show

For that, we use useParams to access the params defined in the URL:

import { useParams, useRouteLoaderData } from "react-router";
import { loadContacts } from "./loader";

const ContactDetail = () => {
  const { contactId } = useParams<{ contactId: string }>(); // Needs TS type annotation
  const routeData = useRouteLoaderData<typeof loadContacts>("root");
  if (!routeData) {
    return <div>Loading...</div>;
  }

  const { contacts } = routeData;
  
  // Find the contact locally
  const contact = contacts.find(({ id }) => id === contactId);

  if (!contact) {
    return <div>Contact not found</div>;
  }
  return (
    <div>
      <h2>Contact Detail</h2>
      <p>{contact.firstName}</p>
      <p>{contact.username}</p>
    </div>
  );
}

export default ContactDetail;

Now we have navigation between contacts working with already loaded data, without extra requests. We also reviewed how to use params in both loaders and components, with proper typing.

In part 5 we’ll improve the detail design and refactor navigation, making sure the active link is correctly marked.
See you in the next one!

React Router Data Mode: Part 3 - Loaders and data fetching

Mon, 07 Jul 2025 11:18:14 +0000

Let's move on to the third part of this tutorial series. In this case, we'll look at a concept that comes from Remix and can now also be found in React Router: loaders.

If you're coming from the previous tutorial, you can leave the project as is, but if you want to make sure everything is clean or start from the same point, you can run the following commands:

# Repository link https://github.com/kevinccbsg/react-router-tutorial-devto
git reset --hard
git clean -d -f
git checkout 02-loaders-detail-page

What are loaders?

Loaders are a mechanism that React Router provides to send information to our components. They are functions that we add in our route definitions.

Here's an example:

createBrowserRouter([
  {
    path: "/",
    loader: async () => {
      // return data from here
      return { records: await getSomeRecords() };
    },
    Component: MyRoute,
  },
]);

In loaders, we add everything we consider necessary to load for that page. When working with React Router, we need to start thinking in terms of pages, since all data loading and mutation is organized at that level.

In our contacts page, we're currently using a hardcoded array of data, which isn't realistic. So, we'll replace it with a call to an API we've created using json-server.
We won't go into detail about what json-server is (it's basically a quick way to simulate a REST API with a JSON file), just note that from now on we'll test the app with the command:

npm run serve:dev

This command starts both the API with json-server and the frontend.

In the src/api folder are all the methods that call the API using Axios. Since this series is about React Router, we won't go into detail about that part.

Now that we've covered the workflow, let's start the refactor. Normally in React, to load data in a component, we use something like:

const [contacts, setContacts] = useState<Contact[]>([]);

useEffect(() => {
  fetchContacts()
    .then((data) => setContacts(data))
}, []);

With React Router, this changes, as we'll use a loader defined in AppRoutes.tsx:

import { createBrowserRouter } from "react-router";
import ContactsPage from "./pages/Contacts";
import ContactForm from "./pages/ContactForm";
import { fetchContacts } from "@/api/contacts";

const AppRoutes = createBrowserRouter([
  {
    path: "/",
    // this property
    loader: async () => {
      const contacts = await fetchContacts();
      return { contacts };
    },
    Component: ContactsPage,
    children: [
      {
        path: "contacts/new",
        Component: ContactForm,
      },
    ],
  },
  {
    path: "/about",
    element: <div>About</div>,
  },
  {
    path: "*",
    element: <div>Not Found</div>,
  },
]);

export default AppRoutes;

Although this works, and we could then access the data using a React Router hook, I don't recommend doing it this way. The routes file can grow a lot, and later we'll need to solve a typing issue with TypeScript, for which this approach isn't ideal.

It's better to create a separate file, for example: src/pages/loader.tsx:

import { fetchContacts } from "@/api/contacts";

export const loadContacts = async () => {
  const contacts = await fetchContacts();
  return { contacts };
};

This way, the AppRoutes.tsx file is much cleaner:

import { createBrowserRouter } from "react-router";
import ContactsPage from "./pages/Contacts";
import ContactForm from "./pages/ContactForm";
import { loadContacts } from "./pages/loader";

const AppRoutes = createBrowserRouter([
  {
    path: "/",
    loader: loadContacts,
    Component: ContactsPage,
    children: [
      {
        path: "contacts/new",
        Component: ContactForm,
      },
    ],
  },
  {
    path: "/about",
    element: <div>About</div>,
  },
  {
    path: "*",
    element: <div>Not Found</div>,
  },
]);

export default AppRoutes;

If we navigate to the web app, we'll see in the "Network" tab that the API call is made.

But the data is still hardcoded in the UI. How do we retrieve the info?

We use the useLoaderData hook from React Router:

const { contacts } = useLoaderData();

This hook always returns what the loader defined in the route for the component returns. In this case, an object with contacts.

However, if we use this in a TypeScript project, we'll get a typing error. To fix it, we write it like this:

const { contacts } = useLoaderData<typeof loadContacts>();

So the Contacts component ends up like this:

import { Link, Outlet, useLoaderData } from "react-router";
import { ScrollArea } from "@/components/ui/scroll-area";
import { Button } from "@/components/ui/button";
import { loadContacts } from "./loader";

const ContactsPage = () => {
  const { contacts } = useLoaderData<typeof loadContacts>();
  return (
    <div className="h-screen grid grid-cols-[300px_1fr]">
      {/* Sidebar */}
      <div className="border-r p-4 flex flex-col gap-4">
        <Button className="w-full" variant="secondary" asChild>
          <Link to="/contacts/new" viewTransition>
            New
          </Link>
        </Button>
        <ScrollArea className="flex-1">
        <div className="flex flex-col gap-1 mt-4">
          {contacts.map(contact => (
            <Button
              key={contact.id}
              className="justify-start"
              asChild
            >
              <Link to={`/contacts/${contact.id}`} viewTransition>
                {contact.firstName} {contact.lastName}
              </Link>
            </Button>
          ))}
        </div>
      </ScrollArea>
      </div>
      {/* Detail View */}
      <div className="p-8">
        <Outlet />
      </div>
    </div>
  );
};

export default ContactsPage;

That's why it's more convenient to have a loader file per page, as it improves type management and keeps everything more separated.

With this, we're doing the same as we did with useEffect, but in the recommended way for React Router.

Finally, you may have noticed a warning in the terminal:

This is because we don't have a loading screen yet. We can simulate a delay in the API to see the problem. In src/api/contacts.ts, uncomment the delay function and modify fetchContacts:

export const fetchContacts = async () => {
  const response = await api.get<Contact[]>('/contacts');
  await delay(2000); // Simulate network latency
  return response.data;
};

When we reload, we'll see the page stays blank for a few seconds until the data loads. This is because there's no loading state. React Router allows us to handle this in several ways, but in this post we'll use the HydrateFallback property.

In this project, we already have the ContactsSkeletonPage component, so we add it like this:

import { createBrowserRouter } from "react-router";
import ContactsPage from "./pages/Contacts";
import ContactForm from "./pages/ContactForm";
import { loadContacts } from "./pages/loader";
import ContactsSkeletonPage from "./Layouts/HomeSkeleton";

const AppRoutes = createBrowserRouter([
  {
    path: "/",
    loader: loadContacts,
    HydrateFallback: ContactsSkeletonPage,
    Component: ContactsPage,
    children: [
      {
        path: "contacts/new",
        Component: ContactForm,
      },
    ],
  },
  {
    path: "/about",
    element: <div>About</div>,
  },
  {
    path: "*",
    element: <div>Not Found</div>,
  },
]);

export default AppRoutes;

And with this, we now have a loading screen. The best part is that this can be applied per page, and each one loads independently without blocking the others.

We'll see this in more detail in the next post about loaders.
Without a doubt, this is one of the most important and powerful parts of React Router, and it will be even more so when we combine it with actions.

See you in part 4

React Router Data Mode: Part 2 - Nested routes and outlets

Fri, 04 Jul 2025 09:09:28 +0000

In this second part of our React Router v7 tutorial, we will dive deeper into the routing system: how to nest views within a shared layout, how to navigate without reloading the page using Link, and how to add visual transitions for a smoother experience.

If you're coming from the previous tutorial, you can leave the project as it is, but if you want to ensure everything is clean or start from the same point, you can run the following commands:

## Repository link https://github.com/kevinccbsg/react-router-tutorial-devto
git reset --hard
git clean -d -f
git checkout 01-outlet-nested-routes-links

Initial route structure

Let's first prepare our routes file. We'll modify the src/AppRoutes.tsx file to use the Component property instead of element for our main pages. We use Component instead of element when we want to directly pass a reference to the component without needing JSX ().

The code will look like this:

// filepath: /root/brikev/react-router-tutorial-devto/src/AppRoutes.tsx
import { createBrowserRouter } from "react-router";
import ContactsPage from "./pages/Contacts";
import ContactForm from "./pages/ContactForm";

const AppRoutes = createBrowserRouter([
  {
    path: "/",
    Component: ContactsPage,
  },
  {
    path: "/contacts/new",
    Component: ContactForm,
  },
  {
    path: "/about",
    element: <div>About</div>,
  },
  {
    path: "*",
    element: <div>Not Found</div>,
  },
]);

export default AppRoutes;

As you can see, we simply indicate which component should be displayed for each route.

Create our pages

Now let's create the ContactsPage and ContactForm components. To organize ourselves better, we'll save them in a new folder src/pages.

src/pages/Contacts.tsx

// filepath: /root/brikev/react-router-tutorial-devto/src/pages/Contacts.tsx
import { ScrollArea } from "@/components/ui/scroll-area";
import { Button } from "@/components/ui/button";

const contacts = [ // mock data
  {
    "id": "1",
    "firstName": "Jane",
    "lastName": "Doe",
    "username": "jane_doe",
    "avatar": "https://i.pravatar.cc/150?img=1",
    "email": "*Emails are not allowed*",
    "phone": "+1 555-1234",
    "favorite": true
  },
  {
    "id": "2",
    "firstName": "John",
    "lastName": "Smith",
    "username": "john_smith",
    "avatar": "https://i.pravatar.cc/150?img=12",
    "email": "*Emails are not allowed*",
    "phone": "+1 555-5678",
    "favorite": true
  }
];

const ContactsPage = () => {
  return (
    <div className="h-screen grid grid-cols-[300px_1fr]">
      {/* Sidebar */}
      <div className="border-r p-4 flex flex-col gap-4">
        <Button className="w-full" variant="secondary" asChild>
          <a href="/contacts/new">
            New
          </a>
        </Button>
        <ScrollArea className="flex-1">
        <div className="flex flex-col gap-1 mt-4">
          {contacts.map(contact => (
            <Button
              key={contact.id}
              className="justify-start"
              asChild
            >
              <a href={`/contacts/${contact.id}`}>
                {contact.firstName} {contact.lastName}
              </a>
            </Button>
          ))}
        </div>
      </ScrollArea>
      </div>
      {/* Detail View */}
      <div className="p-8">
        Contact page
      </div>
    </div>
  );
};

export default ContactsPage;

src/pages/ContactForm.tsx

// filepath: /root/brikev/react-router-tutorial-devto/src/pages/ContactForm.tsx
import { Button } from '@/components/ui/button';
import { Input } from '@/components/ui/input';
import { Label } from '@/components/ui/label';

const ContactForm = () => {
  return (
    <div className="max-w-md mx-auto">
      <h1 className="text-2xl font-bold mb-4">Create New Contact</h1>
      <form className="space-y-4">
        <div>
          <Label className="mb-2" htmlFor="firstName">First Name</Label>
          <Input type="text" id="firstName" name="firstName" required />
        </div>
        <div>
          <Label className="mb-2" htmlFor="lastName">Last Name</Label>
          <Input type="text" id="lastName" name="lastName" required />
        </div>
        <div>
          <Label className="mb-2" htmlFor="username">Username</Label>
          <Input type="text" id="username" name="username" required />
        </div>
        <div>
          <Label className="mb-2" htmlFor="email">Email</Label>
          <Input type="email" id="email" name="email" required />
        </div>
        <div>
          <Label className="mb-2" htmlFor="phone">Phone</Label>
          <Input type="tel" id="phone" name="phone" required />
        </div>
        <div>
          <Label className="mb-2" htmlFor="avatar">Avatar (Optional)</Label>
          <Input type="url" id="avatar" name="avatar" />
        </div>
        <Button type="submit">
          Create Contact
        </Button>
      </form>
    </div>
  );
};

export default ContactForm;

If you visit / or /contacts/new, you should see both pages, but... something is not right:

The form is displayed as a standalone page, without maintaining the sidebar layout. Also, when using the "New" link, we see a full page reload, indicating that we don't yet have a properly configured SPA navigation.

Nest routes within a layout

Now that we have both pages, let's make the /contacts/new route not standalone but rendered within the main contacts page layout (i.e., within ContactsPage).

// filepath: /root/brikev/react-router-tutorial-devto/src/AppRoutes.tsx
import { createBrowserRouter } from "react-router";
import ContactsPage from "./pages/Contacts";
import ContactForm from "./pages/ContactForm";

const AppRoutes = createBrowserRouter([
  {
    path: "/",
    Component: ContactsPage,
    children: [
      {
        path: "contacts/new",
        Component: ContactForm,
      },
    ],
  },
  {
    path: "/about",
    element: <div>About</div>,
  },
  {
    path: "*",
    element: <div>Not Found</div>,
  },
]);

export default AppRoutes;

We now have the nested route, but it won't display until we specify where the children should appear. For that, we use the Outlet component.

Display child routes with Outlet

Within the ContactsPage component, let's import and place Outlet exactly where we want the child pages to be displayed:

// filepath: /root/brikev/react-router-tutorial-devto/src/pages/Contacts.tsx
// Import the component
import { Link, Outlet } from "react-router";
// ...existing code...
{/* Detail View */}
<div className="p-8">
  <Outlet />
</div>

So far, we've used <a> for links, but that causes a full page reload. To enable client-side navigation (without reloading), we need to use the Link component from react-router.

Instead of this:

<a href="/contacts/new">New</a>

Do this:

<Link to="/contacts/new" viewTransition>
  New
</Link>

<Link to={`/contacts/${contact.id}`} viewTransition>
  {contact.firstName} {contact.lastName}
</Link>

The viewTransition prop enables automatic route transition animations (if the browser supports it). Very useful for making navigation feel smoother! By default, it does a fade-in, but this can be customized much further. We can discuss this in a future post.

Recap

So far, we've achieved:

A main route with a layout
Nested routes displayed within that layout
Using Link instead of a to avoid reloads
Enabling visual transitions between routes

What's next?

In the next part, we will do something very powerful: render dynamic data based on the URL and learn how to use loaders to fetch data.
Let's dive into the magic of React Router v7!

See you in part 3.

React Router Data Mode: Part 1 - Installation and first routes

Fri, 27 Jun 2025 07:42:23 +0000

In this series, we will focus on the Data Mode, which is undoubtedly my favorite for creating well-structured and maintainable SPAs.

This series will have several parts, which you can see below:

Installation and first routes
Nested routes and Outlet
Loaders
Routes with parameters, useRouteLoaderData, and useParams
useParams, Navlink
Actions
Multiple actions and form handling on a single page
Form validation and useFetcher
Optimistic UI with useFetcher
Testing with Vitest and React Testing Library

All parts will be explained in this repository, which already comes prepared with some components and style libraries like shadcn/ui and Tailwind.

What are we going to build?

A contact application where we will practice nested routes, data loading and mutation, navigation, validations, etc.

Let's get started!

Installation and first routes

The first step is to clone the base repository.

In your terminal:

git clone *Emails are not allowed*:kevinccbsg/react-router-tutorial-devto.git
# Move to the initial tag
git checkout 00-init-project

Install the dependencies:

npm i

This project is created with Vite and has the shadcn/ui library integrated. We won't explain that part here, but if you'd like a tutorial on Vite + shadcn, let me know in the comments.

Now start the project:

npm run dev

You will see something very simple on the screen: an <h1> with the text "Welcome to React!". Let's change that and start using React Router (Data Mode).

Install React Router

Run:

npm i react-router

Create a new file called src/AppRoutes.tsx, which will contain our route configuration:

import { createBrowserRouter } from "react-router";

const AppRoutes = createBrowserRouter([
  {
    path: "/",
    element: <div>Home</div>,
  },
  {
    path: "/about",
    element: <div>About</div>,
  },
  {
    path: "*",
    element: <div>Not Found</div>,
  },
]);

export default AppRoutes;

Unlike the Declarative Mode (where we use <Routes> and <Route>), in Data Mode, we define routes as objects. Each object represents a route and can include elements like element, loader, action, etc.

In this example:

/ displays a simple "Home"
/about displays "About"
* captures any undefined route (what React Router calls a "splat") and displays "Not Found"

Connect the router with React

To activate React Router, we need to connect it in main.tsx. Edit the file as follows:

import { StrictMode } from 'react'
import { createRoot } from 'react-dom/client'
import './index.css'
import { RouterProvider } from "react-router";
import router from './AppRoutes';

createRoot(document.getElementById('root')!).render(
  <StrictMode>
    <RouterProvider router={router} />
  </StrictMode>,
);

Done! If you visit /, /about, or any other route, you should see the corresponding content.

What's next?

In the next part, we will build the real structure of the application, see how to use Outlet for nested routes, Link, and create a base layout.

See you in part 2.

React Router v7: The Evolution React Needed

Thu, 26 Jun 2025 22:08:37 +0000

If you're reading this, you're probably working with React or learning how to use it. And if that’s the case, you’ve surely heard of react-router, the most popular library for routing in React apps for years.

But what you may not know is that in its latest version, React Router has evolved significantly. It now incorporates concepts from Remix like loaders, actions, ErrorBoundaries, SSR support, and more.

Remix? That’s right. The Remix framework has always been built on top of React Router. But with this new version (v7), the experience has been unified—now you can use that same architecture directly in React Router, without needing to adopt a full framework.

What Does React Router v7 Offer?

The best way to understand what React Router v7 brings is by looking at its three usage modes, each designed for different levels of complexity and application needs:

Declarative Mode
Data Mode
Framework Mode

Let’s break down what each one is and when to use them.

Declarative Mode

This is the classic approach you’re probably already familiar with. You use components like <Routes> and <Route> to define your routes, along with hooks like useNavigate, useParams, and so on.

<Routes>
  <Route index element={<Home />} />
  <Route path="about" element={<About />} />

  <Route element={<AuthLayout />}>
    <Route path="login" element={<Login />} />
    <Route path="register" element={<Register />} />
  </Route>

  <Route path="concerts">
    <Route index element={<ConcertsHome />} />
    <Route path=":city" element={<City />} />
    <Route path="trending" element={<Trending />} />
  </Route>
</Routes>

This mode is perfect if you want a simple SPA using your own bundler (Vite, Webpack...), managing state with Zustand, Redux, or react-query, and you don’t need server-side rendering (SSR).

Data Mode

This is where React Router v7 really transforms. Instead of using components to define routes, you use a route config object. Each route can have a loader (to fetch data) and an action (to handle forms or mutations).

const router = createBrowserRouter([
  {
    path: "/",
    element: <div>Hello World</div>,
  },
]);

ReactDOM.createRoot(document.getElementById("root")).render(
  <RouterProvider router={router} />
);

A more complete example with a loader and action:

createBrowserRouter([
  {
    path: "/items",
    loader,
    action,
    Component: Items,
  },
]);

async function loader() {
  const items = await fakeDb.getItems();
  return { items };
}

async function action({ request }) {
  const data = await request.formData();
  await fakeDb.addItem({ title: data.get("title") });
  return { ok: true };
}

function Items() {
  const data = useLoaderData();
  return (
    <div>
      <TodoList items={data.items} />
      <Form method="post">
        <input type="text" name="title" />
        <button type="submit">Crear</button>
      </Form>
    </div>
  );
}

This mode is ideal if you're building a complex SPA and want to avoid useEffect chaos, centralizing your data flow. You can also keep your current stack and deploy wherever you want (Vercel, Netlify, Firebase, etc.).

I recommend checking out this ejemplos, and stay tuned—I'll be publishing more articles on how to make the most of this mode.

Framework Mode

This mode turns React Router into a full framework with SSR support. You start from scratch using a CLI, and it’s designed for apps that need SEO or super-fast initial loads.

It has the best TypeScript support, shares the loaders and actions concept from Data Mode, and gives you full control.

However, keep in mind:

You need to define your deployment setup from the start.
Not all libraries work well with SSR.
Your team should understand the difference between CSR and SSR.
It works best with Tailwind or styling approaches compatible with SSR.

That said, if your app is private or doesn’t need SEO, I’d recommend sticking with Declarative or Data Mode to avoid unnecessary complexity.

So, Is It Worth It?

Many React frameworks are adding complexity to the frontend with their latest updates. React Router v7 gives you a clear, flexible alternative:

Start with Declarative Mode if you just need routing.
Move to Data Mode to better manage data and forms.
And go full Framework Mode only if SSR is truly required.

All without locking yourself into a single approach from day one.

In upcoming posts, I’ll dive deeper into loaders, actions, and data-mode architecture—building projects from scratch, testing, and real-world integrations.

Are you interested in React Router v7? Want to see practical examples or comparisons with other solutions? Let me know in the comments—I’d love to hear from you.

Post about Use and Misuse of AI in Localized Content and Dynamic Creative Work

Wed, 05 Feb 2025 12:32:25 +0000

Artificial Intelligence (AI) has emerged as a transformative tool across industries. From automating repetitive tasks to generating creative content, it has become an ally to many. However, like any tool, its value lies in how we use it. When misapplied—particularly in areas like localized content creation—it can lead to inaccuracies, cultural insensitivity, and poorly tailored results.
Also in programming, the use of open-source libraries, frameworks and rapidly changing code conventions that are constantly in development. Framework dependencies as upgrades happen soon turn out to cause issues in program development.

Awhile ago when i was trying to unbundle webpack as a newbie in React.js. i found a video that took me on a course on React and React-router using Webpack.
Before i realized that the video was outdated, i ran into error from getting up the webpack structure.
I noticed that their code was working but each time i try it out the, code does not give me the expected result.
I took the error message to Gemini and the response was based on the outdated library i was using.
It was when I rephrased and asked

"Is the current webpack library i was using outdated and is there a
new convention in implementing this code to resolve these errors, also
sending my package.json."

This new query was the beginning of the resolution of the error-bug.

Old Webpack Configuration (Pre-Version 4)

// webpack.config.js (Outdated)
const path = require('path');

module.exports = {
  entry: './src/index.js', // Entry point
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'bundle.js', // Output bundle
  },
  module: {
    rules: [
      {
        test: /\.js$/, // Handling JavaScript files
        exclude: /node_modules/,
        loader: 'babel-loader', // Transpile ES6+ to ES5
      },
    ],
  },
  devServer: {
    contentBase: path.join(__dirname, 'dist'), // Serve static files
    port: 8080,
  },
};

Modern Webpack Configuration (Version 4 and Beyond)

// webpack.config.js (Modern)
const path = require('path');

module.exports = {
  mode: 'development', // Mode: "development" or "production"
  entry: './src/index.js', // Entry point
  output: {
    filename: 'main.js', // Default: "main.js" if not specified
    path: path.resolve(__dirname, 'dist'),
  },
  module: {
    rules: [
      {
        test: /\.js$/, // Handle JavaScript files
        exclude: /node_modules/,
        use: 'babel-loader', // Simplified syntax for loaders
      },
    ],
  },
  devServer: {
    static: './dist', // Serve static files (simplified from contentBase)
    port: 3000, // Optional: Default port is 8080
  },
};

Modern tools like create-react-app and Vite have revolutionized how React applications are built by abstracting away complex Webpack configurations. With just a single command, these tools scaffold a fully functional React app with sensible defaults, making them ideal for beginners or developers who want to focus more on coding than configuration.
For example, create-react-app and its TypeScript counterpart (create-react-app-template-typescript) provide a zero-config setup with Webpack under the hood.
On the other hand, Vite, a newer alternative, offers a lightweight and faster development experience by leveraging native ES modules and modern build tools like Rollup.

However, for developers who want to understand the inner workings of their build tools or customize their setup, starting from scratch with npm init -y and manually configuring Webpack is still a valuable exercise. Below, I’ll show how these tools compare to a manual Webpack setup.

Using create-react-app With create-react-app, setting up a React app
is as simple as running:

npx create-react-app my-app
cd my-app
npm start

To add TypeScript support, use:

npx create-react-app my-app --template typescript

This generates a React app with Webpack preconfigured and ready to go. You don’t need to touch webpack.config.js unless you eject the app (which is rarely necessary). The simplicity makes it perfect for most use cases.

Using Vite to Create a React App Vite provides an even faster and more
modern approach:

npm create vite@latest my-app
cd my-app
npm install
npm run dev

You can also specify React and TypeScript templates during setup:

npm create vite@latest my-app -- --template react
npm create vite@latest my-app -- --template react-ts

Vite eliminates the need for Webpack entirely, offering faster builds and hot module replacement (HMR).

Manual Webpack Setup For a manual setup, follow these steps:

1. Initialize a new project:

 mkdir my-app
    cd my-app
    npm init -y

2. Install Webpack and React dependencies:

npm install react react-dom webpack webpack-cli webpack-dev-server babel-loader @babel/core @babel/preset-env @babel/preset-react html-webpack-plugin --save-dev

3. Create a webpack.config.js file to configure Webpack.

Below is a sample Webpack configuration for a React app:

> // webpack.config.js

    const path = require('path');
    const HtmlWebpackPlugin = require('html-webpack-plugin');
    
    module.exports = {
      mode: 'development', // Switch to "production" for production builds
      entry: './src/index.js', // Main entry point
      output: {
        path: path.resolve(__dirname, 'dist'), // Output directory
        filename: 'bundle.js', // Output bundle name
        clean: true, // Cleans 'dist' folder before each build
      },
      module: {
        rules: [
          {
            test: /\.js$/, // Handle JavaScript files
            exclude: /node_modules/,
            use: {
              loader: 'babel-loader',
              options: {
                presets: ['@babel/preset-env', '@babel/preset-react'], // Transpile modern JavaScript and React JSX
              },
            },
          },
          {
            test: /\.css$/, // Handle CSS files
            use: ['style-loader', 'css-loader'], // Inject styles into DOM
          },
        ],
      },
      plugins: [
        new HtmlWebpackPlugin({
          template: './public/index.html', // Template HTML file
        }),
      ],
      devServer: {
        static: path.resolve(__dirname, 'dist'), // Serve static files from 'dist'
        port: 3000, // Development server port
        hot: true, // Enable hot module replacement
      },
      resolve: {
        extensions: ['.js', '.jsx'], // Resolve these extensions in imports
      },
    };

4. Create the project structure:

  my-app/

      ├── src/

          │├── index.js

          │├── App.js

      ├── public/

         │ ├── index.html

      ├── webpack.config.js

     ├── package.json

5. Add the following scripts to your package.json:

json

    "scripts": {
      "start": "webpack serve --open",
      "build": "webpack"
    }

6. Run the app:

   npm start

Issues that arise in open-source library dependent framework
React as a Project has been on version 18 which there have been crash courses out there and documentations. Ai which uses the Large Language Model (LLM) from either google or any backbone server and data warehouse feed on the outdated information which is used to train this AI.
Most of the documentations are not being updated which lead to outdated response when the current libraries of React have depreciated because react 19 is out.
An example of this is the new way "use" is used to fetch data from an api instate of the joint work of the useEffect and storing state with useStates.

Outdated Approach: Data Fetching Using useEffect and useState

function OldUserProfile() {
  const [userData, setUserData] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    fetch('https://api.example.com/user')
      .then(res => res.json())
      .then(data => {
        setUserData(data);
        setLoading(false);
      });
  }, []);

  if (loading) return <div>Loading...</div>;
  
  return (
    <div className="p-4">
      <h1 className="text-xl font-bold">User Profile</h1>
      <p>Name: {userData.name}</p>
      <p>Email: {userData.email}</p>
    </div>
  );
}

Modern Approach: Data Fetching Using the use() Hook

   // Modern approach - app/root.jsx or similar
import { createBrowserRouter, RouterProvider } from 'react-router-dom';
import { use } from 'react';

// Example of modern data fetching with 'use'
function UserProfile() {
  // The new 'use' approach for data fetching
  const userData = use(fetch('https://api.example.com/user')
    .then(res => res.json()));

  return (
    <div className="p-4">
      <h1 className="text-xl font-bold">User Profile</h1>
      <p>Name: {userData.name}</p>
      <p>Email: {userData.email}</p>
    </div>
  );
}

Key Improvements:

The use() hook eliminates the need for useEffect and useState when fetching data.
Data fetching is more declarative and less verbose.
This works seamlessly with React's server components, aligning well with modern rendering patterns.

Also React-router initially wrap the provider tag in the index.js file, then wrap the file in the app.js using the browser router as router, routes and nav links and the new use of links instead

Outdated React Router Conventions

// index.js
import React from 'react';
import ReactDOM from 'react-dom';
import { BrowserRouter } from 'react-router-dom';
import App from './App';

ReactDOM.render(
  <BrowserRouter>
    <App />
  </BrowserRouter>,
  document.getElementById('root')
);

// App.js
import React from 'react';
import { Route, Switch, NavLink } from 'react-router-dom';

function App() {
  return (
    <div>
      <nav>
        <NavLink to="/">Home</NavLink>
        <NavLink to="/about">About</NavLink>
      </nav>
      <Switch>
        <Route path="/" exact>
          <h1>Home Page</h1>
        </Route>
        <Route path="/about">
          <h1>About Page</h1>
        </Route>
      </Switch>
    </div>
  );
}

export default App;

Modern React Router Conventions

const router = createBrowserRouter([
  {
    path: "/",
    element: <Root />,
    children: [
      {
        path: "user",
        element: <UserProfile />,
        // You can also use loaders for data fetching
        loader: async () => {
          return fetch('https://api.example.com/user');
        }
      },
      {
        path: "review-booking",
        element: <ReviewBooking />,
      },
      // ... other routes
    ],
  },
]);

// Root component
function Root() {
  return (
    <div>
      <nav>
        {/* Modern Link usage */}
        <Link to="/user">User Profile</Link>
        <Link to="/review-booking">Review Booking</Link>
      </nav>
      <Outlet />
    </div>
  );
}

// App component
export default function App() {
  return <RouterProvider router={router} />;
}

The Right Way to Use AI

Localized Content Creation

AI has immense potential to assist in creating localized content. It can help translate, adapt styles, and even suggest culturally relevant expressions. However, the key here is collaboration, not replacement. AI can provide a starting point, but the human touch ensures that the content resonates with the intended audience. Nuances in language, cultural references, and local idioms are often things AI struggles to fully grasp.

Code Writing Assistance

AI has become a programmer’s best friend, especially when it comes to generating boilerplate code or debugging complex problems. Tools like GitHub Copilot and ChatGPT can suggest solutions, optimize algorithms, and even generate entire functions. But relying on AI blindly can result in brittle, unoptimized, or even insecure code. Always review and test the generated code thoroughly. AI should complement your skills, not replace them.

Feedback in Article Journaling

When writing articles or journaling, AI can act as a brainstorming partner. Whether you’re stuck on an introduction or need help refining a paragraph, AI tools can offer suggestions. However, their outputs should be critically assessed. AI doesn’t understand your voice or your audience’s expectations—it generates content based on patterns, not emotions or intent.

The Wrong Way to Use AI

Misusing AI in Localized Content

One of the most common pitfalls is treating AI as a "one-size-fits-all" solution. For example, using AI to directly translate content for different regions without a human review can result in awkward phrasing or offensive translations. Localization isn’t just about language—it’s about context, tone, and cultural relevance. Ignoring this can alienate your audience rather than engaging them.

Blindly Trusting AI-Generated Code

AI-generated code can often appear perfect at first glance, but it may contain subtle bugs, inefficiencies, or security vulnerabilities. Copy-pasting code without understanding it risks introducing issues into your project. Always review the code, test extensively, and adapt it to fit your specific requirements.

Overreliance on AI for Creativity

While AI can assist with creativity, it’s not a replacement for human originality. Overusing AI for journaling or content creation can lead to generic, uninspired results. The magic of writing comes from your personal insights, emotions, and unique perspective—something AI cannot replicate.

Learn how to Implement Public, Private, and Protected Routes in your React Application

Thu, 03 Oct 2024 21:10:25 +0000

React Public, Protected, and Private Routes: A Comprehensive Guide

In certain applications, you might need to implement role-based authorization for your users to access certain pages and be restricted to others. For instance, in an e-commerce application, your users could sign up as a seller or a buyer, and based on their role, you give them access to certain pages in the application. Each page not accessible to a user due to their role is hidden in a private route, and every other page accessible to the users irrespective of their roles is a public route. Aside from private and public routes, there are also protected routes. To access the pages hidden in a protected route, your users must be authenticated—signed up or logged in.
In a multiple-role-based application, you need to implement these routes to have certain accesses and restrictions in place for your users. Without them, your application will be disorganized and confusing for your users and you, especially when accessing users' data.
React Router, the routing library built for React applications, does not have these pre-installed features, so you need to write special configurations for them in your application. In this article, you’ll learn how to create these three special routes for your applications and implement role-based authorization in your React apps through them.

Prerequisites

Although this is a straightforward article, you need to have a good understanding of:

React
React Router
Authorization and Authentication.

Nevertheless, I’ll briefly introduce the mentioned libraries.

Brief Introduction to React, React Router, Authorization, and Authentication

React is a popular JavaScript frontend library built by Facebook to help developers easily start up a web application. It’s a Single Page Application (SPA) library which renders your app in a single HTML file rather than having multiple HTML files for all your application’s pages. React allows you to break down frequently occurring aspects of your app into reusable components, preventing unnecessary repetitions which tend to increase your file size and slow down page load time. In React applications, React Router is used to enable easy navigation across pages. Rather than moving from the home page to the products page with an anchor tag that links both pages, you could use a Link component from the React Router Dom library to achieve the same result faster. In addition to being fast, using React Router Link prevents page refresh, which the anchor tag enables, thereby preserving your application states which could be wiped away when the page is refreshed in the case of an anchor tag.
Authorization and authentication, though appear to have similar meanings, are different. Authentication is the validation of your entity while attempting entrance to a web application, while authorization is the access to features upon your entrance. For instance, you are checked at the front desk of a hotel after booking. The front desk clerk checks to confirm that you’re the one who booked a suite in the hotel by asking for a form of proof which could be a passcode—that is authentication. Upon identity verification at the front desk, you get a key or a card to access the room—authorization. Also, based on the suite type you paid for, you’re entitled to certain hospitality features and restricted from others—role-based authorization.
With the prerequisite terms cleared, let’s proceed to implementing the routes.

Route Definition: Explaining the routes in detail

Before we dive into protected routes, it's important to understand the distinction between different routes in a React application. Here's a table that clarifies the differences between public, private, and protected routes:

Understanding these distinctions will help you implement the appropriate routing strategy for your application.

Protected Route

Any page that you cannot access without authentication is a protected route. To implement a protected route in your application, you need to monitor the logged-in state of your user to know when to allow the user to access the page or redirect the user to the login page. The common page access authorization you get upon authentication is the token. The token is similar to the room key or card you get in a hotel upon identity verification, and in a web application, it is stored in the localStorage in most web applications. However, we'll use HTTP-only cookies to store authentication tokens instead of localStorage for enhanced security. Opposed to using localStorage, this approach helps protect against XSS attacks. The presence of the token in the browser cookies tells you that your user is authenticated, and the absence tells you the reverse—the user has logged out of the application. With this detail, we can implement a protected route component.
First and foremost, let’s create a React app and install React Router.

npm create vite@latest authorization-routes -- --template //vite
npm i react-router-dom // React Router

Cd into your app’s directory and open it in your code editor.

cd authorization-routes
code .

Encapsulate your application’s route in React router by wrapping the BrowserRouter component from react-router-dom around the AllRoutes.jsx file.

App.jsx

import { BrowserRouter } from "react-router-dom";

export default function App() {
  return (
    <BrowserRouter>
      <AllRoutes />
    </BroswerRouter>
  )
}

Then, create a useAuth hook to handle the users’ logged-in state and roles.

import { useState, useEffect } from 'react';

export function useAuth() {
  const [isLoggedIn, setIsLoggedIn] = useState(false);
  const [userRole, setUserRole] = useState(null);

  useEffect(() => {
    const checkAuthStatus = async () => {
      try {
        // Note: Ensure this endpoint is implemented on your server
        // It should validate the token (e.g., check expiration, decode payload)
        const response = await fetch('/api/auth/status', { credentials: 'include' });
        
        if (response.ok) {
          const data = await response.json();
          setIsLoggedIn(true);
          setUserRole(data.role);
        } else {
          // If the response is not OK, assume the user is not logged in
          setIsLoggedIn(false);
          setUserRole(null);
        }
      } catch (error) {
        console.error('Error checking auth status:', error);
        // In case of an error, assume the user is not logged in
        setIsLoggedIn(false);
        setUserRole(null);
      }
    };

    checkAuthStatus();

    // You might want to add a cleanup function or re-fetch logic here
    // depending on your application's needs
  }, []);

  return { isLoggedIn, userRole };
}

The useAuth hook is a custom React hook designed to manage the authentication state in our application.

Now, set up your AllRoutes.jsx page and implement the ProtectedRoute.

AllRoutes.jsx

import { Routes, Route, Navigate, useLocation } from "react-router-dom";

import { useAuth } from "./hooks/useAuth";
import LoginPage from "./pages/Auth/LoginPage";
import SignupPage from "./pages/Auth/SignupPage";
import DashboardPage from "./pages/Dashboard";
import ProfilePage from "./pages/Dashboard/ProfilePage";

export default function AllRoutes() {
  const location = useLocation();
  const { isLoggedIn } = useAuth();

  const ProtectedRoute = ({ children }) => {
    const { isLoggedIn } = useAuth();
    const location = useLocation();

    if (!isLoggedIn) {
      return <Navigate to="/login" state={{ from: location }} replace />;
    }
    return children;
  };
  return (
    <Routes>
      <Route path="/login" element={<LoginPage />} />
      <Route path="/sign-up" element={<SignupPage />} />
      <Route path="/user" element={<ProtectedRoute />}>
        <Route path="dashboard" element={<DashboardPage />} />
        <Route path="profile" element={<ProfilePage />} />
        {/* Other protected routes */}
      </Route>
    </Routes>
  )
}

Just as stated earlier, the protected route component follows a simple principle. It checks if a user is currently authenticated based on the presence of the token in the localStorage API. If the token is present, the user is authorized to access every route without role-based authorization. If not, the user is redirected to the login page to get authenticated.
The replace prop in the Navigate component ensures that the user cannot access the last authenticated page by clicking the back button on the browser.

Private Route

The Private component follows a similar paradigm to the protected route but with an extra layer of checks. In addition to checking if the user is authenticated, it checks for the user role before granting them access to the page.

AllRoutes.jsx

import { Routes, Route, Navigate, useLocation } from "react-router-dom";

import { useAuth } from "./hooks/useAuth";
import LoginPage from "./pages/Auth/LoginPage";
import SignupPage from "./pages/Auth/SignupPage";
import DashboardPage from "./pages/Dashboard";
import ProfilePage from "./pages/Dashboard/ProfilePage";
import UnauthorizedPage from "./pages/UnauthorizedPage";
import NotFoundPage from "./pages/NotFoundPage";

export default function AllRoutes() {
  const location = useLocation();
  const { isLoggedIn, userRole } = useAuth();

  const ProtectedRoute = ({ children }) => {
    const { isLoggedIn } = useAuth();
    const location = useLocation();

    if (!isLoggedIn) {
      return <Navigate to="/login" state={{ from: location }} replace />;
    }
    return children;
  };

  const PrivateRoute = ({ children, allowedRoles = [] }) => {
    const { isLoggedIn, userRole } = useAuth();
    const location = useLocation();

    if (!isLoggedIn) {
      return <Navigate to="/login" state={{ from: location }} replace />;
    }

    if (allowedRoles.length && !allowedRoles.includes(userRole)) {
      return <Navigate to="/unauthorized" replace />;
    }

    return children;
  };
  return (
    <Routes>
      <Route path="/login" element={<LoginPage />} />
      <Route path="/sign-up" element={<SignupPage />} />
      {/* Protected routes */}
      <Route path={`/${userRole}`} element={<ProtectedRoute />}>
        <Route path="dashboard" element={<DashboardPage />} />
        <Route path="profile" element={<ProfilePage />} />
      </Route>
      {/* Buyer's routes */}
      <Route path={`/${userRole}`} element={<PrivateRoute 
      allowedRoles={["buyer"]} />}>
        <Route path="cart" element={<CartPage />} />
        <Route path="wishlist" element={<WishlistPage />} />
      </Route>
      {/* Seller's routes */}
      <Route path={`/${userRole}`} element={<PrivateRoute 
      allowedRole={["seller"]} />}>
        <Route path="post-product" element={<PostProduct />} />
        <Route path="all-products" element={<AllProductsPage/>} />
      </Route>
      {/* Error handling routes */}
      <Route path="/unauthorized" element={<UnauthorizedPage />} />
      <Route path="*" element={<NotFoundPage />} />
    </Routes>
  )
}

An extra layer of scrutiny has been added to check the roles and give users access to the pages. The Private route takes 2 props—the children (the pages to be returned if the check is passed) and the role. The component checks if the user is logged in and the role passed matches the role returned by the useAuth hook. If the checks return true, the user gets access to the page; if not, the user is redirected to the login page.

Public Route

Although the public routes sound like those that should not need a special component, but when you realize how funny your users might be, you see a need to implement one. Logged-in users could decide to clear their current path in the browser and replace it with “/” to get to the home page rather than log out, and if your application allows such, it’s a terrible user experience practice. A public route component prevents logged-in users from accessing unauthenticated pages in the application by redirecting them to the current page they are on until they log out.
The Public route component contrasts the Protected and Private route components.

AllRoutes.jsx

import { Routes, Route, Navigate, useLocation } from "react-router-dom";

import { useAuth } from "./hooks/useAuth";
import LoginPage from "./pages/Auth/LoginPage";
import SignupPage from "./pages/Auth/SignupPage";
import DashboardPage from "./pages/Dashboard";
import ProfilePage from "./pages/Dashboard/ProfilePage";

export default function AllRoutes() {
  const location = useLocation();
  const { isLoggedIn, userRole } = useAuth();

  // Protected Route
  const ProtectedRoute = ({ children }) => {
    const { isLoggedIn } = useAuth();
    const location = useLocation();

    if (!isLoggedIn) {
      return <Navigate to="/login" state={{ from: location }} replace />;
    }
    return children;
  };

  // Private Route
  const PrivateRoute = ({ children, allowedRoles = [] }) => {
    const { isLoggedIn, userRole } = useAuth();
    const location = useLocation();

    if (!isLoggedIn) {
      return <Navigate to="/login" state={{ from: location }} replace />;
    }

    if (allowedRoles.length && !allowedRoles.includes(userRole)) {
      return <Navigate to="/unauthorized" replace />;
    }

    return children;
  };

  // Public Route
  const PublicRoute = ({ children }) => {
    const { isLoggedIn, userRole } = useAuth();
  
    if (isLoggedIn) {
      return <Navigate to={`/${userRole}/dashboard`} replace />;
    }
    return children;
  };

  return (
    <Routes>
      {/* Public Path */}
      <Route path="/" element={<PublicRoute />}>
        <Route path="login" element={<LoginPage />} />
        <Route path="sign-up" element={<SignupPage />} />
      </Route>
      {/* Protected routes */}
      <Route path={`/${userRole}`} element={<ProtectedRoute />}>
        <Route path="dashboard" element={<DashboardPage />} />
        <Route path="profile" element={<ProfilePage />} />
      </Route>
      {/* Buyer's routes */}
      <Route path={`/${userRole}`} element={<PrivateRoute 
      allowedRoles={["buyer"]} />}>
        <Route path="cart" element={<CartPage />} />
        <Route path="wishlist" element={<WishlistPage />} />
      </Route>
      {/* Seller's routes */}
      <Route path={`/${userRole}`} element={<ProtectedRoute 
      allowedRole={["seller"]} />}>
        <Route path="post-product" element={<PostProduct />} />
        <Route path="all-products" element={<AllProductsPage/>} />
      </Route>
      {/* Error handling routes */}
      <Route path="/unauthorized" element={<UnauthorizedPage />} />
      <Route path="*" element={<NotFoundPage />} />
    </Routes>
  )
}

Whenever a user attempts to navigate to any public routes without logging out, the Public route component gets the current pathname and redirects the user to the path if the user is logged in. If the user is not logged in, the user can easily navigate to the unauthenticated pages.

We've defined three types of route components to handle different access levels:

PublicRoute: This component is used for pages that should be accessible to all users, such as the home page, login page, and signup page. If a logged-in user tries to access these routes, they'll be redirected to their dashboard.
ProtectedRoute: This component is used for pages that require authentication but are accessible to all authenticated users, regardless of their role. The dashboard and profile pages are examples of protected routes.
PrivateRoute: This component is used for role-specific pages. It checks if the user is authenticated and also verifies if the user's role is included in the allowedRoles array. This allows for flexible role-based access control.

Using these components, we can easily control access to different parts of our application based on authentication status and user roles.

Real-World Implications of Route Types

Understanding the practical applications and implications of different route types is crucial for building secure and user-friendly React applications. Let's explore each type in more detail:

Public routes are commonly used in landing pages, about pages, pricing information, and login and registration pages. Without proper PublicRoute implementation, logged-in users might face confusing situations. For instance, if a user bookmarks the login page and accesses it later while already logged in, they could see the login form again instead of their dashboard. This creates a poor user experience and might lead to unnecessary logout/login cycles.

Protected routes are used for user dashboards, account settings pages, and basic features available to authenticated users. Failing to implement protected routes could lead to security vulnerabilities. Unauthenticated users might gain access to sensitive information or functionality. For example, if a user's session expires while browsing their account settings, they should be immediately redirected to the login page to authenticate. This ensures the security of their personal information.

Private routes are used for role-based pages like admin panels for admins, seller dashboards (in e-commerce applications), and premium features available to paying users. Without private routes, your application might expose functionality or information to users who shouldn't have access. This not only creates security risks but also leads to a confusing user experience. For instance, in an e-commerce platform, a regular buyer shouldn't see options to add or edit product listings, which should be restricted to seller accounts.

By implementing these route types correctly, you ensure that users are guided to the appropriate parts of your application based on their authentication status and role, sensitive information and functionality are protected from unauthorized access, and the user interface remains clean and relevant to their permissions and needs.

Conclusion

In the article, you’ve learned how to implement Private, Protected, and Public routes and also their differences. These explicit route components provide a clear structure for implementing different levels of access control in your React application. They make it easy to manage public, protected, and role-specific routes, improving the security and organization of your application.
Also, you’ve touched a bit of authorization and authentication. For a better understanding of these concepts see my article on the topic: https://drprime.hashnode.dev/authentication-vs-authorization.

Coder Legion - Recent posts tagged react-router

The easiest way to test React Router v7 apps

Setup

A fallback /testing route

Writing a route-level test

Backend tests: any runner works

Why this works: same utility, different environment

Try it

React Router Data Mode: Part 6 - Actions, forms and mutations

What is an action?

Handling forms

Getting form data

Final action

Redirect after creation

Handling loading state

Conclusion

React Router Data Mode: Part 5 - Refactor, useParams and NavLink

Refactor

How do we mark the active link?

What about NavLink?

React Router Data Mode: Part 4 - Routes with parameters, useRouteLoaderData and useParams

A quick recap

1. Create the page

2. Create the nested route

3. Review our links

Add the loader for the detail

But didn’t we already have that data in another loader?

Using useRouteLoaderData

But we need to know which contact to show

React Router Data Mode: Part 3 - Loaders and data fetching

What are loaders?

React Router Data Mode: Part 2 - Nested routes and outlets

Initial route structure

Create our pages

Nest routes within a layout

Display child routes with Outlet

SPA navigation with Link

Recap

What's next?

React Router Data Mode: Part 1 - Installation and first routes

What are we going to build?

Installation and first routes

Install React Router

Connect the router with React

What's next?

React Router v7: The Evolution React Needed

What Does React Router v7 Offer?

Declarative Mode

Data Mode

Framework Mode

So, Is It Worth It?

Post about Use and Misuse of AI in Localized Content and Dynamic Creative Work

1. Initialize a new project:

2. Install Webpack and React dependencies:

3. Create a webpack.config.js file to configure Webpack.

4. Create the project structure:

5. Add the following scripts to your package.json:

6. Run the app:

Learn how to Implement Public, Private, and Protected Routes in your React Application

React Public, Protected, and Private Routes: A Comprehensive Guide

Prerequisites

Brief Introduction to React, React Router, Authorization, and Authentication

Route Definition: Explaining the routes in detail

Protected Route

Private Route

Public Route

Real-World Implications of Route Types

Conclusion

A fallback `/testing` route