Suggest an edit

Improve this article

Refine the answer for “Can you use Feature-Sliced Design in Next.js?”. Your changes go to moderation before they’re published.

Approval required

Content

What you’re changing

Title (EN)

Short answer (EN)

Shown above the full answer for quick recall.

Answer (EN)

Yes, **Feature-Sliced Design (FSD)** works great in **Next.js** - you just need to understand the boundary:

- `app/` (or `pages/`) is the **routing and page composition layer**
- the FSD layers (`shared / entities / features / widgets / pages`) are **your domain/feature architecture**

### The main rule

**Don't turn FSD folders into routes.**
That is, keep `features/`, `entities/`, `shared/` and so on **outside** `app/`, so Next doesn't start treating them as route segments.

---

## Recommended structure (App Router + FSD)

```txt
src/
  app/                      # routing, layout, page, route handlers only
    (public)/
      page.tsx
    (auth)/
      login/page.tsx
    tasks/
      [id]/
        page.tsx
        layout.tsx
  pages/                    # (optional) if you use the Pages Router
  shared/
    ui/
    lib/
    config/
    api/
  entities/
    task/
      model/
      ui/
      api/
  features/
    solve-task/
      ui/
      model/
      lib/
  widgets/
    task-workspace/
      ui/
  # the pages layer from FSD is often NOT needed in Next, because "pages" = app routes
```

---

## How to "glue" FSD and Next routes together

In `app/.../page.tsx` you usually:

- fetch data (server actions / fetch / ORM)
- wire up **widgets/features/entities** and assemble the page

Example:

```tsx
// src/app/tasks/[id]/page.tsx
import { TaskWorkspace } from "@/widgets/task-workspace/ui/TaskWorkspace";

export default async function Page({ params }: { params: { id: string } }) {
  return <TaskWorkspace taskId={params.id} />;
}
```

---

## An important nuance: server/client components in FSD

In the Next App Router a component is a **Server Component** by default.

- UI that uses `useState`, `useEffect`, `zustand`, the DOM, an editor - make it `use client`
- Models/utilities in `shared/lib`, `entities/*/model` - can often stay server-side/universal

Typical pattern:

- `widgets/.../ui/*.tsx` - can be `use client`
- `entities/.../api` - server functions / repositories
- `features/.../model` - state/stores (usually client)

---

## Where to keep "api" in FSD with Next

There are 2 reasonable options:

### Option A (recommended): server logic next to the domain

```txt
entities/task/api/task.repo.ts   # Prisma/SQL
```

And in `app/api/.../route.ts` - only a thin controller that calls the repo.

### Option B: all HTTP in app/api

```txt
app/api/tasks/[id]/route.ts
```

And in FSD - a client for requests:

```txt
shared/api/http.ts
entities/task/api/getTask.ts
```

---

## Common errors

1. Putting `features/` inside `app/`
   You get "junk" segments, collision problems, confusion.
2. Making "FSD pages" and "Next pages" at the same time for no reason
   In Next, the FSD `pages` layer is usually **not needed**, because `app/` plays the role of pages.
3. Mixing server-repo and client code in the same file
   Next will start complaining about imports and bundling.

Markdown · drag & drop images · ⌘B / ⌘I shortcuts406 words

For the reviewer

Note to the moderator (optional)

Visible only to the moderator. Helps review go faster.