DEV Community: Petar Liovic

What if React State Was a Signal? Applying Linear Algebra to Frontend Architecture

Petar Liovic — Mon, 16 Feb 2026 21:16:59 +0000

React DevTools tells you what rendered. Linters tell you what looks wrong in your code. But neither tells you why your state architecture is broken.

I spent six months thinking about this problem, and I ended up in a strange place: treating React state updates as discrete-time signals and using linear algebra heuristics to find architectural debt at runtime.

This article explains the technique. There's an open-source tool at the end, but the idea is what matters.

The Problem Nobody Talks About

Every React developer has written something like this:

const [isLoading, setLoading] = useState(false);
const [isSuccess, setSuccess] = useState(false);
const [hasError, setError] = useState(false);

Three booleans. They always toggle together. You've created an implicit state machine with impossible states (isLoading: true AND isSuccess: true). A linter won't catch this. A profiler won't catch this. Code review might catch it, if someone's paying attention.

Or this:

const { user } = useContext(AuthContext);
const [localUser, setLocalUser] = useState(user);

useEffect(() => {
  setLocalUser(user); // manual sync
}, [user]);

You've copied a global truth into local state. Now you have two sources of truth. One day they'll drift, and you'll spend three hours debugging it.

These patterns are invisible to static analysis. They only reveal themselves through behavior at runtime. So the question is: can we detect behavior mathematically?

Stop Looking at Values. Start Looking at Timing.

Here's the key insight: you don't need to know what a state variable holds. You only need to know when it changes.

Imagine you're watching your app run. Every time a component re-renders, you write down which state variables changed during that frame. After 50 frames, you have something like this:

Frame:     1  2  3  4  5  6  7  8  9  10 ...
isLoading: 0  1  0  0  1  0  0  1  0  0
isSuccess: 0  1  0  0  1  0  0  1  0  0
userName:  0  0  0  0  0  0  1  0  0  0

Look at isLoading and isSuccess. They update in the exact same frames. Every time. That pattern alone tells you they're redundant, without ever looking at their values.

Now look at userName. Completely independent rhythm. It belongs in the architecture. The other two don't.

This is the core idea: each state variable is a binary vector in {0, 1}⁵⁰, where each dimension is a browser frame. We can use math on these vectors to find relationships.

Cosine Similarity: Measuring How "Together" Two Variables Move

The dot product of two binary vectors counts the frames where both variables updated:

But raw counts are misleading. A variable that updates 40 times out of 50 frames will overlap with almost anything. We need to normalize.

Cosine Similarity solves this:

This gives us a score between 0 and 1:

1.0 means the variables update in perfect sync.
0.0 means they never update in the same frame.

Why 0.88?

Through testing on production codebases (including Excalidraw), I found that 0.88 is the threshold that best filters browser scheduling noise while still catching real architectural problems. Geometrically, that's an angle of about 28° in a 50-dimensional space. Below that, you get false positives from the browser's non-deterministic task scheduling. Above that, you miss real issues.

This is a heuristic, not a formal proof. But it works in practice.

But Wait: Correlation Isn't Causation

Two variables updating in the same frame doesn't mean one caused the other. Maybe they're both responding to the same click event. That's not a bug. That's normal.

To figure out direction, we check the similarity at a time offset.

Instead of comparing frame-to-frame (offset 0), we shift one signal by one frame and compare again:

Offset 0 (sync): A and B update in the same frame. Possibly redundant.
Offset +1: A updates, then B updates one frame later. A might be causing B.
Offset -1: B updates, then A updates one frame later. B might be causing A.

// Normalize the circular offset once, outside the loop
const baseOffset = ((headB - headA + offset) % L + L) % L;

for (let i = 0; i < L; i++) {
  let iB = i + baseOffset;
  if (iB >= L) iB -= L;
  // ... dot product
}

If the highest similarity is at offset +1, that means A consistently updates one frame before B. That's a causal sync leak: A changes, triggers an effect, and that effect sets B. You're forcing a double render.

If the highest similarity is at offset 0, they're just redundant. Two variables storing the same information.

This distinction matters because the fix is different. Redundant state means "delete one." Causal leaks mean "derive instead of sync."

The Subspace Problem: Local vs. Global

There's another pattern that pure correlation misses: Context Mirroring.

When you copy a context value into local state, the local variable will be perfectly correlated with the context. But they have different roles. The context is the source of truth. The local state is a shadow.

To handle this, we assign every signal a role:

Local Basis (U): useState, useReducer. These should be independent.
Global Subspace (W): createContext. These are the anchors.

The ideal architecture is a Direct Sum: V ≈ U ⊕ W, meaning local and global state don't overlap. If a local variable is found inside the global subspace (high similarity with a context value), it's flagged as Context Mirroring.

