DEV Community: 张一凡

EzLang - a systems language aiming to make native software easier to write

张一凡 — Mon, 22 Jun 2026 07:06:31 +0000

EzLang is an experimental systems programming language built around a simple idea: native software should be fast and reliable, but it should not require every small program to carry a heavy mental model.

The project is still early. It is a compiler and language-design experiment, not a production language. I am sharing it because I want feedback from people who care about compilers, memory models, cross-platform tooling, and whether this direction is worth pushing further.

What EzLang is trying to be

EzLang aims to sit in the space between scripting-language ergonomics and systems-language output.

The goals are:

Fewer memory pitfalls without giving up speed.
One codebase that can target native platforms, mobile platforms, and WebAssembly.
Code that reads close to intent, with expression-first syntax and named calls.
A language simple enough that AI-generated code is still easy for humans to review and maintain.
A practical systems language with the compiler, formatter, LSP, VS Code extension, package/project workflow, and docs developed together.

This is not meant to replace C, Rust, Zig, Go, or Swift. It is an attempt to test a different set of tradeoffs: can a small language make systems programming feel lighter while still compiling down to efficient native output?

A small example

from "std/fmt" import { format, toString };
from "std/io" import { println };

struct Data {
    val: I32;
};

const create = (seed: I32): Data => {
    const d = Data(val = seed + 32);
    return d;
};

const main = (): I32 => {
    const created = create(seed = 10);
    const copied = created;
    const args: Str[] = [toString<I32>(value = copied.val)];

    println(msg = format(template = "copied value={}", args = args));
    return copied.val == 42 ? 0 : 1;
};

The syntax is expression-oriented, calls use names where clarity helps, and values are copied by default. The language leans toward explicit, readable code rather than dense cleverness.

The memory model direction

The current design combines value semantics with an Arena-style memory model. Temporary aggregate values can be reclaimed with scope-like lifetimes, while weak references are explicit in the type system.

The ambition is simple: make common memory mistakes harder to write, without asking developers to think about ownership annotations in every line of code.

This part needs the most scrutiny. Escape analysis, diagnostics, and negative tests need to become much stronger before the design can claim real safety.

Cross-platform goal

EzLang is being designed with multiple targets in mind:

native executables
mobile platforms
WebAssembly / emcc-style targets

The standard library is intended to expose consistent interfaces across these targets where that makes sense. The current repository already includes the project CLI, formatter, LSP, VS Code extension, and standard-library direction, but the cross-platform story is still incomplete.

AI and maintainability

One motivation for EzLang is the world we are already entering: more code will be drafted by AI.

That makes the human side more important, not less. A language that is friendly to AI but hostile to human review is not a good outcome. EzLang tries to keep syntax and semantics explicit enough that a human can quickly inspect generated code, understand what it is doing, and safely change it.

This has affected small choices: named arguments, expression-first composition, less hidden magic, and a preference for code that reads like a direct description of intent.

Current implementation

The compiler is currently written in Python and uses ANTLR plus llvmlite:

.ez source -> ANTLR parser -> semantic analysis -> LLVM IR -> object/executable

What exists today:

Parser and semantic-analysis pipeline.
LLVM IR generation for demo programs.
ez init, ez build, ez run, ez test, and ez fmt.
Structs, generics, optional types, union types, function types, named calls, and type aliases.
extern "..." for target plus declare for ABI bindings.
Early flow {}, parallel {}, and race(pl) concurrency hooks.
Formatter, LSP, VS Code extension, bilingual docs, and examples.

What is rough:

The language spec is not stable.
Memory-safety guarantees are not proven.
Error messages need work.
The runtime is tiny.
Cross-platform behavior is incomplete.
The standard library is still more of a map than a mature library.

What I would like feedback on

Is the value-semantics plus Arena direction worth pursuing?
Does this mental model feel meaningfully simpler, or just different?
Are named calls a good readability tradeoff in a systems language?
What tests would make the memory model more credible?
Which small real-world program should EzLang try to compile first?

I am not looking for hype. I am looking for sharp feedback, broken assumptions, small test cases, and criticism from people who have built or used serious language tooling.

EzLang - a small systems language I built in a month with AI

张一凡 — Thu, 18 Jun 2026 05:13:18 +0000

Repo: https://github.com/ZYF93/EzLang

I spent the last month building a small programming language called EzLang.

It is an expression-oriented systems language with default value semantics, an Arena-style memory model, LLVM IR generation, a small Flow concurrency experiment, a CLI, formatter, LSP, VS Code extension, and bilingual docs.

This is not production-ready. It is a demo compiler and language-design experiment. I am posting it here because I would like sharper feedback from people who care about compilers, runtimes, type systems, and language tooling.

Why I built it

I wanted to explore a specific combination of ideas:

Systems-level output without making ownership syntax dominate every small program.
Value semantics by default.
Compiler-managed Arena allocation for temporary aggregates.
Named arguments and expression-first syntax for readability.
A small concurrency model that can lower to native runtimes and emcc/Wasm-like targets.
Tooling from day one, not after the language is "done".

None of these ideas are new. The interesting part, at least to me, is whether they can fit together in a small language that still feels practical.

What it looks like

from "std/fmt" import { format, toString };
from "std/io" import { println };

struct Data {
    val: I32;
};

const create = (seed: I32): Data => {
    const d = Data(val = seed + 32);
    return d;
};

const main = (): I32 => {
    const created = create(seed = 10);
    const copied = created;
    const args: Str[] = [toString<I32>(value = copied.val)];

    println(msg = format(template = "arena: copied value={}", args = args));
    return copied.val == 42 ? 0 : 1;
};

The implementation is conventional:

.ez source -> ANTLR parser -> semantic analysis -> LLVM IR -> object/executable

The compiler is currently written in Python and uses llvmlite for LLVM IR generation.

What works today

Parser and semantic-analysis pipeline.
LLVM IR generation for demo programs.
Native examples.
ez init, ez build, ez run, ez test, ez fmt.
Structs, generics, optional types, union types, function types, named calls, type aliases.
extern "..." for target plus declare for platform ABI bindings.
Early flow {}, parallel {}, and race(pl) runtime hooks.
Formatter, LSP, VS Code extension, and docs.

What does not work well yet

The language spec is not stable.
The Arena model needs much stronger escape analysis and negative tests.
Error messages are rough.
The runtime is intentionally tiny.
Cross-platform behavior is incomplete.
The standard library is more of a design map than a mature library.

I used AI heavily while building this. It was useful for boilerplate, tests, docs, and first-pass implementations, but it also made it very easy to generate plausible compiler code that was subtly wrong. The main lesson was that AI speeds up typing, not language design.

What I want feedback on

Is the Arena/value-semantics direction worth pursuing?
Is flow {} a useful abstraction, or just another async-shaped trap?
Are named arguments everywhere a good tradeoff for a systems language?
Should this stay Python-based while iterating, or move toward a lower-level/self-hosted compiler later?
What small benchmark or test suite would make the project more credible?

