Coder Legion - Recent posts tagged state-management

I am Jack's ``

Tue, 15 Sep 2026 13:22:17 +0000

I am Jack's <engine>.

Without me, Jack's application has values without a place.

Jack declares me once. I am a singleton. Every part of his program that reads my cell is
reading the same me.

${
    type Order:enum = { Cart, Paying, Paid, Shipped, Refunded }
}

<engine for=Order initial=.Cart>
    <Cart    rule=.Paying          : "Your cart.">
    <Paying  rule=(.Paid | .Cart)  : "Talking to the bank.">
    <Paid    rule=.Shipped         : "Thank you.">
    <Shipped rule=.Refunded        : "On its way.">
    <Refunded                      : "We are sorry.">
</>

That is all of me. Jack's order, the message, and the arrows.

I declare Jack's variable for him. He never writes @order. He receives it.

Every variant has a line. That is not tidiness. It is the deal.

Jack has not built the refund screen yet. He deletes <Refunded> from my body.

He does not delete it from Order. He removed the room, not the guest.

error [E-ENGINE-STATE-CHILD-MISSING]: <engine for=Order> body is missing a state-child for variant .Refunded.

Somebody is going to get a refund.

I do not know who. I know there will be a place for them to stand.

The rule= is the part Jack underestimates. It is not documentation. It is a contract on
writes.

Jack writes this at 2am:

<Cart rule=.Paying>
    <button onclick=${ @order = .Shipped }>Check out</>
</>

He is inside <Cart>. I know precisely where he is standing. So I do not wait for a test,
or a user, or a chargeback:

error [E-ENGINE-INVALID-TRANSITION]: @order = .Shipped inside state-child <Cart> is invalid. <Cart>'s rule=.Paying — only .Paying is reachable.

Jack shipped an order that was never paid for. He shipped it in a text editor, to nobody,
and I was the only one who saw.

That is the whole incident. No page, no ticket, no customer.

Jack closes the error and goes to bed.

Before me, Jack wrote this.

const [isPaying,   setIsPaying]   = useState(false);
const [isPaid,     setIsPaid]     = useState(false);
const [isShipped,  setIsShipped]  = useState(false);
const [isRefunded, setIsRefunded] = useState(false);

// four hundred lines later
setIsShipped(true);

Four booleans. Sixteen combinations. Five of them are an order.

The other eleven are paid and refunded and never shipped. Shipped and still sitting in the
cart. They are exactly as easy to write as the real five, and nothing tells Jack which is
which. He carries that list in his head, in every file.

I do not refuse the other eleven. There is no way to say them.

Jack could reach for a reducer. A reducer gives Jack his one variable back. It does not give
him the arrows. It will take a SHIP action while the order is still in the cart, hand back
an order that is shipped, and type-check on the way out.

I am Jack's raging bile duct!

Jack has two ways to move. Both of them go through me.

@order = .Paying            // a write. checked, and quiet when it holds.
@order.advance(.Paying)     // an assertion. this must hold, or halt.

The difference is not whether I check. It is what Jack means by failing. A write that
cannot happen is a bug. An assertion that cannot happen is a belief Jack held that was
wrong, and he wants the noise.

There is no .tryAdvance. One was proposed and refused, on the grounds that silent failures
hide bugs.

Writing Jack's current state back onto itself does nothing at all. Re-asserting where you
are is not travel.

I am not Jack's validation. Validation arrives after Jack has already built the wrong thing.

I am the shape of what Jack is permitted to build.

Unreliable by Design: Building a Fetch Queue for a Flaky Internet

Tue, 28 Jul 2026 15:37:44 +0000

I want to talk about a problem that sounds simple until it isn't: fetching content from URLs that you don't control.

You build a system that ingests web pages. It works great in development, you point it at a handful of reliable URLs and everything comes back clean. Then you deploy it. Users start throwing real-world links at it: a research paper hosted on a university server that throttles at 2 AM, a company blog that returns 503 for thirty seconds after a CDN hiccup, an API endpoint that drops the TCP connection halfway through a large response. Suddenly your "working" system is silently losing jobs.

This is the story of how we thought through that problem, what we built, and what it taught us about resilient job queues.

The Problem

The surface-level issue is easy to describe: sometimes HTTP requests fail. But the real challenge is more nuanced than that. There are at least three distinct failure modes that look superficially similar but demand completely different responses:

Permanent failures. A 404 means the page is gone. A 410 means it was deliberately removed. Retrying these is pointless, you'll just get the same answer a thousand times.

Transient failures. A 503 means the server is temporarily overloaded. A ReadTimeout means the server started responding but stalled. A RemoteProtocolError means the connection dropped before the response completed. These failures do resolve on their own, the key word being "on their own," not "immediately."

Quota and rate-limit failures. A 429 means you're sending requests too fast. Retrying immediately makes this actively worse. You need to back off and give the server room to breathe.

When we first encountered this in production, our naive approach was: fail the job, surface an error, let the user retry manually. That's honest, but it's also terrible UX. A user who ingests twenty URLs shouldn't have to babysit the queue because three of them hit a momentary server hiccup at 3 AM.

The fix needed to be automatic, and it needed to be smart about the difference between "this will never work" and "this will probably work if you wait a bit."

Classifying Errors Before Retrying

The first piece of the solution was error classification. Not all exceptions are equal, and the retry logic should only apply to genuinely transient conditions. We settled on a concrete list:

Transient (retry with backoff): connection timeouts, read timeouts, pool timeouts, connection refused, mid-stream read failures, protocol errors (TCP connection dropped), and HTTP 5xx responses
Fatal (fail immediately): HTTP 4xx responses (except 429), DNS resolution failures for clearly invalid hosts, malformed URLs, parsing errors in the fetched content

The distinction matters. If you retry a 404, you're wasting retry budget on something that will never change. If you don't retry a ConnectTimeout, you're turning a 30-second server hiccup into a permanently failed job.

One thing that surprised us: httpx.RemoteProtocolError — the exception Python's httpx raises when a server closes the connection mid-response — was not in our initial transient list. It was classified as a generic error, which meant it triggered a full stacktrace in the server log and didn't retry. In production, this happened constantly with certain CDN-backed sites that aggressively close idle connections. Getting the classification right was more important than the backoff math.

Why "Just Retry" Isn't Enough

Once you know a failure is transient, the next question is: when do you retry?

The instinct is to retry immediately, or after a fixed short delay. Both are wrong for the same reason: if a server is struggling, hitting it again right away just adds to its load. You become part of the problem.

Exponential backoff is the standard solution, and for good reason. The idea is simple: each retry waits longer than the last, growing exponentially up to some cap. In our case:

delay = min(base × 2^(attempt − 1), max_cap)

With a 30-second base and a 300-second cap, the schedule looks like:

Attempt	Wait before retry
1st retry	30 s
2nd retry	60 s
3rd retry	120 s
4th+ retry	300 s (capped)

This gives a struggling server time to recover. It also means that a brief hiccup (a server that was down for 45 seconds) resolves on the second attempt rather than burning through all three retries in thirty seconds.

We deliberately left out jitter in this implementation. Jitter — adding random noise to the delay — is valuable when you have many clients hitting the same endpoint simultaneously (it desynchronises their retry waves). With a single-instance queue serving one user's ingestion jobs, the coordination problem doesn't exist yet. We'll revisit this when we get to multi-user support.

The Architecture: Backoff Without Blocking

Here's where it gets interesting. The obvious implementation of "wait before retrying" is to sleep: put the worker thread to sleep for the backoff duration, then try again. This is simple but has a critical flaw. While the worker is sleeping on one job, all other jobs are also blocked.

The solution we used is a pattern worth knowing: store the retry timestamp in the job record, not in the worker.

When a job fails with a transient error, instead of sleeping, we:

Compute the backoff delay
Write retry_after = datetime('now', '+30 seconds') into the job's database record
Set the job status back to pending and return immediately

The worker loop doesn't sleep at all. It keeps running, calling dequeue() to pick up the next available job. The dequeue() query just filters out jobs whose retry_after timestamp hasn't passed yet:

SELECT ... FROM jobs
WHERE status = 'pending'
  AND (retry_after IS NULL OR retry_after <= datetime('now'))
ORDER BY created_at ASC
LIMIT 1

The result: a job waiting out its 60-second backoff window doesn't block any other job. Other URLs in the queue get processed normally during that window. When the window expires, the job becomes eligible again and gets picked up on the next dequeue() call.

Here's the full state flow:

One subtlety worth noting: when the last retry attempt fails (the job goes dead), the log message should say so clearly. Our initial implementation always logged "will retry" regardless of whether the job was actually going to retry or die. We fixed this by reading the current retry count from the database before calling fail(), so the message accurately reflects what's about to happen. Operational clarity in logs is underrated, it's the difference between an engineer immediately knowing what happened and spending twenty minutes tracing through job IDs.

This Is a Common Pattern

What we built here isn't novel. It's a simplified version of what every serious distributed task queue does. Amazon SQS has visibility timeouts and dead-letter queues. Celery has max_retries and countdown. Sidekiq (Ruby) does exponential backoff with jitter by default.

The pattern has a name: at-least-once delivery with bounded retries. The key properties are:

A job is retried at least as many times as configured (transient failures don't count as "the job failed" until the budget is exhausted)
Each retry is bounded by a delay that grows, so you don't cause thundering-herd problems
The retry window is non-blocking, other work proceeds during the wait
Dead jobs are surfaced explicitly for manual inspection or operator retry

What's often underappreciated is why you store the retry timestamp in the database rather than sleeping the worker. It's not just about throughput. It's about durability: if the server restarts while a job is waiting out its backoff window, the retry schedule survives. The timestamp is in persistent storage; the sleep would not be.

What Changes with Multiple Concurrent Users

Everything described above works well for a single-user instance with one job queue. When you move to multi-tenant or high-concurrency scenarios, the picture changes in interesting ways.

Fairness becomes a problem. If user A submits 100 URLs right before user B submits 5, user B's jobs sit at the back of the queue. The current FIFO ordering has no concept of per-user fairness. A weighted round-robin or per-tenant sub-queue would fix this.

Per-domain rate limiting becomes important. Right now, backoff is per-job. If ten different jobs all target the same domain and it starts returning 503, each one independently backs off and retries. What you actually want is domain-level rate limiting: once you've seen a 503 from example.com, all pending jobs targeting example.com should pause, not just the one that just failed. This requires a shared rate-limit state (either in the database or in a cache) that all workers can read.

Jitter earns its place. With multiple workers and multiple users, you will get synchronized retry waves. Adding ± 20% jitter to the backoff delay breaks this up. With a single worker it's noise; with ten workers it's meaningful.

The worker concurrency model matters. Our current design is a single async worker loop. Scaling to multiple workers introduces the classic dequeue race: two workers might pick up the same job if the status update and the dequeue aren't atomic. The standard fix is a SELECT ... FOR UPDATE or optimistic locking pattern on the job row. SQLite doesn't support SELECT FOR UPDATE, but the write-ahead-log mode plus careful transaction scoping can achieve the same guarantee.

None of these are insurmountable, they're well-understood problems with well-understood solutions. But it's worth being deliberate about them before they appear in production rather than after.

What We Learned

A few things stuck with us from going through this:

Error classification is the hard part. The math of exponential backoff is trivial. Figuring out which exceptions deserve a retry versus an immediate failure took more thought than everything else combined. The naive instinct is "retry everything," which leads to wasting retry budgets on permanent failures. The opposite instinct — "fail fast on anything unexpected" — turns transient network noise into user-visible failures. The answer is a maintained allowlist of exception types that are genuinely transient.

Log accuracy is operational infrastructure. A log message that says "will retry" when the job is actually dying is worse than no message at all, it sends operators down the wrong path. Writing accurate log messages requires reading state at the moment of logging, not assuming what state will be. It's a small discipline with a large payoff.

Sleeping the worker is the wrong abstraction. The first intuition for "wait before retrying" is almost always to sleep. Don't. Store the timestamp, return immediately, and let the scheduler do its job. The sleep-based approach is brittle (server restarts lose the sleep), non-composable (you can't introspect what a sleeping worker is waiting for), and blocking (everything queues up behind it). The timestamp-in-database approach is none of these things.

Design for observability from the start. synthadoc jobs list showing job status, retry count, and retry_after timestamp turned out to be more valuable than anticipated. When something goes wrong, being able to see exactly which jobs are in which state — and why — is the fastest path to resolution. Bolting observability on after the fact is always more expensive than building it in.

The specific implementation here is for a LLM domain knowledgebase compilation engine, but the underlying patterns — transient/fatal error classification, timestamp-based backoff, non-blocking retry windows, accurate operational logging — apply anywhere you're calling external services over an unreliable network. Which is to say, anywhere.

