Your state shouldn't live in componentsIt belongs to aclass of its own
With MVC, .use() your State instead - data, behavior, lifecycle, and updates in one place. Components read what they need; class itself does the rest.
class Counter extends State { count = 0; increment() { this.count++; }}function App() { const { count, increment } = Counter.use(); return ( <button onClick={increment}> Clicked {count} times </button> );}Drops into React you already have - not a framework, no rewrite.
React has
...gotten complicated.
Every feature has a hook. They need to persist, derive, remember, and refresh. Each concern is another hook, another dependency array, another thing to drift. Logic that belongs together winds up scattered and hard to follow.
The same logic. Half the noise.
Say you want a reusable, component-owned useFooBarBaz that re-renders on change. Same surface everywhere - only the cost to build it differs. Higher readability (and fewer tokens).
import React from 'react';import State from '@expressive/react';class FooBarBaz extends State { foo = 0; bar = 'hello'; baz = true; bump() { this.foo++; }}function Widget() { const { foo, bar, baz, bump } = FooBarBaz.use(); return ( <button onClick={bump}> {foo} · {bar} · {String(baz)} </button> );}import React, { useState, useCallback } from 'react';function useFooBarBaz() { const [foo, setFoo] = useState(0); const [bar, setBar] = useState('hello'); const [baz, setBaz] = useState(true); const bump = useCallback(() => setFoo(f => f + 1), []); return { foo, bar, baz, bump, setFoo, setBar, setBaz };}function Widget() { const { foo, bar, baz, bump } = useFooBarBaz(); return ( <button onClick={bump}> {foo} · {bar} · {String(baz)} </button> );}With MVC, destructuring is your dependency list. Just read a field to subscribe to it. Nothing to declare like setters, useCallback, or factory.
Rails for your React app.
Strong conventions replace a pile of opinions - a good feature looks the same whether it came from you, your team, or an agent.
(Artificial) Idiot-Proof.
The same structure keeps the models working in your codebase on task - individual features and pages modularize for an agent to skim and load as-needed.
Dense business logic
State, derived value, async methods, and lifecycle live together. Composition helps separate concerns into readable chunks.
Fewer imports, less surface area.
Reach for the class before another hook, provider, or client library. Removes bloat for people and your agents to know about.
Less to trace when things break
No dependency arrays, stale closures, or complicated interactions. A fix starts at the class, not a hunt through wiring.
Class instances are just objects
The instance is the source of truth. Log it, assert on it, or bind it to window to inspect directly.
Classes are their own context.
Wrap a subtree in <Provider for={X}> - components inside need only X.get() to interact with the nearest instance. Fully typed, zero boilerplate.
import React from 'react';import State, { Provider } from '@expressive/react';class Theme extends State { mode = 'light'; toggle() { this.mode = this.mode === 'light' ? 'dark' : 'light'; }}const Toggle = () => { const { mode, toggle } = Theme.get(); return <button onClick={toggle}>{mode}</button>;}const App = () => ( <Provider for={Theme}> <Toggle /> </Provider>);No createContext<T>, null default, missing-provider guard to write and maintain. Every app needs this eventually. Jotai's Provider will wrap a whole atom store, MobX leaves it to you.
Component is renderable State.
Reach for Component when making self-contained (or extensible) display logic. Fields drive lazy getters and render() directly - destructure this as you would use hook.
A Component is also its own Provider. Children can pull from it with zero prop drilling.
import React from 'react';import { Component } from '@expressive/react';class TipCalculator extends Component { bill = 50; tipPercent = 18; get tip() { return (this.bill * this.tipPercent) / 100; } get total() { return this.bill + this.tip; } render() { const { bill, tipPercent, tip, total } = this; return ( <div> <input type="number" value={bill} onFocus={(e) => e.currentTarget.select()} onChange={(e) => (this.bill = +e.target.value)} /> <input type="range" min={0} max={30} value={tipPercent} onChange={(e) => (this.tipPercent = +e.target.value)} /> <p> Tip {tip.toFixed(2)} · Total {total.toFixed(2)} </p> </div> ); }}The rest comes along for free.
Data, behavior, and lifecycle in one place - much of what you'd install a library for is just how the class works.
Coexists with hooks
No big-bang rewrite. Adopt it one feature at a time and leave simple useState calls alone. A tool for complexity, not a replacement.
Async is built in
Async factories integrate with Suspense - required data suspends until it resolves. No query library, no middleware, no thunks.
Headless by design
State classes are plain objects - create with .new(), call methods, assert on properties. Whole app unit-testable with just expect. No @testing-library, no act(), no DOM.
Self-documenting
Fields, types, and JSDoc live on the class, so editors surface intent inline. Reusable state your team - and its tools - can reason about without digging.
Move just one feature out of hooks.
Start with one, leave the rest. See how it feels.
The agent skill gives your coding agent the full API and best practices.