Stars are useful because they help me find people interested in pushing the project past demo status. More useful than stars: issues, design criticism, compiler tests, runtime feedback, and small programs that break the current assumptions.

Zustand Is Great. But AI-Heavy React Apps Expose Its Limits Faster Than People Expect.

张一凡 — Tue, 31 Mar 2026 04:37:36 +0000

Zustand is probably the most natural default for many modern React apps now.

That makes sense.

It is small, ergonomic, easy to teach, and dramatically less annoying than the old Redux-first mindset.

But after building more AI-heavy frontends, I have a growing suspicion:

Zustand is excellent for getting started, but AI product UIs expose its scaling limits earlier than most teams expect.

This is exactly why I started reaching for easy-model more often.

The Context: Modern React Usually Starts With Zustand

For a lot of teams, the default conversation is no longer:

"Redux or not?"

It is:

"Do we even need more than Zustand?"

For CRUD pages, dashboards, and lightweight shared UI state, that is often the right answer.

But AI frontends are not normal dashboards.

They tend to combine:

conversation history
streaming output
tool execution state
retries and failure branches
logs and traces
cross-panel synchronization
session scoping
derived execution context

That is not just "more state." It is state with behavior, process, and lifecycle.

The Hidden Cost of a Very Easy Store

Zustand feels great because almost anything can start simple:

const useChatStore = create(set => ({
  messages: [],
  streamingText: '',
  isStreaming: false,
  addMessage: message =>
    set(state => ({ messages: [...state.messages, message] })),
  setStreamingText: text => set({ streamingText: text }),
}));

This is exactly why people love it.

But the same flexibility can become a trap in AI-heavy apps.

As requirements grow, the store often becomes the path of least resistance for everything:

state
business actions
async requests
retries
logs
context management
side-effect coordination

Then it quietly turns into this:

const useChatStore = create((set, get) => ({
  messages: [],
  streamingText: '',
  isStreaming: false,
  toolCalls: [],
  logs: [],
  retries: 0,
  contextWindow: [],
  memory: [],
  activeSessionId: '',

  addMessage: () => {},
  appendStreaming: () => {},
  startToolCall: async () => {},
  completeToolCall: () => {},
  retry: async () => {},
  rebuildContext: () => {},
  fetchHistory: async () => {},
  hydrateSession: async () => {},
}));

Still workable. Still shippable.

But no longer especially clear.

AI Coding Assistants Make This Worse

This is the part people do not talk about enough.

When AI coding tools work inside a growing Zustand codebase, they tend to do one of two things:

keep adding more logic to the existing store
start leaking new logic into helper hooks and utility files

Both are understandable.

Neither is ideal.

That is because Zustand optimizes for low-friction authoring, not necessarily for high-clarity continuation by an AI assistant over many iterations.

And that difference matters now.

Why easy-model Feels Better Here

easy-model pushes state into explicit model classes:

fields represent state
methods represent business actions
model instances can be shared naturally in React

For AI-heavy frontends, that is a big deal.

A session becomes a model, not an ever-expanding store:

class AgentSessionModel {
  messages: Message[] = [];
  streamingText = '';
  status: 'idle' | 'running' | 'streaming' = 'idle';
  toolCalls: ToolCall[] = [];
  logs: string[] = [];

  @loader.load(true)
  async run(input: string) {
    this.status = 'running';
    this.messages.push({ role: 'user', content: input });

    const stream = await agent.run(this.messages);

    this.status = 'streaming';
    for await (const chunk of stream) {
      this.streamingText += chunk;
    }

    this.messages.push({
      role: 'assistant',
      content: this.streamingText,
    });

    this.streamingText = '';
    this.status = 'idle';
  }
}

That model has a visible boundary.

It tells both humans and AI tools:

what this unit owns
where new behavior belongs
what state the UI depends on

That clarity becomes extremely valuable once the feature starts changing every week.

This Is Not "Zustand Bad, easy-model Good"

I do not think that is a serious argument.

My actual take is more practical:

Zustand is fantastic for low-friction shared state
easy-model is stronger when the frontend starts looking like an application runtime

That happens surprisingly often in AI products.

Especially when you also want:

shared instances by session or workspace
richer async coordination
watchable state transitions
clearer business boundaries
code that AI assistants can continue without drifting

The Real Comparison in 2026

The old comparison was:

Redux vs everything

The more relevant comparison now is often:

Zustand for speed
easy-model for structure under complexity

Redux still exists as the historical baseline, but for many modern React teams, Zustand is the real competitor.

And I think easy-model earns its place in that conversation.

Final Thought

If your app is mostly lightweight UI state, Zustand is still hard to beat.

If your app is an AI workspace, agent console, or chat product that keeps accumulating process-heavy behavior, I would not default to Zustand without thinking harder about long-term shape.

That is where easy-model has been surprisingly compelling for me.

GitHub: https://github.com/ZYF93/easy-model

npm: pnpm add @e7w/easy-model

If you are also building AI-heavy React apps, give the repo a star. I think tools optimized for human + AI collaboration are going to become much more important.

I Stopped Judging React State Libraries by DX Alone. AI Compatibility Matters Now.

张一凡 — Mon, 30 Mar 2026 02:50:26 +0000

For years, my checklist for choosing a React state library was pretty standard:

developer experience
TypeScript support
performance
ecosystem

Now I use one more filter:

How well can an AI coding assistant understand, continue, and refactor the pattern?

That shift changed what I value, and it is one reason I keep coming back to easy-model instead of defaulting to Redux or even today's more common lightweight choice, Zustand.

The AI Workflow Changed the Rules

The old assumption was simple: humans write the architecture, then humans maintain it.

That is no longer true for a lot of teams.

A more realistic workflow today looks like this:

a human defines intent
AI scaffolds a feature
a human fixes the edge cases
AI expands the next iteration

In that loop, architecture becomes communication.

Not just communication between teammates, but communication between humans and models.

If the codebase hides intent behind too many disconnected layers, the AI starts guessing. And when AI starts guessing inside your state layer, things get weird fast.

Redux tends to push that guessing into multiple layers.
Zustand tends to hide it behind a deceptively simple store that keeps absorbing more responsibility over time.

What "AI Compatibility" Actually Means

I do not mean "the model can produce a demo with it."

Almost every popular library can get a decent hello-world out of an assistant.

Redux can do it.
Zustand can definitely do it.

I mean:

can the AI find the right place for new logic?
can it extend existing patterns instead of inventing a new one?
can it update a feature without scattering logic across files?
can it read the business model from the code itself?

That is where I think easy-model is unusually strong.

Why easy-model Is Easier for Models to Continue

easy-model organizes state around model classes:

fields hold state
methods hold business behavior
components consume instances via useModel or useInstance

That creates a very direct map between business intent and code structure.

Here is the kind of code AI tools seem to handle well:

class SearchWorkspaceModel {
  query = '';
  results: SearchResult[] = [];
  filters: string[] = [];
  selectedId: string | null = null;