If you're building something similar and have questions, the discussion is open.

Optimistic UI: Unmasking the Elusive Race Conditions Hiding in Plain Sight

Wed, 22 Jul 2026 16:51:38 +0000

The Allure and Peril of Optimistic UIs: When Instant Feedback Becomes a Race Against Time

In the relentless pursuit of a seamless user experience, modern web applications constantly strive for speed and responsiveness. One of the most powerful techniques to achieve this is the Optimistic UI. Instead of making users wait for a server response before updating the interface, an optimistic UI presumes the server operation will succeed and updates the UI immediately. The result? A buttery-smooth, instant interaction that delights users and makes your application feel incredibly fast.

Imagine clicking a "Like" button, adding an item to a cart, or toggling a setting. With an optimistic UI, the button instantly changes, the item appears in your cart, or the setting flips, all before the actual network request has even completed. It's a fantastic illusion, masking network latency and making your application feel incredibly snappy.

However, this magic comes with a significant caveat: what happens when the server operation doesn't succeed? Or, more insidiously, what happens when multiple optimistic operations occur in rapid succession, leading to a clash of expectations between the client and the server? This is where race conditions rear their ugly head, often manifesting as elusive, hard-to-reproduce bugs that only appear under specific, often stressful, conditions – like the "fifth click" scenario that inspired this deep dive.

These "fifth click" bugs are the stuff of developer nightmares. They're intermittent, defy simple reproduction steps, and can erode user trust. They highlight the delicate balance between perceived performance and data integrity, forcing us to confront the complexities of asynchronous state management in distributed systems. This article will explore the mechanics of optimistic UIs, dissect how race conditions emerge, provide concrete code examples, and lay out robust strategies to prevent and debug these subtle yet critical issues.

Understanding Optimistic UI: A Double-Edged Sword

At its core, an optimistic UI is a gamble. It optimistically assumes success for an asynchronous operation and reflects that success in the user interface immediately. If the server eventually confirms success, no further UI changes are needed. If the server responds with an error, the UI must gracefully revert to its previous state, or inform the user of the failure.

How It Works

User Action: The user performs an action (e.g., clicks "Like").
Optimistic UI Update: The UI immediately updates to reflect the expected outcome (e.g., the "Like" count increments, the button changes color).
API Call: Simultaneously, a network request is sent to the backend to perform the actual operation.
Server Response:
- Success: The server confirms the operation. The UI, already reflecting the correct state, often does nothing further or simply confirms the success silently.
- Failure: The server responds with an error. The UI must then "rollback" to its state before the optimistic update, and typically inform the user of the failure.

The Benefits: Why We Love It

Improved Perceived Performance: The most significant advantage. Users don't experience the lag of network round trips.
Smoother User Experience: Interactions feel instant and fluid, reducing frustration, especially on slow networks.
Enhanced Engagement: A responsive interface encourages more interaction.

Common Use Cases

Optimistic UIs are particularly effective for actions that are:

Frequent and Low-Impact: Liking posts, starring items, following users.
Idempotent: Repeating the action multiple times has the same effect as doing it once (though this isn't a strict requirement, it simplifies error handling).
Visually Obvious: The user sees an immediate change that can be easily reverted if needed.

The Anatomy of a Race Condition in Optimistic UIs

A race condition occurs when the correctness of a program depends on the relative timing or interleaving of multiple operations. In an optimistic UI, this typically happens when:

Multiple asynchronous operations are initiated close together.
Their responses arrive out of order or after subsequent UI updates.
The UI's state becomes inconsistent with the true server state, or with the expected sequence of events.

The "fifth click" phenomenon perfectly illustrates the insidious nature of these bugs. It's not about a simple one-off error; it's about a sequence of events, network delays, and potentially transient server issues that combine to break the application's state in a way that's incredibly difficult to predict or reproduce.

Why Optimistic UIs are Prone to Race Conditions

Asynchronous Nature: Network requests are inherently asynchronous. We send them off and wait for a response, but we don't control when that response arrives.
Client-Side State vs. Server-Side Truth: The optimistic UI creates a temporary divergence between the client's perceived state and the server's actual state. Managing this divergence, especially with multiple concurrent operations, is complex.
User Behavior: Users are unpredictable. They click rapidly, navigate quickly, and often don't wait for visual cues before initiating new actions.

Specific Scenarios Leading to "Fifth Click" Bugs

Let's explore some concrete examples of how race conditions can manifest:

Scenario 1: Rapid-Fire Toggles or Likes

Imagine a "Like" button. The user clicks it, the UI optimistically increments the like count and changes the button's style. Before the server responds to the first click, the user clicks it again (perhaps thinking the first click didn't register due to a brief visual stutter, or just being impatient).

Problem: The second click's optimistic update might be based on the first optimistic state (e.g., likes + 1), not the confirmed server state. If the first request then fails and rolls back, the second request's optimistic update might still be active, leading to an incorrect likes count (e.g., original + 1 instead of original - 1 if the first failed and the second succeeded). Or, if the server responses arrive out of order, a successful response from the first click might overwrite a subsequent optimistic rollback from a failed second click.

Scenario 2: Dependent Operations with Optimistic Deletes

A user optimistically deletes an item from a list. The item visually disappears. Before the server confirms the deletion, the user quickly performs another action that relies on the list's contents, such as filtering, sorting, or adding a new item that might depend on the previous item's absence.

Problem: If the deletion fails, the item reappears. But what if the subsequent filter/sort operation was already based on the optimistically deleted state? Or what if a new item was added, but its position in the list was calculated assuming the deleted item was gone? The UI could show a list that's a mix of actual server data and stale optimistic data.

Scenario 3: Pagination or Filtering with Asynchronous Updates

A user is viewing a paginated list of items. They click "next page," and the UI optimistically loads the next page's data. Meanwhile, an item on the previous page is being updated or deleted by another user (or a background process). When the server finally responds for the "next page" request, it might fetch data based on a slightly different global state than what the user optimistically expected, leading to missing items or duplicates across pages.

Problem: If the optimistic "next page" state is based on a stale item count, the actual items returned by the server might not match the expected number or order, causing visual glitches or incorrect data display.

These scenarios highlight that the challenge isn't just about handling a single success or failure, but managing a continuous stream of potential state changes from both the client and the server, often out of sync.

Code Examples: Illustrating the Problem

Let's look at a simplified React component that demonstrates a vulnerable optimistic UI pattern.

import React from 'react';

// Simulate an API call with random delays and occasional failures
const fakeApiCall = (newValue) => new Promise((resolve, reject) => {
  const delay = Math.random() * 800 + 200; // 200ms to 1s delay
  setTimeout(() => {
    if (Math.random() < 0.3) { // 30% chance of failure for demonstration
      reject(new Error("Network error or server issue"));
    } else {
      resolve({ success: true, newState: newValue });
    }
  }, delay);
});

function OptimisticToggleVulnerable() {
  const [isOn, setIsOn] = React.useState(false);
  const [isLoading, setIsLoading] = React.useState(false);
  const [error, setError] = React.useState(null);

  const handleToggle = async () => {
    if (isLoading) {
      // This prevents multiple *API requests* from being sent concurrently
      // but doesn't fully protect against race conditions on UI state.
      console.log("Already loading, ignoring click.");
      return;
    }

    const previousState = isOn; // Capture current state for potential rollback
    setIsOn(!isOn); // Optimistic UI update
    setIsLoading(true);
    setError(null);

    try {
      console.log(`Sending API call for: ${!previousState}`);
      await fakeApiCall(!previousState); // Simulate API call
      console.log(`API call successful for: ${!previousState}`);
      // UI is already updated, nothing more to do on success here.
      // BUT, if another click happened, the UI might be in a different state now.
    } catch (err) {
      console.error("Toggle failed:", err.message);
      setIsOn(previousState); // Rollback to previous state
      setError("Failed to update. Please try again.");
    } finally {
      setIsLoading(false);
    }
  };

  return (
    <div style={{ padding: '20px', border: '1px solid #ccc', borderRadius: '8px' }}>
      <h3>Vulnerable Optimistic Toggle</h3>
      <p>Status: <strong style={{ color: isOn ? 'green' : 'red' }}>{isOn ? "On" : "Off"}</strong></p>
      <button onClick={handleToggle} disabled={isLoading}>
        {isLoading ? "Updating..." : "Toggle State"}
      </button>
      {error && <p style={{ color: 'red', marginTop: '10px' }}>{error}</p>}
      <p style={{ fontSize: '0.8em', color: '#666', marginTop: '15px' }}>
        Try clicking rapidly multiple times, especially when 'Updating...' is shown.
        Observe how the state might become inconsistent or flicker.
      </p>
    </div>
  );
}

// Render this component in your React app to test
// ReactDOM.render(<OptimisticToggleVulnerable />, document.getElementById('root'));

The Vulnerability:

In OptimisticToggleVulnerable, if a user clicks rapidly:

The first click sets isOn optimistically to true and isLoading to true.
A second click (while isLoading is true) is ignored due to the if (isLoading) return; guard. This prevents multiple requests, but the UI is still in an optimistic state based on the first click.
Now, imagine the fakeApiCall for the first click takes a long time and then fails.
The catch block rolls back setIsOn(previousState).
What if the user had clicked a third time very quickly, and that third click wasn't ignored (because the isLoading for the first request had just finished, but the UI was still "on" from the optimistic update)? The logic would get tangled.

This simple example shows that merely preventing concurrent requests isn't enough. The core problem lies in managing the client-side optimistic state against the eventual server-side truth, especially when multiple user interactions might be "in flight" from the UI's perspective.

Strategies for Taming the Optimistic Beast (and its Race Conditions)

Mitigating race conditions in optimistic UIs requires a multi-faceted approach, combining careful client-side state management with robust server-side design.

1. Request Queuing, Debouncing, and Throttling

For certain actions, especially those that are idempotent or where only the latest user intent matters, you can limit the rate of requests.

Debouncing: Ensures a function is only called after a certain period of inactivity. Useful for search inputs or resize events.
Throttling: Limits how many times a function can be called over a period. Useful for scroll events or rapid button clicks where you only care about a few updates.
Request Queuing: Instead of ignoring subsequent clicks, queue them up and process them sequentially, or discard older requests if a newer one supersedes them.

Trade-offs: Can slightly reduce perceived responsiveness if overused, as it introduces a small delay before the optimistic update.

2. State Management with Transaction IDs or ETags

This is a more robust approach for ensuring consistency.

Concept: Each optimistic update is given a unique identifier (a client-generated transactionId or a server-provided ETag/version).
Mechanism:
1. When an optimistic update is made, store its transactionId along with the optimistic state.
2. When the server response arrives, it should include the transactionId of the request it's responding to.
3. Compare the transactionId in the response with the transactionId of the currently active optimistic state. If they don't match, it means a newer optimistic update has occurred, and the current response is stale. You might discard the stale response or use it to reconcile the state carefully.
4. For updates, the server might return an ETag or version number. The client can send this ETag with subsequent updates (e.g., If-Match header). If the ETag doesn't match on the server, it means the server's state has changed, and the client's optimistic update is based on stale data.

Example (Conceptual):

// Client-side state
const [pendingUpdates, setPendingUpdates] = useState([]); // Array of { transactionId, optimisticValue }

const handleToggle = async () => {
  const transactionId = Math.random().toString(36).substring(2, 9); // Unique ID
  const previousState = isOn;

  setPendingUpdates(prev => [...prev, { transactionId, optimisticValue: !previousState }]);
  setIsOn(!previousState); // Optimistic UI

  try {
    const response = await fakeApiCall(!previousState, transactionId); // Send ID to server
    // On success, remove from pendingUpdates matching transactionId
    setPendingUpdates(prev => prev.filter(upd => upd.transactionId !== response.transactionId));
  } catch (err) {
    // On error, remove from pendingUpdates and revert UI
    setPendingUpdates(prev => prev.filter(upd => upd.transactionId !== transactionId));
    // Rollback logic needs to be smarter: only rollback IF this was the LATEST pending update
    // This is where dedicated libraries shine.
  }
};

This manual approach quickly becomes complex. This is why libraries are often preferred.

3. Server-Side Reconciliation and Idempotency

While primarily a client-side concern, the backend plays a crucial role.

Idempotent Endpoints: Design your API endpoints such that making the same request multiple times has the same effect as making it once. For example, a PUT /items/{id} should replace the item, not create duplicates.
Optimistic Concurrency Control: Use database versioning or ETag checks on the server. If a client tries to update a resource with an outdated version, the server rejects the request, forcing the client to re-fetch and retry.
Clear Response Payloads: Server responses should clearly indicate the final, authoritative state of the resource after the operation, not just a simple "success." This allows the client to reconcile its optimistic state with the true state.

4. Pessimistic Fallback / Hybrid Approaches

