Feature-Sliced Design

Straturi, slice-uri, segmente, regula importurilor și FSD cu Next.

Actualizat 8 octombrie 2026

Ce este Feature-Sliced Design

Feature-Sliced Design (FSD) e o metodologie de arhitectură pentru frontend, cu reguli stricte despre unde pui codul și cine ce poate importa. Codul e împărțit după cât de specific e pentru business — de la pagini (foarte specifice) până la utilitare (generice).

Feature-Sliced Design în 1 minut

FSD organizează codul pe 3 niveluri: straturi (layers) → felii (slices) → segmente (segments).

src/
- app/configurare globală: providers, stiluri, init
- views/pagini (în FSD „pages”; redenumit ca să nu se bată cu Next)
- widgets/blocuri mari de UI compuse: header, sidebar, playground
- features/acțiuni ale userului cu valoare de business: run-exercise, add-to-cart
- entities/concepte de business: user, lesson, product, progress
- shared/cod generic, fără business: ui kit, lib, api client, config

Regula de aur

Un strat poate importa doar din straturile de sub el.

views→widgets→features→entities→shared

features/run-exercise poate folosi entities/exercise ✓
entities/exercise NU poate folosi features/... ✗
Două slice-uri din același strat nu se importă între ele (features/a ✗→ features/b). Le combini un nivel mai sus (widget/view).

Slice-uri și segmente

Slice = un concept (entities/lesson). În el, segmente după rol tehnic:

Segment	Conține
`ui/`	componente
`model/`	tipuri, state, store, hook-uri de logică
`api/`	request-uri, query-uri, server actions
`lib/`	helpers specifici slice-ului
`config/`	constante

Cum îl folosim în proiectul ăsta

app/[locale]/[topic]/[lesson]/page.tsxdoar compune view-ul
src/
- views/lesson/ui/lesson-view.tsx
- widgets/playground/ui/playground.tsx
- features/run-exercise/lib/run-js.ts
- entities/lesson/
  - api/lesson-api.ts
  - ui/lesson-content.tsx

Convenția noastră: fără index.ts care re-exportă — importăm direct din fișier, cu nume descriptive kebab-case. FSD oficial recomandă un index.ts ca public API al fiecărui slice; noi renunțăm la el pentru căutare mai ușoară, dev server mai rapid și zero dependențe circulare accidentale. Costul: disciplina „nu importa detalii interne” e pe tine, nu pe structură.

FSD + Next App Router

Folderul app/ de la rădăcină e routing-ul Next — fișiere subțiri care importă din views.
Stratul pages din FSD → îl numim views (evităm confuzia cu Pages Router).
Stratul FSD app (providers, global CSS) poate trăi în app/layout.tsx sau în src/app.

Plusuri / minusuri

Plusuri	Minusuri
reguli clare: știi unde pui orice	curbă de învățare, „e entity sau feature?”
fără importuri circulare	prea mult pentru proiecte mici
scalează la echipe mari	mulți pași de navigare între foldere
ștergi un feature = ștergi un folder	necesită lint (Steiger) ca să rămână curat

Pe scurt

6 straturi, de la specific la generic: app → views → widgets → features → entities → shared.
Importuri doar în jos; slice-urile din același strat nu se importă între ele.
La noi: fără barrel-uri, fișiere kebab-case descriptive, app/ de la rădăcină doar pentru routing.

Surse oficiale

Exerciții

#1Regula importurilor

Scrie canImport(from, to) pentru căi ca 'features/run-exercise' sau 'shared'. Ordinea: app > views > widgets > features > entities > shared. Permis doar spre un strat inferior, sau în același slice. Între slice-uri diferite din același strat → interzis. shared și app n-au slice-uri.

⌘ Enter rulează

○features → entities ✓
○entities → features ✗
○features/a → features/b ✗, același slice ✓

#2În ce strat?

Scrie layerOf(description) pe baza cuvintelor cheie: 'page' → 'views', 'block' → 'widgets', 'action' → 'features', 'concept' → 'entities', altfel 'shared'.