  setQuery(query: string) {
    this.query = query;
  }

  toggleFilter(filter: string) {
    this.filters = this.filters.includes(filter)
      ? this.filters.filter(item => item !== filter)
      : [...this.filters, filter];
  }

  select(id: string | null) {
    this.selectedId = id;
  }

  @loader.load()
  async search() {
    this.results = await api.search({
      query: this.query,
      filters: this.filters,
    });
  }
}

The business domain is obvious.
The actions are obvious.
The UI dependencies are obvious.

That alone makes AI-generated follow-up changes much more stable.

This Becomes Even More Valuable in AI Products

If you are building:

chat UIs
agent dashboards
retrieval interfaces
multi-panel copilots
tool-execution consoles

you are dealing with unusually rich frontend state.

Not just "is the modal open," but:

what is currently streaming
which tool is running
what the session history is
which panel shares the same session
how retries and logs behave

Those apps benefit from having state and behavior live in the same place.

For example:

class ChatWorkspaceModel {
  messages: Message[] = [];
  draft = '';
  streamingText = '';
  toolCalls: ToolCall[] = [];
  error: string | null = null;

  setDraft(draft: string) {
    this.draft = draft;
  }

  @loader.load(true)
  async send() {
    const content = this.draft.trim();
    if (!content) return;

    this.messages.push({ role: 'user', content });
    this.draft = '';
    this.error = null;

    try {
      const stream = await llm.stream(this.messages);
      for await (const chunk of stream) {
        this.streamingText += chunk;
      }

      this.messages.push({
        role: 'assistant',
        content: this.streamingText,
      });
      this.streamingText = '';
    } catch (error) {
      this.error = 'Send failed';
    }
  }
}

When an assistant sees this, it has far less ambiguity about where the next feature belongs.

The Supporting Pieces Matter Too

What makes easy-model practical is not just the model class pattern, but the utilities around it:

instance sharing by arguments is useful for session-based UIs
watchers help with logging, analytics, and side effects
loading utilities reduce repetitive async state wiring
IoC features make service boundaries cleaner in larger apps

That combination makes it a good fit for apps where business logic is not trivial and AI is expected to contribute repeatedly.

That is the gap I increasingly feel between easy-model and Zustand:

Zustand wins on minimal entry cost
easy-model wins once business behavior, shared instances, async flow, and AI-assisted extension all start compounding

Redux still has its place, but in day-to-day modern React discourse, Zustand is usually the more relevant comparison, and I think easy-model holds up well there.

My New Mental Model

I still care about ergonomics and performance.

But I now treat AI compatibility as a first-class architectural concern.

A state pattern is stronger if:

a human can read it quickly
an AI can continue it predictably
both can locate business intent without hunting through five layers

That is the real reason easy-model stands out to me.

It does not just reduce boilerplate. It reduces ambiguity.

And ambiguity is exactly where AI-assisted codebases start to decay.

Closing

If you are evaluating React state management in an AI-assisted workflow, I would seriously add this question to your shortlist:

Will this pattern still feel coherent after ten rounds of human + AI iteration?

For me, easy-model is one of the few tools that earns a solid "yes" there.

GitHub: https://github.com/ZYF93/easy-model

npm: pnpm add @e7w/easy-model

If you are also thinking about AI compatibility as a real frontend architecture concern, a star on the repo would mean a lot.

Why Class-Based State Feels Surprisingly Good for AI-Generated React Apps

张一凡 — Sun, 29 Mar 2026 03:25:30 +0000

AI coding tools are getting very good at generating React code.

What they are still bad at is maintaining coherence once your app gets real.

That gap matters a lot in 2026, because many of us no longer build apps in one pass. We build them in loops:

We sketch the direction.
Cursor / Copilot / Claude Code fills in 60-80%.
We refine the edges.
The AI takes another pass.

If your state architecture is hard for the model to read, every loop adds more glue code, more accidental complexity, and more places to get lost.

That is exactly why I started liking easy-model for React projects, especially AI-heavy frontends where Redux and Zustand each hit different limits.

The Real Problem Isn't "Can AI Write React?"

It can.

The real question is:

Can AI keep extending the same codebase without making it worse?

A lot of React state patterns are technically correct but semantically scattered:

state in one file
actions in another
selectors somewhere else
async logic hidden in hooks
cross-component sharing handled by a separate abstraction

That usually shows up in two familiar forms:

Redux: explicit, powerful, but easy for AI to overproduce boilerplate around.
Zustand: fast and elegant at first, but easy for AI to keep stretching into an oversized store plus ad hoc hooks.

Humans can learn that structure over time.

Models struggle more, especially when they need to continue an existing pattern instead of generating a toy example from scratch.

Why easy-model Clicks

easy-model is built around a very simple idea:

a class represents a business model
fields represent state
methods represent business actions
React integrates through useModel / useInstance

That means a lot of app logic becomes compact and obvious:

class UserListModel {
  users: User[] = [];
  keyword = '';
  page = 1;
  pageSize = 20;
  total = 0;

  setKeyword(keyword: string) {
    this.keyword = keyword;
  }

  setPage(page: number) {
    this.page = page;
  }

  @loader.load()
  async fetchList() {
    const res = await api.getUsers({
      keyword: this.keyword,
      page: this.page,
      pageSize: this.pageSize,
    });

    this.users = res.list;
    this.total = res.total;
  }
}

This structure is not clever.

That is precisely the point.

It is easy for a human to scan, and easy for an AI model to continue.

Why This Matters for AI-Assisted Development

When I ask an AI tool to extend a codebase, I want it to infer:

where the logic belongs
how state is organized
how async actions are handled
how a component should consume that state

Class-based models make those decisions easier because the business boundary is already visible.

UserListModel tells the model what domain it is working in.

fetchList, setKeyword, and setPage tell the model what actions already exist.

The fields tell it exactly what the UI depends on.

That dramatically reduces the chance of the assistant inventing a second pattern halfway through the feature.

It Works Especially Well for AI Product Frontends

AI frontends are usually more stateful than they look.

A "simple" chat page often includes:

message history
streaming output
tool execution state
retry and error handling
multi-panel synchronization
logs or observability
per-session instance sharing

That is a lot of moving pieces for scattered state primitives.

With easy-model, an AI-oriented frontend can stay readable:

class AgentSessionModel {
  messages: Message[] = [];
  streamingText = '';
  status: 'idle' | 'running' | 'streaming' = 'idle';
  toolCalls: ToolCall[] = [];

  @loader.load(true)
  async run(input: string) {
    this.status = 'running';
    this.messages.push({ role: 'user', content: input });

    const stream = await agent.run(this.messages);

    this.status = 'streaming';
    for await (const chunk of stream) {
      this.streamingText += chunk;
    }

    this.messages.push({
      role: 'assistant',
      content: this.streamingText,
    });

    this.streamingText = '';
    this.status = 'idle';
  }
}

Again: not magic, just clarity.

And that clarity matters because the current alternative for many teams is not "easy-model vs Redux" alone. It is often "easy-model vs Zustand for modern React apps, with Redux still as the legacy baseline."