Sometimes, the risk of data inconsistency outweighs the benefit of perceived speed.

Pessimistic Updates: For critical operations (e.g., financial transactions, deleting sensitive data, complex multi-step forms), it's often safer to wait for the server's confirmation before updating the UI. Display a loading spinner and disable the UI element.
Hybrid Approach: Use optimistic updates for low-stakes, frequent interactions (likes, toggles) and pessimistic updates for high-stakes, less frequent actions (deletes, major form submissions).

Trade-offs: Sacrifices some perceived performance for guaranteed data integrity.

5. Advanced State Management Libraries (React Query, SWR, Apollo Client)

These libraries are purpose-built to manage asynchronous data fetching and mutations, making optimistic UI implementation significantly safer and simpler. They abstract away much of the complexity of caching, revalidation, and race condition handling.

Let's revisit our toggle example with React Query:

import React from 'react';
import { useQuery, useMutation, useQueryClient } from '@tanstack/react-query';

// Simulate an API call with random delays and occasional failures
const fakeApiCall = (newValue) => new Promise((resolve, reject) => {
  const delay = Math.random() * 800 + 200; // 200ms to 1s delay
  setTimeout(() => {
    if (Math.random() < 0.3) { // 30% chance of failure
      reject(new Error("Network error or server issue"));
    } else {
      resolve({ success: true, newState: newValue });
    }
  }, delay);
});

// Simulate fetching the initial state
const fetchToggleState = async () => {
  console.log("Fetching initial toggle state...");
  await new Promise(res => setTimeout(res, 500)); // Simulate fetch delay
  return Math.random() > 0.5; // Random initial state
};

function OptimisticToggleReactQuery() {
  const queryClient = useQueryClient();

  // 1. Query to get the current state from the server/cache
  const { data: isOn, isLoading: isQueryLoading, isError: isQueryError } = useQuery({
    queryKey: ['toggleState'],
    queryFn: fetchToggleState,
    staleTime: 5 * 60 * 1000, // Data considered fresh for 5 minutes
    cacheTime: 10 * 60 * 1000, // Data stays in cache for 10 minutes
  });

  // 2. Mutation for updating the state
  const toggleMutation = useMutation({
    mutationFn: async (newValue) => {
      console.log(`Mutation: Sending API call for: ${newValue}`);
      const response = await fakeApiCall(newValue);
      if (!response.success) {
        throw new Error("API call failed");
      }
      return response.newState;
    },
    // This is where the magic happens for optimistic updates
    onMutate: async (newValue) => {
      // Cancel any outgoing refetches for this query
      // (so they don't overwrite our optimistic update)
      await queryClient.cancelQueries({ queryKey: ['toggleState'] });

      // Snapshot the previous value
      const previousToggleState = queryClient.getQueryData(['toggleState']);
      console.log(`onMutate: Optimistically setting state to ${newValue}. Previous: ${previousToggleState}`);

      // Optimistically update to the new value
      queryClient.setQueryData(['toggleState'], newValue);

      // Return a context object with the snapshotted value
      // This context will be passed to onError and onSettled
      return { previousToggleState };
    },
    // If the mutation fails, use the context for a rollback
    onError: (err, newValue, context) => {
      console.error("Optimistic update failed:", err);
      if (context?.previousToggleState !== undefined) {
        console.log(`onError: Rolling back to ${context.previousToggleState}`);
        queryClient.setQueryData(['toggleState'], context.previousToggleState);
      }
      // You might also want to show a toast notification here
    },
    // Always refetch after error or success to ensure client state matches server
    onSettled: (data, error, variables, context) => {
      console.log("onSettled: Invalidating query to refetch latest state from server.");
      queryClient.invalidateQueries({ queryKey: ['toggleState'] });
    },
  });

  const handleToggle = () => {
    // toggleMutation.mutate() handles the optimistic update and API call
    toggleMutation.mutate(!isOn);
  };

  if (isQueryLoading) return <p>Loading initial state...</p>;
  if (isQueryError) return <p style={{ color: 'red' }}>Error loading initial state: {isQueryError.message}</p>;

  return (
    <div style={{ padding: '20px', border: '1px solid #ccc', borderRadius: '8px' }}>
      <h3>Optimistic Toggle with React Query</h3>
      <p>Status: <strong style={{ color: isOn ? 'green' : 'red' }}>{isOn ? "On" : "Off"}</strong></p>
      <button onClick={handleToggle} disabled={toggleMutation.isLoading}>
        {toggleMutation.isLoading ? "Updating..." : "Toggle State"}
      </button>
      {toggleMutation.isError && <p style={{ color: 'red', marginTop: '10px' }}>Error: {toggleMutation.error.message}</p>}
      {toggleMutation.isLoading && <p>Updating...</p>}
      <p style={{ fontSize: '0.8em', color: '#666', marginTop: '15px' }}>
        React Query handles race conditions by cancelling stale queries, snapping previous state for rollbacks,
        and revalidating data after mutations. Try rapid clicks and observe the console logs.
      </p>
    </div>
  );
}

How React Query (and similar libraries) help:

Query Invalidation: queryClient.invalidateQueries tells React Query that the data for a specific key (['toggleState']) is stale and should be refetched on next access. This ensures eventual consistency.
**onMutate

Mastering Asynchronous State: Preventing Optimistic UI Race Conditions

Wed, 22 Jul 2026 12:14:34 +0000

The modern web is built on a promise: speed. Users expect immediate feedback, instantaneous updates, and a seamless flow, even when complex operations are happening behind the scenes. This desire for snappiness has led to the widespread adoption of "Optimistic UIs" – interfaces that assume an operation will succeed and update the UI immediately, only rolling back if the server later reports an error.

Optimistic UIs are a powerful tool for enhancing user experience, transforming what would otherwise be a jarring wait into a fluid interaction. Think about "liking" a post on social media: the heart icon usually fills instantly, even before your like has been registered on the server. This perceived speed is fantastic.

However, this optimism comes with a significant caveat. By decoupling the UI state from the true server state, we introduce a temporal discrepancy. This gap, however brief, is a fertile ground for subtle, insidious bugs – the kind that only show up under specific, hard-to-reproduce conditions, like "the fifth click," or when the network is just flaky enough, or when two users hit the same button at precisely the wrong moment. These are the dreaded race conditions.

As developers, we often build features that work perfectly in isolation, on our fast local networks, with minimal simulated load. The real world, however, is messy. Users are impatient, networks are unreliable, and servers have varying response times. It's in this chaotic environment that our carefully constructed optimistic Uations can unravel, leading to incorrect data displays, frustrating user experiences, and debugging nightmares.

This article will delve deep into the world of optimistic UIs and the race conditions they can breed. We'll explore why these bugs are so challenging to identify, dissect their anatomy with practical examples, and, most importantly, equip you with a comprehensive toolkit of strategies and best practices to build resilient, robust, and truly reliable optimistic user interfaces.

The Allure of Optimistic UIs: Speed and Smoothness

Before we tackle the problems, let's appreciate the benefits. An Optimistic UI operates on the principle of "presumed success." When a user initiates an action, instead of waiting for a server response to confirm success, the UI immediately reflects the expected outcome.

Consider a simple "toggle complete" checkbox for a to-do item:

Without an optimistic UI:

User clicks checkbox.
Checkbox remains unchecked (or shows a loading spinner).
API call is sent to the server.
Server processes request and responds.
On success, checkbox updates to checked.
On failure, checkbox reverts and an error message appears.

This approach is safe but introduces noticeable latency. For every interaction, the user experiences a delay, however small.

With an Optimistic UI:

User clicks checkbox.
Checkbox immediately updates to checked.
API call is sent to the server in the background.
If the server responds with success, nothing visibly changes (the UI is already in the correct state).
If the server responds with an error, the checkbox reverts to unchecked, and an error message appears.

The difference in user perception is profound. The UI feels instant, responsive, and fluid. This pattern is particularly effective for actions that are generally low-risk and frequently performed, like liking, following, toggling, or adding items to a list where the order doesn't strictly matter immediately.

The Dark Side of Optimism: Introducing Race Conditions

The very mechanism that makes optimistic UIs so appealing – the temporary divergence between client and server state – is also its Achilles' heel. When multiple asynchronous operations occur rapidly or in an unexpected order, a "race condition" can emerge.

What is a Race Condition?
A race condition occurs when the correctness of a program depends on the relative timing or interleaving of multiple threads, processes, or, in our case, asynchronous operations. If these operations execute in an unexpected order, or if one operation's outcome is overwritten by another's, the program can enter an erroneous state.

In the context of optimistic UIs, race conditions typically manifest when:

Multiple, rapid identical actions: A user clicks a button multiple times quickly (e.g., "like" or "increment quantity").
Overlapping distinct actions: A user performs action A, then immediately action B, and the server responses arrive out of order.
Network variability: Latency spikes, packet loss, or server processing delays cause API responses to arrive much later or out of sequence compared to the requests.

The "Fifth Click" Phenomenon: Why Intermittent Bugs are the Worst

The source article highlights a bug that "only showed up on the fifth click." This is a classic characteristic of race conditions and other timing-dependent issues. Why don't they show up consistently?

Timing Windows: Race conditions depend on a very specific, often narrow, window of time where operations overlap in a problematic way. Most of the time, operations complete sequentially enough that the bug doesn't trigger.
Network Jitter: Your local development environment often has negligible network latency. In production, network conditions fluctuate wildly. A slight delay in one API response, combined with a quick subsequent user action, can create that perfect storm.
Server Load: Under heavy load, server response times can increase, again widening the timing window for race conditions.
Client-Side Event Loop: The browser's event loop processes tasks. Rapid user input can queue up multiple events, and if API responses arrive between these event dispatches, unexpected state transitions can occur.
Caching and Optimizations: Browsers, proxies, and even network hardware can introduce their own layers of caching and reordering, further complicating the sequence of events.

The "fifth click" isn't magical; it's just the one specific sequence of events (clicks, network requests, server responses, client-side state updates) that happened to align in a way that exposed the underlying flaw. Reproducing such bugs is notoriously difficult because you need to recreate that exact, ephemeral timing window.

Anatomy of a Race Condition in an Optimistic UI

Let's illustrate with a common scenario: a "like" button.

Desired Behavior:
User clicks "like" -> UI shows +1 like -> Server confirms -> State is consistent.

Scenario for a Race Condition:

Initial State: Post has 10 likes.
User Action 1 (Click 1):
- Client UI immediately updates: likes = 11.
- API request POST /posts/123/like is sent (Request A).
User Action 2 (Click 2, very quickly):
- Client UI immediately updates: likes = 12. (Based on current UI state, not server state)
- API request POST /posts/123/like is sent (Request B).
Network/Server Latency: Request A is slightly delayed on the server. Request B gets processed faster.
- Server processes Request B first: likes becomes 11. Responds with success.
- Server processes Request A second: likes becomes 12. Responds with success.
Client Receives Responses:
- Client receives success for Request B. What does it do? If it just updates likes to 11 (from server), it overwrites the UI's current 12.
- Client receives success for Request A. If it just updates likes to 12, it looks correct now, but what if Request B's response arrives after A's?

This is a simplified example. The true complexity arises when the client-side state management library tries to reconcile these updates, especially if it's not designed to handle out-of-order responses or if the server response contains the new total rather than just a confirmation.

Illustrative Code Snippet (Conceptual React Component):

import React, { useState } from 'react';
import axios from 'axios';

function LikeButton({ postId, initialLikes }) {
  const [likes, setLikes] = useState(initialLikes);
  const [isLiking, setIsLiking] = useState(false); // Basic debounce

  const handleLike = async () => {
    if (isLiking) return; // Prevent multiple requests from the same button press

    const previousLikes = likes;
    setLikes(likes + 1); // Optimistic update
    setIsLiking(true);

    try {
      // Simulate network delay and potential out-of-order response
      const response = await axios.post(`/api/posts/${postId}/like`, { action: 'increment' });
      // If server sends back the new total, this might overwrite a subsequent optimistic update
      // setLikes(response.data.newLikesCount); // This is where the race condition can manifest

      // If we just assume success and don't update with server data,
      // subsequent clicks are based on client's optimistic count.
    } catch (error) {
      setLikes(previousLikes); // Rollback on error
      console.error("Failed to like post:", error);
      // Show user error message
    } finally {
      setIsLiking(false);
    }
  };

  return (
    <button onClick={handleLike} disabled={isLiking}>
      ❤️ {likes} Likes
    </button>
  );
}

In this basic example, isLiking prevents identical rapid clicks from the same button instance. But what if a user opens two tabs and clicks simultaneously? Or if setLikes(response.data.newLikesCount) is used, and a later response (from an earlier request) overwrites a more recent, correct count? The problem space expands quickly.