This catches a class of bugs that pure similarity analysis misses: the local state isn't "redundant" with another local state. It's redundant with a context.

Finding the Root Cause: Who Do I Fix First?

In a complex app, this analysis can produce dozens of findings. Three boolean explosions, two context mirrors, five sync leaks. Where do you start?

This is where it gets interesting. We can model all these relationships as a directed graph.

Nodes: State variables, effects, and events.
Edges: "A triggered B" (from the lead-lag analysis).

But here's the problem: when two variables update from the same click handler, neither caused the other. To handle this, we create a virtual event node for every external trigger:

Event_click → {setUser, setTheme, setTimestamp}

Now we can tell the difference between a dependency chain (A → effect → B) and siblings responding to the same trigger (Event → A, Event → B). Without this, every pair of simultaneous updates looks like a causal leak.

Eigenvector Centrality (PageRank for React Hooks)

Once we have the graph, we need to rank nodes by importance. A simple "count the edges" approach doesn't work because not all downstream nodes are equally important.

Instead, we calculate Eigenvector Centrality. The idea is the same as PageRank: a node is important if it triggers other important nodes.

We solve this iteratively (Power Iteration, typically converges in under 20 iterations). The node with the highest score is the Prime Mover: the single root cause driving the most downstream activity.

In practice, this means: instead of fixing 12 individual issues, you fix the one event handler or effect that's causing all of them.

Does It Actually Work?

I tested this on two real codebases:

Excalidraw (114k stars): The engine identified a sequential sync leak in theme management. A context update was triggering a local state sync via useEffect, causing a double render on every theme change. The lead-lag analysis at τ = +1 caught it.

shadcn-admin: Found a Global Event Fragmentation pattern where a single user action was updating three separate context providers. The spectral ranking correctly identified the event handler as the Prime Mover, not any of the individual state variables.

Both findings led to PRs that got merged.

Performance

The whole thing runs in the browser without blocking the UI:

Signal recording: O(1) per update (ring buffer overwrite)
Correlation analysis: O(D × N) where D = dirty variables (typically 2-3)
Spectral ranking: ~0.3ms for a typical app (18 nodes), ~27ms for 30,000 nodes
Memory: 0 bytes heap growth over a 20-minute endurance test

The signal recording uses requestAnimationFrame for sampling and requestIdleCallback for analysis. The math only runs when the browser is idle.

The Technique, Summarized

Represent each state variable as a binary vector: did it update this frame (1) or not (0)?
Use Cosine Similarity to find variables that update together (redundancy).
Use Lead-Lag Correlation (offset ±1) to find causal chains (double renders).
Assign roles (local vs. context) to detect context mirroring.
Build a directed graph of causal relationships.
Run Eigenvector Centrality to find the root cause.

None of this looks at actual state values. None of this reads your source code. It's purely behavioral, purely based on timing.

Try It

The technique is implemented as an open-source library called react-state-basis. It wraps your React hooks at build time via a Babel plugin, runs the analysis in development, and compiles down to zero-op passthrough hooks in production.

If the math interests you, the wiki goes deeper into the signal processing model, the spectral ranking algorithm, and the performance benchmarks.

If you try it on your codebase and find something interesting, I'd genuinely love to hear about it.

Mathematical Audit of Excalidraw: Finding "Logic Echoes" via Linear Algebra

Petar Liovic — Mon, 12 Jan 2026 12:21:42 +0000

The Signal is Getting Stronger

When I released the first version of react-state-basis, the goal was theoretical: could we model React hooks as temporal signals to detect architectural debt?

Since then, the project has hit #1 on r/reactjs and gained validation from senior engineers at companies like Calendly and Snowpact. But for v0.3.1, I wanted to move from "Theory" to "Forensics." I wanted to run the auditor against one of the most high-performance engines in the React ecosystem: Excalidraw.

The "Invisibility" Milestone (v0.3.1)

The biggest barrier to architectural telemetry is the "Import Tax." No one wants to change their source code to run an audit.

As of v0.3.1, Basis is now a "Ghost" in the machine. Using a custom Babel AST transformer and a Vite Proxy, it auto-instruments standard React imports at build-time.

Semantic Extraction: It reads your source code to label hooks automatically (e.g., count, user).
Zero Code Changes: You keep your import { useState } from 'react' exactly as is.
Isomorphism: The proxy maintains 100% type congruence, ensuring the IDE and compiler see a "perfect body double" of React.

Case Study: Auditing Excalidraw

Excalidraw is a 114,000-star project and a masterpiece of performance engineering. It handles massive amounts of high-frequency state transitions. It was the perfect "Laboratory" for the R⁵⁰ vector model.