The Features That Make It Practical

easy-model is not only about classes. The supporting APIs are what make it useful in real apps:

useModel lets React components create or reuse model instances naturally.
provide allows instance sharing by arguments, which is perfect for session-based UIs.
watch / useWatcher make side effects and state observation much easier to centralize.
loader / useLoader provide a consistent loading story for async methods.
IoC helpers make service injection more explicit when your app starts growing.

One subtle but important detail: state and behavior are class-based, but advanced features are opt-in. You do not need a full decorator-heavy mental model just to update state.

The New Evaluation Criteria for State Management

We used to compare React state tools by asking:

Is it fast?
Is it ergonomic?
Is it type-safe?
Is the ecosystem mature?

I think we now need one more question:

Can AI understand and extend it without drifting?

That may sound like hype, but it is already a practical concern for teams using AI day to day.

If a state pattern is hard for models to follow, your future "AI speed" will be lower than you expect, no matter how nice the abstraction looked at first.

Final Thought

I do not think easy-model replaces every state library.

But I do think it hits a very interesting sweet spot:

simple enough for humans
structured enough for AI
expressive enough for real business logic
especially strong for AI product frontends

Redux still makes sense in some organizations. Zustand still makes sense for many lightweight apps. But if your app is AI-heavy and your workflow is AI-assisted, easy-model feels unusually well-positioned.

If you're building React apps with heavy AI assistance, or building AI products themselves, it is worth a serious look.

GitHub: https://github.com/ZYF93/easy-model

npm: pnpm add @e7w/easy-model

If this resonates, give the repo a star. Tools that make AI-generated code easier to extend are going to matter a lot more than people think.

Why I Chose easy-model for My AI Chatbot (Not Redux)

张一凡 — Sat, 28 Mar 2026 03:33:26 +0000

Building an AI chatbot frontend? Here's why Redux was never an option.

The Problem

AI chatbot frontends have complex state:

// What you're actually dealing with
interface ChatState {
  // Message history
  messages: Message[];

  // Streaming response
  streamingText: string;
  isStreaming: boolean;

  // Tool execution
  toolCalls: ToolCall[];
  activeTool: Tool | null;
  toolResults: Map<string, any>;

  // Context management
  contextWindow: Message[];
  memory: MemoryItem[];

  // User intent tracking
  currentIntent: Intent | null;
  intentHistory: Intent[];

  // Execution flow
  currentStep: number;
  stepResults: Map<number, any>;

  // Error handling
  errors: Error[];
  retryCount: number;
}

This isn't a simple counter. Redux was built for a different era.

Why Not Redux?

1. Boilerplate Overload

// Actions (30+ lines)
const ADD_MESSAGE = "chat/ADD_MESSAGE";
const SET_STREAMING = "chat/SET_STREAMING";
const START_TOOL = "chat/START_TOOL";
// ... 20 more

// Reducer (100+ lines)
const chatReducer = (state, action) => {
  switch (action.type) {
    case ADD_MESSAGE:
      return { ...state, messages: [...state.messages, action.payload] };
    // ... 20 more cases
  }
};

// Selectors (20+ lines)
export const selectMessages = (state) => state.chat.messages;
export const selectStreaming = (state) => state.chat.streaming;
// ... 10 more

// Component (50+ lines)
const messages = useSelector(selectMessages);
const dispatch = useDispatch();

Total: 200+ lines for basic chat functionality.

2. TypeScript Pain

// Redux + TypeScript = suffering
dispatch({ type: "ADD_MESSAGE", payload: unknown });
// Have to type every action
// Have to type every reducer case
// Have to type every selector

3. No Native Tool Tracking

Tools in AI chatbots need:

Status (running/completed/failed)
Parameters
Results
Retry logic

Redux doesn't make this easy.

Why easy-model?

One Class = All State

class AIChatModel {
  // State
  messages: Message[] = [];
  streamingText = "";
  isStreaming = false;
  toolCalls: ToolCall[] = [];
  activeTool: Tool | null = null;
  toolResults: Map<string, any> = new Map();
  errors: Error[] = [];

  // Actions
  @loader.load()
  async sendMessage(content: string) {
    this.messages.push({ role: "user", content });
    this.isStreaming = true;

    const response = await llm.streamChat(this.messages);
    for await (const chunk of response) {
      this.streamingText += chunk;
    }

    this.messages.push({ role: "assistant", content: this.streamingText });
    this.isStreaming = false;
  }

  async executeTool(tool: Tool, params: any) {
    this.activeTool = tool;
    const result = await tool.execute(params);
    this.toolResults.set(tool.name, result);
    this.activeTool = null;
  }
}

~50 lines instead of 200+.

Built-in Loading States

class ChatModel {
  @loader.load()
  async sendMessage(content: string) {
    /* ... */
  }
}

// In component
const { isLoading } = useLoader();
{
  isLoading(chat.sendMessage) && <SendingIndicator />;
}

No manual loading state management.

Undo/Redo for Free

const chat = useModel(AIChatModel, []);
const history = useModelHistory(chat);

// Debug AI responses
history.back();
history.forward();

Cross-Component State Sharing

// Chat component
function ChatPanel() {
  const chat = useModel(AIChatModel, ["chat-1"]);
  return <MessageList messages={chat.messages} />;
}

// Status component
function StatusPanel() {
  const chat = useInstance(ChatProvider("chat-1"));
  return <StatusBadge isStreaming={chat.isStreaming} />;
}

Deep Watching

watch(chat, (keys, prev, next) => {
  console.log(`${keys.join(".")} changed:`, prev, "→", next);
  // "messages.5.content"
  // "toolCalls.0.status"
  // "streamingText"
});

Comparison

Feature	Redux	Zustand	MobX	easy-model
Class-based	❌	❌	✅	✅
No decorators	✅	✅	❌	✅
Built-in DI	❌	❌	❌	✅
Undo/Redo	❌	❌	❌	✅
Deep watch	❌	⚠️	✅	✅
TypeScript	⚠️	✅	⚠️	✅
Tool tracking	❌	❌	❌	✅

What I Built

With easy-model:

✅ Chat message history
✅ Streaming response display
✅ Tool call tracking
✅ Error handling with retry
✅ Context/memory management
✅ Multi-turn conversation
✅ Undo/redo for debugging

All in ~150 lines of clean code.

The Point

Redux was designed for simple state updates. AI chatbots are anything but simple.

easy-model gives you:

Class-based simplicity
Complex state handling
Built-in utilities (loading, history, DI)
TypeScript that just works

Result: More time building features, less time fighting state.

GitHub: https://github.com/ZYF93/easy-model

npm: pnpm add @e7w/easy-model

⭐️ Stop using Redux for AI apps. Your future self will thank you.

I Let AI Code My React App. Here's What Happened

张一凡 — Fri, 27 Mar 2026 04:19:46 +0000

I gave Cursor free reign to build a React app. The result? Surprisingly solid code.