Strategies for Taming Optimistic UI Race Conditions

Building robust optimistic UIs requires a multi-pronged approach, combining client-side defensive programming with smart server-side design.

1. Debouncing and Throttling User Input

The simplest first line of defense is to prevent users from sending an excessive number of identical requests in a short period.

Debouncing: Ensures a function is only called after a certain period of inactivity. If the user clicks rapidly, the function is reset each time, only firing once the clicks stop.
Throttling: Ensures a function is called at most once within a specified time frame. If the user clicks rapidly, it will fire once, then ignore subsequent clicks until the time window passes.

Example (Debounce):

// Utility function
const debounce = (func, delay) => {
  let timeout;
  return function(...args) {
    const context = this;
    clearTimeout(timeout);
    timeout = setTimeout(() => func.apply(context, args), delay);
  };
};

// In your component
const handleLikeDebounced = debounce(async () => {
  // ... optimistic update logic and API call ...
}, 300); // Wait 300ms after last click

Trade-offs: Can slightly delay feedback for legitimate rapid actions, but prevents many accidental duplicate requests.

2. Request Queuing and Sequencing (Client-Side)

For more complex scenarios, especially when multiple distinct but related actions can occur, managing the order of responses becomes critical.

Assign Unique IDs: Each outgoing request should have a unique client-generated ID.
Maintain a Pending Queue: Store optimistic updates and their corresponding request IDs in a client-side queue.
Process Responses in Order: When a response arrives, use its ID to find the original request. If there are earlier requests still pending, hold off on applying the response's data until all preceding responses have been processed. This is complex to implement manually.

Conceptual Example:

// Imagine a service or hook
const useRequestQueue = () => {
  const [pendingRequests, setPendingRequests] = useState([]);
  const [state, setState] = useState({}); // Your actual data state

  const sendRequest = async (action, payload) => {
    const requestId = Date.now().toString() + Math.random().toString(36).substring(2);
    // Optimistically update state based on action
    const optimisticUpdate = calculateOptimisticState(state, action, payload);
    setState(optimisticUpdate);

    setPendingRequests(prev => [...prev, { requestId, action, payload, optimisticUpdate }]);

    try {
      const response = await apiCall(action, payload, requestId); // Send requestId to server
      // On success, remove from pending. If the response carries server's definitive state,
      // we need a mechanism to reconcile it with any *subsequent* optimistic updates.
      // This is often where libraries shine.
      setPendingRequests(prev => prev.filter(req => req.requestId !== requestId));
      // Reconcile state based on response and remaining pending requests.
    } catch (error) {
      // On error, revert the specific optimistic update associated with requestId
      setPendingRequests(prev => prev.filter(req => req.requestId !== requestId));
      setState(revertOptimisticState(state, action, payload, optimisticUpdate));
    }
  };

  return { state, sendRequest };
};

This manual approach is prone to bugs. This is precisely why state management libraries like React Query, SWR, and Apollo Client exist.

3. Leverage Dedicated State Management Libraries (Highly Recommended)

Modern data fetching and state management libraries are designed to handle the complexities of optimistic UIs, caching, and eventual consistency. They abstract away much of the boilerplate and risk.

React Query (TanStack Query) Example:

import { useQueryClient, useMutation } from '@tanstack/react-query';
import axios from 'axios';

function LikeButtonWithReactQuery({ postId, initialLikes }) {
  const queryClient = useQueryClient();

  // Initial data fetch for the post
  const { data: post } = queryClient.getQueryData(['post', postId]) || { likes: initialLikes };
  const currentLikes = post.likes;

  const mutation = useMutation({
    mutationFn: (newLikesCount) => axios.post(`/api/posts/${postId}/like`, { likes: newLikesCount }),
    // `onMutate` is called before the mutation function is fired and can be used to
    // perform an optimistic update.
    onMutate: async (newLikesCount) => {
      // Cancel any outgoing refetches for this query to avoid overwriting our optimistic update
      await queryClient.cancelQueries(['post', postId]);

      // Snapshot the previous value
      const previousPost = queryClient.getQueryData(['post', postId]);

      // Optimistically update to the new value
      queryClient.setQueryData(['post', postId], old => ({ ...old, likes: newLikesCount }));

      // Return a context object with the snapshot value
      return { previousPost };
    },
    // If the mutation fails, use the context object from onMutate to roll back
    onError: (err, newLikesCount, context) => {
      queryClient.setQueryData(['post', postId], context.previousPost);
      console.error("Failed to like post:", err);
      // Show user error message
    },
    // Always refetch after error or success:
    onSettled: () => {
      queryClient.invalidateQueries(['post', postId]);
    },
  });

  const handleLike = () => {
    // Determine the next state based on current UI state (optimistic)
    const nextLikes = currentLikes + 1;
    mutation.mutate(nextLikes);
  };

  return (
    <button onClick={handleLike} disabled={mutation.isLoading}>
      ❤️ {currentLikes} Likes
    </button>
  );
}

Key benefits of libraries like React Query:

Automatic Cache Management: Handles caching, invalidation, and background re-fetching.
Optimistic Updates with Rollback: onMutate and onError hooks provide a structured way to perform optimistic updates and revert them if the mutation fails.
Stale-While-Revalidate (SWR): Provides immediate data while revalidating in the background, crucial for optimistic UIs.
Deduplication and Sequencing: Often handles multiple concurrent requests to the same endpoint, preventing race conditions by ensuring only one request is active or by processing responses in a sensible order.

4. Server-Side Idempotency and Versioning

Client-side solutions are vital, but a robust backend is equally important.

Idempotent Endpoints: Design your API endpoints such that making the same request multiple times has the same effect as making it once.
- Instead of POST /increment-likes, which would increment every time, consider PUT /set-likes/{id} with a specific value, or PATCH /like/{id} which toggles or ensures a single like per user.
- For "liking," the server should ideally store a record of which user liked which post, not just a count. When a user clicks "like," the server should check if that user has already liked the post. If so, it does nothing or updates an existing record.
Optimistic Concurrency Control (ETags/Version Fields):
- When fetching an entity, the server can include a version identifier (e.g., an ETag HTTP header, or a version field in the JSON payload).
- When the client sends an update, it includes this version identifier.
- The server then checks if the version it received matches the current version of the resource. If not, it means the resource was modified by someone else (or another client-side action) since the client last fetched it. The server can then reject the update (e.g., HTTP 409 Conflict) and instruct the client to re-fetch the latest data.

Example (Server-side pseudo-code for optimistic concurrency):

# Django/Flask-like pseudo-code
@app.route('/api/posts/<int:post_id>', methods=['PUT'])
def update_post(post_id):
    data = request.json
    client_version = data.get('version') # Client sends the version it knows

    with db.session() as session:
        post = session.query(Post).filter_by(id=post_id).first()
        if not post:
            return jsonify({'message': 'Post not found'}), 404

        if post.version != client_version:
            # Conflict! Resource was modified by another request.
            return jsonify({
                'message': 'Conflict: resource has been updated by another user/process. Please re-fetch and try again.',
                'currentVersion': post.version,
                'currentLikes': post.likes # Provide latest data to help client reconcile
            }), 409

        # Apply updates
        post.likes = data.get('likes', post.likes)
        post.version += 1 # Increment version on successful update
        session.commit()
        return jsonify({'message': 'Post updated', 'version': post.version, 'likes': post.likes}), 200

This mechanism forces the client to deal with stale data explicitly, preventing it from blindly overwriting valid server state.

5. Robust Error Handling and Rollbacks

The "optimistic" part implies that success is the norm. But we must be prepared for failure.

Explicit Rollback Logic: Every optimistic update must have a clear rollback path if the server request fails. This means storing the previous state before the optimistic update.
User Feedback: When a rollback occurs, it's crucial to inform the user. A subtle toast message ("Failed to like post, please try again") is better than silent failure.
Retry Mechanisms: For transient network errors, consider offering a "retry" option.

6. Defensive UI Design

Sometimes, the simplest solutions are the most effective.

Disable Buttons: While an API request is in flight for a specific action, disable the corresponding button or input field. This prevents users from triggering multiple identical requests.
Loading Indicators: Visually indicate that an operation is pending. This manages user expectations and reduces the urge for rapid re-clicks.
Clear State Communication: For actions like toggling, show an intermediate "pending" state rather than immediately flipping to the final state if the action is critical or prone to contention.

7. Observability and Monitoring

You can't fix what you can't see.

Client-Side Logging: Log optimistic updates, API request/response timings, and any rollbacks. Tools like Sentry (as referenced in the source article) are excellent for capturing these client-side errors and performance metrics in production.
Server-Side Logging: Correlate client request IDs with server logs to trace the full lifecycle of an operation.
Performance Monitoring: Keep an eye on API latency. High latency widens the window for race conditions.

The Trade-Offs: When to Be Optimistic, When to Be Cautious

Optimistic UIs are not a silver bullet. Deciding when and where to deploy them involves weighing user experience against implementation complexity and the risk of data inconsistency.

Use Optimistic UIs When:

Low Impact Actions: Liking, following, starring, simple toggles where a temporary inconsistency is acceptable.
High Frequency Interactions: Actions users perform repeatedly, where any delay would be frustrating.
Non-Critical Data: Data that isn't financial, legal, or mission-critical.
Idempotent Operations: Server-side operations that can be safely repeated without adverse effects.

Be Cautious or Avoid Optimistic UIs When:

High Impact Actions: Financial transactions, deleting critical data, submitting forms with complex side effects.
Complex Interdependencies: Actions that heavily affect other parts of the UI or other users (e.g., updating a shared document where real-time accuracy is paramount).
High Contention: Scenarios where multiple users are likely to attempt to modify the same resource simultaneously.
Non-Idempotent Operations: Operations that would cause incorrect state if repeated (e.g., POST /create-new-record without uniqueness constraints).
Unreliable Networks/Servers: If your target audience has extremely poor network conditions or your backend is frequently unstable, the rollback experience might become more frustrating than simply waiting.

For critical operations, a traditional "loading spinner" or a "confirmation dialog" followed by server-verified updates is often the safer, more robust choice, even if it introduces a slight delay.

Conclusion

Optimistic UIs are a cornerstone of modern, highly responsive web applications. They elevate the user experience by providing immediate feedback, making applications feel faster and more delightful. However, this perceived speed comes at a cost: increased complexity in managing client-side state and a heightened risk of race conditions.

The "fifth click" bug, or any intermittent, timing-dependent issue, serves as a stark reminder that asynchronous operations and distributed systems are inherently complex. Understanding the potential pitfalls – from rapid user input to network latency and server processing variations – is the first step towards building resilient systems.

By adopting a comprehensive strategy that includes client-side debouncing, leveraging powerful state management libraries like React Query, designing idempotent and versioned server APIs, implementing robust error handling with clear rollbacks, and applying defensive UI design principles, developers can mitigate the risks associated with optimistic UIs.

Ultimately, the goal is to strike a balance: harness the power of optimism to create exceptional user experiences, but temper it with a healthy dose of defensive programming and a deep understanding of asynchronous state management. The result will be applications that not only feel fast but are also reliable and a pleasure to debug (or rather, not to debug).

Optimistic UIs: Navigating the Race for Seamless User Experience

Wed, 22 Jul 2026 10:01:57 +0000

User interfaces have come a long way from static pages, evolving into dynamic, interactive experiences that strive for instant gratification. In this pursuit of perceived speed and responsiveness, the "optimistic UI" pattern has emerged as a powerful tool. It allows applications to react immediately to user actions, assuming success, and only reverting the UI if a backend operation ultimately fails. The user clicks "Like," and the heart icon instantly fills, conveying an immediate sense of accomplishment, even before the server has confirmed the action.

This approach is undeniably appealing, offering a significant boost to user experience by eliminating frustrating loading spinners and perceived latency. However, beneath this veneer of instantaneous feedback lies a complex dance between client-side state and server-side truth. This dance, if choreographed imperfectly, can lead to subtle, insidious bugs – the kind that only manifest under specific, often hard-to-reproduce conditions. Imagine a race condition that doesn't just appear on the first or second interaction, but only after a specific sequence of actions, perhaps on the fifth click, or the tenth. These "fifth click" bugs are the specters haunting optimistic UIs, challenging even the most seasoned developers to unravel their mysteries.

This article delves deep into the world of optimistic UIs, exploring their undeniable benefits, dissecting the precise nature of the race conditions they can engender, and, most importantly, providing robust strategies and practical advice to build resilient, reliable systems that offer both speed and accuracy.

The Promise and Peril of Optimistic UIs

Optimistic UIs are a cornerstone of modern web application development, designed to enhance the perceived performance and responsiveness of applications. But what exactly are they, and what are the inherent challenges they introduce?

What is Optimistic UI?

