Karkas
An opinionated React reference application

A React stack where the tools agree with each other.

Karkas is a production-shaped example of React 19, Reatom, Panda CSS, Park UI, Storybook, Vitest, Playwright, MSW, and an adapted Feature-Sliced Design — wired together with enforceable conventions instead of a pile of disconnected defaults.

State, routes, server scenarios, accessible tests, localization, architecture checks, and deployment are all part of the same example.

Feature-Sliced layers erected on a Reatom spine over the MSW network boundaryMSW · network boundarysharedui kit · router · libentitiesdomain models · MSW handlerswidgetscomposed feature blockspagesroute-level screensappcomposition · providers · routesReatom · load-bearing state

Why it exists

More than a starter. Less than a framework.

Most templates show how to boot an app. Karkas shows how to keep one coherent as it grows — concrete choices about state, routing, styling, testing, localization, file boundaries, quality gates, and deployment, demonstrated across realistic screens and failure states.

01

See the decisions in context

The demo includes authenticated navigation, master–detail screens, forms, loading states, failures, retries, responsive behavior, and persisted preferences.

02

Read behavior as documentation

Storybook stories are reproducible user journeys, not screenshots. The same scenarios run as browser integration tests.

03

Let tooling protect the architecture

Formatting, linting, types, FSD boundaries, dead code, duplication, complexity, coverage, and translation tree-shaking are all checked automatically.


The choices

Deliberate choices, not interchangeable badges.

Each tool has a job, and the boundaries between them are explicit.

S-01

Reatom

state, routing, forms, async

Atoms, actions, computed values, forms, persistence, localization, and routes share one reactive model. Karkas deliberately avoids rebuilding that model out of scattered React hooks — React renders, Reatom decides.

S-02

Panda CSS + Park UI

typed styling, accessible primitives

Build-time, type-safe styling meets accessible Ark UI primitives. Tokens, recipes, and semantic light/dark themes are owned by the repository, not inherited from a framework default.

S-03

Storybook 10

the behavior catalog

Every meaningful state can be opened by a person and exercised by Vitest in Chromium. Stories model success, errors, retries, loading, direct URLs, mobile layouts, and request cancellation.

S-04

MSW 2

the network boundary

Demo and tests use the same request-level mocks. Server states — success, error, retry, 404, abort — are modelled at the boundary, so the published demo needs no backend to behave realistically.

S-05

Feature-Sliced Design, adapted

layer boundaries, with deliberate deviations

app, pages, widgets, entities, and shared are more than folders. Karkas follows Feature-Sliced Design rather than the letter of its spec — Steiger enforces the layer and import boundaries, with public-API and segment rules relaxed for generated, UI-kit, and test code.

S-06

Vite+ · mise · hk · Fallow

one layered toolchain

Vite+ runs the frontend tools. mise defines project workflows. hk gives fast changed-file checks and Git hooks. Fallow turns coverage and source analysis into maintainability signals.


Testing philosophy

Test what a user can perceive and do.

Karkas queries the interface by role, accessible name, heading, link, button, and visible text. It waits for lifecycle signals instead of sleeping. It proves that pending route requests are cancelled when navigation makes them irrelevant. When accessibility is unclear, the preferred fix is to improve the interface — not add a test ID.

Open integration stories →

From clone to confidence

A short local loop and a strict full gate.

  1. Installnub install

    Generates Panda output, compiles messages, verifies the MSW worker, installs hooks.

  2. Runnub run dev

    Starts the application through the repository's mise workflow.

  3. Checkhk check

    Validates changed files; hk fix applies safe formatting and lint fixes.

  4. Provemise run validate

    Coverage, types, architecture checks, Fallow analysis, production builds, and tree-shaking.


Explore the project

Three ways to inspect the same architecture.

Demo

A product-shaped SPA with mocked APIs, responsive navigation, persisted preferences, localization, and real loading and error states.

Open the demo →
Storybook

Jump straight to a screen, state, viewport, or user journey — and read the assertions that define its behavior.

Explore Storybook →
Source

Follow the FSD layers, entity-local mocks, Reatom models, theme recipes, and the source-first technical notes in docs.

View on GitHub →

Updates

What is changing, and why.

Karkas tracks a fast-moving frontend toolchain. Updates focus on decisions: what changed, what problem it solves, what tradeoff it introduces, and where to inspect it.

All updates

No updates published yet — formal release notes live inGitHub Releases.


Who it is for

See the architecture behaving, not just described.

Karkas is for teams and developers who want to study a coherent modern React setup, copy selected patterns, or start from strong defaults. The value is not that every choice is universal — it is that every choice is explicit, demonstrated, and checked.

  • Teams

    Study a coherent, modern React setup end to end — state, styling, tests, and boundaries.

  • Adopters

    Copy selected patterns — Reatom models, theme recipes, entity-local mocks — into an existing codebase.

  • New projects

    Start from strong, explicit defaults instead of a pile of disconnected framework choices.