The Setup

I decided to build a project management app using Cursor (AI coding assistant). The goal: see how well AI can handle React state management.

Challenge: Which state library would AI understand best?

The Contenders

Redux - Powerful but verbose
Zustand - Minimal but simple
MobX - Class-based but decorators
easy-model - The unknown

The Test

I gave Cursor the same prompt for each:

"Build a user management page with CRUD operations, search filtering, and pagination."

Let's see what it generated.

Redux Version

Cursor generated:

3 action files
2 reducer files
1 selector file
1 hook file
Component code

Then it got confused. Which action does what? Where should this logic go?

Result: ~300 lines, but messy.

Zustand Version

const useStore = create((set) => ({
  users: [],
  loading: false,
  filter: "",
  setUsers: (users) => set({ users }),
  setFilter: (filter) => set({ filter }),
}));

Clean, but Cursor struggled with:

Where to put business logic?
How to handle async properly?
No clear pattern for complex scenarios

Result: ~80 lines, but incomplete.

MobX Version

Cursor loved the class syntax at first:

class UserStore {
  @observable users = [];
  @action async fetchUsers() {
    /* ... */
  }
}

But then TypeScript errors started appearing:

"Decorator support is experimental"
"Property does not exist on type"
"Cannot find name 'observer'"

Result: ~120 lines, but broken.

easy-model Version

class UserModel {
  users: User[] = [];
  loading = false;
  filter = "";

  @loader.load()
  async fetchUsers() {
    this.loading = true;
    const res = await api.getUsers({ filter: this.filter });
    this.users = res.data;
    this.loading = false;
  }

  setFilter(filter: string) {
    this.filter = filter;
    this.fetchUsers();
  }
}

Cursor nailed it. First try. No errors.

Result: ~60 lines, fully functional.

Why easy-model Won

1. Class = AI's Native Language

AI models are trained on OOP code. Classes make sense to them.

class UserModel {
  // properties = state
  users: User[] = [];

  // methods = actions
  async fetchUsers() {
    /* ... */
  }
}

2. Templates Work

Cursor could apply templates:

// CRUD template
class CRUDModel {
  items: Item[] = [];
  @loader.load() async fetchAll() {
    /* ... */
  }
  @loader.load() async create(item: Item) {
    /* ... */
  }
  async update(id: number, item: Item) {
    /* ... */
  }
  delete(id: number) {
    /* ... */
  }
}

3. No Decorator Confusion

No @observable, @action, @observer. Just plain TypeScript.

4. TypeScript Just Works

Full inference, no any, no type gymnastics.

5. DI Makes Dependencies Clear

const apiSchema = object({ baseUrl: string() });

class UserApi {
  @inject(apiSchema)
  config?: { baseUrl: string };
}

Cursor knows what this service needs.

The Verdict

Library	Lines	Errors	AI Understanding
Redux	300+	Few	Poor
Zustand	80	None	Medium
MobX	120	Many	Good
easy-model	60	None	Excellent

What Cursor Built

With easy-model, Cursor built:

✅ User CRUD
✅ Search filtering
✅ Pagination
✅ Loading states
✅ Error handling
✅ Cross-component state sharing
✅ Undo/redo capability

All in ~60 lines of readable code.

Conclusion

For AI-assisted coding, easy-model is the clear winner:

AI understands class-based models
No boilerplate to confuse AI
TypeScript works out of the box
Templates are learnable
Dependencies are explicit

Result: AI produces working code on the first try.

GitHub: https://github.com/ZYF93/easy-model

npm: pnpm add @e7w/easy-model

⭐️ Star if this experiment surprised you too!

5 React State Management Libraries Compared: Which One Should You Choose?

张一凡 — Thu, 26 Mar 2026 01:57:15 +0000

5 React State Management Libraries Compared

Choosing a state management library is one of the first - and most important - decisions in a React project. Let me break down the most popular options.

The Contenders

Redux - The old guard
MobX - The reactive option
Zustand - The minimalist
Recoil - Facebook's experiment
easy-model - The newcomer with IoC

1. Redux

The elephant in the room. Still popular but increasingly seen as over-engineered.

// Action
const increment = () => ({ type: "INCREMENT" });

// Reducer
const counterReducer = (state = 0, action) => {
  switch (action.type) {
    case "INCREMENT":
      return state + 1;
    default:
      return state;
  }
};

// Store
const store = createStore(counterReducer);

// Component
function Counter() {
  const count = useSelector((state) => state);
  const dispatch = useDispatch();

  return <button onClick={() => dispatch(increment())}>{count}</button>;
}

Pros:

Predictable
DevTools are amazing
Huge ecosystem

Cons:

Boilerplate is insane
Steep learning curve
any types everywhere

2. MobX

Reactive, class-based approach.

class Store {
  @observable count = 0;

  @action
  increment() {
    this.count += 1;
  }
}

const store = new Store();

const Counter = observer(() => (
  <button onClick={() => store.increment()}>{store.count}</button>
));

Pros:

Less boilerplate than Redux
Class-based (familiar OOP)
Fine-grained reactivity

Cons:

TypeScript pain
Hidden dependencies
Decorator drama

3. Zustand

Minimalist and fast.

const useStore = create((set) => ({
  count: 0,
  increment: () => set((state) => ({ count: state.count + 1 })),
}));

function Counter() {
  const { count, increment } = useStore();
  return <button onClick={increment}>{count}</button>;
}

Pros:

Absolutely minimal
Insanely fast
Good TypeScript support

Cons:

No class models
No dependency injection
Can't watch nested changes

4. Recoil

Facebook's attempt at something better.

const countAtom = atom({ key: "count", default: 0 });

const countSelector = selector({
  key: "doubleCount",
  get: ({ get }) => get(countAtom) * 2,
});

function Counter() {
  const [count, setCount] = useRecoilState(countAtom);
  return <button onClick={() => setCount((c) => c + 1)}>{count}</button>;
}

Pros:

Simple API
Good async support

Cons:

Not stable (Facebook abandoned it)
Performance issues at scale
Hard to debug

5. easy-model

The newcomer that combines the best of all worlds.

class CounterModel {
  count = 0;

  increment() {
    this.count += 1;
  }
}

function Counter() {
  const counter = useModel(CounterModel, []);
  return <button onClick={() => counter.increment()}>{counter.count}</button>;
}

Pros:

Class-based (like MobX)
Built-in IoC
Deep watching
History/Undo-Redo
Great TypeScript support

Cons:

Newer, smaller community
No Redux DevTools (yet)

Performance Comparison

Test: 100,000 element array, 5 rounds of batch updates:

Library	Time (ms)
Zustand	0.6
easy-model	3.1
MobX	16.9
Redux	51.5

Feature Matrix

Feature	Redux	MobX	Zustand	easy-model
Class models	❌	✅	❌	✅
Built-in IoC	❌	❌	❌	✅
Deep watching	❌	✅	✅	✅
History	❌	❌	❌	✅
Minimal boilerplate	❌	⚠️	✅	✅
TypeScript	⚠️	⚠️	✅	✅