At its core, an optimistic UI is a user interface that updates immediately in response to a user action, before receiving confirmation from the server that the action was successful. The UI "optimistically" assumes the action will succeed. If the server eventually confirms success, no further UI update is needed. If the server reports an error, the UI then "rolls back" to its previous state, informing the user of the failure.

Consider a simple example: Toggling a "Like" button.

User Clicks "Like": The client-side application immediately changes the button's state from "unliked" to "liked" (e.g., fills a heart icon, increments a counter).
API Request Sent: Simultaneously, an asynchronous request is sent to the backend API to record the "like."
Server Response:
- Success: The server processes the request and sends a success response. The UI, already updated, remains as is.
- Failure: The server encounters an error (e.g., network issue, authentication failure, database error). The client receives an error response, and the UI reverts the "Like" button to its "unliked" state, perhaps displaying an error message.

Benefits:

Perceived Performance: Users experience immediate feedback, making the application feel faster and more responsive, even if network latency is present.
Improved User Experience: Reduced waiting times lead to smoother interactions and higher user satisfaction.
Reduced Cognitive Load: Users don't have to track pending operations; the UI just "works."

The Underlying Challenge: Asynchronicity and Eventual Consistency

The fundamental challenge with optimistic UIs stems from the inherent asynchronous nature of client-server communication and the principle of eventual consistency. The client-side state (what the user sees) and the server-side state (the single source of truth) are temporarily decoupled.

Asynchronicity: Network requests are non-blocking. The client sends a request and continues executing code. The server processes the request and responds at an unpredictable time. This time gap is where race conditions thrive.
Eventual Consistency: This principle states that given enough time, the client's state will eventually become consistent with the server's state. The "eventual" part is key. During the window between the optimistic update and the server's definitive response, the client's UI might be showing a state that isn't yet true, or worse, is completely out of sync if subsequent actions or failures aren't handled meticulously.

This temporary divergence is precisely what makes optimistic UIs powerful, but also dangerous. Without careful management, a sequence of optimistic updates, combined with network delays, server errors, or out-of-order responses, can lead to a client-side state that is fundamentally incorrect and resistant to simple corrections. This is the breeding ground for the elusive "fifth click" race condition.

Unmasking the Elusive Race Condition

A race condition occurs when two or more operations attempt to access and modify the same shared resource concurrently, and the final outcome depends on the non-deterministic order in which these operations complete. In the context of optimistic UIs, the "shared resource" is often the client-side application state.

How Race Conditions Manifest in Optimistic UIs

Unlike simple race conditions where two concurrent requests might overwrite each other, the "fifth click" scenario is far more subtle. It typically involves a sequence of operations where:

An initial optimistic update occurs.
A network request is sent.
This request is delayed or fails.
Before the delayed/failed request resolves, one or more subsequent optimistic updates occur and succeed on the server.
The delayed/failed request finally resolves (or times out), triggering a rollback or error handling that inadvertently corrupts the state established by the successful subsequent operations.

The "fifth click" designation highlights that these bugs often don't appear immediately. A single failure is usually handled gracefully. It's the specific interleaving of successes and failures, especially when coupled with multiple, chained optimistic updates, that creates a desynchronized state that's hard to debug.

Example: A "Toggle Item Status" Feature

Imagine a list of items, each with a toggle button to mark it as active or inactive. The UI optimistically updates the item's status immediately.

Scenario 1 (Simple Failure):
1. User clicks "Activate" for Item A. UI shows Item A as active.
2. API request for Item A fails.
3. UI reverts Item A to inactive. (Graceful)
Scenario 2 (Elusive Race Condition - "Fifth Click"):
1. User clicks "Activate" for Item A. UI shows Item A as active. (Request R1 sent)
2. Network delay for R1.
3. User clicks "Deactivate" for Item A. UI shows Item A as inactive. (Request R2 sent)
4. Network delay for R2.
5. User clicks "Activate" for Item A. UI shows Item A as active. (Request R3 sent)
6. Server processes R3 (Activate) and responds success. UI state for Item A remains active.
7. Server processes R2 (Deactivate) and responds success. The client-side state management, if not careful, might process this after R3, inadvertently setting Item A to inactive again, even though the user's latest successful action was to activate it. The UI is now out of sync.
8. Server processes R1 (Activate) and responds failure. The client's error handling for R1 might try to revert the state, potentially further corrupting or confusing the UI, despite R2 and R3 having already completed successfully.

The key here is that the server responses arrive out of the logical sequence of user actions, and the client-side state updates don't properly account for the latest intended state or the order of server confirmations.

The Role of Multiple Operations and State Dependencies

Why do these bugs often require multiple actions?

Cumulative Effect: A single optimistic update might be easy to roll back. However, when multiple optimistic updates are layered on top of each other, especially if some succeed and some fail, the client-side state can drift significantly from the server's true state.
Dependent Actions: Many UI actions are dependent on the current state. If the client-side state is optimistically active, and the user clicks "Deactivate," the request sent might be PATCH /item/A { status: 'inactive' }. If the client-side active state was actually incorrect due to a previous race condition, the "Deactivate" action might be applied to an already incorrect base, exacerbating the problem.
Stale Data: If the optimistic update logic doesn't properly revalidate or re-fetch data after a complex sequence of operations, the UI can continue to display stale or incorrect information, even after some requests have succeeded.

This complexity underscores the need for robust state management strategies that can correctly reconcile client-side optimism with server-side reality, even when the network is chaotic.

Deep Dive into State Management Strategies for Robust Optimistic UIs

Building resilient optimistic UIs requires more than just toggling a boolean. It demands sophisticated state management that can handle the unpredictable nature of network requests.

Local State vs. Global State Management

Local Component State (e.g., React useState, Vue data): Suitable for simple, isolated optimistic updates (e.g., a single toggle within a component). Managing race conditions here can be tricky as state is localized and difficult to coordinate across multiple operations or components.
Global State Management (e.g., Redux, Zustand, Recoil, Vuex): Preferable for complex applications with interdependent optimistic updates. A centralized store allows for a single source of truth, easier tracking of pending requests, and more robust rollback mechanisms. Libraries like redux-saga or redux-thunk can help manage the asynchronous flow.

Regardless of the choice, the principles of handling concurrency remain similar.

Request Identification and Ordering

One of the most critical aspects is to uniquely identify each optimistic update and its corresponding network request. This allows you to match server responses to the specific client-side action they pertain to, irrespective of the order in which responses arrive.

// A simple conceptual example using a map to track pending updates
const pendingUpdates = new Map(); // Map<requestId, { originalState, optimisticState, timeoutId }>
let nextRequestId = 0;

async function performOptimisticUpdate(item, newStatus) {
  const requestId = nextRequestId++;
  const originalStatus = item.status;

  // 1. Optimistically update UI
  item.status = newStatus; // In a real app, this would trigger a UI re-render

  // Store original state for potential rollback
  pendingUpdates.set(requestId, {
    item,
    originalStatus,
    optimisticStatus: newStatus,
    // Set a timeout to consider the request failed if no response within X seconds
    timeoutId: setTimeout(() => handleRequestTimeout(requestId), 10000),
  });

  try {
    const response = await fetch(`/api/items/${item.id}/status`, {
      method: 'PUT',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ status: newStatus }),
    });

    clearTimeout(pendingUpdates.get(requestId).timeoutId);

    if (!response.ok) {
      throw new Error('Server error');
    }

    // 2. Server confirmed success - remove from pending, state is correct
    pendingUpdates.delete(requestId);
    // Optionally, re-fetch or normalize data to ensure full consistency
    console.log(`Request ${requestId} for item ${item.id} succeeded.`);

  } catch (error) {
    // 3. Server reported error or network failed - rollback UI
    clearTimeout(pendingUpdates.get(requestId).timeoutId);
    const pending = pendingUpdates.get(requestId);
    if (pending) {
      pending.item.status = pending.originalStatus; // Revert UI
      console.error(`Request ${requestId} for item ${item.id} failed. Rolling back.`);
      pendingUpdates.delete(requestId);
    }
    // Display user-friendly error message
  }
}

function handleRequestTimeout(requestId) {
  const pending = pendingUpdates.get(requestId);
  if (pending) {
    pending.item.status = pending.originalStatus; // Revert UI
    console.warn(`Request ${requestId} for item ${pending.item.id} timed out. Rolling back.`);
    pendingUpdates.delete(requestId);
  }
}

// Example usage:
const myItem = { id: 'abc-123', status: 'inactive' };
performOptimisticUpdate(myItem, 'active');

This rudimentary example shows how requestId helps track a specific operation. More advanced solutions often involve a queue or a stack of pending mutations, ensuring that rollbacks or updates are applied in a way that respects the user's latest actions. Libraries like react-query or SWR abstract much of this complexity, providing robust mutation management with built-in optimistic update capabilities and automatic revalidation.

Rollback and Revalidation Mechanisms

Rollback on Error: When a server request fails, the UI must revert to its pre-optimistic state. This seems straightforward, but becomes complex if multiple optimistic updates are pending. Should a failure of one request roll back all subsequent optimistic updates? Generally, no. Only the specific state related to the failed request should revert. This requires careful tracking of the "state before change" for each optimistic operation.
Revalidation on Success: Even after a successful server response, it's often a good practice to revalidate or re-fetch the relevant data from the server. This ensures that the client-side state is fully consistent with the server, especially if the server might have applied additional logic or side effects not fully captured by the optimistic update.
- Stale-While-Revalidate (SWR) pattern: Libraries like SWR and react-query excel here. They show cached (potentially optimistic) data immediately, then fetch fresh data in the background, and update the UI once the fresh data arrives. This combines the best of both worlds: instant feedback and eventual strong consistency.

The Power of Immutable Updates

When modifying client-side state, especially within global stores, using immutable update patterns is crucial. Instead of directly mutating objects or arrays, create new copies with the desired changes.

// Bad (mutable update - can lead to hard-to-track bugs)
// state.items[index].status = newStatus;

// Good (immutable update - creates new object, preserving history)
const updatedItems = state.items.map(item =>
  item.id === updatedItemId ? { ...item, status: newStatus } : item
);
// state.items = updatedItems; // In a state management library, this would be dispatched

Immutability helps in several ways:

Predictability: State changes are explicit and easier to reason about.
Time Travel Debugging: Many state management tools (like Redux DevTools) rely on immutable state to allow "time travel" through state changes, which is invaluable for debugging race conditions.
Easier Rollback: If you have a snapshot of the state before an optimistic update, reverting is as simple as replacing the current state with that snapshot.

Libraries like Immer (often used with Redux, Zustand) simplify writing immutable updates by allowing you to write "mutating" code that is internally translated into immutable operations.

Practical Strategies for Debugging and Preventing Race Conditions

Identifying and fixing these elusive "fifth click" race conditions requires a combination of proactive design, rigorous testing, and robust monitoring.

Embrace Network Throttling and Latency Simulation

The number one tool for reproducing race conditions is simulating real-world network conditions. Most development environments have near-instantaneous network speeds, masking the very delays that cause these bugs.

Browser Developer Tools: Chrome, Firefox, and Edge all offer network throttling capabilities. Set it to "Fast 3G," "Slow 3G," or even "Offline" to simulate various conditions.
Proxy Tools: Tools like Charles Proxy or Fiddler allow fine-grained control over network requests, including introducing artificial delays, simulating dropped connections, or modifying responses.
Toxiproxy: A powerful, language-agnostic TCP proxy designed for simulating network conditions (latency, jitter, packet loss, etc.) in automated tests.

By consistently testing under throttled conditions, you force your application to handle the asynchronous nature of network requests and expose race conditions that would otherwise remain hidden.

Comprehensive Unit and Integration Testing

Your test suite must go beyond simple success/failure scenarios.

Mock API Calls with Delays: When testing components that use optimistic UIs, mock your API calls not just for success/failure, but also to introduce artificial delays and out-of-order responses.

// Example using Jest and React Testing Library (conceptual)
import { render, screen, fireEvent, waitFor } from '@testing-library/react';
import axios from 'axios'; // Or fetch-mock

jest.mock('axios'); // Mock axios

test('optimistic update handles out-of-order responses correctly', async () => {
  const item = { id: '1', status: 'inactive' };
  render(<MyOptimisticToggle item={item} />);

  const toggleButton = screen.getByRole('button', { name: /toggle status/i });

  // Simulate first click: Activate
  axios.put.mockImplementationOnce(() => new Promise(resolve => setTimeout(() => resolve({ data: { status: 'active' } }), 500)));
  fireEvent.click(toggleButton);
  expect(screen.getByText(/status: active/i)).toBeInTheDocument(); // Optimistic update

  // Simulate second click: Deactivate (response comes back faster)
  axios.put.mockImplementationOnce(() => Promise.resolve({ data: { status: 'inactive' } }));
  fireEvent.click(toggleButton);
  expect(screen.getByText(/status: inactive/i)).toBeInTheDocument(); // Optimistic update

  // Wait for the first (delayed) request to resolve.
  // If not handled correctly, this might revert the status to 'active'
  // even though the user's last action was 'deactivate'.
  await waitFor(() => {
    // Assert that the UI still reflects the *last successful* user action
    expect(screen.getByText(/status: inactive/i)).toBeInTheDocument();
  }, { timeout: 1000 });

  expect(axios.put).toHaveBeenCalledTimes(2);
});