The Audit Results:

1. Dimension Collapse in the Theme Engine

The Basis HUD immediately flagged a perfect collinearity (1.0 similarity) between appTheme and editorTheme in the core theme-handle hook.

The Math: These two vectors were pulsing in identical coordinates in the 50-dimensional space.
The Debt: One variable was a redundant mirror of the other, kept in sync via an imperative effect.

2. Sequential Sync Leaks (Causal Loops)

The telemetry matrix detected multiple "Blue Box" violations. These represent directed edges in the component's causal topology where an effect "pushes" data back into state after the render pass.

The Cost: In a high-performance canvas, these sequential updates force unnecessary double-reconciliation cycles, adding avoidable overhead to every theme toggle and window focus event.

Closing the Loop: The Refactor

An auditor's job isn't just to find problems; it's to provide the Basis for a Solution.

I submitted a Pull Request to Excalidraw (which was recently noticed and reposted by @vjeux on x.com platform, one of the most important people in the Frontend industry) to refactor this logic.

The Fix: We removed the redundant state and moved to a Pure Projection using useSyncExternalStore and useMemo.
The Win: Theme transitions now resolve in a single Atomic Render Pass, restoring the linear independence of the component's basis.

What’s Next: v0.4.0 and Linear Maps

We are now moving from Vector Spaces to Linear Operator Theory.

To handle browser-thread jitter (1ms delays), we are investigating Signal Conditioning via linear maps. By applying a temporal convolution (smoothing) and a difference operator (velocity) to our R⁵⁰ basis, we can move from "Bit-Matching" to Scientific Signal Processing.

Formalize Your Basis

Basis is open-source and ready for zero-config integration. If you want to see the "heartbeat" of your own architecture and find where your logic is redundant, give it a run.

GitHub: liovic/react-state-basis
Technical Wiki: 8 Chapters on Vector Spaces and Causal Topology

Auditing React State & Hooks with Math (shadcn-admin Case Study)

Petar Liovic — Mon, 05 Jan 2026 21:51:49 +0000

The "Aha!" Moment

Most React developers view state as a collection of variables. We look at a snapshot in time and ask, "What is the value of isLoading right now?"

But state isn't a static value. It's a signal that moves through time.

I spent my holiday break building react-state-basis, an architectural auditor that treats every React hook as a vector in a 50-dimensional space. After my last post about the theory, I realized one thing: Engineers don't want more console logs. They want an Oscilloscope.

So, I built the Temporal Matrix HUD.

The Matrix: Visualizing Dimension Collapse

When multiple state variables update in perfect sync, they aren't adding new information - they are redundant dimensions. In Linear Algebra, we call this Linear Dependence. In React, we call it Architectural Debt.

I implemented a Zero-Overhead HUD (using Canvas API and requestAnimationFrame) that visualizes your state transitions as a real-time heatmap.

How it works:

Vectorization: Every state variable is mapped to a row.
Temporal Window: The HUD shows a sliding window of the last 50 "ticks" (20ms windows).
Redundancy Detection: Every 5 ticks, the engine calculates the Cosine Similarity between all active vectors.
Visual Alert: If similarity exceeds 0.88, the rows in the HUD turn Red.

If it pulses together, it belongs together. If your matrix is full of red blocks, you're storing the same data in multiple places. Move it to useMemo.

Case Study: Auditing `shadcn-admin`

To test the engine, I audited the popular shadcn-admin template - a gold standard for clean shadcn/ui implementations.

The Results:

Efficiency Score: 100%. The mathematical rank of the system was perfect. Every state variable was a unique source of truth.
The "Causal" Catch: Even in perfect code, the Causality Detective flagged a sequential sync leak in the use-mobile.tsx hook. It detected a "Double Render Cycle" where state was being manually synchronized within an effect.

This is the power of Basis: it finds execution-level bottlenecks that are invisible to static analysis and standard DevTools.

Key Features in v0.2.4

React 19 Ready: Full support for use(), useOptimistic(), and useActionState().
Causality Detective: Tracks the chain of updates from useEffect to state setters to find unnecessary renders.
Circuit Breaker: Forcefully halts infinite loops before they lock up your browser thread.
Ghost Mode: In production, the engine resolves to "Zero-Op" exports. Zero bundle bloat. Zero performance penalty.

Why Math?

We’ve spent a decade "guessing" why our React apps feel sluggish. By treating state transitions as vectors, we move from "voodoo debugging" to formal verification.

If you can measure the Rank of your state-space, you can prove that your architecture is optimal.

Check it out on GitHub:

👉 https://github.com/liovic/react-state-basis