My Recommendation

Simple project / local state: Zustand
Need Redux ecosystem: Redux
Enterprise / Need IoC: easy-model
Legacy MobX project: Stay with MobX

For new projects? I'd pick easy-model. It gives you the class model of MobX, the simplicity of Zustand, and adds IoC capabilities that no other library provides.

What's your pick? Drop a comment!

GitHub: ZYF93/easy-model

Why I Switched from MobX to easy-model (And Why You Might Too)

张一凡 — Wed, 25 Mar 2026 02:22:31 +0000

Why I Switched from MobX to easy-model

MobX was my go-to for class-based state management. Until I found something better.

My MobX Journey

Started with MobX 4, migrated to MobX 6. Used decorators everywhere:

class OrderStore {
  @observable orders: Order[] = [];
  @observable loading = false;

  @computed
  get totalAmount() {
    return this.orders.reduce((sum, o) => sum + o.amount, 0);
  }

  @action
  async fetchOrders() {
    this.loading = true;
    try {
      const res = await api.getOrders();
      runInAction(() => {
        this.orders = res.data;
      });
    } finally {
      runInAction(() => {
        this.loading = false;
      });
    }
  }
}

Then TypeScript started complaining. Then decorators got deprecated. Then I had to rewrite everything with makeAutoObservable.

The MobX Pain Points

1. Type Inference Hell

// This should work but doesn't
const orders = store.orders.map((o) => o.items);
// TypeScript: "Object is of type 'unknown'"

class Store {
  @observable map = new Map<string, Order>();

  getOrder(id: string) {
    return this.map.get(id); // Returns Order | undefined
  }
}

// Later...
const order = store.getOrder("123");
order.amount; // Property 'amount' does not exist on type 'Order | undefined'

2. Hidden Dependencies

class Store {
  @observable firstName = "John";
  @observable lastName = "Doe";

  @computed
  get fullName() {
    return `${this.firstName} ${this.lastName}`;
  }

  @computed
  get greeting() {
    return `Hello, ${this.fullName}`;
  }
}

// When firstName changes, both fullName and greeting recompute
// But it's not obvious from reading the code

3. No Built-in IoC

Want dependency injection? No native support. You end up passing dependencies manually or using service locators.

Then I Discovered easy-model

Same Class Model, Better DX

class OrderModel {
  orders: Order[] = [];
  loading = false;

  get totalAmount() {
    return this.orders.reduce((sum, o) => sum + o.amount, 0);
  }

  async fetchOrders() {
    this.loading = true;
    const res = await api.getOrders();
    this.orders = res.data;
    this.loading = false;
  }
}

No decorators needed. Plain TypeScript classes work out of the box.

Explicit Watching

const store = useModel(OrderModel, []);

// Explicit dependency - clear from the code
watch(store, (keys, prev, next) => {
  console.log(`${keys.join(".")} changed`, prev, next);
});

Built-in IoC

import { inject, CInjection, Container, config } from "easy-model";
import { object, string } from "zod";

const configSchema = object({
  apiUrl: string(),
}).describe("API Config");

class ApiService {
  @inject(configSchema)
  config?: { apiUrl: string };

  async getData() {
    return fetch(`${this.config?.apiUrl}/data`);
  }
}

config(
  <Container>
    <CInjection
      schema={configSchema}
      ctor={ApiService}
      params={["https://api.example.com"]}
    />
  </Container>,
);

Comparison

Feature	easy-model	MobX
Class-based	✅	✅
No decorators needed	✅	❌
Explicit APIs	✅	❌
Built-in IoC	✅	❌
Deep watching	✅	✅
TypeScript support	✅	⚠️
History/Undo-Redo	✅	❌

Performance

Same benchmark - 100K elements, 5 rounds batch update:

easy-model: 3.1ms
MobX: 16.9ms

easy-model is ~5x faster.

Verdict

easy-model gives me:

What I loved about MobX (class models)
What was missing from MobX (IoC, explicit APIs)
Better TypeScript support
Better performance

Now my go-to for new React projects.

GitHub: ZYF93/easy-model

Try it and let me know what you think! ⭐️

I Built a React State Management Library that Combines the Best of Zustand and MobX

张一凡 — Tue, 24 Mar 2026 09:19:21 +0000

I Built a React State Management Library that Combines the Best of Zustand and MobX

After years of struggling with Redux boilerplate and MobX's type inference issues, I built my own state management library that hits the sweet spot.

The Problem

I loved Zustand for its simplicity:

const useStore = create((set) => ({
  count: 0,
  inc: () => set((state) => ({ count: state.count + 1 })),
}));

But it lacked:

Class-based organization
Dependency injection
Deep property watching

MobX had class models and deep watching, but:

Type inference was painful
Hidden dependency tracking made debugging hard
Learning curve was steep

Introducing: easy-model

class CounterModel {
  count = 0;

  increment() {
    this.count += 1;
  }

  decrement() {
    this.count -= 1;
  }
}

function Counter() {
  const counter = useModel(CounterModel, []);

  return (
    <div>
      <h1>{counter.count}</h1>
      <button onClick={() => counter.increment()}>+</button>
      <button onClick={() => counter.decrement()}>-</button>
    </div>
  );
}

That's it. No actions, no reducers, no selectors.

Key Features

1. Dependency Injection (IoC)

import { CInjection, Container, config, inject } from "easy-model";
import { object, string } from "zod";

const apiSchema = object({
  baseUrl: string(),
}).describe("API Config");

class UserApi {
  @inject(apiSchema)
  config?: { baseUrl: string };

  async fetchUsers() {
    return fetch(`${this.config?.baseUrl}/users`);
  }
}

config(
  <Container>
    <CInjection
      schema={apiSchema}
      ctor={UserApi}
      params={["https://api.example.com"]}
    />
  </Container>,
);

2. Deep Watching

class OrderModel {
  order = {
    items: [{ name: "Product", price: 100 }],
    customer: { name: "John" },
  };
}

watch(order, (keys, prev, next) => {
  console.log(`Path: ${keys.join(".")}`);
  console.log(`Changed: ${prev} -> ${next}`);
});

order.order.items[0].price = 150;
// Output: Path: order.items.0.price
// Changed: 100 -> 150

3. History (Undo/Redo)

const order = useModel(OrderModel, []);
const history = useModelHistory(order);

order.value = 1;
order.value = 2;
order.value = 3;

history.back(); // Undo to 2
history.forward(); // Redo to 3
history.reset(); // Back to initial

4. Loading States

class UserModel {
  @loader.load(true)
  async fetchUser(id: string) {
    return api.getUser(id);
  }
}

function UserPage() {
  const { isGlobalLoading, isLoading } = useLoader();
  const user = useModel(UserModel, [id]);

  return (
    <button disabled={isLoading(user.fetchUser)}>
      {isLoading(user.fetchUser) ? "Loading..." : "Fetch"}
    </button>
  );
}