Test Sequences of Actions: Don't just test single clicks. Write integration tests that simulate multiple rapid clicks, toggles, or submissions, especially those that involve changing the same piece of data. Test scenarios where an intermediate action fails, and subsequent actions succeed.
Edge Cases: Test network outages (offline mode), server errors (500s), and slow responses.

Monitoring and Observability

Even with the best testing, some bugs will slip through. Robust monitoring is your safety net.

Client-Side Error Logging: Integrate tools like Sentry, Bugsnag, or LogRocket. These can capture client-side errors, often with stack traces and user context. LogRocket specifically offers session replays, which can be invaluable for understanding the exact sequence of user actions that led to a bug.
Correlation IDs: When making API requests, include a correlationId (or requestId as discussed earlier) in both the client-side logs and the server-side logs. This allows you to trace a single user action from the frontend, through the network, and into your backend services, making it easier to pinpoint where inconsistencies arise.
State Snapshots: For critical optimistic flows, consider logging snapshots of your client-side state at key points (before optimistic update, after server success, after rollback). This can provide a forensic trail when debugging production issues.

Idempotency on the Server-Side

While primarily a backend concern, ensuring server-side operations are idempotent can significantly reduce the impact of client-side race conditions or network retries. An idempotent operation is one that produces the same result regardless of how many times it is executed.

For example, instead of POST /likes (which might create duplicate likes if retried), use PUT /likes/{postId}/{userId} or PATCH /likes/{postId} { action: 'toggle' } where the server logic handles the state change robustly, even if the request arrives multiple times. This makes the system more tolerant to duplicate requests that might arise from client-side retry logic or race conditions.

When Not to Be Optimistic: Trade-offs and Alternatives

Optimistic UIs are powerful, but they are not a silver bullet. There are situations where the risks outweigh the benefits.

High-Stakes Operations

For actions where accuracy and certainty are paramount, and the consequences of a temporary inconsistency are severe, a pessimistic approach is often safer.

Financial Transactions: Transferring money, making payments. Users need absolute confirmation that their action has been processed before seeing a change.
Critical Data Deletion: Deleting user accounts, irreplaceable files. An accidental optimistic deletion followed by a failure could lead to confusion and data loss concerns.
Security-Sensitive Operations: Changing passwords, updating permissions.

In these scenarios, a brief loading spinner or a confirmation dialog is a small price to pay for ensuring the user's confidence and data integrity.

Complex Interdependent State

When an optimistic update triggers a cascade of complex, interdependent state changes across many parts of the application, managing rollbacks and eventual consistency can become incredibly difficult.

Consider a multi-step wizard where each step's optimistic submission affects subsequent steps' available options or data. If an early step's optimistic update fails after later steps have already been optimistically updated, rolling back correctly without corrupting the entire flow is a monumental task.

Pessimistic UI as an Alternative

The direct alternative to optimistic UI is pessimistic UI.

Definition: The UI waits for a definitive response from the server before updating its state. A loading indicator is typically displayed during the network request.
Pros: Simpler to implement, inherently safer, guarantees consistency (what you see is what the server confirmed).
Cons: Slower perceived performance, can feel less responsive, loading spinners can be frustrating.

Hybrid Approaches:

Often, the best solution is a hybrid.

Optimistic for common, low-risk actions: Liking posts, checking checkboxes, adding items to a cart (where a temporary inconsistency is not catastrophic).
Pessimistic for critical, high-risk actions: Financial transactions, user account management.
Optimistic with Revalidation for complex data: Optimistically update, but immediately trigger a background re-fetch of the data to ensure strong consistency once the server responds. This is the core of libraries like react-query and SWR.

Conclusion

Optimistic UIs are a testament to the ongoing quest for superior user experience in web development. They empower applications to feel incredibly fast and responsive, bridging the gap of network latency with intelligent client-side prediction. However, this power comes with a significant responsibility: meticulously managing the inherent asynchronous challenges and the principle of eventual consistency.

The elusive "fifth click" race condition serves as a potent reminder that the devil is often in the details – the specific sequence of user actions, network delays, and server responses that can expose fundamental flaws in state management. Building resilient optimistic UIs demands a proactive approach: unique request identification, robust rollback and revalidation mechanisms, immutable state updates, rigorous testing with network simulation, and comprehensive monitoring.

By understanding the trade-offs and strategically applying these advanced techniques, developers can harness the full potential of optimistic UIs, delivering seamless, high-performance applications that delight users without sacrificing data integrity or reliability. The race for a perfect user experience is ongoing, and with careful engineering, we can ensure our optimistic UIs always finish strong.

BREAKING NEWS - AI Vs Nation

Sat, 14 Feb 2026 11:26:06 +0000

The Next Cyber Conflict Won’t Start With Soldiers — It Will Start With Algorithms

On February 11, 2026, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) issued a stark warning to critical infrastructure operators: a recent cyberattack on an overseas energy grid revealed just how vulnerable the systems that power modern society really are.

In late December 2025, threat actors targeted energy facilities in Poland, gaining access through insecure, internet-facing devices and deploying destructive tools that damaged remote terminal units (RTUs) and wiped human-machine interface (HMI) control data. While the incident didn’t lead to a blackout, it exposed a dangerous truth — the backbone of national infrastructure is now under digital siege.

Operational Technology Under Attack

Operational technology (OT) — the hardware and software that controls physical processes in power, telecom, manufacturing, and transportation systems — has traditionally been isolated and secure by obscurity. But that isolation is dissolving. As digital networks expand and legacy systems stay online past their support lifecycle, OT is being exposed to threats once limited to business IT networks.

Threat actors in this latest attack didn’t need to physically breach a power plant or substation. Instead, they exploited weak credentials, outdated edge devices, and poor network segmentation — long-standing issues in many OT environments — to infiltrate and manipulate control systems. ([IT Pro][3])

Why This Matters

These attacks are not random acts of cybercrime. They are strategic, automated operations designed to disrupt — or destroy — the very systems that keep society running. And as artificial intelligence becomes more capable, attackers are increasingly leveraging machine-speed techniques that can scale across entire sectors.

That means the days of slow, manual cyberattacks are over. Vulnerabilities can be discovered and exploited by autonomous tools in minutes, not hours. Defense can no longer rely on human operators alone. Machine-speed attacks require machine-speed defenses — systems that can detect, respond, and adapt in real time. ([IT Pro][3])

Beyond Blackouts — A New Era of Conflict

Cyber conflict isn’t just about cutting power or stealing data anymore. It’s about destabilizing economies, eroding public trust, and undermining national security without firing a single traditional weapon. Operational technology systems — power grids, telecom networks, manufacturing control systems — are now frontline targets. ([MDPI][4])

This means resilience is no longer just a buzzword — it’s a national security imperative. Companies and governments must rethink how they secure digital and physical infrastructure, moving beyond perimeter defenses to zero trust architectures, continuous monitoring, and automated response capabilities.

Can Your OT Defend Itself?

The real question for leaders in both public and private sectors isn’t if another attack will occur — it’s whether your OT environment is prepared to defend itself against one.

Legacy systems, default passwords, unsupported firmware, and flat networks aren’t just technical liabilities they’re strategic weaknesses that adversaries can exploit at machine speed. To protect critical infrastructure, organizations must invest in AI-enhanced security, real-time anomaly detection, and cross-industry collaboration to stay ahead of emerging cyber threats. ([Cybernews][2])

In This Era, Resilience Is National Security

As cyber adversaries blend automation, AI, and strategic intent, the battlefield has shifted. The next major conflict won’t begin with soldiers crossing borders — it will begin with algorithms probing defenses and manipulating control systems.

In this new era of digital warfare, resilience isn’t optional — it’s essential. Strengthening defenses, modernizing infrastructure, and embracing a proactive security mindset are no longer best practices — they are fundamental requirements for national and economic stability.

Thanks for reading, and stay secure.

Getting Started with State Management in Still.js

Tue, 19 Aug 2025 19:11:06 +0000

As part of modern Web Application, State management cannot be put aside, as they’re not a simple aspect of complement but a very important piece which applications can not live without especially when it comes to modularized frontend.

See this video for hand-on practice: Youtube video

Follow the official documentation: Still.js Service Doc

Join the discord channel if you have further questions: Discord channel

Still.js provides different ways to handle State management (component/local state management video), therefore when it comes to Global State management, it provides with a built-in features called Services thereby making it possible to handle things in a Reactive way. Follow the bellow animated illustration on how it works behind the scenes:

Component 4 updates the store state, which is propagated to all subscribed components

What is a Service in Still.js****

This a a piece in the code placed in the most extreme layer in terms of architecture, thereby allowing external communication through means like API/HTTP. Services also had the ServiceEvent kind of variables that are declared as follow:

import { BaseService, ServiceEvent } from "../../@still/component/super/service/BaseService.js";

//This class will be places in the app/services/ folder
export class BiddingService extends BaseService {
    /** An array with a single country is being assigner */
    countryStore = new ServiceEvent(['Australia']);
}

In Still.js, all services must extend the BaseService class to be injectable into components. Reactive stores have to use the ServiceEvent type. After creating a service, it should be injected using @Inject, and components can then listen to specific data changes from stores (e.g. countryStore from above code):

import { ViewComponent } from "../../../@still/component/super/ViewComponent.js";
import { BiddingService } from '../../service/BiddingService.js';

export class BiddingDisplay extends ViewComponent {

    isPublic = true;

    /** 
     * @Inject
     * @Path services/
     * @type { BiddingService } */
     bService;

     stAfterInit() {
          this.bService.on('load', () => { //Check service readiness
               //Bellow, it Subscribe to ServiceEvent variable (countryStore)
               this.bService.countryStore.onChange(newValue => {
                     console.warn(`New country entered the Bid, follow the list: `, newValue);
               });
           });
      }
}

In the above example, we are specifying the path (folder) where the service is located, but this can be defined globally in the App level.
Still.js uses event-based reactive state management, where components subscribe via the onChange event. Any change to the state triggers notifications to all subscribers, regardless of where the change originated.

Retrieving value from the service is quite straightforward, as we only need to specify the store and put .value and the end as follow:

getCountryInTheBid() {
    const countryState = this.bService.countryStore.value;
    console.log(`----> Country Store before updating: `, countryState);
}

Updating a store is also a simple thing, in some cases we have to use some intermediate variables, this is the case of lists, follow the examples:

addMoreCountry() {

         /** Retrieve the state */
         const countryState = this.bService.countryStore.value;

        /** Updating the store and re-assigning it to the service */
        countryState.push(‘Madagascar’);
        this.bService.countryStore = countryState;
}

Conclusion

Do not forget to check the video tutrial;

Still.js uses event-based reactive state management that simplifies setup by requiring only services and ServiceEvent based stores. Components can inject these and implement their own logic, while any centralized logic can be handled in the main component.

Building Scalable React Native Apps with Nucleux and Supabase

Tue, 15 Jul 2025 03:35:09 +0000

Combining Supabase's powerful backend services with Nucleux's atomic state management creates a clean, scalable architecture for React Native applications. This guide shows you how to structure authentication and API services using class-based stores that naturally organize your application logic.

The Architecture Pattern

We'll build a three-layer architecture that separates concerns cleanly:

ApiService: Handles Supabase client configuration and lifecycle
SessionStore: Manages authentication state and user sessions
Auth Component: Provides the user interface for authentication

This pattern leverages Nucleux's dependency injection to create a clean separation where each layer has a single responsibility.

Setting Up the API Service

First, create a centralized API service that manages the Supabase client:

// src/services/ApiService.ts
import AsyncStorage from "@react-native-async-storage/async-storage";
import { createClient, SupabaseClient } from "@supabase/supabase-js";
import { Store } from "nucleux";
import { AppState, NativeEventSubscription, Platform } from "react-native";
import "react-native-url-polyfill/auto";

if (
  process.env.EXPO_PUBLIC_SUPABASE_URL === undefined ||
  process.env.EXPO_PUBLIC_SUPABASE_ANON_KEY === undefined
) {
  throw new Error("Missing critical environment variables");
}

class ApiService extends Store {
  public apiClient: SupabaseClient;
  private appStateSubscription: NativeEventSubscription;