I'm a solo dev and would love to hear your thoughts.

Let's discuss in the comments.

I built a runtime profiler that catches React state anti-patterns

Petar Liovic — Sat, 27 Dec 2025 01:16:30 +0000

The Problem: State Gets Messy

In large React apps, we often end up with state that's harder to maintain than it needs to be. You've probably written code like this:

const [user, setUser] = useState(null);
const [isLoggedIn, setIsLoggedIn] = useState(false);

const onLogin = (data) => {
   setUser(data);
   setIsLoggedIn(true); // Do we need both?
};

isLoggedIn isn't really independent—it's just !!user. But keeping them in sync manually creates extra work and potential bugs.

Or this pattern:

const [celsius, setCelsius] = useState(0);
const [fahrenheit, setFahrenheit] = useState(32);

useEffect(() => {
  setFahrenheit(celsius * 9/5 + 32); // Double render!
}, [celsius]);

This causes two renders every time: one for celsius, then another for fahrenheit. A useMemo would be better.

These aren't syntax errors. They work. But they create architectural debt that compounds over time.

The Challenge: How Do You Find These?

Standard tools like React DevTools show you what your state is right now. ESLint catches some hook mistakes. But nothing really tells you:

"These two states always update together—they're probably redundant"
"This useEffect is creating a double-render cycle"
"You have an infinite loop about to freeze your browser"

So I built something that does.

The Tool: react-state-basis

It's a development-time profiler that watches when state updates happen (not the values themselves) and detects patterns that suggest architectural problems.

What it catches:

1. Redundant State
When two states always update together, it suggests refactoring to a single source of truth or useMemo.

2. Double-Render Cycles
When a useEffect triggers another state update, causing an extra render.

3. Infinite Loops
High-frequency oscillations that would normally freeze your browser—caught and stopped before they lock up your tab.

4. Hidden Coupling
States that should be independent but are actually synchronized (even across different contexts).

How it looks

Detecting Redundant Boolean Flags

The Problem: Using multiple boolean flags (isLoading, isSuccess, hasData) often leads to "impossible states."

What Basis catches: Even though these are separate variables, they update in perfect sync. It flags them as redundant and suggests consolidating into a single state machine or status enum.

Circuit Breaker for Infinite Loops

The Problem: A recursive useEffect causing an infinite loop—normally this freezes your browser.

What Basis does: Detects high-frequency oscillations (25+ updates in 500ms) and automatically halts the update chain before it locks up. Gives you a diagnostic report showing where the loop is.

Catching Manual State Synchronization

The Problem: Manually syncing fahrenheit via useEffect creates a double-render cycle.

What Basis suggests: It identifies the sequential dependency and recommends refactoring to useMemo for a cleaner, single-render solution.

Finding Hidden Cross-Context Dependencies

The Scenario: You have separate contexts (AuthContext, ThemeContext), but they're manually synchronized in your logic (e.g., switching to dark theme when a user logs in).

What Basis reveals: By analyzing update timing across your entire app, it identifies that user and theme are moving in perfect sync—exposing hidden coupling between supposedly independent parts of your architecture.

System Health Check

Architectural Overview: Basis performs a global audit showing how much of your state is actually independent vs. redundant.

An efficiency of 40% means 60% of your state variables are synchronized with others—they could probably be derived or consolidated.

The Goal: Get closer to 100% efficiency, where every state variable serves as a true independent source of truth.

How It Works (High Level)

The tool runs only in development and tracks the timing of state updates across a sliding window. By looking at when updates happen (not what the values are), it can detect:

States that always change together
Sequential update chains
Oscillating patterns

It's inspired by signal processing and correlation analysis—think of it like a profiler for your state architecture.

Zero Production Overhead

The detection engine completely disappears in production builds. Your production bundle stays clean—this only runs during development.

Try it out

I just released this as open source. Looking for feedback from engineers who've dealt with messy state architecture.

GitHub: https://github.com/liovic/react-state-basis

NPM: npm i react-state-basis

Setup is straightforward—uses a Babel plugin to automatically instrument your hooks. No need to change your component code.

Why I Built This

After working on large React codebases for years, I kept seeing the same patterns cause problems:

Boolean flags that should be enums
Manual synchronization that should be derivation
Hidden dependencies across contexts
Infinite loops that only appear in production

Most of these aren't caught by linters or type checkers. They're architectural issues that emerge over time. I wanted a tool that could spot them automatically.

If you've struggled with state management complexity, I'd love to hear your thoughts. What patterns do you wish tools could catch automatically?

Star the repo if this looks useful, or open an issue with feedback. Always looking to improve it.

Keep your state minimal and your architecture clean. ✨