Performance Benchmark

Testing with 100,000 element array, 5 rounds of batch updates:

Library	Time (ms)
Zustand	0.6
easy-model	3.1
MobX	16.9
Redux	51.5

easy-model is 3x slower than Zustand, but offers:

Class-based organization
Built-in IoC/DI
Deep watching
History support

Trade-off worth making for most projects.

When to Use

Yes: Domain-driven apps, need for DI, deep watching requirements
No: Very simple local state, or already happy with current solution

Installation

pnpm add @e7w/easy-model

Dependency Injection in React: A Practical Guide

张一凡 — Mon, 23 Mar 2026 03:16:00 +0000

Bringing enterprise-grade architecture to frontend development

What is Dependency Injection?

Dependency Injection (DI) is a design pattern where dependencies are provided to a class from outside, rather than created internally.

// ❌ Without DI: tight coupling
class BlogService {
  private http = new AxiosHttp(); // Hard-coded
  async getPosts() {
    return this.http.get("/api/posts");
  }
}

// ✅ With DI: loose coupling
class BlogService {
  constructor(private http: HttpClient) {}
  async getPosts() {
    return this.http.get("/api/posts");
  }
}

While common in backend development (Spring, .NET Core), DI is rarely discussed in frontend — until now.

Why DI in React?

1. Service Reuse Across Models

Without DI, you'd pass dependencies manually to every model:

// Tedious
const blogService = new BlogService(new AxiosHttp());
const userService = new UserService(new AxiosHttp());
const productService = new ProductService(new AxiosHttp());

With DI, services are automatically injected:

class BlogModel {
  @inject(HttpSchema)
  private http?: HttpClient;

  async fetchPosts() {
    return this.http?.get("/api/posts");
  }
}

2. Environment Switching

Switch between mock and production APIs without code changes:

// Development
config(
  <Container>
    <CInjection schema={HttpSchema} ctor={MockHttp} />
  </Container>
);

// Production - just change one line
// <CInjection schema={HttpSchema} ctor={AxiosHttp} />

3. Testability

Mock dependencies for unit testing:

describe('BlogModel', () => {
  beforeEach(() => {
    const mockHttp: HttpClient = {
      get: async (url: string) => {
        if (url.includes('posts')) {
          return [{ id: '1', title: 'Test Post' }];
        }
        return [];
      },
      post: async () => ({ id: 'new', title: 'New Post' }),
    };

    config(
      <Container>
        <CInjection schema={HttpSchema} ctor={mockHttp} />
      </Container>,
    );
  });

  test('fetches posts', async () => {
    const blog = provide(BlogModel)();
    await blog.fetchPosts();
    // Test passes with mock data
  });
});

easy-model IoC: Architecture Overview

┌─────────────────────────────────────────┐
│                 App                      │
├─────────────────────────────────────────┤
│  ┌─────────────┐  ┌─────────────────┐   │
│  │  BlogModel  │  │  UserModel      │   │
│  │  @inject    │  │  @inject        │   │
│  └──────┬──────┘  └────────┬────────┘   │
│         │                  │             │
│  ┌──────▼──────────────────▼────────┐   │
│  │         Container                 │   │
│  │  ┌─────────────────────────────┐  │   │
│  │  │  CInjection                 │  │   │
│  │  │  schema={HttpSchema}         │  │   │
│  │  │  ctor={MockHttp}            │  │   │
│  │  └─────────────────────────────┘  │   │
│  └───────────────────────────────────┘   │
└─────────────────────────────────────────┘

Step-by-Step Implementation

Step 1: Define Schema with Zod

// types/http.ts
import { z } from "zod";

export const HttpSchema = z.object({
  get: z.function().args(z.string()),
  post: z.function().args(z.string(), z.unknown()),
});

export type HttpClient = z.infer<typeof HttpSchema>;

Step 2: Implement Services

// http/mock-http.ts
export class MockHttp implements HttpClient {
  private database: Record<string, unknown[]> = {
    "/api/posts": [
      { id: "1", title: "Getting Started", content: "..." },
      { id: "2", title: "Advanced Topics", content: "..." },
    ],
  };

  async get(url: string) {
    return this.database[url] || [];
  }

  async post(url: string, data: unknown) {
    console.log("Mock POST:", url, data);
    return { id: crypto.randomUUID(), ...(data as object) };
  }
}

// http/axios-http.ts
export class AxiosHttp implements HttpClient {
  private client = axios.create({ baseURL: "" });

  async get(url: string) {
    const res = await this.client.get(url);
    return res.data;
  }

  async post(url: string, data: unknown) {
    const res = await this.client.post(url, data);
    return res.data;
  }
}

Step 3: Inject into Models

// models/blog.ts
import { inject, loader } from "@e7w/easy-model";
import { HttpSchema, type HttpClient } from "@/types/http";

export class BlogModel {
  posts: Post[] = [];

  @inject(HttpSchema)
  private http?: HttpClient;

  @loader.load(true)
  @loader.once
  async fetchPosts() {
    this.posts = (await this.http?.get("/api/posts")) as Post[];
  }
}

Step 4: Configure Container

// main.tsx
import { CInjection, config, Container } from "@e7w/easy-model";
import { MockHttp } from "./http/mock-http";

config(
  <Container>
    <CInjection schema={HttpSchema} ctor={MockHttp} />
  </Container>
);

ReactDOM.createRoot(document.getElementById("root")!).render(
  <React.StrictMode>
    <App />
  </React.StrictMode>
);

Project Structure

src/
├── types/
│   └── http.ts           # Schema definitions
├── http/
│   ├── mock-http.ts     # Mock implementation
│   └── axios-http.ts    # Axios implementation
├── models/
│   ├── blog.ts
│   ├── user.ts
│   └── comment.ts
├── ioc/
│   └── container.ts     # Container setup
└── main.tsx

Namespace Isolation

For multiple environments or tenants:

import { CInjection, config, Container } from "@e7w/easy-model";
import { AdminAuth } from "./auth/admin";
import { UserAuth } from "./auth/user";

config(
  <>
    <Container namespace="admin">
      <CInjection schema={AuthSchema} ctor={AdminAuth} />
    </Container>
    <Container namespace="user">
      <CInjection schema={AuthSchema} ctor={UserAuth} />
    </Container>
  </>
);

Then specify the namespace in your Model:

class DashboardModel {
  @inject(AuthSchema, "admin")
  adminAuth!: AuthService;

  @inject(AuthSchema, "user")
  userAuth!: AuthService;
}

Testing Strategy

Unit Tests

describe('BlogModel', () => {
  let mockHttp: jest.Mocked<HttpClient>;

  beforeEach(() => {
    mockHttp = {
      get: jest.fn(),
      post: jest.fn(),
    } as any;

    config(
      <Container>
        <CInjection schema={HttpSchema} ctor={mockHttp} />
      </Container>,
    );
  });

  afterEach(() => {
    clearNamespace();
  });

  test('fetches posts successfully', async () => {
    const mockPosts = [{ id: '1', title: 'Test' }];
    mockHttp.get.mockResolvedValue(mockPosts);

    const { fetchPosts } = provide(BlogModel)();
    await fetchPosts();

    expect(mockHttp.get).toHaveBeenCalledWith('/api/posts');
  });
});