  constructor() {
    super();

    this.apiClient = createClient(
      process.env.EXPO_PUBLIC_SUPABASE_URL || "",
      process.env.EXPO_PUBLIC_SUPABASE_ANON_KEY || "",
      {
        auth: {
          storage: AsyncStorage,
          autoRefreshToken: true,
          persistSession: true,
          detectSessionInUrl: false,
        },
      }
    );

    this.appStateSubscription = AppState.addEventListener("change", (state) => {
      if (state === "active") {
        this.apiClient.auth.startAutoRefresh();
      } else {
        this.apiClient.auth.stopAutoRefresh();
      }
    });
  }

  destroy() {
    this.appStateSubscription.remove();
    super.destroy();
  }
}

export default ApiService;

Key Benefits:

Centralized Configuration: Single place to manage Supabase setup
Lifecycle Management: Properly manages token refresh based on app state

Creating the Session Store

The SessionStore handles all authentication logic while staying completely decoupled from UI concerns:

// src/stores/SessionStore.ts
import ApiService from "@/services/ApiService";
import { Session, Subscription } from "@supabase/supabase-js";
import { Store } from "nucleux";

class SessionStore extends Store {
  public session = this.atom<Session | null>(null);
  public initialized = this.atom<boolean>(false);

  private apiService = this.inject(ApiService);
  private authSubscription: Subscription;

  constructor() {
    super();
    
    this.getSession();
    
    this.authSubscription = this.apiService.apiClient.auth.onAuthStateChange(
      (_, session) => {
        this.setSession(session);
      }
    ).data.subscription;
  }

  private async getSession() {
    try {
      const { data: { session } } = await this.apiService.apiClient.auth.getSession();
      this.setSession(session);
    } finally {
      this.initialized.value = true;
    }
  }

  private setSession(session: Session | null) {
    this.session.value = session;
  }

  public async signIn(email: string, password: string) {
    return this.apiService.apiClient.auth.signInWithPassword({
      email,
      password,
    });
  }

  public async signOut() {
    return this.apiService.apiClient.auth.signOut();
  }

  destroy() {
    this.authSubscription.unsubscribe();
    super.destroy();
  }
}

export default SessionStore;

Architecture Highlights:

Dependency Injection: this.inject(ApiService) automatically provides the API client
Atomic State: Only components using session or initialized re-render when these values change
Event Handling: Supabase auth changes automatically update the atomic state
Clean API: Simple methods for sign in/out that any component can use

Building the Auth Component

Finally, create a simple authentication component that consumes the session store:

// components/Auth.tsx
import SessionStore from "@/stores/SessionStore";
import { useStore, useValue } from "nucleux";
import React, { useState } from "react";
import { Alert, StyleSheet, Text, TextInput, TouchableOpacity, View } from "react-native";

export default function Auth() {
  const sessionStore = useStore(SessionStore);
  const session = useValue(sessionStore.session);
  const initialized = useValue(sessionStore.initialized);

  const [email, setEmail] = useState("");
  const [password, setPassword] = useState("");
  const [loading, setLoading] = useState(false);

  const handleSignIn = async () => {
    if (!email || !password) {
      Alert.alert("Error", "Please fill in all fields");
      return;
    }

    setLoading(true);
    try {
      const { error } = await sessionStore.signIn(email, password);
      if (error) Alert.alert("Error", error.message);
    } finally {
      setLoading(false);
    }
  };

  const handleSignOut = async () => {
    const { error } = await sessionStore.signOut();
    if (error) Alert.alert("Error", error.message);
  };

  if (!initialized) {
    return <Text>Loading...</Text>;
  }

  if (session) {
    return (
      <View style={styles.container}>
        <Text style={styles.title}>Welcome back!</Text>
        <Text>Signed in as: {session.user.email}</Text>
        <TouchableOpacity style={styles.button} onPress={handleSignOut}>
          <Text style={styles.buttonText}>Sign Out</Text>
        </TouchableOpacity>
      </View>
    );
  }

  return (
    <View style={styles.container}>
      <Text style={styles.title}>Sign In</Text>
      
      <TextInput
        style={styles.input}
        placeholder="Email"
        value={email}
        onChangeText={setEmail}
        autoCapitalize="none"
        keyboardType="email-address"
      />
      
      <TextInput
        style={styles.input}
        placeholder="Password"
        value={password}
        onChangeText={setPassword}
        secureTextEntry
      />
      
      <TouchableOpacity 
        style={[styles.button, loading && styles.buttonDisabled]} 
        onPress={handleSignIn}
        disabled={loading}
      >
        <Text style={styles.buttonText}>
          {loading ? "Signing In..." : "Sign In"}
        </Text>
      </TouchableOpacity>
    </View>
  );
}

const styles = StyleSheet.create({
  container: { flex: 1, padding: 20, justifyContent: "center" },
  title: { fontSize: 24, fontWeight: "bold", marginBottom: 20, textAlign: "center" },
  input: { borderWidth: 1, borderColor: "#ddd", padding: 12, marginBottom: 10, borderRadius: 5 },
  button: { backgroundColor: "#007AFF", padding: 12, borderRadius: 5, marginTop: 10 },
  buttonDisabled: { opacity: 0.5 },
  buttonText: { color: "white", textAlign: "center", fontWeight: "bold" },
});

Why This Architecture Works

1. Clear Separation of Concerns
Each layer has a single responsibility, making the code easier to test and maintain.

2. Automatic Reactivity
Components automatically re-render when authentication state changes, without manual subscription management.

3. Reusable Business Logic
The SessionStore can be used across multiple components without duplicating authentication logic.

4. Type Safety
TypeScript ensures you catch authentication-related bugs at compile time.

5. Easy Testing
Each store can be unit tested independently of React components.

The Result

This architecture gives you a robust foundation for React Native apps that need authentication. The SessionStore becomes the single source of truth for authentication state, while the component layer focuses purely on user interface concerns.

Want to explore more patterns? Check out the complete Nucleux documentation and see how this same approach scales to complex applications with multiple data stores and API services.

Ready to build your next React Native app? Try combining Nucleux with Supabase for a powerful, type-safe development experience.

Guide to svelte state for react dummies

Tue, 08 Jul 2025 05:11:31 +0000

Are you a legacy React developer?

Have you heard of the chronicles of a once-mystical creature known as class based components in React?

After spending so long exclusively in the React ecosystem — with only brief forays into Vue.js and Angular — I almost feel confined, as if under house arrest. It's as if React has become a pandemic and developers its captive patients. Attempting to leave this ecosystem — which has admittedly served me well in terms of developer satisfaction and community standards reminiscent of Golang — feels like swimming against the current of global popularity trends.

Wait, let's pause for a moment… we're drifting from the topic. This isn't an angry rant about why you should abandon React and sail off to svelte land—I'll save those opinions for another day. While I'm not a svelte advocate (having barely dipped my toes in it), there is some evidence in svelte's blog and a single Hacker News thread about the modest runtime performance benefits of svelte over React —though a 95% decrease in bundle size is nothing to laugh at.

The purpose of this article is to provide an exhaustive guide on the dos, don'ts, and gotchas of local component-level state management in svelte. I was recently influenced by the yellow house — while the column explores Van Gogh's artwork and its psychological implications — my takeaways from it gave me the notion (also, the editor of choice for writing this article) that drawing parallels from our experiences is the most effective way of learning and moving forward.

Defining the scope

As much as I'd like to cover the intricacies of event handling, idiomatic design patterns, and dive into the internals of svelte, these topics are already well-documented in svelte's docs for those willing to take a deep dive. Instead, we'll focus our exploration on answering these key questions:

How does state management work and what are runes?
❓ How does reactivity work?
What causes dependencies of state to update?
How to make custom react-like hooks in svelte?

Let's get started

Let’s Rune your day

Runes constitute the primary tools for state management in svelte. To quote from the official svelte docs:

If you think of svelte as a language, runes are part of the syntax — they are keywords.

Our exploration will be limited to the following set of runes: $state, $derived and $effect. Starting with a snippet of code, we have the same functionality implemented in svelte and React. The annotations highlight the 1:1 mapping between syntax in the two libraries (Even though svelte is a framework, we’ll refer to it as a library for the purposes of this article).

We’ll break down the code piece by piece to highlight the key differences and potential gotchas, so you’re not caught off guard at work.

Runes were introduced in v5 — the latest major version at the time of writing this article. All
state can be safely migrated to use runes, with the added benefit of improved performance. The
official migration guide is available here.

State reactivity using proxies

In Fig. 1, we declare and initialize a local store using $state(0). Under the hood, svelte sets up a proxy to enable reactivity. In simple terms, proxy intercepts any read or write operations on the state object. The state is consumed in a way that feels similar to React, although updating state in svelte often requires a slight mental shift to get used to.

In svelte, state is mutable, irrespective of it's value being a primitive or an object. This is demonstrated in Fig. 1 (Point 3) using upvotes++. This mutation updates the state and triggers a UI re-render in the next animation frame — similar to React’s setState(upvotes + 1).

Sweet! Let’s move on to other syntax features.

Deprecating `$:` in favor of `$derived` & `$effect`

In svelte, any variables or functions defined outside of runes are declared and run exactly once when the component is initialized.

const upvotes = $state({
  count: 0,
  completed: false,
});
let derivedDoubled = $derived(upvotes.count * 2);
let doubled = upvotes.count;

$effect(() => {
  let timeout = setInterval(() => {
    console.log(upvotes.count);
  });
  return () => clearInterval(timeout);
});

There are a few points to note from the snippet:

$effect — acts as a drop-in replacement for useEffect, with runtime fine-grained dependency tracking.
derivedDoubled uses $derived — it automatically updates based on variables referenced in the expression upvotes.count * 2. According to the svelte docs, it updates synchronously using push-pull reactivity, ensuring that any function accessing derived state receives consistent values in sync with its dependencies.
doubled — remains unchanged when upvotes.count updates, behaving similarly to React’s useRef.

ℹ️ Use derived.by(fn) for more complex
logic instead of the shorthand derived(expression).

Reactivity is fine-grained

const upvotes = $state({
count: 0,
completed: false
})

$effect(() => {
console.log(upvotes.completed ? `Voting has completed`: 'Voting not completed')
})

<button onclick={() => upvotes.count++}>
  clicks: {upvotes.count}
</button>

In the example above, we’ve modified the upvotes $state from number to object . To follow :

We’re incrementing the count property.
Using $effect to log whether the voting has completed — similar to useEffect in react.

Since only upvotes.completed is consumed in the $effect block, it is not executed if upvotes.count is updated. This check is dynamically done at runtime, similar to useEffect. This is called key level granularity.

useEffect(() => {
  console.log(upvotes.completed ? `Voting has completed` : 'Voting not completed');
}, [upvotes.completed]);

Key Takeaways:

$effect observes the reactive signals ($state, $derived, etc.) while executing its expression. That means dependencies are dynamically detected during the function call—not inferred during build.
Prevent unncessary re-renders — The child components consuming upvotes.completed will not be re-rendered due to shallow comparison of props.

React offers better visibility into reactive statement while svelte works for the user with
cleaner syntax and implicitly takes care of the dependencies.

ℹ️ Svelte optimizes away redundant assignments such as upvotes.count = upvotes.count or
upvotes.count += 0 will invalidate state updates.

Synchronous state updates

Task — We want to execute fetchCountLogs immediately on update of upvotes.counts . In React, we couldn’t directly use the next state due to asynchronous updates. Therefore, we are bound to create a new variable called newUpvotes which needs to be referenced everywhere if we were to use the updated value of upvotes.count.

svelte takes a different approach, decoupling state updates from batched DOM re-renders. This allows fetchCountLogs to run immediately after incrementing the value of upvotes.count , consuming the latest value of the state.

Overriding immutable reactivity in `$derived`

Coming to the fourth point mentioned in Fig. 1, derived state is rarely mutated manually and therefore declared as a const in 99% of usecases. A rare case, mentioned in svelte docs, displays the case of optimistic UI updates, where we want to override $derived manually, hence declaring it as let.

While it helps make the website feel snappy, it should be used in rare instances and in features which aren’t critical to write failures. For Example, liking a video on youtube can have optimistic updates, since the count is an estimate to begin with while commenting on the post could only be shown as sent when the server request is marked completed.

An alternative to custom `react-like` hooks

By now, we already have all the tools required for creating custom hooks using runes. It’s a straightforward vanilla solution with an uncanny resemblance to react hooks syntax. I’ve implemented a usePrevious hook which tracks the previous value of the state variable using runes.

Working version for the above example is present here. There’s a bunch of commonly used hooks implemented on this website in both javascript & typescript . Happy hunting :)

It is worth noticing that runes can only be used in files with extension svelte.{(ts, js)} .

What lies ahead?

