Feature
How to organise storefront code by feature in the SHOPin storefront accelerator: folders under apps/presentation/features/, what goes inside each, and how imports stay bounded.
Feature directory structure
The presentation app uses a feature-based layout: one directory per feature area under features/. That keeps UI, hooks, and feature-specific logic in one place.
Layout
Typical contents of a feature directory:
- Components — Pages, sections, and UI used only in that feature.
- Hooks — Data fetching, state, or behaviour scoped to the feature.
- Lib — Helpers or logic used only inside the feature.
Shared UI, hooks, and types belong in shared packages (for example core/contracts, components/ui, Storybook)—not inside a feature folder unless it is truly feature-private.
Rule: From outside a feature, import only from that feature’s public root (e.g. the page or top-level barrel), not from nested components/, hooks/, or lib/. ESLint in the repo enforces this.
Naming folders under features/
Use one top-level folder per domain (one area of the storefront: cart, product, checkout, and so on). The accelerator does not define a required list of names—pick names that match your product and keep each folder cohesive.
Adding or extending a feature
- New feature — Add
apps/presentation/features/<feature-name>/. Put feature-only code there; export entry points (pages or top-level components) for routing and parents. - Existing feature — Extend inside that folder. Use the BFF client and contracts for data and types.
Follow General workflow rules (types, tests, lint, format) and validate in the browser, Storybook, and BFF when behaviour changes.
Workflow reminders
- Data — Communication between presentation and BFF
- Shared types — Maintain contracts
Related
- Component — Where shared vs feature UI lives, Storybook, tokens
- Icons
- Translations
- Config & constants
- BFF
- Data sources
Reusable logic that is not tied to one feature may belong in core/ or another workspace; see Other workspaces.