Integration Tests

describe('BlogModel Integration', () => {
  beforeEach(() => {
    // Use real HTTP client for integration tests
    config(
      <Container>
        <CInjection schema={HttpSchema} ctor={AxiosHttp} />
      </Container>,
    );
  });

  test('fetches real data', async () => {
    const { fetchPosts } = provide(BlogModel)();
    await fetchPosts();
    // Tests hit real API
  });
});

Comparison with Alternatives

Feature	easy-model	InversifyJS	Manual DI
React Integration	✅ Native	❌ Adapter needed	✅
Zod Support	✅	❌	❌
Type Safety	✅ Full	✅ Full	⚠️ Partial
Learning Curve	Low	Medium	Low
Boilerplate	Minimal	Medium	Variable

When to Use DI

Use DI when:

Building medium to large applications
Multiple services need shared dependencies
Testing is a priority
Different environments require different implementations

Skip DI when:

Building simple prototypes
Services have minimal dependencies
Team is unfamiliar with DI patterns

Conclusion

Dependency injection brings backend engineering best practices to React development. With easy-model's IoC container, you get:

Service reuse without tight coupling
Environment switching with one-line configuration
Testability through easy mocking
Type safety with Zod schema validation

For enterprise React applications, these benefits significantly improve maintainability and code quality.

GitHub: https://github.com/ZYF93/easy-model

Have you implemented DI in frontend projects? Share your approach and experiences!

Rethinking React State Management with easy-model

张一凡 — Sun, 22 Mar 2026 04:45:02 +0000

How I learned to stop worrying about Redux boilerplate and love class-based models

The Problem with Traditional State Management

Building React applications often means wrestling with state management. Redux is powerful but verbose. MobX has a learning curve. Zustand is lightweight but limited.

What if you could describe your business logic in plain TypeScript classes and have everything else just work?

Let me introduce you to easy-model — a React state management library that changed how I think about frontend architecture.

The Core Idea: Classes as Models

The mental shift is simple:

Fields are state, methods are business logic.

export class CounterModel {
  count = 0;

  increment() {
    this.count += 1;
  }

  decrement() {
    this.count -= 1;
  }
}

No actions. No reducers. No dispatch. Just a class.

Quick Comparison

Redux Version

// 4 files, 60+ lines for a simple counter
// actions/counter.ts
// reducers/counter.ts
// store.ts
// Counter.tsx

easy-model Version

// counter.ts - one file
export class CounterModel {
  count = 0;
  increment() { this.count += 1; }
}

// Counter.tsx
const counter = useModel(CounterModel, []);
<button onClick={counter.increment}>{counter.count}</button>

Key Features

1. React Hooks Integration

function BlogPostList() {
  const blog = useModel(BlogModel, []);

  return (
    <div>
      <button onClick={blog.fetchPosts}>Load Posts</button>
      {blog.posts.map(post => (
        <PostCard key={post.id} post={post} />
      ))}
    </div>
  );
}

2. Shared Instances with `provide`

export const appContext = provide(
  class AppContext {
    currentUser: User | null = null;
    notifications: Notification[] = [];

    setUser(user: User) {
      this.currentUser = user;
    }

    addNotification(message: string) {
      this.notifications.push({
        id: Date.now().toString(),
        message,
        timestamp: new Date(),
      });
    }
  },
)();

// In components
function Navbar() {
  const { currentUser } = useInstance(appContext);
  return <div>{currentUser?.name || 'Guest'}</div>;
}

function NotificationBell() {
  const { notifications } = useInstance(appContext);
  return <Badge count={notifications.length} />;
}

3. Automatic Loading States

class BlogModel {
  posts: Post[] = [];

  @loader.load(true) // Participates in global loading
  @loader.once // Only load once
  async fetchPosts() {
    const res = await fetch("/api/posts");
    this.posts = await res.json();
  }
}

No more manual setLoading(true) -> fetch -> setLoading(false) -> handleError patterns.

4. Dependency Injection with Zod

// types/http.ts
import { z } from "zod";

export const HttpSchema = z.object({
  get: z.function().args(z.string()),
  post: z.function().args(z.string(), z.unknown()),
});

// Inject into any model
class BlogModel {
  posts: Post[] = [];

  @inject(HttpSchema)
  private http?: HttpClient;

  @loader.load(true)
  @loader.once
  async fetchPosts() {
    this.posts = (await this.http?.get("/api/posts")) as Post[];
  }
}

Configure once, use everywhere:

// main.tsx
import { CInjection, config, Container } from "@e7w/easy-model";

config(
  <Container>
    <CInjection schema={HttpSchema} ctor={MockHttp} />
  </Container>
);

5. Environment Switching

// Development
config(
  <Container>
    <CInjection schema={HttpSchema} ctor={MockHttp} />
  </Container>
);

// Production - just swap the implementation
// <CInjection schema={HttpSchema} ctor={AxiosHttp} />

Real-World Example: Task Management

// models/task.ts
export class TaskModel {
  tasks: Task[] = [];

  @inject(HttpSchema)
  private http?: HttpClient;

  @loader.load(true)
  async fetchTasks() {
    this.tasks = (await this.http?.get('/api/tasks')) as Task[];
  }

  @loader.load(true)
  async createTask(title: string) {
    const task = (await this.http?.post('/api/tasks', { title })) as Task;
    this.tasks.push(task);
    return task;
  }

  toggleTask(id: string) {
    const task = this.tasks.find(t => t.id === id);
    if (task) task.completed = !task.completed;
  }
}

// pages/tasks/index.tsx
function TasksPage() {
  const taskModel = useModel(TaskModel, []);

  return (
    <div>
      <button onClick={taskModel.fetchTasks}>Refresh</button>
      <TaskForm onSubmit={taskModel.createTask} />
      {taskModel.tasks.map(task => (
        <TaskItem key={task.id} task={task} />
      ))}
    </div>
  );
}

Performance Benchmarks

In stress tests with 1000 simultaneous component updates:

Library	Time
Zustand	~0.6ms
easy-model	~3.1ms
MobX	~16.9ms
Redux	~51.5ms

17x faster than Redux while providing more features.

When to Use easy-model

Great for:

Medium to large React applications
TypeScript projects
Enterprise applications needing DI
Projects migrating from Redux/MobX
Complex form applications

Not ideal for:

Very simple apps (useState is fine)
Stateless UI components
Projects avoiding TypeScript

Getting Started

npm install @e7w/easy-model

Conclusion

easy-model represents a different philosophy: instead of adapting your code to fit a state management pattern, let the pattern adapt to how you naturally write code.

Give it a try — your future self might thank you.

GitHub: https://github.com/ZYF93/easy-model

Have you tried class-based state management? Share your experience in the comments!