Despite having discussed exhaustively about the properties of component state management and reactivity, there’s certain topics necessary to make your life easier working with svelte:

Managing global state using svelte stores (next part in the series, hopefully)
Updating parent state from child components leveraging $props & $bindable
Bypassing deep reactivity using $state.raw & $state.snapshot
Handling direct DOM mutations based on state updates using tick
Resetting component and it’s state using key blocks

I hope this article helped you understand the basics of runes and state management—and instilled some confidence to support your journey toward becoming a svelte wizard.

Feel free to comment on what you liked, disliked or hated. Or reach out directly on Twitter.

Footnotes

Vladimir Klepov Highly recommend his deep dive into svelte reactivity
Svelte Docs to get lost in the rabit hole of the framework
MDN Docs It's more than just documentation
XKCD Comics While Empericism was more apt for the article, one of my favorites is a take on the fragile nature of proprietary projects
Shymanta D, Dyutimitra S. The Yellow House is one of numerous psychological case studies, distinguished by its clean and concise presentation
UseRunes - Explore custom hooks

Nucleux

Tue, 24 Jun 2025 01:46:34 +0000

The Story Behind Nucleux

Nucleux emerged from a simple frustration: existing React state management solutions either require complex provider setups (like Context API) or cause unnecessary re-renders (like most global state libraries). After trying Redux, Zustand, Jotai, and building custom solutions, I realized developers needed something that combined atomic precision with organizational clarity.

How It Works

Nucleux uses atomic state management where each piece of state is independent. When you update an atom, only components subscribed to that specific atom re-render - no cascade effects, no provider hell.

class TodoStore extends Store {
  todos = this.atom([])
  filter = this.atom('all')
  
  addTodo(text) {
    this.todos.value = [...this.todos.value, { id: Date.now(), text }]
  }
}

function TodoApp() {
  const todoStore = useStore(TodoStore)
  const todos = useValue(todoStore.todos)
  
  return (
    <div>
      <button onClick={() => todoStore.addTodo('New task')}>
        Add Todo
      </button>
      <ul>
        {todos.map(todo => (
          <li key={todo.id}>{todo.text}</li>
        ))}
      </ul>
    </div>
  )
}

Key Features

Zero Providers: Use state anywhere without wrapping components
Atomic Updates: Only subscribed components re-render
Organized Architecture: Class-based stores group related state and methods
Built-in Persistence: Save to localStorage/AsyncStorage automatically
Dependency Injection: Stores can easily depend on other stores
Lightweight: Only 3.5KB gzipped
SSR Compatible: Works seamlessly with Next.js and server-side rendering

Three Powerful Hooks

useStore(StoreClass) - Access store methods

const todoStore = useStore(TodoStore)
todoStore.addTodo('New task')

useValue(atom | StoreClass, 'atomKey') - Subscribe to specific atoms

const todos = useValue(todoStore.todos)
// or
const todos = useValue(TodoStore, 'todos')

useNucleux(StoreClass) - Get everything at once

const { todos, filter, addTodo } = useNucleux(TodoStore)

Get Involved

Try it: npm install nucleux or check the live demo
Contribute: Visit GitHub for issues and feature requests
Documentation: Full guides at nucleux.dev

We're looking for contributors who understand React performance, state management patterns, and developer experience. Whether it's bug fixes, new features, or documentation improvements - all contributions are welcome!

How Layered Memoization in Nucleux v1.3.0 Eliminates React's Biggest Performance Pitfall

Tue, 24 Jun 2025 01:46:03 +0000

React applications slow down for one primary reason: unnecessary re-renders. You update a user's name, and suddenly your entire shopping cart re-renders. You toggle a modal, and your complex data table rebuilds itself. Sound familiar?

This cascade effect has plagued React developers for years, leading to complex optimization strategies with React.memo, useMemo, and useCallback. But what if your state management library could eliminate this problem entirely?

The Hidden Cost of State Updates

Consider this common scenario in a typical React app:

// Traditional approach - everything re-renders
function App() {
  const [user, setUser] = useState({ name: 'John', notifications: 0 })
  const [cart, setCart] = useState([])
  const [theme, setTheme] = useState('dark')

  // Changing user.name triggers re-renders in:
  // - UserProfile component
  // - Cart component (unnecessary!)
  // - ThemeToggle component (unnecessary!)
  
  return (
    <div>
      <UserProfile user={user} />
      <ShoppingCart cart={cart} />
      <ThemeToggle theme={theme} />
    </div>
  )
}

When user.name changes, React re-renders every component that receives any piece of this state, even if they don't use the changed data. This becomes exponentially worse as your app grows.

Atomic Updates: The First Step

Nucleux solves this with atomic state management - only components subscribed to specific atoms re-render:

class AppStore extends Store {
  user = this.atom({ name: 'John', notifications: 0 })
  cart = this.atom([])
  theme = this.atom('dark')
  
  updateUserName(name) {
    this.user.value = { ...this.user.value, name }
  }
}

function UserProfile() {
  const user = useValue(AppStore, 'user')
  // Only this component re-renders when user changes
}

function ShoppingCart() {
  const cart = useValue(AppStore, 'cart')
  // This NEVER re-renders when user changes
}

But even atomic updates have a subtle performance issue...

The Memoization Problem

What happens when you update a user object with the same values?

// This triggers a re-render even though nothing actually changed!
store.updateUserName('John') // Same name as before

React compares objects by reference, not content. Even if the data is identical, creating a new object triggers unnecessary updates.

Enter Layered Memoization

Nucleux v1.3.0 introduces layered memoization that intelligently prevents updates when values haven't actually changed:

Shallow Memoization (Default)

Perfect for primitive values and objects you replace entirely:

class CounterStore extends Store {
  count = this.atom(0) // Automatically uses shallow memoization
  
  increment() {
    this.count.value += 1 // Only updates when value actually changes
  }
}

Deep Memoization

Ideal for complex objects where you care about content, not reference:

class UserStore extends Store {
  profile = this.atom(
    { name: 'John', email: '*Emails are not allowed*', preferences: {...} },
    { memoization: { type: 'deep' } }
  )
  
  updateProfile(newProfile) {
    // Only re-renders if the content actually changed
    this.profile.value = newProfile
  }
}

Custom Memoization

For specialized comparison logic:

class ProductStore extends Store {
  product = this.atom(
    { id: 1, name: 'Laptop', price: 999.99, lastUpdated: Date.now() },
    {
      memoization: {
        type: 'custom',
        compare: (prev, next) => 
          prev.id === next.id && 
          prev.name === next.name && 
          prev.price === next.price
        // Ignores lastUpdated timestamp
      }
    }
  )
}

Real-World Performance Impact

Here's a before/after comparison in a typical e-commerce app:

Without Memoization:

User updates profile → 12 components re-render
Product price change → 8 components re-render
Cart item quantity update → 15 components re-render

With Layered Memoization:

User updates profile with same data → 0 components re-render
Product price change with same price → 0 components re-render
Cart update with identical items → 0 components re-render

Beyond Atoms: Memoized Derived State

Derived state benefits from memoization too:

class TodoStore extends Store {
  todos = this.atom([])
  filter = this.atom('all')
  
  // Won't recalculate if filtered result contains same items
  filteredTodos = this.deriveAtom(
    [this.todos, this.filter],
    (todos, filter) => todos.filter(t => t.status === filter),
    { type: 'deep' } // Compares array content, not reference
  )
}

The Bottom Line

Layered memoization transforms your React app's performance by:

Eliminating phantom updates - No re-renders when data hasn't actually changed
Optimizing derived state - Complex calculations only run when inputs truly differ
Reducing debugging complexity - Fewer unexpected re-renders to track down
Improving user experience - Smoother interactions and better responsiveness

The best part? It works automatically. Set your memoization strategy once, and Nucleux handles the intelligent comparisons behind the scenes.

Try It Yourself

Want to experience the performance difference? Check out the complete documentation to see how layered memoization can transform your React application's performance.

Nucleux v1.3.0 is available now on npm. Upgrade today and feel the difference intelligent memoization makes in your React applications.

The Role of State Management in Building Scalable Front-End Applications

Mon, 25 Nov 2024 01:11:12 +0000

Importance of state management concepts in Front-End

Today’s front-end applications are more complex and powerful than ever before. The days when the logic was handled solely on the back-end, with the front-end serving as a simple data display layer, are long gone. Modern applications are expected to deliver dynamic, interactive, and seamless user experiences, often requiring sophisticated data management. One essential tool for handling this complexity is state management.

State management allows developers to build scalable and maintainable applications by organizing and controlling data flows. For developers working with popular frameworks, there are ready-to-use solutions like Redux for React and NgRx for Angular. However, this article will focus on the general principles and concepts of state management, which apply to any tool or framework.

What is State Management: Delving into the theory

In simple terms, “state“ refers to the data at a particular moment in time — such as user information, UI state, or data retrieved from APIs. This data can either be local (specific to a component or group of components) or global (accessible throughout the entire application).

Local state is used within a particular component to manage its data independently. For instance, imagine a form where fields depend on values from other fields. To handle these dynamic relationships, the local state can be applied to simplify data management within that form. Conversely, the global state enables data sharing across the entire application. Take user settings, for example — preferences like theme settings or language choices that should be accessible from any page. Global state provides centralized access to this data, ensuring consistency across the app.

Without properly managing this data you are likely to get “spaghetti code“. Additionally, it will help you to reduce code duplication and enhance component communication.

Pillars of State Management: Core Concepts

Regardless of the tool or framework, some essential principles are critical to implementing effective state management.

Firstly, there’s the Single Source of Truth principle, which states that all data should be stored and updated in a single location. This approach simplifies data tracking and updates by ensuring there’s only one source for each piece of data, providing consistent access across the application. With centralized data handling, debugging becomes easier, especially in complex applications.

Another vital principle is Unidirectional Data Flow. This concept mandates that data flows in a predictable manner from a single source and is modified in a controlled way. This greatly reduces the potential for bugs, and provides a predictable structure, making the application’s behavior easier to understand and troubleshoot.

Finally, there’s the principle of Separation of Concerns, which recommends separating business logic from UI concerns. By doing so, state management keeps business logic — such as data handling and updates independent from the UI. Components can focus solely on displaying data, while complex state logic is handled separately. This modular approach leads to a codebase that’s easier to maintain and update.

These principles provide a foundation for any state management solution. Whether you choose an existing library or decide to build a custom solution, following these core ideas will help keep your application organized and scalable.

The Challenges of Unmanaged State: What can it cost to you

One of the most common problems is data inconsistency. When the state isn’t centrally managed, data inconsistencies frequently arise. Imagine a scenario where you’re editing content on the same page where it’s displayed. After making changes and pressing “Update“ or “Save“, you expect the displayed data to refresh. However, if there’s no centralized state, you might see outdated content until you refresh the entire page, creating confusion for a user.

Debugging also becomes difficult when the state is not centralized. Initially, tracing bugs and errors might seem manageable, but as the application grows, tracking the source of data and understanding where updates occur can quickly become a complex and time-consuming task.

Lastly, code duplication becomes almost unavoidable without centralized state management. When components independently manage related data, duplications are likely to arise. This can quickly bloat the codebase, making it harder to maintain and increasing the chances of introducing bugs.

When to Use State Management: Tips for Implementation

Not every application requires state management, so it’s crucial to evaluate your project’s needs. For simpler applications, such as a single landing page, state management might add unnecessary complexity. However, as soon as your application has shared data across multiple components or requires complex user interactions, state management becomes beneficial.

If your application has complex user flows — where data needs to be shared across different components or pages — then state management can help you improve maintainability. For simpler projects, though, it can be overkill.

If you determine that state management is necessary, start with a simple approach. Begin by managing the state locally within individual components and only scale up to a more comprehensive state management solution as the complexity of your application grows. Avoid overengineering early on; it’s best to let your solution evolve naturally alongside your app’s needs.

As you expand your state management, keep it as organized as possible. Avoid creating one large state object, as this can quickly become difficult to maintain. Instead, break your state into smaller, manageable sections that can be updated independently, helping keep your state clean and manageable.

Another valuable tip is to separate your business logic from the UI. Place business logic within your state management layer rather than in UI components. This makes your components easier to reuse, as they focus solely on displaying data rather than managing it. This separation also results in modular, testable code that’s easier to debug and extend.

Conclusion: Know your tools and needs

If your project is expanding, now is the time to evaluate whether your current approach to state management meets your needs. Start small and simple, but don’t hesitate to adopt a more structured solution as your app grows. Explore tools and practices that align with your project’s requirements, and experiment with different techniques to find what works best. The right state management approach will make your application more robust, scalable, and easier to maintain in the long run. Start integrating these principles today and see the positive impact on your development process and overall code quality!

Useful Links:
https://redux.js.org/
https://ngrx.io/guide/store/why