Coder Legion - Recent posts tagged react

What I've Been Improving Behind the Scenes

Sat, 31 Oct 2026 07:26:42 +0000

Over the past few weeks, I've been spending more time refining Galaxy Movies rather than adding entirely new features.

For anyone who hasn't come across it yet, Galaxy Movies is my movie and TV discovery project. It helps people find titles and check where they're streaming.

A few recent changes have made a noticeable difference to the experience.

Giving the watchlist a better starting point

One thing I wanted to improve was the empty watchlist experience.

Previously, a new user could open the app and immediately be greeted with an empty page. Now the empty state includes a trending section with titles that can be added directly to the watchlist.

The basic idea is to give users something to explore before they've saved anything.

{watchlist.length === 0 ? (
  <WatchlistEmptyState>
    <TrendingRail
      title="Start Here"
      onAdd={addToWatchlist}
    />
  </WatchlistEmptyState>
) : (
  <WatchlistGrid titles={watchlist} />
)}

It's a small change, but it gives people a much better starting point.

I added a progress bar for page transitions so there's better feedback when navigating around the app.

I also fixed an issue with streaming provider filters where search results could briefly appear before the provider lookup finished.

The important part is keeping the loading state visible until the provider lookup is complete.

if (isLoadingProviders) {
  return <SearchLoadingState />;
}

return (
  <MovieGrid movies={filteredMovies} />
);

This prevents users from seeing results that haven't been filtered yet.

Spending more time on the details

I've also been consolidating repeated UI elements into shared components. It's not the most exciting work to show off, but it makes future changes easier and keeps the interface more consistent.

Instead of maintaining separate versions of the same card rail across the app, shared components can handle the common layout.

<CardRail
  title="Trending Now"
  items={trendingTitles}
  renderItem={(title) => (
    <MovieCard
      key={title.id}
      movie={title}
    />
  )}
/>

On the SEO side, I revisited the sitemap to focus on pages that are more useful to search engines.

I also added a yearly streaming changes accumulator to preserve arrivals and departures by provider. This will make it possible to build yearly streaming recaps using data collected throughout the year.

What's next?

I'm still working on improving discovery and making Galaxy Movies more useful without adding unnecessary complexity.

Building a product independently means constantly deciding where time is best spent. Sometimes the most useful improvements aren't new features. They're the smaller fixes that make everything work better.

You can check out the latest version - https://www.galaxymovies.app

Source code is available - https://github.com/NickFasulo/galaxy-movies

If you're building a side project too, I'm curious how much of your development time goes toward new features versus improving what already exists.

Stop Syncing State With useEffect: 4 Bugs That Disappear When You Delete the Effect

Thu, 29 Oct 2026 10:55:28 +0000

Here is a pattern I see in almost every React codebase I read:

const [fullName, setFullName] = useState('');

useEffect(() => {
  setFullName(firstName + ' ' + lastName);
}, [firstName, lastName]);

It works. It also renders twice every time a name changes, shows a stale value for one frame, and is a bug waiting to happen when someone adds a third dependency and forgets to list it.

The fix is to delete the effect. Here are four cases where that is the right move.

Why These Effects Cause Bugs

An effect runs after React has painted the screen. So any state you set inside it means:

React renders with the old value and paints it.
The effect runs and calls setState.
React renders again with the new value.

The user can see step 1. That is the flicker. And every effect you add is another place where the dependency list can silently drift out of date.

Case 1: Derived Values

If you can calculate something from props or state you already have, do not store it:

// Before
const [fullName, setFullName] = useState('');
useEffect(() => {
  setFullName(firstName + ' ' + lastName);
}, [firstName, lastName]);

// After
const fullName = firstName + ' ' + lastName;

No state, no effect, no extra render, and it can never be out of sync, because it is recalculated every time.

The same goes for filtering and sorting:

// Before: two sources of truth
const [visible, setVisible] = useState(items);
useEffect(() => {
  setVisible(items.filter((i) => i.active));
}, [items]);

// After
const visible = items.filter((i) => i.active);

If the calculation is genuinely expensive, wrap it in useMemo. Measure first. For a few hundred items, plain code is fine.

Case 2: Resetting State When a Prop Changes

This is the one people struggle with most:

function Profile({ userId }: { userId: string }) {
  const [comment, setComment] = useState('');

  useEffect(() => {
    setComment(''); // reset when the user changes
  }, [userId]);

  return <textarea value={comment} onChange={(e) => setComment(e.target.value)} />;
}

When userId changes, the old comment shows for one frame, then clears. If you have several pieces of state, you need one reset line for each, and you will forget one.

The fix is the key prop:

function ProfilePage({ userId }: { userId: string }) {
  return <Profile key={userId} userId={userId} />;
}

function Profile({ userId }: { userId: string }) {
  const [comment, setComment] = useState('');
  return <textarea value={comment} onChange={(e) => setComment(e.target.value)} />;
}

When the key changes, React treats it as a different component: it throws away the old one, including all its state, and mounts a fresh one. Every piece of state resets, with no effect and no flicker. Remember this one, because it solves a whole category of "why is the old data still there" bugs.

Case 3: Logic That Belongs in an Event Handler

const [submitted, setSubmitted] = useState(false);

useEffect(() => {
  if (submitted) {
    sendOrder(cart);
    setSubmitted(false);
  }
}, [submitted, cart]);

return <button onClick={() => setSubmitted(true)}>Buy</button>;

This uses an effect as a delayed event handler. It is hard to follow, and it can fire again if cart changes while submitted is still true.

Put the logic where the event happens:

function handleBuy() {
  sendOrder(cart);
}

return <button onClick={handleBuy}>Buy</button>;

The rule of thumb: if something happens because the user did something, it belongs in an event handler. If it happens because the component appeared on screen, it can be an effect.

Case 4: Notifying a Parent

useEffect(() => {
  onChange(value);
}, [value, onChange]);

This calls the parent after the render, so the parent and child briefly disagree, and it can trigger extra renders in both. Call the parent in the same handler that changes the value:

function handleChange(next: string) {
  setValue(next);
  onChange(next);
}

Both updates are batched into one render.

So When Is an Effect Right?

Effects are for synchronizing with something outside React:

Subscribing to a browser event, a WebSocket or a timer
Starting and cleaning up a third-party widget
Sending an analytics event because a page was shown
Fetching data on mount (with a cleanup, so a slow response cannot overwrite a newer one)

That last point deserves care, because an effect that fetches can show old results if responses arrive out of order. I wrote about that race condition in a separate article about search inputs. If your library offers one, a data-fetching library or a framework's server data loading removes the need for the effect altogether.

Quick Checklist Before You Write an Effect

Question	If yes
Can I calculate it from existing props or state?	Calculate it during render
Am I resetting state when a prop changes?	Use `key`
Does it happen because the user did something?	Put it in the event handler
Am I telling the parent something changed?	Call the parent in the handler
Am I connecting to something outside React?	An effect is right

The Rule

An effect that only calls setState based on other state or props is almost always a bug waiting to happen. Compute it during render, reset with key, and handle events in handlers.

Quick audit: search your project for useEffect and read the body of each one. Count how many do nothing but set state. Each one is a candidate for deletion, and the component usually gets shorter and faster when you remove it.

If you build with Next.js and React and want a clean starting point, you can browse my templates on pixelanas.com.

Get the templates: https://pixelanas.gumroad.com

What is the strangest useEffect you have ever found in a codebase? Share it in the comments.

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Mastering the Native Drag and Drop API in React

Thu, 29 Oct 2026 10:24:46 +0000

What is the Drag and Drop API?

The Drag and Drop API is a built-in browser capability that allows web applications to make elements on a webpage interactive through dragging and dropping. Instead of forcing users to click buttons or select items from drop-down menus, this browser feature enables users to click on an item, hold down the mouse button or touchscreen, move the item across the screen, and release it over a designated area. The browser automatically tracks the movement coordinates, mouse state, and transfer data throughout the entire process.

At its core, this API exposes a set of event listeners—hooks provided by the browser to run code when specific interactions happen—that fire as an item is picked up, dragged over drop targets, and finally released.

A Real-Life Analogy: The Corkboard and Sticky Notes

Imagine you have a physical corkboard on your office wall divided into three columns: "To Do," "In Progress," and "Done." Each task is written on a physical sticky note.

When you decide to start working on a task, you place your finger on a sticky note in the "To Do" column, lift it off the board, hover it across the room over to the "In Progress" column, and press it onto the corkboard. During this entire movement, you are carrying both the physical note and the context of what task is written on it. The board itself does not need to send a letter to an assistant asking to move the note; your hands handle the position, while the board simply provides the surface to receive it.

This is precisely how the Drag and Drop API works on a screen. The draggable element acts as the sticky note, the data payload attached to the drag event acts as the text on the note, and the drop target acts as the receiving column on the corkboard.

Why It Matters in Tech Today

In modern web engineering, user experience (UX) directly impacts engagement and product adoption. Complex interfaces like Kanban boards (such as Trello or Jira), file management dashboards (like Google Drive), and custom page builders (like Wix or Squarespace) rely heavily on drag-and-drop interactions to make software feel natural and tactile.

Engineers use the native Drag and Drop API to create fluid interfaces without dragging down performance. Without this browser-native API, software developers would have to write complex, prone-to-bugs math scripts that manually track mouse pixel coordinates on every screen frame. Utilizing the browser's built-in events prevents memory leaks, reduces CPU usage, and saves hundreds of hours of manual positioning logic.

Furthermore, when building file uploading components, this API allows users to drag files straight from their computer's desktop into a browser window, bridging the gap between desktop operating systems and web applications.

Building a Drag and Drop Task List in React

Below is a simple React component that uses the browser's native Drag and Drop API to move tasks between two lists.

import React, { useState } from 'react';

export default function TaskBoard() {
  const [tasks, setTasks] = useState([
    { id: '1', title: 'Design Database Schema', status: 'todo' },
    { id: '2', title: 'Build Express Route', status: 'todo' },
  ]);

  // Triggered when the user starts dragging an item
  const handleDragStart = (event, id) => {
    event.dataTransfer.setData('text/plain', id);
  };

  // Necessary to allow dropping into a container
  const handleDragOver = (event) => {
    event.preventDefault();
  };

  // Triggered when the item is dropped
  const handleDrop = (event, targetStatus) => {
    event.preventDefault();
    const taskId = event.dataTransfer.getData('text/plain');
    
    setTasks((prevTasks) =>
      prevTasks.map((task) =>
        task.id === taskId ? { ...task, status: targetStatus } : task
      )
    );
  };

  return (
    <div style={{ display: 'flex', gap: '20px', padding: '20px' }}>
      {['todo', 'done'].map((status) => (
        <div
          key={status}
          onDragOver={handleDragOver}
          onDrop={(e) => handleDrop(e, status)}
          style={{
            width: '200px',
            minHeight: '200px',
            border: '2px dashed #ccc',
            padding: '10px',
          }}
        >
          <h3>{status.toUpperCase()}</h3>
          {tasks
            .filter((task) => task.status === status)
            .map((task) => (
              <div
                key={task.id}
                draggable
                onDragStart={(e) => handleDragStart(e, task.id)}
                style={{
                  padding: '10px',
                  marginBottom: '8px',
                  backgroundColor: '#4A90E2',
                  color: '#fff',
                  cursor: 'grab',
                }}
              >
                {task.title}
              </div>
            ))}
        </div>
      ))}
    </div>
  );
}

Key Takeaway

The Drag and Drop API transforms rigid web interactions into intuitive, tactile experiences by letting the browser perform the heavy lifting of mouse tracking and state transfers. Mastering this native web feature enables engineers to craft modern, highly interactive web applications with minimal overhead and zero external dependencies.

Enjoyed this breakdown? Support my open-source work on Buy Me a Coffee or explore react-hook-lab!

Originally published on my blog. You can read the alternative breakdown here.

Redux Refactoring Playbook: From Action-Types Soup to RTK Query — Without Rewriting the App

Thu, 29 Oct 2026 08:51:02 +0000

Every React codebase of a certain age has one: the legacy Redux store. Hundreds of thunk actions, manually managed loading flags, per-feature cache invalidation, and a polling timer per data type pulling the full payload whether anything changed or not.

Ours lived under a real-time monitoring dashboard tracking 1,000+ GSM installations at Orange Romania — and by the time we migrated to RTK Query, the story ended with dashboard responsiveness up ~40%, telemetry traffic down 20%, and "frozen dashboard" complaints down 30%.

The previous article told that performance story. This one is the refactoring mechanics: in what order things moved, which decisions unlocked the next one, and the one rule that made a no-rewrite migration possible.

Rule 1 — Strangle, don't rewrite

The store wasn't broken in one place; it was broken everywhere: a switch-case reducer file nobody fully read, five middleware, isLoading / isRefreshing / hasError flag families per resource, and component-level useEffect chains firing fetches in a specific order "because it worked."

A big-bang rewrite was a non-starter: the dashboard was used every day by operations teams. So the rule was:

One page migrates per PR. The rest of the app keeps running on the legacy store untouched.

Redux makes this possible because combineReducers is natural strangler scaffolding:

const rootReducer = combineReducers({
  // new pages live here
  ordersApi: ordersApi.reducer,          // RTK Query
  invoices: invoicesSlice.reducer,       // RTK slice
  // legacy pages keep their ducks until their turn
  legacyTelemetry: legacyTelemetryReducer, // switch-case reducer, retired last
});

Each migration PR carried its own before/after render counts and INP p75 from a fixed scripted interaction. If the numbers moved the wrong way, the PR didn't merge — refactoring without a measurement loop is just rewriting with extra steps.

The code was the easy half. The pitch mattered as much: I sold this as risk control, not cleanup. Every PR shippable alone meant no feature-freeze window that anyone had to buy; the cost I did have to name up front was the parallel-store tax: two stores side by side meant duplicated fixtures and slower reviews while a slice waited for its turn. Leadership signed off because every migration PR ended with a measurement, not with the word "done". One more org-side lesson: the change-flag contract needed a backend buy-in, and I opened that conversation politely, late. Open it on day one; that delay cost us a month.

Rule 2 — Selectors are the API. Freeze them first.

The trick that removed 90% of the migration risk: components never touched state shapes directly.

The legacy store had selector functions (selectOrders, selectNodeById, selectIsNodeActive). Before migrating anything, we froze them as the contract and then made each selector a re-export shim that could source data from either world:

// selectors/orders.js
import { legacyOrders } from './legacySelectors';
import { useGetOrdersQuery } from '../api/ordersApi';

export function useOrders(selector) {
  const { data, isFetching } = useGetOrdersQuery();
  // legacy pages keep working against the same contract
  return useMemo(() => selector(data ?? legacyOrders()), [data, selector]);
}

(Simplified — the real shims carried fallbacks during the window when a page's data half-lived in the old store. The point is the shape: the component-facing API never moved, only its plumbing did.)

Result: a "migration PR" changed the data layer under a page, not forty components over it. That made page-by-page migration realistic rather than a nice idea.

Rule 3 — Kill loading flags with RTK Query, not with better thunks

There was a middle step available: keep the thunks and clean them up. I'd have kept every race. Request A finishing after request B silently overwrote fresher data, and that was our most common production bug, because each flag family carried its own private version of it.

So server state moved into RTK Query, and components declare what they need, not how to fetch it:

// before: every call site, every page
dispatch(fetchOrders());
// + component-local: isLoading, ordersError, lastRefreshed...

// after: the component declares the requirement
const { data: orders, isLoading } = useGetOrdersQuery(undefined, {
  pollingInterval: 0, // see Rule 4 — we don't poll blindly
});

Seventeen loading-flag families disappeared in this step. After it, a component tracking its own fetch lifecycle existed in exactly one place: a page that legitimately needed manual control.

Rule 4 — Polling moves from timers to tags

Old polling: one setInterval per data type, full payload every tick. On a dashboard watching 1,000+ nodes, that's thousands of identical requests an hour and constant re-render churn over data that hadn't changed.

New polling is no polling — it's a change-flag endpoint: a ten-byte version string the dashbo
ard polls on a timer, and the real data refetches when that string actually changes.

export const api = createApi({
  reducerPath: 'api',
  baseQuery: fetchBaseQuery({ baseUrl: '/api' }),
  tagTypes: ['Nodes'],
  endpoints: (build) => ({
    nodesChanged: build.query<{ version: string }, void>({
      query: () => 'nodes/changed',       // returns a version string only
    }),
    getNodes: build.query<NodeState[], void>({
      query: () => 'nodes',
      providesTags: ['Nodes'],
    }),
    // refetch tagged data only when the flag version changes:
    // a listener middleware polls `nodesChanged` (cheap, ~10 lines) and,
    // on version change, dispatches api.util.invalidateTags(['Nodes'])
  }),
});

const flagListener = createListenerMiddleware();

flagListener.startListening({
  predicate: (action, currentState, previousState) => {
    // the version lives in RTK Query's own cache, so the store
    // snapshot gives us both "current" and "what it used to be"
    const cur = nodesChanged.select()(currentState)?.data;
    const prev = nodesChanged.select()(previousState)?.data;
    return cur != null && cur !== prev;
  },
  effect: (action, api) => {
    api.dispatch(api.util.invalidateTags(['Nodes']));
  },
});

// the flag endpoint itself: cheap on purpose
//   query: () => 'nodes/changed',   // returns ~10 bytes: a version string
//   pollingInterval: 5000,

What happens on an update, end to end: the version goes into the cache and
predicate sees it differ from the previous snapshot, invalidateTags marks
every tagged entry stale without removing it (the screen keeps the old
data), mounted subscribers immediately refetch — deduplicated to one request
per endpoint+args no matter how many components listen — and one re-render
lands the new data. A component sees isLoading: false, isFetching: true
during that window, which is why nothing flashes. If the flag endpoint dies,
data simply goes stale until the next successful tick; nothing breaks. If
nodes changed five times between two ticks, one refetch covers it: the
version is a snapshot of "what is true now", not an event queue.

What stayed in Redux core

A mistake we avoided (mostly): RTK Query is for server state only. UI-owned state — selected node, filter panel state, column layout, wizard steps — stayed in plain createSlice. Migrating that into queries would have replaced a working pattern with a worse one.

The end state: slices for decisions, RTK Query for data, zero custom cache code, zero hand-rolled loading flags.

The honest ledger

From the published case, measured as perceived dashboard responsiveness (how fast fresh data lands after a change, without UI-thread churn):

Dashboard responsiveness: +~40%
"Frozen dashboard" complaints: −30%
REST telemetry traffic: −20%

What I can't give you is a LOC table with a precise count — we deleted more code than we wrote every migration PR, and by the end the store directory had visibly halved; I kept no exact tally, and a made-up precision here would be dishonest.

What I'd do differently

Start with RTK Query for any new page. Half the migration tail was legacy thunks for features that could have been endpoints from day one.
Freeze selectors before touching anything. The component-facing API is the migration's unit of safety.
Measure per PR, not per epic. The scripted interaction + INP check cost minutes per PR and caught two regressions a "it looks fine" test never would.
Write the change-flag backend contract early. The polling redesign was the single biggest win and it needed a backend buy-in — politeness about it cost us a month.

Your refactoring checklist

Inventory actions/thunks/loading flags — count them, this is your "before" baseline.
Freeze selectors as the component-facing contract.
Add RTK Query via combineReducers alongside the legacy store.
Migrate one page per PR; measure INP p75 + render count on a fixed interaction.
Server state → endpoints with tags; UI state stays in slices.
Replace timers with a change-flag contract before touching fetch logic.
Delete: action-type strings, flag families, custom cache code. The deletion count is the score.

The performance numbers come from the same production system as my earlier piece, A 40% Faster Fault-Detection Pipeline Without WebSockets — that one tells the polling-protocol story; this is the data-layer refactoring around it.

LifeOps Project (Part 6): 360° Analytics Dashboard with Multi-Dimensional Filtering, Recharts and Co

Wed, 28 Oct 2026 08:18:20 +0000

In Part 5 of our engineering series, we achieved a major milestone: deploying the entire LifeOps architecture 24/7 in production at zero cost ($0/month) by combining Netlify, Render, and Supabase, optimizing mobile ergonomics for smartphones, and installing the app as a native PWA.

However, once you start logging dozens of daily activities (workouts, bike rides, books read, movies watched, and Kanban tasks), a critical analytical challenge emerges: data without analysis lacks operational value.

Having 40 or 50 records in a PostgreSQL database is of little use if opening the dashboard doesn't immediately answer operational questions such as:

“How many kilometers did I run this month compared to last month?”
“What percentage of my training went into sprint intervals versus long endurance runs?”
“How has my daily consistency evolved, and what is my current active day streak?”
“How can I filter exclusively by Running to inspect average pace and calories burned without mixing in gym workouts or movies?”

In this sixth installment, we tackle the full evolution of the 360° Analytics Dashboard, addressing both the deterministic client-side aggregation design and the most notorious UX challenge of zero-cost serverless infrastructure: cloud container sleep periods (cold-starts).

💡 Try the analytics live: You can test the new 360° Dashboard with interactive data in Sandbox mode at https://datalaria.com/apps/lifeops/#/?mock=true&lang=en or log in with your Supabase account at https://datalaria.com/apps/lifeops/#/?lang=en.

1. Architecture Decision: External BI (Grafana / Metabase) vs. Native React Engine (ADR-013) ⚖️

When planning advanced charts and timeframe filters, the first engineering instinct is often to reach for established Business Intelligence tools like Grafana, Metabase, or Apache Superset. However, evaluating our requirements against our project constraints led to architectural decision ADR-013:

Evaluation Factor	External BI Tool (Grafana / Metabase)	Native React 19 + Recharts 3.10 Engine (Our Choice)
Multi-Tenant Security (RLS)	❌ Requires static direct database connection. Passing individual Supabase Auth JWTs requires expensive Enterprise licenses or custom proxy tokens.	✅ Perfect Isolation: consumes secure user-scoped REST endpoints protected by Row-Level Security (`auth.uid() = user_id`).
Infrastructure Cost	❌ Requires a separate container running 24/7 with dedicated RAM, or paid cloud plans.	✅ $0.00/month: compiles directly into the Netlify static bundle.
Sandbox Demo Mode (`?mock=true`)	❌ Impossible to feed an external iframe using in-memory mock state.	✅ 100% Compatibility: runs instantly with deterministic synthetic data.
Filter Latency	⚠️ Every click triggers a remote SQL round-trip to the cloud.	✅ 0 ms: the timeframe dataset filters in client memory using pure `useMemo` hooks.
Mobile UX & Aesthetics	⚠️ Visual disconnect from Glassmorphism Dark Mode and nested iframe scroll friction on mobile.	✅ Unified Design: seamless responsive layout tailored to our design system.

Data Flow Architecture

API Layer: FastAPI REST API / Supabase PostgreSQL (GET /api/v1/activities/details?limit=200).
Local Cache: Stale-While-Revalidate (SWR) cache in localStorage (lifeops_swr_v1:<user_id>).
Client Engine: Deterministic Client Analytics Engine (lib/analyticsEngine.js).
Control Bar: Timeframes (7D, 30D, Month, 90D, Year), period comparisons (vs. prev.), and category/subcategory drill-downs.
Visual Suite: 4 dynamic KPI cards with Δ%, multi-metric ComposedChart time-series, PieChart donut breakdowns, and a 16-week consistency heatmap.

2. Multi-Dimensional Cascading Filters & Period-over-Period Deltas ⏱️📊

The cornerstone of the new experience is the Analytics Control Bar, enabling three levels of analytical exploration without page reloads:

A. Timeframe Resolution

The engine supports five time horizons powered by the deterministic resolveTimeWindows() function:

7 Days (week): Rolling last 7 days vs. immediately preceding 7 days.
30 Days (month): Rolling last 30 days vs. immediately preceding 30 days.
By Month (calendar_month): Dynamic month selector (January to December) and year, compared against the preceding calendar month.
90 Days (quarter): Rolling last 90 days aggregated into weekly buckets.
By Year (year): Full annual overview with 12 monthly buckets vs. prior year.

B. Invariant INV-8: Safe Percentage Delta Calculation (Δ%)

To compare current performance (V_curr) against the previous period (V_prev) without division-by-zero errors when starting a new discipline:

If V_prev = 0 and V_curr = 0 → Δ% = 0% (Stable).
If V_prev = 0 and V_curr > 0 → Δ% = +100% (Baseline creation).
In any other case → Δ% = round(((V_curr - V_prev) / V_prev) * 100).

export function computeDelta(currentVal, prevVal, unit = '', language = 'en') {
  const curr = Number(currentVal) || 0;
  const prev = Number(prevVal) || 0;
  const vsLabel = language === 'es' ? 'vs. ant.' : 'vs. prev.';

  if (prev === 0 && curr === 0) {
    return { positive: true, deltaPct: 0, text: 'Stable (0% vs. prev.)' };
  }
  if (prev === 0 && curr > 0) {
    return { positive: true, deltaPct: 100, text: `+100% (+${curr}${unit} ${vsLabel})` };
  }

  const diff = curr - prev;
  const pct = Math.round((diff / prev) * 100);
  const sign = diff >= 0 ? '+' : '';
  return {
    positive: diff >= 0,
    deltaPct: pct,
    diff,
    text: `${sign}${pct}% (${sign}${diff.toFixed(1)}${unit} ${vsLabel})`,
  };
}

3. The Visual Suite with Recharts: Contextual KPIs, Time-Series & Donut Charts 📈🍩

Selecting a category or drilling down into a subcategory (for example, filtering by Sport ➔ Running) dynamically updates the entire dashboard:

4 Contextual KPI Cards:
- In Sport: adapt metrics to the selected discipline:
  - Sessions: workout count with Δ% badge and personal bests (PB).
  - Distance: cumulative mileage and average km per session.
  - Time & Pace: active duration and average pace (min/km in running or km/h in cycling).
  - Calories & Effort: calories burned, average heart rate (bpm), and elevation gain (+m).
Multi-Metric Time-Series Chart (ComposedChart):
- Renders current period bars color-coded by category and overlays a dashed trendline of the previous period when the ⇄ Compare vs. prev. toggle is active.
- Built-in metric switcher: toggle on the fly between Sessions, Distance (km), Calories (kcal), Duration (h), or Elevation Gain (m).
Subcategory Distribution (PieChart Donut):
- Displays percentage and absolute shares for each activity type. Clicking any slice or legend item applies an automatic drill-down into that subcategory.

4. 16-Week Consistency Daily Heatmap (Strava / GitHub Style) 🔥🗓️

Habit formation and athletic progression rely on consistency. To provide clear visual accountability, we built a 112-day grid (16 weeks × 7 days, Monday to Sunday):

The algorithm evaluates daily activity volume across 5 intensity tiers (level-0 to level-4) and computes in real time:

Active days during the evaluated window.
Current active streak: counting consecutive active days backwards from today or yesterday.
All-time best streak.

5. Overcoming the Free-Tier Cloud UX Challenge: Cold-Start Mitigation ⚡🛡️

Deploying full-stack web applications on free cloud tiers (such as Render.com's Free Web Service) introduces an unavoidable reality: the container sleeps after 15 minutes of inactivity.

When a user visits after several hours, the initial request takes 20 to 40 seconds while the virtual machine boots. In early versions, this lag produced a terrible UX: users saw blank charts and KPI cards showing 0, leading them to believe their data was lost or deleted.

To eliminate this friction while staying strictly within our $0.00/month budget, we engineered a 3-layer mitigation system:

Layer 1: Silent Pre-Warming (`wakeUpServer`)

The moment the browser loads the SPA inside AuthContext.jsx—before the user even finishes entering credentials or navigating to the Dashboard—a non-blocking background fetch pings /health. This gives the container a 5-to-10 second head start to spin up.

Layer 2: User-Scoped Stale-While-Revalidate (SWR) Local Cache

Every read request (GET /api/v1/activities/details, /tasks, /stats/dashboard) is cached in localStorage under a strict user-prefixed key (lifeops_swr_v1:<user_id>:<endpoint>).

On subsequent visits, cards and charts hydrate in under 10 milliseconds (effectively 0 ms).
The user sees their data immediately while background network calls fetch fresh updates.
Any write operation (POST, PATCH, DELETE) automatically invalidates the local cache to guarantee consistency.

If a user accesses the app from a clean browser and must wait through a cold start:

Never show misleading zeros: KPI cards display waiting indicators (···) instead of 0.
Transparent Status Banner: displays an animated spinner, live elapsed seconds counter (0s, 1s, 2s...), visual progress bar, and active phase badges:
- ✓ Authenticated Session (Supabase Auth)
- ⟳ Waking API Engine on Render Cloud
- ⏳ Hydrating Activities & 360° Analytics
If the wait exceeds 4 seconds, the banner explicitly explains that the free cloud container is spinning up and that all data is 100% safe.
Automatic Timeframe Fallback: if the query returns activities but none fall within the last 30 days (e.g. after a vacation), the dashboard automatically switches to 90 Days or By Year so charts appear populated immediately.

6. Conclusions & Links 🚀

With this update, LifeOps evolves from a plain activity logger into a full personal operations intelligence system. Combining deterministic client-side analytics with a resilient cold-start mitigation architecture proves that it is entirely possible to build fast, secure, and visually stunning software on a $0.00/month infrastructure bill.

🎮 Deployed Web App: https://datalaria.com/apps/lifeops/
🕹️ Interactive Sandbox Mode (No Registration): https://datalaria.com/apps/lifeops/#/?mock=true&lang=en
📋 Official LifeOps Technical Overview: https://datalaria.com/en/apps/lifeops/

If you enjoyed this technical breakdown, explore more open engineering articles and quantitative apps at www.datalaria.com.

You Upgraded to Next.js 15 and Your Site Got Slower. The Caching Defaults Flipped

Tue, 27 Oct 2026 16:13:23 +0000

You upgrade from Next.js 14 to 15. The app compiles, the tests pass, nothing visibly breaks. A week later your database bill is higher, your pages feel slower, and your Time to First Byte graph has a step in it that lines up exactly with the deploy.

Nothing is broken. Something that used to happen for free stopped happening.

What Changed

In Next.js 14, data fetching was cached by default. A fetch in a Server Component ran once, the result was stored, and later requests reused it. You had to opt out of caching.

In Next.js 15, the default flipped. Per the upgrade notes:

fetch requests are no longer cached by default.
GET route handlers are no longer cached by default.
The client-side router cache no longer holds page segments between navigations by default.

So code you wrote once and never touched now behaves differently:

// app/products/page.tsx
export default async function ProductsPage() {
  const res = await fetch('https://api.example.com/products');
  const products = await res.json();
  return <ProductList products={products} />;
}

On 14, this fetched the data once and served the page from cache. On 15, every visitor triggers the API call, and because the page now depends on data fetched at request time, the route is rendered dynamically.

Why It Is Easy to Miss

Nothing errors. The code is valid. It just does more work.
Dev mode hides it. In next dev, nearly everything is rendered per request anyway.
The slowdown is gradual. With low traffic, an extra API call per request is invisible. It shows up when the traffic does.
Third-party limits bite later. If the API you call has rate limits or per-request billing, you find out from the invoice.

How to See It in 30 Seconds

Run a production build and read the route table at the end:

next build

Route (app)
┌ ○ /                 (Static)
├ ƒ /products         (Dynamic)
└ ƒ /blog/[slug]      (Dynamic)

○ means the page is pre-rendered once at build time. ƒ means it runs on the server for every request. A page that used to be static and is now ƒ is exactly what this upgrade can cause. Compare the table before and after the upgrade.

Fix 1: Cache One Request on Purpose

const res = await fetch('https://api.example.com/products', {
  cache: 'force-cache',
});

This restores the old behavior for that single request. Use it for data that does not change per user and rarely changes at all.

Fix 2: Cache With an Expiry

Most data is not permanent, just slow-changing. Revalidate it on a timer:

const res = await fetch('https://api.example.com/products', {
  next: { revalidate: 3600 }, // seconds
});

Visitors get the cached copy, and after an hour the next request refreshes it in the background. This is the right default for product lists, blog posts and prices.

Fix 3: Set It Once for the Whole Page

If several fetches on a page should share the same freshness, declare it at the route level:

// app/products/page.tsx
export const revalidate = 3600;

Everything that page renders is treated as cacheable for an hour, without repeating options on each call.

Fix 4: Route Handlers Need Their Own Opt-In

A GET route handler that returns the same data for everyone used to be cached automatically. Now you must say so:

// app/api/products/route.ts
export const dynamic = 'force-static';

export async function GET() {
  const products = await getProducts();
  return Response.json(products);
}

Without that line, the handler runs on every request.

The Part People Forget: Your Database Was Never Covered

Here is the subtle thing. The fetch cache only ever applied to fetch. If you read from MongoDB or Postgres directly with an ORM, this change did not touch those calls. Depending on whether the page used request data such as cookies, it was either rendered once at build time with the data frozen in, or rendered on every request. Neither is controlled by the fetch cache, so check your build table for those pages too.

To cache a database call at runtime, wrap it:

import { unstable_cache } from 'next/cache';

const getProducts = unstable_cache(
  async () => Product.find().lean(),
  ['products'],
  { revalidate: 3600, tags: ['products'] }
);

The tags option lets you clear that cache on demand with revalidateTag('products') after an edit. I wrote about why revalidateTag appears to do nothing when the data is not tagged in the first place. Newer Next.js versions keep moving toward explicit opt-in caching, so check the docs for the version you are on before copying any of this.

Should You Cache Everything Again?

No. The new default exists because stale data surprised people. Show a user their own cart, balance or notifications from a shared cache and you have a bug, or a data leak.

Data	Choice
Public, rarely changes (marketing pages, docs)	Cache it, long expiry
Public, changes often (product list, prices)	Cache with a short `revalidate`
Per-user (dashboard, cart, account)	Do not cache
Admin views	Do not cache

The Rule

When a framework changes a default, your old code changes behavior without a single line changing. After any major upgrade, run next build before and after and compare which routes are static (○) and which are dynamic (ƒ). Then opt back in on purpose, for the data that deserves it.

Slow server responses hurt the metrics Google measures. I break those down in plain language in my guide to Core Web Vitals, and if you want a Next.js starting point, you can browse my templates on pixelanas.com.

Get the templates: https://pixelanas.gumroad.com

Did a framework upgrade ever quietly change your app's behavior? Tell me what it was in the comments.

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

How to Build a Real Time Activity Log for Your Web App

Tue, 27 Oct 2026 06:15:00 +0000

Modern web applications generate a continuous stream of user activities. Users log in, update their profiles, create records, upload files, change permissions, and perform many other actions throughout the day. In a small application, tracking these activities manually may seem manageable. However, as an application grows, understanding who did what, when an action occurred, and what changed becomes increasingly important.

This is where a real-time activity log becomes valuable.

A real-time activity log records important events within an application and makes them available to users, administrators, or support teams as they happen. Instead of searching through scattered server logs or asking users to explain what happened, developers can provide a centralized timeline of meaningful actions.

For example, a project management application might display the following activities:

Sarah created a new project.
Michael updated the project deadline.
David uploaded a document.
Sarah invited a new team member.
An administrator changed a user's permissions.

These events help teams understand application activity, investigate problems, and collaborate more effectively.

In this article, we will explore how to design and build a real-time activity log using React, Python, FastAPI, PostgreSQL, and WebSockets. We will cover database design, event recording, real-time updates, security, performance optimization, and deployment considerations.

1. Understanding Real-Time Activity Logs

Before writing code, it is important to understand what an activity log does and how it differs from ordinary application logging.

Traditional application logs are primarily designed for developers and infrastructure teams. They record technical information such as exceptions, failed database connections, HTTP errors, and performance problems.

An activity log focuses on meaningful actions performed by users or systems.

For example:

Technical log: POST /api/projects returned status 201.
Activity log: Sarah created the project "Website Redesign".

Both records may describe the same operation, but they serve different purposes.

Common use cases

Real-time activity logs are useful in many applications.

Project management platforms: Track task creation, assignments, comments, and deadline changes.

E-commerce applications: Record order updates, refunds, inventory changes, and administrative actions.

CRM systems: Track customer record updates, sales activities, and changes to lead ownership.

Financial dashboards: Maintain auditable records of important account operations.

Administrative panels: Show user logins, permission changes, configuration updates, and security events.

A well-designed activity log should answer three fundamental questions:

Who performed the action?
What action occurred?
When did the action happen?

Depending on the application, it may also record the affected resource, the previous and updated values, the source of the action, and the result.

2. Choosing the Technology Stack

Our example uses a stack that supports structured data, asynchronous APIs, and live browser updates.

Frontend: React

React renders the activity timeline and updates the interface when new events arrive. It can connect to a WebSocket endpoint and display incoming messages without requiring a complete page refresh.

Backend: Python and FastAPI

FastAPI handles authentication, validates incoming requests, records activities, and exposes endpoints for retrieving historical events. Its WebSocket support allows the backend to communicate with connected browsers.

Database: PostgreSQL

PostgreSQL stores activity records permanently. It supports relational queries, indexes, transactions, and pagination, making it suitable for an activity timeline.

Real-time communication: WebSockets

WebSockets establish a persistent connection between the browser and server. After a new activity is committed to the database, the backend can publish an event to authorized connected clients.

Optional infrastructure: Redis

For applications running multiple backend instances, Redis Pub/Sub or a durable message broker can distribute events between servers. Redis is not required for a single-instance prototype.

The architecture looks like this:

User performs an action
          |
          v
React frontend
          |
          v
FastAPI endpoint
          |
          v
Business operation + database transaction
          |
          v
PostgreSQL activity record
          |
          v
Event publisher
          |
          v
WebSocket connection
          |
          v
React activity timeline

The essential principle is that the database remains the source of truth. WebSockets deliver updates quickly, but clients should be able to retrieve historical events from the database if they disconnect.

3. Designing the Activity Log Database

A reliable activity log starts with a clear database schema. Each record should contain enough information to explain an event without storing unnecessary sensitive data.

We can create an activity_logs table with the following fields:

Field	Purpose
`id`	Unique event identifier
`actor_id`	User or system responsible for the action
`action`	Type of activity performed
`entity_type`	Type of affected resource
`entity_id`	Identifier of the affected resource
`description`	Human-readable event summary
`metadata`	Additional structured event details
`created_at`	Timestamp when the event was recorded

The metadata field can use PostgreSQL's JSONB type. This makes it possible to store flexible information without creating a new database column for every event type.

For example, a project update could contain:

{
  "field": "deadline",
  "old_value": "2026-11-10",
  "new_value": "2026-11-15"
}

Avoid storing passwords, authentication tokens, payment card details, or unnecessary personal information in event metadata.

Creating the database table

A simple PostgreSQL migration might look like this:

CREATE TABLE activity_logs (
    id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    actor_id BIGINT NULL,
    action VARCHAR(100) NOT NULL,
    entity_type VARCHAR(100),
    entity_id VARCHAR(100),
    description TEXT NOT NULL,
    metadata JSONB NOT NULL DEFAULT '{}'::jsonb,
    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

CREATE INDEX idx_activity_logs_created_at
    ON activity_logs (created_at DESC, id DESC);

CREATE INDEX idx_activity_logs_actor
    ON activity_logs (actor_id, created_at DESC, id DESC);

CREATE INDEX idx_activity_logs_entity
    ON activity_logs (
        entity_type,
        entity_id,
        created_at DESC,
        id DESC
    );

These indexes support common queries, including retrieving recent events, filtering by actor, and viewing the history of a specific resource.

In a multi-tenant application, include a tenant_id or equivalent ownership identifier and design indexes around the actual access patterns.

The example uses a nullable actor_id because some events may be generated by scheduled jobs or automated processes. In a production database, define appropriate foreign keys and retention rules according to your user-deletion and audit requirements.

4. Defining Consistent Activity Events

A major challenge is maintaining consistency across different parts of an application.

Without a shared event structure, one feature might record "user updated" while another records "profile_changed". The frontend then becomes responsible for understanding many inconsistent formats.

A better approach is to define a standard event contract.

For example:

{
  "id": "evt_1024",
  "actor": {
    "id": 42,
    "name": "Sarah"
  },
  "action": "project.updated",
  "entity_type": "project",
  "entity_id": "project_15",
  "description": "Sarah updated the project deadline",
  "metadata": {
    "field": "deadline"
  },
  "created_at": "2026-10-27T06:30:00Z"
}

The action name should describe the event in a predictable way. Names such as project.created, project.updated, task.assigned, and user.permission_changed are easier to maintain than arbitrary descriptions used as event identifiers.

Separate the machine-readable action from the human-readable description.

The action supports filtering, analytics, and integrations. The description is intended for display and can be localized later.

Also, distinguish between the person who performed an action and the person or object affected by it. For example, an administrator may change another user's permissions.

5. Building the FastAPI Activity Service

The backend should provide reusable functions for creating and retrieving activities. Individual business endpoints should call these functions rather than duplicating database logic.

The following example illustrates the structure of a service. It assumes that the application has already configured its database session and authentication system.

from datetime import datetime, timezone
from typing import Any

from pydantic import BaseModel, Field


class ActivityCreate(BaseModel):
    actor_id: int | None = None
    action: str = Field(min_length=1, max_length=100)
    entity_type: str | None = None
    entity_id: str | None = None
    description: str = Field(min_length=1, max_length=500)
    metadata: dict[str, Any] = Field(default_factory=dict)


class ActivityResponse(BaseModel):
    id: int
    actor_id: int | None
    action: str
    entity_type: str | None
    entity_id: str | None
    description: str
    metadata: dict[str, Any]
    created_at: datetime

Pydantic validates the shape of the data before it reaches the service. However, validation alone is not enough. The backend must also determine whether the authenticated actor is allowed to perform the action and whether the supplied resource belongs to the correct tenant.

Recording an activity

The activity service should insert the event into the database using the same transaction as the business operation whenever practical.

Conceptually, the service performs the following steps:

Validate the event data.
Confirm the actor's identity and permissions.
Execute the business operation.
Insert the activity record.
Commit the transaction.
Publish the event for real-time delivery.

This ordering matters. Broadcasting an event before the database transaction commits can cause the interface to display a change that is later rolled back.

For a small application, a database insert followed by publication may be sufficient. For production systems where losing an event is unacceptable, the transactional outbox pattern provides stronger reliability.

6. Connecting Business Operations to the Activity Log

The most useful logs are generated automatically by meaningful application operations.

Suppose a user creates a project. The backend should create the project and its activity record together.

A simplified FastAPI endpoint could follow this pattern:

from fastapi import APIRouter, Depends, HTTPException

router = APIRouter()


@router.post("/projects")
async def create_project(
    payload: dict,
    current_user=Depends(get_current_user),
    db=Depends(get_db),
):
    project = await save_project(db, payload, current_user.id)

    activity = await save_activity(
        db=db,
        actor_id=current_user.id,
        action="project.created",
        entity_type="project",
        entity_id=str(project.id),
        description=f"{current_user.name} created a project",
        metadata={"project_name": project.name},
    )

    await db.commit()

    await publish_activity(activity)

    return project

Here, get_current_user, get_db, save_project, save_activity, and publish_activity represent application-specific functions that must be implemented.

For true transactional safety, both database writes must use the same transaction, and failures must roll back both operations. The publishing function should also handle delivery failures without incorrectly reporting that a committed business operation failed.

A stronger design records an outbox message in the same transaction. A separate worker publishes committed messages and retries failed deliveries.

Which actions should be recorded?

Do not record every technical operation indiscriminately. Focus on events that help users understand changes or help administrators investigate important activity.

Useful examples include:

Creating, editing, or deleting a record.
Assigning a task to a team member.
Updating an order status.
Changing account permissions.
Uploading or removing a document.
Inviting or removing a user.

Read-only operations, routine polling requests, and other high-frequency events usually belong in application telemetry rather than the business activity timeline.

7. Building the WebSocket Endpoint

REST APIs are useful for retrieving historical activities, but repeatedly polling an endpoint is inefficient when users need immediate updates.

WebSockets allow the server to push newly published events to connected clients.

A minimal FastAPI implementation might look like this:

from fastapi import WebSocket, WebSocketDisconnect


class ConnectionManager:
    def __init__(self):
        self.connections: set[WebSocket] = set()

    async def connect(self, websocket: WebSocket):
        await websocket.accept()
        self.connections.add(websocket)

    def disconnect(self, websocket: WebSocket):
        self.connections.discard(websocket)

    async def broadcast(self, event: dict):
        disconnected = []

        for connection in list(self.connections):
            try:
                await connection.send_json(event)
            except Exception:
                disconnected.append(connection)

        for connection in disconnected:
            self.disconnect(connection)


manager = ConnectionManager()


@app.websocket("/ws/activity")
async def activity_socket(websocket: WebSocket):
    # Authenticate and authorize the connection before accepting it.
    user = await authenticate_websocket(websocket)

    if user is None:
        await websocket.close(code=1008)
        return

    await manager.connect(websocket)

    try:
        while True:
            # Production implementations should also handle heartbeats,
            # disconnects, and bounded message processing.
            await websocket.receive_text()
    except WebSocketDisconnect:
        manager.disconnect(websocket)

This code illustrates the connection lifecycle rather than a complete production implementation. The authenticate_websocket function must be implemented using your application's authentication strategy.

The manager broadcasts only to sockets registered with it. In a real multi-user application, a global broadcast to every connection would be unsafe. Store connections by authorized tenant, project, organization, or user, and send each event only to clients entitled to see it.

Never assume that a user is authorized simply because they successfully established a WebSocket connection.

8. Implementing the React Activity Timeline

The frontend needs two capabilities: loading existing activities and receiving new ones.

The historical API might expose an endpoint such as GET /api/activity?limit=20. The browser can load the most recent records when the page opens, while the WebSocket delivers updates afterward.

A basic React component could look like this:

import { useEffect, useState } from "react";

export default function ActivityTimeline() {
  const [activities, setActivities] = useState([]);

  useEffect(() => {
    let socket;

    async function loadActivities() {
      const response = await fetch("/api/activity?limit=20", {
        credentials: "include",
      });

      if (!response.ok) {
        throw new Error("Unable to load activity history");
      }

      const data = await response.json();
      setActivities(data.items);
    }

    loadActivities().catch(console.error);

    socket = new WebSocket("wss://example.com/ws/activity");

    socket.onmessage = (message) => {
      const activity = JSON.parse(message.data);

      setActivities((current) => {
        if (current.some((item) => item.id === activity.id)) {
          return current;
        }

        return [activity, ...current].slice(0, 50);
      });
    };

    return () => {
      socket?.close();
    };
  }, []);

  return (
    <section>
      <h2>Recent Activity</h2>

      <ul>
        {activities.map((activity) => (
          <li key={activity.id}>
            <strong>{activity.description}</strong>
            <time dateTime={activity.created_at}>
              {new Date(activity.created_at).toLocaleString()}
            </time>
          </li>
        ))}
      </ul>
    </section>
  );
}

Replace the example domain with your own deployment address. The API response is assumed to contain an items array, and the WebSocket endpoint must return events matching the activity schema.

This example intentionally stays small. A production component should handle loading states, API errors, WebSocket reconnection, authentication expiration, and changes to network connectivity.

For session-cookie authentication, use secure cookie settings and validate the WebSocket handshake's origin. If your system uses bearer tokens, avoid placing long-lived credentials in URLs because URLs can appear in logs and monitoring systems.

Improving the user experience

An activity timeline should be easy to scan. Consider displaying:

The actor's name and profile image, where appropriate.
A short action description.
A relative timestamp such as "2 minutes ago".
A link to the affected resource.
Filters for event type, user, or date range.

Use semantic HTML and accessible labels. Color can communicate event categories, but the interface should not depend on color alone.

Also, avoid inserting user-generated descriptions as raw HTML. Render them as text or sanitize them appropriately to prevent cross-site scripting.

9. Retrieving Historical Activities with Pagination

An activity table can grow rapidly. Returning every event in one API response will eventually become slow and expensive.

Use pagination to retrieve only the records the interface needs.

For smaller datasets, limit-and-offset pagination is straightforward:

SELECT id, actor_id, action, entity_type,
       entity_id, description, created_at
FROM activity_logs
WHERE tenant_id = :tenant_id
ORDER BY created_at DESC, id DESC
LIMIT 20 OFFSET 0;

This query assumes that a tenant_id column has been added to the table.

For large datasets, cursor-based pagination is usually preferable. The client supplies the timestamp and ID of the last event it received. The next page uses a condition such as:

SELECT id, actor_id, action, entity_type,
       entity_id, description, created_at
FROM activity_logs
WHERE tenant_id = :tenant_id
  AND (created_at, id) < (:cursor_time, :cursor_id)
ORDER BY created_at DESC, id DESC
LIMIT 20;

The timestamp and ID together provide a stable ordering when multiple activities share the same timestamp.

Validate pagination parameters on the backend and apply a maximum page size. The database should return only fields the client is allowed to see.

10. Handling Real-Time Events Reliably

A WebSocket connection does not guarantee that every event will reach every browser.

Users may lose their network connection, close a laptop, refresh a page, or move between networks. A server may also restart while clients are connected.

For that reason, treat real-time delivery as an optimization rather than the permanent storage mechanism.

A reliable workflow should:

Save the activity record.
Commit the database transaction.
Publish an event containing the record identifier and relevant payload.
Retry publication if delivery fails.
Allow clients to reconnect.
Fetch missed activities after reconnection.

For higher reliability, use the transactional outbox pattern. In the same database transaction as the business change, insert an outbox record describing the event. A background worker reads unpublished records, publishes them to a message broker, and marks them as processed.

If the worker crashes after publishing but before marking a message as processed, it may publish the same event again. Therefore, consumers should be idempotent and use event IDs to avoid duplicate processing.

Redis Pub/Sub can distribute messages between application instances, but it does not provide durable message storage for disconnected consumers. If events must survive outages, consider a durable queue or streaming system appropriate to your workload.

11. Security and Access Control

Activity logs can contain sensitive information about business operations. Protecting them is as important as protecting the primary application database.

Authenticate every request

Require authentication for historical activity endpoints and WebSocket connections. Expired sessions and revoked permissions must be handled correctly.

Enforce authorization

Filter activity records by tenant, organization, project, or user permissions on the server. Never rely on the React interface to hide records that the user is not allowed to access.

Prevent tampering

For important audit trails, restrict modification and deletion privileges. Consider append-only database permissions, immutable backups, or external audit storage where appropriate.

Minimize sensitive data

Do not store passwords, session cookies, API keys, full payment details, or unnecessary personal information in event descriptions or metadata.

Validate WebSocket origins

For cookie-authenticated connections, validate the request origin against an explicit allowlist. Use encrypted connections in production and rate-limit connection attempts.

Separate business events from security logs

A business activity timeline and a security audit trail may overlap, but they are not identical. Security logs may require stricter access controls, longer retention, reliable ingestion, and records of privileged administrative actions.

Do not assume that a normal user-facing activity feed is sufficient for regulatory or security auditing.

12. Performance Optimization for Large Applications

As the number of users grows, the volume of activity events can increase significantly. A design that works for a small prototype may struggle under a large workload.

Use appropriate database indexes

Index fields used for filtering and ordering. Avoid adding indexes without a clear query pattern because every additional index increases storage requirements and write costs.

Limit WebSocket payloads

Send only the fields the recipient needs. Large metadata objects increase network traffic and browser processing time.

Avoid blocking database operations

Use asynchronous database access where appropriate, connection pooling, and carefully managed transaction boundaries.

Batch or queue publication

If many events are generated in a short period, a queue can absorb bursts and allow workers to publish at a controlled rate.

Apply retention policies

Not every event needs to remain in the primary database forever. Depending on business requirements, older records may be archived, partitioned, or deleted after an approved retention period.

Never introduce a retention policy that conflicts with legal, contractual, or audit obligations.

Monitor important metrics

Track event creation latency, publication failures, queue depth, WebSocket connection counts, query duration, and database storage growth.

These metrics help identify bottlenecks before users experience slow timelines or missing updates.

13. Testing the Activity Log

Testing should cover both the stored history and real-time behavior.

Unit tests: Verify event validation, action naming, metadata handling, and formatting.

Integration tests: Confirm that a successful business operation creates the expected activity record and that a failed transaction does not leave a misleading record.

WebSocket tests: Check that authorized clients receive relevant events and unauthorized clients cannot subscribe to restricted activity streams.

Pagination tests: Verify stable ordering when timestamps match and ensure that cursor-based requests do not unexpectedly repeat records.

Reconnect tests: Simulate a dropped connection, reconnect, and fetch missed events.

Security tests: Check tenant isolation, authorization changes, origin validation, and attempts to inject unsafe content.

One especially important test is whether a client can request another tenant's activity by changing a URL parameter or subscribing to a different WebSocket channel. The server must reject unauthorized access regardless of what the frontend displays.

14. Common Mistakes to Avoid

Several implementation mistakes can make an activity log unreliable or unsafe.

Publishing before committing: The browser may display an event for a transaction that later fails.

Broadcasting to every connected user: Private activities may be disclosed to unauthorized clients.

Using WebSockets as the only data store: Disconnected clients can miss events permanently unless they can retrieve history.

Logging every request: Excessive noise makes meaningful activity difficult to find and increases storage costs.

Storing entire database records: This can expose sensitive fields and produce large event payloads.

Ignoring duplicate delivery: Retries can cause the same activity to appear multiple times.

Using unstable pagination: Ordering only by timestamp can produce inconsistent pages when several events share the same timestamp.

Skipping authorization checks: A valid login does not automatically grant access to every project or organization.

Avoiding these mistakes early makes the system easier to maintain as the application grows.

15. Deployment Considerations

Before deploying the activity service, configure the infrastructure for production workloads.

Use environment variables or a managed secrets system for database credentials. Enable TLS for HTTPS and WSS traffic. Configure connection limits, request timeouts, database pooling, and reverse-proxy WebSocket support.

If multiple FastAPI instances are running, remember that an in-memory connection manager only knows about connections attached to its own process. Use shared messaging infrastructure so events can reach clients connected to different instances.

Configure health checks for the API and background workers. Monitor failed publications and make sure the outbox or queue can be recovered after an outage.

Finally, test deployment behavior under realistic conditions. Restart application instances while users are connected, simulate slow clients, and confirm that historical events remain available after reconnecting.

16. Future Enhancements

Once the basic activity log is working, several improvements can make it more useful.

Advanced filtering: Allow users to filter by actor, event category, project, or date range.

Search: Add full-text search for descriptions and selected metadata fields.

Notifications: Turn important activity events into targeted notifications or email alerts.

Export functionality: Allow authorized users to export filtered activity records for reporting.

Analytics: Aggregate event data to understand product usage and team collaboration patterns.

Audit history: Provide detailed before-and-after values for selected changes, with appropriate redaction and access controls.

Live indicators: Show a small notification badge when new events arrive and let users decide when to load them into the current timeline.

Each feature should be built around a clear requirement. Avoid adding complexity that does not improve the experience or meet an operational need.

Conclusion

Building a real-time activity log is more than connecting a WebSocket to a React component. A dependable implementation combines a well-designed database schema, consistent event definitions, secure authorization, reliable persistence, and a frontend that can handle new events and network interruptions.

React provides the interactive timeline, FastAPI manages application operations and real-time connections, and PostgreSQL stores the permanent activity history. WebSockets deliver immediate updates, while pagination, database indexes, and background workers help the architecture scale.

For a small application, begin with a structured activity table, a reusable event service, a historical REST endpoint, and a secured WebSocket connection. As requirements grow, introduce cursor-based pagination, a transactional outbox, shared messaging, retention policies, and stronger audit controls.

The ultimate goal is to make application activity transparent, useful, and trustworthy. When implemented correctly, a real-time activity log helps users understand changes, gives administrators better visibility, and makes complex web applications easier to maintain.

Building a CSV Import and Export System for a Web Application

Sun, 25 Oct 2026 08:09:06 +0000

Modern web applications often need to handle large amounts of structured data. Whether you are building a customer relationship management (CRM) platform, an inventory management system, an employee dashboard, or an e-commerce application, users frequently need to move data between different systems. One of the simplest and most widely supported formats for this purpose is CSV, which stands for Comma-Separated Values.

CSV files allow users to organize information in a tabular structure that can be opened in spreadsheet applications such as Microsoft Excel, Google Sheets, and LibreOffice Calc. They are lightweight, easy to generate, and supported by almost every programming language.

A well-designed CSV import and export system enables users to upload data into an application and download existing records for reporting, analysis, backup, or migration. However, building this functionality involves more than simply reading a file or converting database records into comma-separated text. Developers must consider data validation, error handling, security, performance, encoding, database transactions, and the user experience.

In this article, we will explore how to build a reliable CSV import and export system for a modern web application. We will discuss the architecture, implementation strategy, validation techniques, security measures, and optimization practices needed to create a solution that works effectively in production.

1. Understanding CSV Import and Export

Before implementing the system, it is important to understand the responsibilities of CSV import and export functionality.

CSV Import

CSV import allows users to upload a file containing structured information and insert or update records in an application.

For example, an administrator might upload a CSV file containing hundreds of customer records.

A typical file could look like this:

name,email,company
John Smith,*Emails are not allowed*,Example Inc
Sarah Johnson,*Emails are not allowed*,Tech Solutions
Michael Brown,*Emails are not allowed*,Digital Systems

The application reads the file, checks whether the values are valid, and stores the accepted records in a database.

CSV Export

CSV export performs the opposite operation. It retrieves information from a database and converts it into a downloadable file.

For example, a CRM application might allow a user to export all customers matching a particular search query.

The generated file could contain the same columns shown in the import example.

Why These Features Matter

CSV functionality provides several benefits:

Data migration: Move records between applications.
Bulk operations: Create or update many records at once.
Reporting: Analyze application data using spreadsheet tools.
Backup support: Download structured copies of selected information.
Integration: Exchange data with external business systems.
Productivity: Reduce repetitive manual data entry.

These benefits make CSV processing a valuable feature for applications of almost any size.

2. Choosing the Right Technology Stack

The implementation depends on the application's existing technology stack. A common architecture uses React for the frontend and Python with FastAPI for the backend, supported by PostgreSQL or another relational database.

Each component has a specific responsibility.

Frontend

The frontend provides the interface for selecting files, submitting imports, monitoring progress, displaying validation errors, and downloading exported data.

React is suitable for this purpose because it supports reusable components and interactive interfaces.

Backend

The backend receives uploaded files, validates their contents, processes records, queries the database, and generates export files.

FastAPI provides request validation, asynchronous request handling, file upload support, and automatically generated API documentation.

Database

The database stores imported records and supplies data for export operations.

PostgreSQL is a strong option when the application requires relational integrity, unique constraints, transactions, and efficient filtering.

CSV Processing Libraries

Python's built-in csv module is useful for straightforward CSV processing. It handles quoted fields, delimiters, and escaped quotation marks without requiring an additional dependency.

For complex data transformations, libraries such as pandas may be useful. However, pandas can consume substantial memory when processing very large files, so it should not be the default choice for every import operation.

The best technology stack is the one that fits the application's scale, existing architecture, and operational requirements.

3. Designing the System Architecture

A reliable CSV system separates the user interface, file processing, validation, persistence, and export generation.

A typical import workflow follows these steps:

The user selects a CSV file.
The frontend submits the file to the backend.
The backend checks the file type and size.
The CSV parser reads the header and rows.
The validation layer checks each record.
Validated records are inserted or updated in the database.
The application returns a summary of the results.

The export workflow is slightly different:

The user selects an export option or applies filters.
The frontend sends an authenticated request.
The backend checks permissions and validates the filters.
The database returns the authorized records.
The backend serializes the records into CSV format.
The response provides a downloadable file.

Keeping these responsibilities separate makes the system easier to test, maintain, and extend.

For larger applications, the import process can be moved into a background worker. The API then creates an import job and returns a job identifier. The frontend polls a status endpoint or receives updates through a notification mechanism.

This architecture prevents long-running operations from blocking ordinary application requests.

4. Creating the Database Model

Before implementing the import endpoint, define the structure of the records being imported.

Consider a customer management application using SQLAlchemy and PostgreSQL.

A simplified SQLAlchemy model could look like this:

from sqlalchemy import String, Integer
from sqlalchemy.orm import DeclarativeBase, Mapped, mapped_column

class Base(DeclarativeBase):
    pass


class Customer(Base):
    __tablename__ = "customers"

    id: Mapped[int] = mapped_column(
        Integer,
        primary_key=True
    )

    name: Mapped[str] = mapped_column(
        String(150),
        nullable=False
    )

    email: Mapped[str] = mapped_column(
        String(255),
        unique=True,
        nullable=False
    )

    company: Mapped[str | None] = mapped_column(
        String(200),
        nullable=True
    )

This model defines a customer with a required name, a unique email address, and an optional company name.

The unique constraint on the email field is particularly important. Application-level validation can detect duplicate emails before insertion, but the database constraint provides a final layer of protection against concurrent requests and unexpected data conditions.

In production, use database migrations to create and modify tables instead of relying on automatic table creation during application startup.

5. Building the CSV Import Endpoint

FastAPI supports file uploads through UploadFile. It provides access to the uploaded file without requiring the entire request body to be copied into a Python string.

The following example demonstrates a basic import endpoint. It assumes that get_db provides a SQLAlchemy session and Customer is the database model defined earlier.

import csv
import io

from fastapi import (
    FastAPI,
    UploadFile,
    File,
    Depends,
    HTTPException
)
from sqlalchemy.orm import Session

app = FastAPI()

MAX_FILE_SIZE = 5 * 1024 * 1024

REQUIRED_COLUMNS = {
    "name",
    "email",
    "company"
}


@app.post("/customers/import")
async def import_customers(
    file: UploadFile = File(...),
    db: Session = Depends(get_db)
):
    if not file.filename or not file.filename.lower().endswith(".csv"):
        raise HTTPException(
            status_code=400,
            detail="Please upload a CSV file."
        )

    content = await file.read(MAX_FILE_SIZE + 1)

    if len(content) > MAX_FILE_SIZE:
        raise HTTPException(
            status_code=413,
            detail="The uploaded file exceeds the size limit."
        )

    try:
        text = content.decode("utf-8-sig")
    except UnicodeDecodeError:
        raise HTTPException(
            status_code=400,
            detail="The file must use UTF-8 encoding."
        )

    reader = csv.DictReader(io.StringIO(text))

    if not reader.fieldnames:
        raise HTTPException(
            status_code=400,
            detail="The CSV file has no header row."
        )

    headers = {
        header.strip()
        for header in reader.fieldnames
        if header
    }

    if not REQUIRED_COLUMNS.issubset(headers):
        raise HTTPException(
            status_code=400,
            detail="The CSV file is missing required columns."
        )

    created = 0
    errors = []

    try:
        for row_number, row in enumerate(reader, start=2):
            name = (row.get("name") or "").strip()
            email = (row.get("email") or "").strip().lower()
            company = (row.get("company") or "").strip()

            if not name or not email:
                errors.append({
                    "row": row_number,
                    "error": "Name and email are required."
                })
                continue

            if "@" not in email:
                errors.append({
                    "row": row_number,
                    "error": "Email address is invalid."
                })
                continue

            customer = Customer(
                name=name,
                email=email,
                company=company or None
            )

            db.add(customer)
            created += 1

        db.commit()

    except Exception:
        db.rollback()
        raise HTTPException(
            status_code=500,
            detail="The import could not be completed."
        )

    return {
        "created": created,
        "errors": errors
    }

This example illustrates the basic workflow, but it is not a complete production implementation. A production version should also validate field lengths, reject duplicate headers, detect duplicate emails within the file, and distinguish database uniqueness violations from unexpected server errors.

The header validation shown here checks whether the required names are present, but the parser still uses the original header names. A hardened implementation should normalize the headers before constructing row dictionaries or reject unexpected whitespace and duplicate column names.

The example also reads the entire file into memory, so its five-megabyte limit is important. For larger files, process the upload in bounded chunks or stream the file into controlled temporary storage.

6. Validating Imported Data

Validation is one of the most important parts of a CSV import system.

A syntactically valid CSV file may still contain incorrect, incomplete, or malicious values. Importing such data without validation can damage application consistency and create security problems.

Required Field Validation

Required fields must contain meaningful values.

For example, a customer record may require a name and email address. Rows missing either value should be rejected or reported as invalid.

Data Type Validation

Fields should match their expected types.

An age field should contain an integer within an acceptable range. A date field should follow an agreed date format. Numeric values should not contain unexpected characters.

Length Validation

Database columns often have maximum lengths. Validate these limits before inserting records to avoid database errors.

For example:

if len(name) > 150:
    errors.append({
        "row": row_number,
        "error": "Name exceeds 150 characters."
    })
    continue

Email Validation

Checking for an @ character is not sufficient for comprehensive email validation. Use a suitable validation library or a carefully designed validation process.

Even a syntactically valid address does not guarantee that the mailbox exists.

Duplicate Detection

Duplicates can appear within the uploaded file or in the existing database.

For example, a file might contain two records with the same email address. The application must define whether to reject the duplicate, skip it, update the existing record, or merge selected fields.

These rules should be communicated clearly to users before the import begins.

Validation Reports

Instead of returning only a generic error, generate a report containing the row number, field name, and reason for rejection.

A helpful report might say:

Row 4: Email address is missing.
Row 9: Name exceeds the maximum length.
Row 15: Email address already exists.
Row 21: Invalid date format.

For large imports, offer a downloadable error report so users can correct the original file without manually searching through hundreds of records.

7. Deciding Between Partial and All-or-Nothing Imports

There are two common import strategies.

Partial Import

The application saves valid records while rejecting invalid rows.

This approach is useful when users upload large datasets and want to correct only the problematic records.

The response should clearly report how many rows were accepted, rejected, skipped, or updated.

Atomic Import

The application validates the complete file and commits all changes only if every required operation succeeds.

If any record fails, the transaction is rolled back.

This approach is appropriate when partial data could violate business rules or produce inconsistent relationships.

The choice depends on the application. A contact-management system may benefit from partial imports, while financial or inventory workflows may require stricter transactional behavior.

For larger datasets, avoid holding a database transaction open during lengthy file uploads or extended validation. Validate first, then perform the database operation in a controlled transaction or staged workflow.

8. Implementing Duplicate Handling and Updates

Importing a file twice should not unexpectedly create duplicate records.

A practical system supports explicit duplicate-handling policies.

Skip duplicates: Existing records remain unchanged.

Update existing records: Matching records are updated using a stable identifier, such as an external ID or unique email address.

Reject duplicates: The application reports conflicts and asks the user to resolve them.

Create new records: Every valid row creates a new record, provided the data model permits duplicates.

For business applications, a stable external identifier is often safer than relying only on email addresses because email addresses can change.

When using PostgreSQL, an upsert operation can insert new records and update matching records in one database statement. SQLAlchemy supports PostgreSQL-specific insert operations that can be configured with on_conflict_do_update.

Whatever strategy is chosen, document it in the interface and test concurrent imports to ensure database constraints remain effective.

9. Building the CSV Export Endpoint

Export functionality retrieves records from the database and serializes them into CSV format.

Python's csv module handles quoting and escaping more reliably than manually joining values with commas.

A simple FastAPI endpoint can generate a CSV file using StreamingResponse.

import csv
import io

from fastapi import Depends
from fastapi.responses import StreamingResponse
from sqlalchemy.orm import Session


@app.get("/customers/export")
def export_customers(
    db: Session = Depends(get_db)
):
    customers = (
        db.query(Customer)
        .order_by(Customer.id)
        .all()
    )

    output = io.StringIO(newline="")

    writer = csv.writer(output)

    writer.writerow([
        "id",
        "name",
        "email",
        "company"
    ])

    for customer in customers:
        writer.writerow([
            customer.id,
            customer.name,
            customer.email,
            customer.company or ""
        ])

    output.seek(0)

    return StreamingResponse(
        iter([output.getvalue()]),
        media_type="text/csv; charset=utf-8",
        headers={
            "Content-Disposition":
                'attachment; filename="customers.csv"'
        }
    )

This endpoint creates a downloadable file with a header row followed by customer records.

However, despite using StreamingResponse, this implementation builds the entire CSV in memory before returning it. It is suitable for small datasets, not for genuinely large exports.

For larger datasets, use a generator that writes records incrementally and retrieves database rows in batches. Alternatively, generate the file in a background job and provide a secure download link when it is ready.

Always ensure that the export query returns only records the requesting user is authorized to access.

10. Exporting Large Datasets Efficiently

Export performance becomes important when a database contains hundreds of thousands or millions of records.

Loading every record into a Python list can consume significant memory. Generating the complete CSV in a string creates another large in-memory object.

A more efficient approach uses database pagination or streaming iteration.

For example, a SQLAlchemy query can iterate through records in batches:

query = (
    db.query(Customer)
    .order_by(Customer.id)
    .yield_per(1000)
)

for customer in query:
    process_customer(customer)

The exact behavior depends on the database driver and session configuration. For very large PostgreSQL exports, server-side cursors or carefully managed keyset pagination may be more appropriate.

Keyset pagination uses a stable ordering column, such as the customer ID, and retrieves the next batch after the last processed ID. This can perform better than large offset-based queries.

For extremely large exports, consider a background job that writes a file to private object storage. The application can then provide a time-limited download URL after checking permissions.

Also consider database indexes, query filters, request timeouts, storage limits, and the number of concurrent export jobs.

11. Creating a React CSV Import Interface

A useful frontend should make uploading and monitoring a file straightforward.

Users should be able to select a file, review the selected filename, submit the upload, and see the result.

A basic React component can use the FormData API to submit the file.

import { useState } from "react";

export default function CsvImport() {
  const [file, setFile] = useState(null);
  const [message, setMessage] = useState("");
  const [loading, setLoading] = useState(false);

  async function handleImport(event) {
    event.preventDefault();

    if (!file) {
      setMessage("Please select a CSV file.");
      return;
    }

    const formData = new FormData();
    formData.append("file", file);

    setLoading(true);
    setMessage("");

    try {
      const response = await fetch(
        "/customers/import",
        {
          method: "POST",
          body: formData,
          credentials: "include"
        }
      );

      const result = await response.json();

      if (!response.ok) {
        throw new Error(
          result.detail || "Import failed."
        );
      }

      setMessage(
        `Created ${result.created} records. ` +
        `Rejected ${result.errors.length} rows.`
      );
    } catch (error) {
      setMessage(
        error.message || "An unexpected error occurred."
      );
    } finally {
      setLoading(false);
    }
  }

  return (
    <form onSubmit={handleImport}>
      <label htmlFor="csv-file">
        Choose a CSV file
      </label>

      <input
        id="csv-file"
        type="file"
        accept=".csv,text/csv"
        onChange={(event) =>
          setFile(event.target.files?.[0] ?? null)
        }
      />

      <button type="submit" disabled={loading}>
        {loading ? "Importing..." : "Import CSV"}
      </button>

      {message && <p role="status">{message}</p>}
    </form>
  );
}

This component provides a basic import experience, but production interfaces should also display detailed validation errors and handle authentication, session expiration, and network failures.

The browser's accept attribute helps users select CSV files, but it is not a security boundary. The backend must independently validate every upload.

The frontend should also disable duplicate submissions while an import is running and explain whether the operation can be safely retried.

12. Adding a CSV Export Button in React

Exporting a file can be initiated through a link or a button, depending on the application's authentication and download requirements.

For cookie-based authentication, a simple link can be sufficient:

export default function CsvExport() {
  return (
    <a href="/customers/export">
      Download Customers CSV
    </a>
  );
}

If the API requires a bearer token or the frontend needs to inspect the response, use fetch, read the response as a Blob, and create a temporary download link.

The frontend should revoke temporary object URLs after the download has been initiated.

For large files, prefer a direct download or a secure, time-limited file URL rather than buffering the entire response in browser memory.

Export controls should also respect the application's permission system. Hiding the button is not enough; the server must enforce authorization independently.

13. Improving the User Experience with Import Previews

A CSV import preview can prevent common mistakes before data is written to the database.

Instead of immediately importing the uploaded file, the application can provide a preview stage.

The user uploads a file, the backend parses it, and the frontend displays a small sample of the rows. The interface can identify missing columns, invalid values, duplicate records, and potential conflicts.

The user can then confirm the import or cancel it.

A preview workflow is especially useful when the file comes from another application with unfamiliar column names or inconsistent formatting.

For example, the application may receive a column named Customer Email when the expected field is email. A mapping interface allows users to associate incoming columns with database fields.

The system should validate the mapping before accepting the import and clearly indicate which fields are required.

For large files, previews should be limited to a reasonable number of rows rather than sending the complete dataset to the browser.

14. Handling Encoding and CSV Formatting

CSV files are not always formatted identically.

One file may use commas, another may use semicolons, and another may contain a byte-order mark at the beginning of the file. Some files use Windows-specific line endings or contain non-English characters.

These differences can cause parsing problems.

UTF-8 Encoding

UTF-8 is a practical default for modern applications. In Python, decoding with utf-8-sig can remove a UTF-8 byte-order mark when one is present.

Quoted Fields

CSV fields may contain commas, quotation marks, or newline characters. The CSV parser should handle these correctly.

For example:

name,company
"John Smith","Smith, Johnson & Co."

Manually splitting each line on commas would incorrectly divide the company field.

Line Endings

Files can use different newline conventions. Python's CSV documentation recommends opening file objects with newline="" when using the csv module.

Delimiter Detection

If users regularly upload files from different spreadsheet applications, the application may offer an explicit delimiter option or use carefully constrained detection.

Automatic detection is not always reliable, so the interface should let users correct the delimiter when necessary.

15. Securing the Import and Export System

Security should be part of the design from the beginning.

Validate File Size

Set file-size limits at the application, reverse-proxy, and infrastructure levels. Do not rely solely on a filename or a browser-side restriction.

Validate File Content

A .csv extension does not prove that the uploaded content is a valid CSV file. Parse the contents and validate the expected structure.

Enforce Authentication and Authorization

Only authenticated users with the appropriate permissions should be able to import or export records.

For multi-tenant applications, every database query must also enforce tenant boundaries. Otherwise, users could download or modify another organization's information.

Protect Against CSV Formula Injection

CSV exports can be dangerous when cells begin with characters that spreadsheet applications interpret as formulas, including =, +, -, or @.

If an exported value contains untrusted user input, opening the file in a spreadsheet application may trigger formula evaluation.

Mitigations include neutralizing dangerous leading characters according to the target spreadsheet applications and the application's requirements. Quoting a field according to CSV syntax alone does not reliably prevent formula injection.

Test the chosen mitigation with the spreadsheet applications your users actually use, and preserve the original data in the database rather than silently altering stored values.

Avoid Sensitive Information Leakage

Do not export passwords, authentication tokens, internal notes, or confidential fields unless the user has explicit authorization and a valid business reason.

Keep temporary files in protected storage and remove them according to a defined retention policy.

Apply Rate Limits

Large imports and exports can consume substantial CPU, memory, database capacity, and storage. Limit concurrent jobs, enforce quotas, and prevent abusive repeated requests.

Protect Upload Endpoints Against CSRF

If the application uses cookie-based authentication, implement appropriate CSRF protection and secure cookie settings. CORS configuration alone is not a substitute for CSRF protection.

16. Handling Errors and Import Status

A good CSV system provides meaningful feedback when something goes wrong.

Errors can occur during file upload, parsing, validation, database operations, or export generation.

Instead of returning a generic message for every failure, classify errors into understandable categories.

Examples include:

Invalid file format.
Missing required columns.
Unsupported encoding.
Invalid field values.
Duplicate records.
Database constraint violations.
Permission denied.
File exceeds the permitted size.
Import job failed unexpectedly.

For background processing, create an import-job table containing the job identifier, initiating user, status, timestamps, and summary counts.

A job might move through the following states:

pending → processing → completed

It may also enter failed or completed_with_errors, depending on the application's policy.

Expose a status endpoint so the frontend can retrieve progress and results. Avoid returning sensitive information in error messages or logs.

For long-running jobs, retain enough diagnostic information to investigate failures without keeping uploaded files indefinitely.

17. Making the System Scalable with Background Jobs

Processing a large CSV synchronously can exceed request timeouts and degrade the user experience.

A background worker architecture separates request handling from file processing.

The API receives the upload, validates basic requirements, stores the file securely, creates a job record, and returns a job identifier. A worker then processes the file independently.

A queue such as Celery with Redis or RabbitMQ can coordinate background work, depending on the application's infrastructure.

The frontend can periodically query the job status or receive updates through WebSockets or server-sent events.

This architecture offers several benefits:

Long-running imports do not occupy ordinary request workers.
Jobs can be retried under controlled conditions.
Processing capacity can be scaled independently.
Progress can be reported to users.
Failed jobs can be investigated and resumed safely.

Retries require special attention. If a worker crashes after inserting records but before marking the job complete, processing the file again may create duplicates.

Use idempotency keys, unique constraints, checkpoints, or deterministic upsert rules to ensure that retrying a job does not produce unintended results.

18. Testing the CSV System

Testing should cover both ordinary operations and unusual inputs.

Unit Tests

Test parsing, normalization, validation, duplicate detection, and CSV serialization independently.

Include names containing commas, quotation marks, Unicode characters, and line breaks.

Integration Tests

Verify that valid records are saved correctly and invalid records follow the intended transaction policy.

Test duplicate database constraints, rollback behavior, authorization, and tenant isolation.

API Tests

Test upload and export endpoints using valid files, empty files, malformed CSV content, oversized uploads, missing headers, and unsupported encodings.

Frontend Tests

Verify file selection, loading states, error messages, successful downloads, and prevention of accidental repeated submissions.

Performance Tests

Measure processing time, memory usage, database load, and concurrent job behavior with realistic datasets.

A system that works for 20 rows may behave very differently with 200,000 rows. Performance tests should reflect expected production workloads.

19. Monitoring and Maintaining the System

After deployment, monitor the system to identify problems before they affect many users.

Useful metrics include:

Number of imports and exports.
Total rows processed.
Validation failure rate.
Average and maximum processing duration.
Background queue length.
Failed job count.
Database query duration.
Temporary storage consumption.

Logs should include a correlation ID or job ID so developers can trace a particular import across application components.

Avoid recording full CSV contents, passwords, access tokens, or unnecessary personal information in logs.

Review file-retention rules, database indexes, and worker capacity as usage grows. Remove expired temporary files and export artifacts through a controlled cleanup process.

A clear operational policy is just as important as the initial implementation.

20. Common Mistakes to Avoid

Several mistakes frequently appear in CSV implementations.

Reading every large file into memory: This can exhaust application resources. Use bounded processing or background jobs for larger datasets.

Manually splitting rows by commas: This fails when values contain quoted commas, newlines, or escaped quotation marks. Use a proper CSV parser.

Trusting the file extension: Validate content and structure on the server.

Ignoring duplicate policies: Decide how repeated records are handled before deploying the feature.

Using unbounded database transactions: Large transactions can increase lock duration and resource consumption. Choose batch boundaries carefully.

Returning vague errors: Include actionable row-level feedback without exposing sensitive server details.

Ignoring spreadsheet formula injection: Treat exported values as potentially dangerous when opened in spreadsheet software.

Forgetting authorization: Enforce access controls on both import and export endpoints, not only in the frontend.

Retrying jobs without idempotency: Ensure that interrupted jobs can be retried without producing unintended duplicates.

Avoiding these mistakes will make the system more secure, predictable, and maintainable.

Conclusion

Building a CSV import and export system is a practical way to make a web application more flexible and useful. It enables users to move data efficiently, perform bulk operations, generate reports, and integrate information with other business tools.

However, a reliable implementation requires more than reading rows and writing files. Developers must design clear API boundaries, validate incoming data, establish duplicate-handling rules, protect database integrity, generate efficient exports, and provide meaningful error reports.

A React frontend combined with a FastAPI backend and PostgreSQL database provides a strong foundation for this functionality. Python's built-in CSV module handles standard parsing and serialization, while background workers and controlled database operations support larger workloads.

Security also deserves special attention. File-size restrictions, authorization checks, tenant isolation, safe temporary storage, and CSV formula-injection defenses help prevent common vulnerabilities.

Start with a small implementation that supports well-defined columns and straightforward validation. Then introduce previews, field mapping, background processing, detailed reports, and scalable exports as the application's needs grow.

By treating CSV processing as a complete data workflow rather than a simple file operation, developers can build a feature that remains reliable as both the application and its users grow.

Mastering React Performance: Optimizations That Actually Matter 🚀

Sun, 25 Oct 2026 05:57:59 +0000

Introduction

React is a powerful JavaScript library, but as applications grow, performance bottlenecks can arise. Unnecessary re-renders, inefficient state management, and large bundle sizes can lead to slow applications.

This guide covers practical performance optimizations that actually matter. Whether you’re working on a small project or a large-scale application, these best practices will help you write faster, scalable, and efficient React applications.

By the end of this blog, you’ll learn:
✅ Why React apps slow down
✅ Best practices for optimizing re-renders
✅ How to efficiently manage state
✅ How to optimize large lists
✅ lazy loading for faster load times

Let’s dive in! 🚀

1️⃣ Understanding React’s Rendering Behavior

Before optimizing, it’s crucial to understand how React renders components.

📌 React re-renders a component when:

State changes in that component.
Props change from the parent component.
A parent re-renders, causing child components to re-render.

🔍 How to detect unnecessary re-renders?
Use React DevTools Profiler to analyze component renders.

✅ Solution: Memoization & Avoiding Unnecessary Renders

2️⃣ Optimize Component Re-Renders with `React.memo`

By default, React re-renders a component when its parent renders, even if props haven’t changed.

🚀 Solution: Use React.memo() to prevent unnecessary renders

🔴 Without React.memo (Unnecessary re-renders)

import React, { useState } from "react";

const MovieDetails = ({ title, director }) => {
  console.log("🎬 MovieDetails component re-rendered");
  return (
    <div>
      <h2>{title}</h2>
      <p>Directed by: {director}</p>
    </div>
  );
};

const App = () => {
  const [count, setCount] = useState(0);

  return (
    <div>
      <h1>React.memo Example</h1>
      <button onClick={() => setCount(count + 1)}>Click Me ({count})</button>
      <MovieDetails title="Inception" director="Christopher Nolan" />
    </div>
  );
};

export default App;

👉 Here, MovieDetails re-renders every time the parent renders, even if props hasn't changed.

🟢 Optimizing with React.memo
To prevent unnecessary re-renders, wrap MovieDetails with React.memo():

const MovieDetails = React.memo(({ title, director }) => {
  console.log("🎬 MovieDetails component re-rendered");
  return (
    <div>
      <h2>{title}</h2>
      <p>Directed by: {director}</p>
    </div>
  );
});

👉 Now, MovieDetails will only re-render if its props (title or director) change.

Clicking the button will no longer trigger a re-render of MovieDetails unless new props are passed.

📌 When to use React.memo?
✅ The component receives static or rarely changing props (e.g., user profile, movie info).
✅ The component is expensive to render (e.g., complex UI elements like charts).
✅ The parent re-renders frequently, but child props remain the same.

3️⃣ Minimize Re-Renders with Derived State

Unnecessary state updates can cause frequent re-renders, slowing down your React app. Instead of storing derived state, compute values when needed.

🔴 Problem: Storing Derived State in useState (Causes Extra Re-Renders)

const [items, setItems] = useState([...]); 
const [filteredItems, setFilteredItems] = useState([]);

useEffect(() => {
  setFilteredItems(items.filter(item => item.active));
}, [items]); // Extra re-render every time `items` change

📌 Issue:
Every update to items triggers an unnecessary state update for filteredItems.

This causes an extra re-render that could have been avoided.

🟢 Solution: Use Derived State Instead of Storing It

const filteredItems = items.filter(item => item.active);

✅ Now, filteredItems is computed only when needed, avoiding extra state updates and re-renders.

4️⃣ Optimize Function Props with `useCallback`

Passing new function instances as props causes child components to unnecessarily re-render.

🔴 Problem: Without useCallback (Function re-creates on every render)

const ParentComponent = () => {
  const handleClick = () => {
    console.log("Button clicked");
  };

  return <ButtonComponent handleClick={handleClick} />;
};

👉 Even if handleClick doesn’t change, it gets re-created every time ParentComponent renders.

🟢 Solution: Use useCallback to memoize the function

const handleClick = useCallback(() => {
  console.log("Button clicked");
}, []);

✅ Now, handleClick retains the same reference, preventing unnecessary re-renders.

5️⃣ Optimize Expensive Computations with `useMemo`

If a component performs heavy calculations on every render, it can slow down the UI.

🔴 Problem: Without useMemo (Expensive re-computation)

const heavyComputation = (num) => {
  console.log("Expensive calculation running...");
  return num * 2;
};

const Component = ({ number }) => {
  const result = heavyComputation(number); // Runs on every render
  return <p>Result: {result}</p>;
};

🟢 Solution: Use useMemo to cache expensive computations

const result = useMemo(() => heavyComputation(number), [number]);

✅ heavyComputation() only re-runs when number changes.

6️⃣ Optimize Lists & Large Data Rendering

🔍 Problem: Rendering large lists slows down UI
Solution: Use Virtualization with react-window

🔴 Without Virtualization (Slow performance)

const List = ({ items }) => {
  return (
    <ul>
      {items.map((item) => (
        <li key={item.id}>{item.name}</li>
      ))}
    </ul>
  );
};

🟢 With Virtualization (react-window)

import { FixedSizeList as List } from "react-window";

const VirtualizedList = ({ items }) => (
  <List height={500} itemCount={items.length} itemSize={35} width={300}>
    {({ index, style }) => (
      <div style={style}>{items[index].name}</div>
    )}
  </List>
);

✅ Only visible items are rendered, improving performance significantly.

7️⃣ Reduce Bundle Size with Code Splitting & Lazy Loading

Large JavaScript bundles slow down initial page load.

✅ Solution: Use React.lazy() for dynamic imports

const HeavyComponent = React.lazy(() => import("./HeavyComponent"));

const App = () => (
  <Suspense fallback={<div>Loading...</div>}>
    <HeavyComponent />
  </Suspense>
);

👉 Components load only when needed, reducing bundle size.

Conclusion: Build Fast & Scalable React Apps

Optimizing React apps is crucial for fast UI interactions and smooth performance. By implementing:
✅ Memoization (React.memo, useCallback, useMemo)
✅ Efficient state management
✅ Virtualization for large lists
✅ Lazy loading for faster page loads

You’ll significantly improve performance! 🚀

💡 What performance tricks do you use in React? Drop a comment below! 👇

Your Next.js Dates Are Wrong for Half Your Users (and the Hydration Warning Is Only the Start)

Wed, 21 Oct 2026 11:48:27 +0000

You format a date in a component. It looks right on your laptop. Then a user in another country opens the page and either sees a console full of hydration errors, or worse, sees nothing wrong at all and reads the wrong time.

I live in a timezone that is five hours away from where most servers run, so this one finds me every time.

The Code That Looks Fine

// components/OrderDate.tsx
export function OrderDate({ date }: { date: string }) {
  return <p>Ordered on {new Date(date).toLocaleString()}</p>;
}

No hooks, no browser APIs, nothing that looks risky. It even works in next dev, because on your machine the server and the browser are the same computer.

Why It Breaks

In Next.js, this component runs twice: once on the server to produce the HTML, and again in the browser to hydrate it. toLocaleString() with no arguments uses the timezone and language of whatever machine runs it.

The server is often in UTC, with a default locale such as en-US.
Your user's browser might be in Karachi, with en-GB.

Server HTML:   Ordered on 10/20/2026, 10:15:00 AM
Browser render: Ordered on 20/10/2026, 15:15:00

React compares the two, finds that they differ, and logs a hydration error. In development, you see it. In production, React quietly tries to recover by re-rendering on the client, which costs time and can cause a visible flash.

Why It Is Hard to Catch

It never fails where you test. Same machine, same timezone, same locale: the two outputs are identical.
Many users never see an error. The page just shows one format for a split second and then another.
It often hides inside other pieces of data. Date.now(), Math.random(), new Date().getFullYear() and anything that reads window or localStorage can all produce a different value on the server and in the browser.

The Fix That Is Tempting, and Wrong

You will find this advice everywhere:

<p suppressHydrationWarning>
  Ordered on {new Date(date).toLocaleString()}
</p>

It does silence the warning. But per React's documentation, it only suppresses the warning on that one element and does not patch up mismatched text. The user can end up looking at the server's version of the time, which is in the wrong timezone.

You did not fix the bug, you removed the alarm for it.

Fix 1: Make the Output the Same on Both Sides

Pass an explicit locale and timezone, so the server and the browser calculate the same string:

export function OrderDate({ date }: { date: string }) {
  const text = new Date(date).toLocaleString('en-US', {
    timeZone: 'UTC',
    dateStyle: 'medium',
    timeStyle: 'short',
  });

  return <time dateTime={date}>{text} UTC</time>;
}

This is deterministic, so there is nothing to mismatch. It is the right choice for logs, admin tables and anything where showing UTC is acceptable. Label it as UTC so nobody reads it as local time.

Fix 2: Show the Local Time After the Page Loads

If users should see their own timezone, only compute it in the browser:

'use client';

import { useEffect, useState } from 'react';

export function LocalDate({ date }: { date: string }) {
  const [local, setLocal] = useState<string | null>(null);

  useEffect(() => {
    setLocal(
      new Date(date).toLocaleString(undefined, {
        dateStyle: 'medium',
        timeStyle: 'short',
      })
    );
  }, [date]);

  return (
    <time dateTime={date}>
      {local ?? new Date(date).toISOString().slice(0, 10)}
    </time>
  );
}

The first render, on the server and in the browser, shows a stable fallback (the ISO date). Right after hydration, useEffect runs only in the browser and swaps in the local time. Nothing mismatches, and the user ends up with the right value.

The cost is a brief change from the fallback to the local string. Keep the fallback short so the layout does not jump.

Fix 3: Store and Send Dates as ISO Strings

Whichever display option you pick, pass dates around as ISO strings (2026-10-20T10:15:00.000Z) and format them only at the edge, in one place. An ISO string is plain text, so it means the same thing on the server, in the browser and in your database.

Which One When

Situation	Fix
Admin tables, logs, reports	Fixed locale and `timeZone: 'UTC'`
Customer-facing times (orders, bookings, messages)	Format in the browser after mount
A date that never changes (blog post date)	Fixed locale and timezone, since the author's date is what matters

The Rule

Any value that depends on where the code runs, such as timezone, locale, the current time or a random number, will differ between the server and the browser. Either make it identical on both sides, or compute it only in the browser after hydration. Do not suppress the warning and hope.

Quick audit: search your project for toLocaleString(, toLocaleDateString(, Date.now() and Math.random() inside components that render on the server. Each one is either deterministic on purpose, or a mismatch that has not met a user in another timezone yet.

Hydration mistakes also slow pages down, because React has to redo work in the browser. I explain what that does to real-world speed scores in this plain-language guide to Core Web Vitals, and I keep every date in my Next.js templates formatted through one small helper so the server and the browser always agree.

Get the templates: https://pixelanas.gumroad.com

Which timezone bug has bitten you hardest? Drop it in the comments, especially if it only showed up in production.

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Mastering the Critical Path in Performance Budgets for Faster React Apps

Tue, 20 Oct 2026 09:05:05 +0000

What is the Critical Path in Performance Budgets?

A performance budget is a set of strict limits agreed upon by a web development team to cap resource sizes, file counts, or loading speeds. The critical path—often called the Critical Rendering Path—is the exact sequence of assets and browser processing steps required to render the initial visible portion of a webpage. Combining these two concepts means setting explicit size and time limits specifically for the code and assets that block the initial page display.

The Airport Fast Track Analogy

Imagine walking through an airport terminal to board a flight. To get through the boarding gate, you only need two essential items in your hand: your passport and your boarding pass. These two items represent your critical path.

If you try to haul three oversized suitcases, two heavy coats, and a duty-free shopping bag through the gate check all at once, you will slow down the entire line. A critical path performance budget is like an airport rule stating that passengers can only hold their passport and ticket while stepping up to the gate. Everything else—your checked luggage and heavy items—must be handled separately so you can pass through instantly.

Why it Matters in Daily Software Engineering

In modern web development, teams often bundle massive amounts of JavaScript and CSS together. When a user opens an application, the browser must download, parse, and execute all of this code before showing a single pixel of the user interface.

If software engineers do not restrict what travels down the critical path, the browser gets clogged with non-essential files—such as analytics scripts, chat widgets, or secondary modal dialogues. By defining a strict performance budget for the critical path, engineers guarantee that the essential visual structure loads within milliseconds, keeping users engaged and preventing high bounce rates on mobile networks.

Practical Code Example: React Code Splitting

To keep our critical path budget light, we should dynamically import non-essential React components so they do not block the main render. Here is how you can defer non-critical widgets using React.lazy and Suspense in a React application:

import React, { Suspense, lazy } from 'react';

// Critical component: Loaded immediately for the initial render
import Header from './Header';
import MainContent from './MainContent';

// Non-critical component: Loaded on-demand outside the critical path
const HeavyAnalyticsDashboard = lazy(() => import('./HeavyAnalyticsDashboard'));

function App() {
  return (
    <div className="app-container">
      {/* Essential components render without delay */}
      <Header />
      <MainContent />

      {/* Non-critical component is deferred with a lightweight fallback */}
      <Suspense fallback={<div>Loading analytics...</div>}>
        <HeavyAnalyticsDashboard />
      </Suspense>
    </div>
  );
}

export default App;

By splitting the bundle, HeavyAnalyticsDashboard is pulled out of the critical rendering budget, ensuring the Header and MainContent display almost instantaneously.

Key Takeaway

Managing your critical path within a performance budget is not about stripping away feature-rich functionality; it is about controlling when those features are delivered. By keeping your initial rendering pipeline lean and pushing non-essential scripts into secondary loading phases, you preserve ultra-fast initial page loads without sacrificing modern application capabilities.

Enjoyed this breakdown? Support my open-source work on Buy Me a Coffee or explore react-hook-lab!

Originally published on my blog. You can read the alternative breakdown here.

Build a Slide-In Mobile Menu in TanStack Start with Tailwind v4

Sun, 18 Oct 2026 18:49:44 +0000

A mobile menu that pops in and out works, but it feels unfinished. In this article we turn it into a drawer that slides in from the right with a fading backdrop, using only Tailwind classes and no animation library. We also keep it usable for keyboard and screen-reader users, lock the page scroll while it is open, and respect the reduced-motion setting.

This is part of the TanStack Start Basics series. It builds on the responsive Header and the separate NavLinks component from the previous part.

You can view the video Here

In the previous part, the mobile menu lived in the Header, underneath the flex container, and the hamburger button toggled it. Delete it. This is the code to remove:

{open && (
  <nav
    id="mobile-menu"
    aria-label="Mobile"
    className="border-t md:hidden"
  >
    <NavLinks
      listClass="flex flex-col px-6 py-2"
      linkClass="block py-3 text-base font-medium text-neutral-600 hover:text-black"
      onNavigate={() => setOpen(false)}
    />
  </nav>
)}

When open is false, React removes this menu from the page completely. A CSS transition needs an element that exists in both the start and end states, so there is nothing to animate. The fix is a side panel that is always on the page, which we slide off screen with Tailwind.

Always render the panel

Here is the side panel. It replaces the old menu in the same position in the header. It uses a cn helper, so you will also need this function in the utils file in your lib folder. If you use shadcn/ui, you already have it. Otherwise, install clsx and tailwind-merge (npm i clsx tailwind-merge) and add:

// src/lib/utils.ts
import type { ClassValue } from 'clsx'
import { clsx } from 'clsx'
import { twMerge } from 'tailwind-merge'

export function cn(...inputs: ClassValue[]) {
  return twMerge(clsx(inputs))
}

The panel also uses the X icon, so add these imports at the top of Header.tsx if you don't have them yet:

import { X } from 'lucide-react'
import { cn } from '@/lib/utils'

<nav
  id="mobile-menu"
  aria-label="Mobile"
  className={cn(
    'fixed inset-y-0 right-0 z-50 w-72 bg-white p-6 shadow-xl md:hidden',
  )}
>
  <button
    type="button"
    onClick={() => setOpen(false)}
    aria-label="Close menu"
    className="mb-6 ml-auto block rounded p-2 hover:bg-gray-100"
  >
    <X className="size-6" />
  </button>
  <NavLinks
    listClass="flex flex-col gap-4"
    linkClass="text-lg text-gray-600 hover:text-black"
    onNavigate={() => setOpen(false)}
  />
</nav>

Make it jump in and out

To move the panel on and off the screen, add Tailwind's translate classes with a ternary on open:

open ? 'translate-x-0' : 'translate-x-full',

Add it as a second argument to cn on the <nav>:

<nav
  id="mobile-menu"
  aria-label="Mobile"
  className={cn(
    'fixed inset-y-0 right-0 z-50 w-72 bg-white p-6 shadow-xl md:hidden',
    open ? 'translate-x-0' : 'translate-x-full',
  )}
>
  {/* the close button and NavLinks stay the same */}
</nav>

The panel now jumps on and off the screen, but it doesn't slide yet.

You may have noticed the helper function cn. It joins class names, skips the ones that are false, and if two Tailwind classes conflict, the last one wins.

Add the backdrop

Next, a dark layer behind the panel. Clicking it closes the menu, which is what people expect from a drawer. It sits one layer below the panel (z-40 against z-50) and covers the whole screen. When the menu is closed it must not catch clicks, so pointer-events-none is not optional here. Without it, an invisible full-screen layer would swallow every tap on the page. Put it right above the <nav>:

<div
  aria-hidden="true"
  onClick={() => setOpen(false)}
  className={cn(
    'fixed inset-0 z-40 bg-black/50 md:hidden',
    open ? 'opacity-100' : 'pointer-events-none opacity-0',
  )}
/>

This is how it should look in your code:

<div
  aria-hidden="true"
  onClick={() => setOpen(false)}
  className={cn(
    'fixed inset-0 z-40 bg-black/50 md:hidden',
    open ? 'opacity-100' : 'pointer-events-none opacity-0',
  )}
/>
<nav
  id="mobile-menu"
  aria-label="Mobile"
  className={cn(
    'fixed inset-y-0 right-0 z-50 w-72 bg-white p-6 shadow-xl md:hidden',
    open ? 'translate-x-0' : 'translate-x-full',
  )}
>
  <button
    type="button"
    onClick={() => setOpen(false)}
    aria-label="Close menu"
    className="mb-6 ml-auto block rounded p-2 hover:bg-gray-100"
  >
    <X className="size-6" />
  </button>
  <NavLinks
    listClass="flex flex-col gap-4"
    linkClass="text-lg text-gray-600 hover:text-black"
    onNavigate={() => setOpen(false)}
  />
</nav>

Make it slide

Now the fun part, and it takes two classes. transition-transform tells the browser to animate changes to the position, duration-300 makes it take 300 milliseconds, and ease-out makes it start fast and settle gently. The backdrop gets the same treatment, but it fades, so it uses transition-opacity.

Add this to the panel:

transition-transform duration-300 ease-out

Add this to the backdrop:

transition-opacity duration-300

Your code should look like this:

<div
  aria-hidden="true"
  onClick={() => setOpen(false)}
  className={cn(
    'fixed inset-0 z-40 bg-black/50 transition-opacity duration-300 md:hidden',
    open ? 'opacity-100' : 'pointer-events-none opacity-0',
  )}
/>
<nav
  id="mobile-menu"
  aria-label="Mobile"
  className={cn(
    'fixed inset-y-0 right-0 z-50 w-72 bg-white p-6 shadow-xl transition-transform duration-300 ease-out md:hidden',
    open ? 'translate-x-0' : 'translate-x-full',
  )}
>
  <button
    type="button"
    onClick={() => setOpen(false)}
    aria-label="Close menu"
    className="mb-6 ml-auto block rounded p-2 hover:bg-gray-100"
  >
    <X className="size-6" />
  </button>
  <NavLinks
    listClass="flex flex-col gap-4"
    linkClass="text-lg text-gray-600 hover:text-black"
    onNavigate={() => setOpen(false)}
  />
</nav>

One Tailwind v4 detail: translate-x-* sets the CSS translate property, not transform. In v4, transition-transform includes translate, so this works. If a slide ever refuses to animate, check that your transition covers translate.

Hide the closed panel

It looks right, but there is a catch. The panel is only parked off screen. Press Tab with the menu closed and focus disappears into links you can't see, and a screen reader will still read them out. The fix is the invisible class when the menu is closed.

If we add invisible and nothing else, the panel vanishes the instant you close it, and the slide-out never shows. So we also tell the transition to animate visibility, not just position. The browser keeps the panel visible until the slide finishes, then hides it.

Make two changes to the panel:

Replace transition-transform with transition-[translate,visibility].
Replace translate-x-full with invisible translate-x-full.

Your code should look like this:

<div
  aria-hidden="true"
  onClick={() => setOpen(false)}
  className={cn(
    'fixed inset-0 z-40 bg-black/50 transition-opacity duration-300 md:hidden',
    open ? 'opacity-100' : 'pointer-events-none opacity-0',
  )}
/>
<nav
  id="mobile-menu"
  aria-label="Mobile"
  className={cn(
    'fixed inset-y-0 right-0 z-50 w-72 bg-white p-6 shadow-xl transition-[translate,visibility] duration-300 ease-out md:hidden',
    open ? 'translate-x-0' : 'invisible translate-x-full',
  )}
>
  <button
    type="button"
    onClick={() => setOpen(false)}
    aria-label="Close menu"
    className="mb-6 ml-auto block rounded p-2 hover:bg-gray-100"
  >
    <X className="size-6" />
  </button>
  <NavLinks
    listClass="flex flex-col gap-4"
    linkClass="text-lg text-gray-600 hover:text-black"
    onNavigate={() => setOpen(false)}
  />
</nav>

Stop the page from scrolling

With the drawer open, scrolling still moves the page behind it, which feels sloppy. We already have an effect that listens for the Escape key, so we extend it: lock scrolling when the menu opens, and unlock it in the cleanup. Replace the useEffect from the previous part, the one that closes the menu on Escape, with this:

useEffect(() => {
  if (!open) return

  const onKeyDown = (e: KeyboardEvent) => {
    if (e.key === 'Escape') setOpen(false)
  }

  document.addEventListener('keydown', onKeyDown)
  document.body.style.overflow = 'hidden'

  return () => {
    document.removeEventListener('keydown', onKeyDown)
    document.body.style.overflow = ''
  }
}, [open])

The cleanup function runs when the menu closes and also if the Header ever unmounts, so the page can never get stuck locked.

Respect reduced motion (optional)

Some people turn on "reduce motion" in their system settings because animation makes them dizzy. Tailwind gives us a variant for that, motion-reduce:, so honoring it costs one class per element. If that's you, add motion-reduce:transition-none to the panel and the backdrop, like so.

Panel:

className={cn(
  'fixed inset-y-0 right-0 z-50 w-72 bg-white p-6 shadow-xl transition-[translate,visibility] duration-300 ease-out motion-reduce:transition-none md:hidden',
  open ? 'translate-x-0' : 'invisible translate-x-full',
)}

Backdrop:

className={cn(
  'fixed inset-0 z-40 bg-black/50 transition-opacity duration-300 motion-reduce:transition-none md:hidden',
  open ? 'opacity-100' : 'pointer-events-none opacity-0',
)}

Test it and wrap up

Open the menu: the panel slides in and the backdrop fades.
Click the backdrop: the menu closes.
Open it again and press Escape: it closes.
Open it and click a link: it navigates and closes.
Close the menu and press Tab: focus skips the hidden links.
Open the menu and try to scroll the page: it stays put.
Turn on reduced motion in your system settings: the menu appears with no animation.

Let's recap. We always render the panel and move it with translate. The backdrop fades and closes the menu. transition-[translate,visibility] keeps the slide-out visible, then hides the panel from keyboards and screen readers. We locked the page scroll, and we respect reduced motion. All of it is plain Tailwind classes and one small effect.

Good to know and what to try next

A gotcha: a fixed element is positioned against the viewport unless an ancestor has a transform, filter or backdrop-filter. If your header uses backdrop-blur, move the backdrop and panel outside the <header> element or the drawer will be sized to the header instead of the screen.

Tell screen readers the menu state: the hamburger button from the previous part should announce whether the menu is open. Add aria-expanded and aria-controls (the <nav> already has id="mobile-menu"), and keep the label constant, because the state comes from aria-expanded and a label that flips between "Open" and "Close" can make it get announced twice. If your button already has a label like "Open menu", change it to a fixed one:

<button
  type="button"
  onClick={() => setOpen((o) => !o)}
  aria-expanded={open}
  aria-controls="mobile-menu"
  aria-label="Menu"
>
  {/* your hamburger icon */}
</button>

Try next:

Close the menu automatically when the window grows past the md breakpoint, so the scroll lock can never be left on.
Move focus to the Close button when the menu opens, and back to the hamburger when it closes.
Swap the slide for a left-side drawer by changing right-0 to left-0 and translate-x-full to -translate-x-full.

Next in the series: error handling and a proper not-found page.

Fix: useSearchParams() Should Be Wrapped in a Suspense Boundary (and Why It Only Breaks at Build

Sun, 18 Oct 2026 12:23:34 +0000

You add a small search box to your navbar. It reads the query string, so you reach for useSearchParams(). Everything works in next dev. You push, the deploy fails, and the build log says:

useSearchParams() should be wrapped in a suspense boundary at page "/about".
Read more: https://nextjs.org/docs/messages/missing-suspense-with-csr-bailout

Notice the page name. You did not touch /about. That detail is the whole story.

The Code That Triggers It

// components/SearchBox.tsx
'use client';

import { useSearchParams } from 'next/navigation';

export function SearchBox() {
  const searchParams = useSearchParams();
  const query = searchParams.get('q') ?? '';

  return <input defaultValue={query} placeholder="Search..." />;
}

// app/layout.tsx
import { SearchBox } from '@/components/SearchBox';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>
        <nav>
          <SearchBox />
        </nav>
        {children}
      </body>
    </html>
  );
}

Nothing here looks wrong, and next dev agrees with you.

Why Only the Build Complains

At build time, Next.js tries to pre-render every page that does not obviously need request data into static HTML. That is the fast path, and it is the default.

But a static page is built once, before any visitor exists, so it has no query string. useSearchParams() needs one. Next.js handles this by bailing out of static rendering for that part of the tree: the component is skipped on the server and rendered in the browser instead.

The catch is how far the bail-out spreads. Without a Suspense boundary around the component, the nearest boundary is the page itself, which would turn the whole page into client-side rendering and quietly throw away the static HTML you were about to ship. Instead of letting that happen silently, the build fails and asks you to say where the boundary should be.

Dev mode renders every page on demand, so it never has to make that decision, which is why the error only shows up when you build.

Why It Hits Every Page at Once

I put the component in layout.tsx on purpose. A shared layout wraps every page, so one unguarded useSearchParams() in a navbar breaks the build for /, /about, /pricing and every other static route at the same time.

That is also why the error names a page you never edited. The problem lives in a shared component.

Fix 1: Wrap the Component in Suspense

// app/layout.tsx
import { Suspense } from 'react';
import { SearchBox } from '@/components/SearchBox';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>
        <nav>
          <Suspense fallback={<input disabled placeholder="Search..." />}>
            <SearchBox />
          </Suspense>
        </nav>
        {children}
      </body>
    </html>
  );
}

Now only the search box is rendered in the browser. Everything else stays static HTML. The fallback is what visitors see until the client takes over, so make it the same size as the real component to avoid the layout jumping when it swaps in.

This is the fix to reach for first. It keeps your pages static and limits the client-side part to the one component that needs it.

Fix 2: Read the Params on the Server and Pass Them Down

If the value is only needed on one page, skip the hook entirely. Pages receive searchParams as a prop:

// app/search/page.tsx
export default async function SearchPage({
  searchParams,
}: {
  searchParams: Promise<{ q?: string }>;
}) {
  const { q } = await searchParams;
  return <SearchResults query={q ?? ''} />;
}

In Next.js 15, searchParams is a Promise, so it has to be awaited. Reading it marks that page as dynamic, so it renders per request instead of at build time. For a real search results page that is exactly what you want.

Fix 3: Force the Route to Be Dynamic

export const dynamic = 'force-dynamic';

This also makes the error disappear, but it does so by giving up static rendering for the route. Use it when the page genuinely depends on the request, not as a way to silence the build. On a marketing page it trades speed for nothing.

Which Fix When

Situation	Fix
Small interactive component reads the URL (navbar search, filters, tabs)	Suspense around that component
An entire page depends on the query string	Read `searchParams` in the page
The page really is per-request	`force-dynamic`

A Detail Worth Knowing About the Fallback

Whatever sits inside the Suspense boundary is client-rendered, so it will not be in the initial HTML. For a search input that does not matter. For content you want indexed, keep it outside the boundary. A fallback that does not match the final size also adds layout shift, which counts against your Core Web Vitals. I cover what those metrics measure in this plain-language guide.

The Rule

A client component that reads request-time data needs a Suspense boundary, so Next.js knows how much of the page to make dynamic. Put the boundary as close to the component as you can, and the rest of the page stays static.

I wrap every URL-driven component this way across my Next.js templates, so the production build never depends on where a navbar or filter bar ends up in the layout.

Get the templates: https://pixelanas.gumroad.com

Search your project for useSearchParams and check that every use sits inside a Suspense boundary, especially anything imported by layout.tsx. If you have hit a different build-only error, drop it in the comments.

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Your Server Action Error Messages Vanish in Production, and Throwing Is the Wrong Tool

Sat, 17 Oct 2026 09:48:36 +0000

Here is a bug report you will eventually get: "The signup form told me what was wrong on your machine, but on the live site it just says something went wrong."

Nothing is broken. Next.js is doing this on purpose. But the code that triggers it looks completely normal, and it is in a lot of Server Actions tutorials, including a version in my own earlier post on replacing API routes.

The Code That Works Locally

// actions/signup.ts
'use server';

export async function signup(formData: FormData) {
  const email = formData.get('email') as string;

  const existing = await User.findOne({ email });
  if (existing) {
    throw new Error('That email is already registered');
  }

  await User.create({ email });
}

// components/SignupForm.tsx
'use client';

export function SignupForm() {
  const [error, setError] = useState('');

  async function handleSubmit(formData: FormData) {
    try {
      await signup(formData);
    } catch (e) {
      setError((e as Error).message);
    }
  }

  return (
    <form action={handleSubmit}>
      <input name="email" type="email" />
      <button type="submit">Sign up</button>
      {error && <p>{error}</p>}
    </form>
  );
}

In development, a duplicate email shows "That email is already registered". After next build and next start, or on Vercel, the same submission shows a generic message about an error occurring on the server, with a short digest string instead of your text.

Why Next.js Hides It

An error thrown on the server can carry anything: a database connection string inside a driver message, a file path, a query, a stack trace. If Next.js forwarded every thrown message to the browser, a single unexpected failure could leak internal details to anyone watching the network tab.

So in production builds, Next.js replaces the message of a thrown error with a generic one and attaches a digest, a short hash you can search for in your server logs. In development it shows you the real message because you are the only one looking.

That is the correct default. The mistake is using throw for something that is not an unexpected failure.

Two Kinds of Errors, Two Different Tools

Expected errors are things that will happen during normal use: a duplicate email, a wrong password, a failed validation, a card that was declined. The user should see a specific message and fix it.

Unexpected errors are things that should not happen: the database is down, a bug, a null that should not be null. The user should see a safe generic message and you should see the details in your logs.

throw is the right tool for the second kind. It is the wrong tool for the first, because the framework treats every thrown error as potentially sensitive and strips it.

The Fix: Return Expected Errors as Data

// actions/signup.ts
'use server';

import { z } from 'zod';

const SignupSchema = z.object({
  email: z.string().email('Enter a valid email'),
});

export type SignupState = {
  success: boolean;
  message?: string;
  fieldErrors?: Record<string, string[]>;
};

export async function signup(
  prevState: SignupState | null,
  formData: FormData
): Promise<SignupState> {
  const parsed = SignupSchema.safeParse({
    email: formData.get('email'),
  });

  if (!parsed.success) {
    return {
      success: false,
      fieldErrors: parsed.error.flatten().fieldErrors,
    };
  }

  const existing = await User.findOne({ email: parsed.data.email });
  if (existing) {
    return { success: false, message: 'That email is already registered' };
  }

  await User.create({ email: parsed.data.email });
  return { success: true, message: 'Account created' };
}

// components/SignupForm.tsx
'use client';

import { useActionState } from 'react';
import { signup } from '@/actions/signup';

export function SignupForm() {
  const [state, action, isPending] = useActionState(signup, null);

  return (
    <form action={action}>
      <input name="email" type="email" />
      {state?.fieldErrors?.email && <p>{state.fieldErrors.email[0]}</p>}
      <button type="submit" disabled={isPending}>
        {isPending ? 'Creating account...' : 'Sign up'}
      </button>
      {state?.message && <p>{state.message}</p>}
    </form>
  );
}

A returned value is just data. Next.js does not treat it as sensitive, so the exact same message reaches the user in development and in production. You also get useActionState handling pending state and the previous result for free, with no try/catch in the component.

Keep `throw` for the Real Failures

export async function signup(prevState, formData) {
  // ...expected errors returned as data above...

  try {
    await User.create({ email: parsed.data.email });
  } catch (error) {
    console.error('signup failed', error); // full details stay in your logs
    throw error; // user gets the safe generic message
  }

  return { success: true, message: 'Account created' };
}

When this throws in production, the user sees the generic message and an error boundary can take over. You search your logs for the digest and find the real error. Nothing sensitive reaches the browser.

Why This Survives Testing

Every manual test happens in next dev, where thrown messages are shown in full. The code looks perfect right up until the first production build, which is usually when real users start signing up.

The Rule

Return expected errors as data, throw only for unexpected failures. If a message is meant for the user to read, it should travel as a returned value. If it is meant for you to debug, it should go to your logs and surface to the user as something generic.

I use this return-a-state pattern in the forms and dashboard actions across my Next.js templates, so validation messages behave identically in development and on the live site.

Get the templates: https://pixelanas.gumroad.com

Search your own codebase for throw new Error inside files marked 'use server'. For each one, ask whether a user is supposed to read that message. If yes, it is probably already invisible in production. Drop what you find in the comments.

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Responsive Navigation in TanStack Start: Hamburger Menu and Desktop Navbar

Fri, 16 Oct 2026 02:14:20 +0000

A header that works on a phone and on a desktop is one of the first things every site needs. In this part of the TanStack Start Basics series, we'll build one with inline links on wide screens, a hamburger menu on small ones, and a few accessibility details that are easy to skip.

You can watch the video here: Responsive Navigation. Everything below is the written version.

Write the links once

Start with a single list of links that both menus will read from:

// src/lib/nav.ts
export const navLinks = [
  { to: '/', label: 'Home' },
  { to: '/products', label: 'Products' },
  { to: '/about', label: 'About' },
  { to: '/contact', label: 'Contact' },
] as const;

The as const lets TypeScript treat every to as an exact route, so a typo is a compile error and not a broken link.

Think mobile first

Tailwind is mobile first. Classes without a prefix apply to every screen size, and a prefix such as md: applies from that width upward. So the plan is to style the phone version first, and then add the desktop changes on top:

hidden md:block is hidden on phones and shown from 768px up (the desktop links)
md:hidden is shown on phones and hidden from 768px up (the menu button and the mobile menu)

A separate NavLinks component

Both menus need the same list of links, so it gets its own component. Start with the props type:

// src/types/index.ts
export type NavLinksProps = {
  listClass: string;
  linkClass: string;
  activeClass?: string;
  onNavigate?: () => void;
};

Then the component:

// src/components/NavLinks.tsx
import { Link } from '@tanstack/react-router';
import { navLinks } from '@/lib/nav';
import type { NavLinksProps } from '@/types';

export default function NavLinks({
  listClass,
  linkClass,
  activeClass = 'text-black underline underline-offset-4',
  onNavigate,
}: NavLinksProps) {
  return (
    <ul className={listClass}>
      {navLinks.map((link) => (
        <li key={link.to}>
          <Link
            to={link.to}
            activeOptions={{ exact: link.to === '/' }}
            className={linkClass}
            activeProps={{ className: activeClass }}
            onClick={onNavigate}
          >
            {link.label}
          </Link>
        </li>
      ))}
    </ul>
  );
}

The two class props let each menu style the list its own way. activeClass has a default, so most callers can leave it out, and onNavigate is optional, so the desktop menu doesn't need it. Because the component lives in its own file, you can reuse it later, in a footer for example, without copying anything.

The header

// src/components/Header.tsx
import { useEffect, useState } from 'react';
import { Link } from '@tanstack/react-router';
import { Menu, X } from 'lucide-react';
import NavLinks from '@/components/NavLinks';

export default function Header() {
  const [open, setOpen] = useState(false);

  useEffect(() => {
    if (!open) return;
    const onKeyDown = (e: KeyboardEvent) => {
      if (e.key === 'Escape') setOpen(false);
    };
    window.addEventListener('keydown', onKeyDown);
    return () => window.removeEventListener('keydown', onKeyDown);
  }, [open]);

  return (
    <header className="border-b bg-white">
      <div className="mx-auto flex h-16 max-w-6xl items-center justify-between px-6">
        <Link to="/" className="text-lg font-bold">
          My Store
        </Link>

        <nav aria-label="Main" className="hidden md:block">
          <NavLinks
            listClass="flex items-center gap-6"
            linkClass="text-sm font-medium text-neutral-600 hover:text-black"
          />
        </nav>

        <button
          type="button"
          onClick={() => setOpen((o) => !o)}
          aria-label={open ? 'Close menu' : 'Open menu'}
          aria-expanded={open}
          aria-controls="mobile-menu"
          className="flex size-11 items-center justify-center rounded-md md:hidden"
        >
          {open ? <X className="size-6" /> : <Menu className="size-6" />}
        </button>
      </div>

      {open && (
        <nav
          id="mobile-menu"
          aria-label="Mobile"
          className="border-t md:hidden"
        >
          <NavLinks
            listClass="flex flex-col px-6 py-2"
            linkClass="block py-3 text-base font-medium text-neutral-600 hover:text-black"
            onNavigate={() => setOpen(false)}
          />
        </nav>
      )}
    </header>
  );
}

If you skip this, you'll notice a bug: you tap a link, the page changes, and the menu stays open. The header lives in a layout route, and a layout stays mounted while the pages inside it change, so its state is never reset.

The fix is to close the menu in the link's click handler, which is where the user's action happens. React's documentation recommends handling things caused by a user action in the event handler for that action, and not in an effect. So NavLinks gets an optional onNavigate prop, and only the mobile menu passes () => setOpen(false).

This also closes the menu when you tap the link for the page you're already on, which an effect that watches the path would miss. If you also want the menu to close when the user presses the browser's back button, you can add an effect that watches the path on top of this, but the click handler covers the main case.

Active links

Link knows when it points at the current page, and activeProps lets you style that state. Every path starts with a slash, so the home link would look active everywhere. activeOptions={{ exact: true }} fixes that, and the code above applies it only to the home link.

Accessibility basics

Use a real button for the toggle, with type="button", so the keyboard can reach it
Label it with aria-label, and update the label with the state
Use aria-expanded and aria-controls so assistive technology knows whether the menu is open
Close the menu with the Escape key
Give each nav its own label, so a screen reader user can tell them apart

Use it in the layout

// src/routes/_appLayout.tsx
import { createFileRoute, Outlet } from '@tanstack/react-router';
import Header from '@/components/Header';

export const Route = createFileRoute('/_appLayout')({
  component: AppLayout,
});

function AppLayout() {
  return (
    <>
      <Header />
      <main className="mx-auto max-w-6xl px-6 py-8">
        <Outlet />
      </main>
    </>
  );
}

Try it

Open your browser's device toolbar and drag the width between 375px and 1024px. The hamburger should appear below 768px, and the inline links above it. Tap a link in the mobile menu and check that it closes.

What's next

In the next part, we'll look at slide-in animation and a dark mode toggle. If you got stuck anywhere, leave a comment on the video.

Why Your Tailwind Classes Work in Development and Silently Vanish in Production

Thu, 15 Oct 2026 12:05:37 +0000

Almost every Tailwind developer hits this exact bug once, usually right after a deploy, and the confusing part is that nothing about it looks wrong in the code, nothing throws an error, and it worked completely fine five minutes earlier on the same machine.

The Code That Looks Completely Reasonable

function StatusBadge({ status }: { status: 'success' | 'warning' | 'error' }) {
  const color = status === 'success' ? 'green' : status === 'warning' ? 'yellow' : 'red';

  return (
    <span className={`bg-${color}-100 text-${color}-800 px-2 py-1 rounded`}>
      {status}
    </span>
  );
}

In development, this renders exactly as expected, colored badges for each status, built dynamically from a single reusable component instead of three separate hardcoded ones. Then you deploy, and every badge renders as a plain, unstyled span. No color, no padding in some setups, nothing, depending on exactly what else got purged alongside it.

Why This Happens: Tailwind Doesn't Actually Execute Your Code

Tailwind doesn't run your JavaScript to figure out which classes you're using. It scans your source files as plain text, looking for strings that match known utility class patterns, and only generates CSS for the classes it actually finds written out, literally, somewhere in that scanned text.

className={`bg-${color}-100 text-${color}-800`}

Tailwind's scanner sees the literal text bg-${color}-100, not bg-green-100, bg-yellow-100, or bg-red-100. Template literal interpolation happens at runtime, in the browser or on your server, long after Tailwind's build step has already finished scanning your source files and generating the final CSS. Since none of the three actual color classes your component needs ever appears as literal, complete text anywhere in your codebase, Tailwind never generates CSS for any of them, and the class names that do get applied to the DOM at runtime simply don't exist in your stylesheet at all.

Why This Specifically Survives Local Development

This is the part that makes the bug genuinely sneaky rather than just a misunderstanding: in development mode, especially with certain dev server configurations or cached builds from before the dynamic class was introduced, you can sometimes see the correct styling anyway, either because an earlier full build still has the class generated from some other literal usage elsewhere in the project, or because of how some dev tooling handles incremental rebuilds. The failure shows up specifically in a clean production build, which scans and purges from scratch, with nothing left over from earlier development sessions to accidentally mask the problem.

The Fix: Always Write Complete Class Names, Literally

function StatusBadge({ status }: { status: 'success' | 'warning' | 'error' }) {
  const styles = {
    success: 'bg-green-100 text-green-800',
    warning: 'bg-yellow-100 text-yellow-800',
    error: 'bg-red-100 text-red-800',
  };

  return (
    <span className={`${styles[status]} px-2 py-1 rounded`}>
      {status}
    </span>
  );
}

Every complete, literal class name Tailwind needs now appears as actual text somewhere in the source file, bg-green-100, bg-yellow-100, bg-red-100, text-green-800, and so on, even though the specific one that gets applied is still chosen dynamically at runtime based on status. Tailwind's scanner finds all three as literal strings during the build, generates CSS for all three, and the correct one gets applied correctly regardless of which branch of the mapping object actually executes.

The Rule That Generalizes Beyond This One Example

Tailwind only generates CSS for class names that exist as complete, literal text somewhere in your scanned source files, string concatenation and template literal interpolation don't count, no matter how confident the resulting string looks at runtime. This applies to any dynamic styling pattern, not just color variants, conditionally built spacing classes, responsive variants built from a variable, state-based classes constructed from a prop, all of them need the complete literal class name written out somewhere Tailwind's scanner can see it, usually in a lookup object exactly like the one above, rather than assembled through string interpolation.

I keep every dynamic variant mapped out explicitly like this across the component libraries in my Next.js and Tailwind templates, specifically because this exact bug is so easy to reintroduce months later when someone, often future-you, refactors a component back toward the more compact-looking interpolated version without remembering why it was written the longer way.

Get the templates: https://pixelanas.gumroad.com

Go check your own codebase for className={...${variable}...} patterns building Tailwind classes dynamically. If you find one, do a clean production build and actually look at it, don't trust how it renders in dev. Drop what you find in the comments.

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Your Next.js Page Might Be Caching One User's Data and Serving It to Everyone Else

Wed, 14 Oct 2026 07:51:52 +0000

This is the kind of bug that goes from "works perfectly in every test" to "actively leaking one customer's data to another customer" without a single code change in between, purely because of how caching and personalization interact in a way that isn't obvious from reading the component code.

The Setup

// app/dashboard/page.tsx
export default async function DashboardPage() {
  const session = await getServerSession();
  const user = await User.findById(session.userId);

  return (
    <div>
      <h1>Welcome back, {user.name}</h1>
      <p>Account balance: {user.balance}</p>
    </div>
  );
}

This looks obviously personalized, it reads the session, looks up the specific user, renders their specific data. There's nothing here that looks like it needs special caching considerations. That assumption is exactly where this goes wrong.

Why Next.js Can Get This Wrong

Next.js's App Router tries to statically render as much as possible by default, for good performance reasons. A page gets treated as static (cacheable, shared across all visitors) unless something in it signals that it needs to be dynamic (rendered fresh per-request). Specific APIs, reading cookies(), headers(), or searchParams directly, are what tell Next.js a page actually depends on request-specific data and needs dynamic rendering.

The problem is that getServerSession() in the example above may, depending on exactly how it's implemented and which auth library version you're on, read the session cookie in a way that doesn't always propagate that dynamic signal up to the page itself, especially if the cookie read happens inside a library function several layers removed from the page component, rather than a direct cookies() call visible in the page's own code. When that signal doesn't propagate correctly, Next.js can determine the page is eligible for static optimization, render it once during the build or on first request, and then serve that exact same rendered HTML, including the first user's name and balance, to every subsequent visitor who hits that route, until the cache naturally expires or gets invalidated.

Why This Is Specifically Dangerous, Not Just Buggy

A caching bug that shows stale content is annoying. A caching bug that shows a different user's personal data is a real data exposure incident, and the specific danger here is that it doesn't look like a caching bug from the outside, it looks like the application is broken for that specific user, showing someone else's name and balance, which can easily get reported and triaged as "a display bug" rather than correctly identified as a serious caching and session isolation issue.

Why This Survives Normal Testing

Testing a dashboard page almost always means logging in as a specific test user and confirming their own correct data renders. That test passes regardless of whether the response got cached and shared or genuinely rendered fresh for that specific request, because from a single test account's perspective, the result looks identical either way. The bug only becomes visible with two separate user sessions hitting the same route in a way that reveals the cached response is actually shared, which isn't a scenario most manual or automated testing naturally covers.

The Fix: Force Dynamic Rendering Explicitly for Anything Personalized

Don't rely on an auth helper's internal implementation to correctly signal dynamic rendering. State it explicitly for any route serving per-user data:

// app/dashboard/page.tsx
export const dynamic = 'force-dynamic';

export default async function DashboardPage() {
  const session = await getServerSession();
  const user = await User.findById(session.userId);

  return (
    <div>
      <h1>Welcome back, {user.name}</h1>
      <p>Account balance: {user.balance}</p>
    </div>
  );
}

The export const dynamic = 'force-dynamic' line removes any ambiguity about whether the page qualifies for static optimization. It costs the performance benefit of static rendering for that specific route, which is the correct tradeoff for anything genuinely personalized, that cost is real but small compared to the alternative.

An equally valid alternative is calling cookies() or headers() directly inside the page itself, rather than only inside a wrapped auth helper function, since a direct call from the page component is what reliably signals dynamic rendering without depending on how a library internally implements its own session check.

import { cookies } from 'next/headers';

export default async function DashboardPage() {
  cookies(); // explicit, direct call signals dynamic rendering regardless of what getServerSession does internally
  const session = await getServerSession();
  // ...
}

The Rule

Any page serving per-user or per-request data needs to explicitly and verifiably opt out of static rendering, not just assume an auth library's internals do that correctly on its behalf. This matters more, not less, as auth libraries and caching layers evolve between versions, since a signal that correctly propagated in one version can silently stop doing so after an update you didn't closely audit.

I treat every authenticated dashboard route as explicitly force-dynamic by default in the Next.js dashboard templates I build, specifically because the cost of guessing wrong here is a real user data leak, not just a stale page.

Get the templates: https://pixelanas.gumroad.com

Go check your own authenticated pages for an explicit dynamic export or a direct cookies()/headers() call, rather than relying on an auth helper to signal it correctly on your behalf. If you're not sure, this is worth verifying with two separate logged-in sessions today, not assuming. Drop what you find in the comments.

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Isolate to Elevate: Why Component Testing in Isolation Saves Your Codebase

Mon, 12 Oct 2026 13:46:09 +0000

Isolate to Elevate: Why Component Testing in Isolation Saves Your Codebase

Component testing in isolation is a software verification strategy where an individual piece of an application—such as a button, user profile card, or navigation bar—is evaluated entirely on its own. Instead of connecting the component to real databases, live servers, or neighboring UI elements, developers replace external dependencies with controlled, artificial placeholders called mocks or stubs. This guarantees that if a test fails, the issue is guaranteed to exist inside that specific component rather than in an external network or backend service.

A Real-Life Analogy: The Bench-Tested Alternator

Imagine a mechanic inspecting a newly manufactured car alternator. Instead of installing the alternator inside a fully assembled luxury vehicle, turning the key in the ignition, and hoping the dashboard lights illuminate, the mechanic places the alternator onto a specialized workbench.

On this test bench, artificial wires power the alternator, and a standalone machine spins its rotor while measuring electrical voltage. If the meter shows an improper charge, the mechanic instantly knows the alternator itself is defective. There is zero ambiguity—the problem cannot be blamed on a dead car battery, a frayed ignition wire, or a blown fuse elsewhere in the vehicle. Component testing in isolation applies this exact bench-test philosophy to user interface elements.

Why Component Testing in Isolation Matters Daily

In modern web development, frontend components frequently rely on complex API (Application Programming Interface) calls—the background communication channels that fetch data from databases over the internet. If you attempt to test a component while connected to live production or staging servers, your automated tests become fragile and unpredictable. A minor network hiccup or scheduled database maintenance will cause UI tests to fail, triggering false alarms and wasting valuable engineering hours.

Testing components in isolation eliminates this instability. It yields significant daily benefits:

Lightning-Fast Execution: Tests run in a local memory environment without waiting for HTTP network responses, executing hundreds of checks in milliseconds.
Deterministic Feedback: Tests yield identical, repeatable results regardless of backend availability or database state.
Effortless Edge-Case Coverage: Developers can effortlessly simulate tricky scenarios, such as slow network connections, server crash codes (like 500 errors), or extremely long text strings, without needing to manipulate a real server.

Code Example: Testing a React Component in Isolation

Below is a practical example using React (a popular JavaScript library for building user interfaces) and React Testing Library.

First, here is our component, UserProfile:

// UserProfile.jsx
import React from 'react';

export function UserProfile({ user, isLoading, error }) {
  if (isLoading) {
    return <div data-testid="loading">Loading user details...</div>;
  }

  if (error) {
    return <div data-testid="error">Error loading user profile.</div>;
  }

  return (
    <div className="user-card">
      <h2>{user.name}</h2>
      <p>Email: {user.email}</p>
    </div>
  );
}

Now, we test UserProfile in total isolation. Notice how we pass fake JavaScript object data directly through props (inputs passed to React components) without making real network requests:

// UserProfile.test.jsx
import React from 'react';
import { render, screen } from '@testing-library/react';
import { UserProfile } from './UserProfile';

test('renders user details correctly when data is provided', () => {
  // 1. Arrange: Create mock user data
  const mockUser = { name: 'Sarah Connor', email: 'sarah@skynet.com' };

  // 2. Act: Render component in isolation
  render(<UserProfile user={mockUser} isLoading={false} error={false} />);

  // 3. Assert: Verify the rendered output
  expect(screen.getByText('Sarah Connor')).toBeInTheDocument();
  expect(screen.getByText('Email: sarah@skynet.com')).toBeInTheDocument();
});

test('renders error message during failure state', () => {
  render(<UserProfile user={null} isLoading={false} error={true} />);

  expect(screen.getByTestId('error')).toHaveTextContent('Error loading user profile.');
});

In these tests, the render function mounts UserProfile inside a simulated virtual browser. We control every input state directly, ensuring complete certainty over what we are testing.

Summary Takeaway

Building resilient digital experiences requires modular confidence. By isolating individual UI components during automated testing, engineering teams replace slow, flaky test pipelines with deterministic feedback loops that pinpoint bugs in milliseconds. Mastering this technique ensures that every piece of your user interface is proven battle-ready before it ever integrates into a larger software ecosystem.

Originally published on my blog. You can read the alternative breakdown here.

https://dev.to/senthil_kumar_b6b9dcdaa4e/stop-rewriting-browser-fingerprinting-logic-in-react-meet-u

Sun, 11 Oct 2026 21:10:23 +0000

Stop Rewriting Browser Fingerprinting Logic in React: Meet `useFingerprint`

Browser fingerprinting is an interesting technique for understanding whether multiple browser visits might come from the same browser environment. But if you're building React applications, implementing browser-signal collection and managing its lifecycle can quickly become repetitive.

What if you could encapsulate that functionality in a reusable React hook and use it wherever you need it?

That's the idea behind useFingerprint, one of the browser-focused hooks in useThisHook, an open-source collection of reusable React hooks.

Explore the live demo: https://usethishook.mentorbridge.in/useFingerprint

What Is Browser Fingerprinting?

Every browser exposes information about its environment. Depending on browser capabilities and permissions, this may include:

Browser and platform characteristics
Screen dimensions and display properties
Language and locale settings
Time zone information
Other browser-exposed signals

Individually, these signals may not be particularly distinctive. Combined, they can contribute to a browser fingerprint.

A browser fingerprint is a derived identifier based on characteristics of the browser environment. It can help applications assess whether visits may be associated with a similar environment.

However, there is an important distinction:

A browser fingerprint is not a guaranteed, permanent identity for a person or device.

Different browsers on the same device may produce different fingerprints. Browser updates, privacy protections, configuration changes, and fingerprinting defenses can also affect the result.

Why Use a Custom React Hook?

Imagine you're developing an application that needs to work with a browser fingerprint.

Without a reusable abstraction, you might end up implementing the following concerns in individual components:

Collecting the required browser signals
Handling asynchronous initialization, where applicable
Managing the resulting value
Integrating browser-specific logic with React's component lifecycle
Handling environments where browser APIs are unavailable

Repeating this logic across components increases maintenance costs and makes it harder to keep implementations consistent.

React custom hooks offer a better way to organize reusable stateful behavior.

Instead of coupling browser-related logic to a particular component, you encapsulate it behind a reusable function.

That is where useFingerprint comes in.

Introducing `useFingerprint` from useThisHook

useFingerprint is a browser-focused custom hook in useThisHook, a reusable React hooks library.

The library follows a straightforward philosophy:

Stop rewriting the same React hooks in every project.

Rather than rebuilding common behavior for every application, developers can install the library and import the hooks they need.

The useFingerprint hook provides an abstraction for working with a client-side visitor identifier derived from browser signals.

You can explore its interactive documentation here:

Try useFingerprint

Installation

If you haven't installed useThisHook yet, add it to your React project.

Using npm:

npm install usethishook

Using pnpm:

pnpm add usethishook

Using Yarn:

yarn add usethishook

Using `useFingerprint` in a React Component

Once the package is installed, import the hook from the library.

import { useFingerprint } from 'usethishook';

function FingerprintExample() {
  const fingerprint = useFingerprint();

  return (
    <section>
      <h2>Browser Fingerprint</h2>
      <pre>{String(fingerprint ?? '')}</pre>
    </section>
  );
}

export default FingerprintExample;

This example illustrates the intended integration pattern: call the hook inside a React component and render the resulting value.

Important: Verify the hook's exact return type and initialization behavior against the official useFingerprint documentation before using this snippet. The example assumes that the hook returns a directly renderable value; if its documented API returns an object or exposes a loading state, adapt the component accordingly.

The key idea is to keep browser fingerprinting behavior separate from the UI that consumes it.

Where Could You Use Browser Fingerprinting?

Browser fingerprinting can be relevant to several application scenarios, depending on the implementation and applicable privacy requirements.

1. Analytics and visitor analysis

Applications may use browser-derived signals as one input when analyzing repeat visits or understanding browsing patterns.

A fingerprint should not be treated as a definitive count of unique people because one person may use multiple browser environments, and multiple people may share one environment.

2. Fraud prevention

Browser signals can contribute to a broader fraud-detection system.

For example, a backend service might consider browser-derived signals alongside account activity, transaction patterns, authentication events, and other risk indicators.

A fingerprint alone should never be treated as proof of identity or sufficient evidence to block a legitimate user.

3. Session risk assessment

Applications may incorporate browser characteristics into risk assessments for sensitive workflows.

For instance, a financial application might evaluate changes in browser signals alongside authentication and session information.

For security-sensitive applications, keep the following principle in mind:

Browser fingerprints are supporting signals, not authentication credentials.

Use server-side authorization, secure session management, and appropriate authentication controls to protect sensitive operations.

Is Browser Fingerprinting Reliable?

Not completely. Understanding its limitations is essential before integrating it into a production application.

Fingerprints can change

A browser update, operating system change, or altered browser configuration may affect the collected signals.

Fingerprint collisions are possible. A fingerprint should not be assumed to be globally unique.

Privacy-focused browsers may reduce fingerprintability

Some browsers and extensions intentionally restrict or standardize exposed characteristics to make tracking more difficult.

Fingerprinting has privacy implications

Browser fingerprinting can contribute to tracking users without traditional cookies. Depending on the purpose, implementation, and jurisdiction, collecting or using fingerprint data may trigger transparency, consent, or other legal requirements.

If your application serves users in the European Union, assess your implementation against the applicable GDPR and ePrivacy requirements. Do not assume that browser-derived identifiers are exempt from privacy obligations simply because they are not stored in cookies.

Collect only what you need, explain the purpose clearly, and obtain consent where required.

Best Practices When Using `useFingerprint`

Before using browser fingerprinting in a production application, keep these practices in mind:

Define the purpose first. Avoid collecting browser signals without a clear product or security requirement.
Do not use fingerprints as authentication. A fingerprint does not prove who a user is.
Plan for changes. Your application should handle fingerprint changes and missing values gracefully.
Consider server-side rendering. Browser-specific APIs are unavailable during server rendering. Verify that the hook handles server environments safely.
Test privacy protections. Check how your application behaves when browser signals are restricted or unavailable.
Review privacy requirements. Document the data collected, retention policy, and intended use.

Why I Built useThisHook

As React developers, we repeatedly solve similar problems across projects.

Sometimes the repeated logic is simple, such as managing a boolean. Other times, it involves browser APIs, asynchronous behavior, state management, or interactions that require more careful lifecycle handling.

I built useThisHook to make reusable React behavior easier to discover, understand, and integrate.

The library brings together practical hooks with documentation and interactive examples, allowing developers to focus more on application requirements and less on repeatedly rebuilding common functionality.

useFingerprint is one example of the browser-focused utilities available in the collection.

Try It Yourself

Explore the hook, review its documented API, and experiment with the interactive example.

Live demo: https://usethishook.mentorbridge.in/useFingerprint
Library: https://usethishook.mentorbridge.in/
GitHub repository: https://github.com/senthilkumar979/useThisHook
npm package: https://www.npmjs.com/package/usethishook

If you find a useful improvement, encounter an edge case, or want to contribute another reusable hook, contributions and feedback are welcome.

Final Thoughts

Reusable hooks are valuable when they encapsulate behavior that would otherwise be duplicated across components.

Browser fingerprinting is one example where a focused abstraction can make browser-related logic easier to integrate into a React application.

But good engineering involves more than reducing boilerplate. It also means understanding the limitations, privacy implications, and security boundaries of the underlying technology.

Build reusable behavior. Keep the UI focused. Use browser signals responsibly.

That is the philosophy behind useThisHook.

Happy coding!

— Senthil Kumar

Building practical tools for React developers through useThisHook.

🔥 30 Days of Frontend — Day 4: Memoization in React

Sun, 11 Oct 2026 17:45:13 +0000

Have you ever looked at a React component and thought:

“Maybe I should wrap this function with useCallback, this calculation with useMemo, and the component with React.memo?”

You're not alone.

Memoization is one of the most frequently discussed React performance techniques. But it's also one of the easiest to misuse.

You can add memoization to an application, introduce more complexity, and still fail to improve its performance.

Why?

Because memoization is not about preventing every render. It's about avoiding work that doesn't need to happen again.

Let's understand how it works, when it helps, and when it becomes unnecessary complexity.

1. What Is Memoization?

Memoization is an optimization technique that caches the result of a computation so it can be reused when the relevant inputs haven't changed.

Imagine you have an expensive function:

function calculateTotalPrice(products: Product[]) {
  console.log("Calculating total price...");

  return products.reduce(
    (total, product) => total + product.price,
    0
  );
}

Every time you call this function, it calculates the total again.

If the product list hasn't changed, repeating the same calculation may be unnecessary.

Memoization lets us reuse a previous result when the inputs are still valid.

Conceptually:

Inputs
  |
  v
Have relevant inputs changed?
  |
  +---- Yes ----> Recalculate and cache the result
  |
  +---- No -----> Reuse the cached result

React provides three commonly used memoization APIs:

useMemo — caches a calculated value.
useCallback — caches a function reference.
React.memo — can skip a component render when its props are unchanged.

They solve different problems, so they shouldn't be treated as interchangeable.

2. `useMemo`: Cache an Expensive Calculation

Consider a product dashboard containing thousands of products.

You need to filter products by category and calculate which products match a search query.

function ProductList({
  products,
  search,
}: {
  products: Product[];
  search: string;
}) {
  const filteredProducts = products.filter((product) =>
    product.name.toLowerCase().includes(search.toLowerCase())
  );

  return (
    <ul>
      {filteredProducts.map((product) => (
        <li key={product.id}>{product.name}</li>
      ))}
    </ul>
  );
}

The filtering operation runs whenever ProductList renders.

That may be perfectly fine for a small list. But imagine the filtering logic is expensive and the component also renders because some unrelated state changes.

We can cache the calculated array with useMemo:

import { useMemo } from "react";

function ProductList({
  products,
  search,
}: {
  products: Product[];
  search: string;
}) {
  const filteredProducts = useMemo(() => {
    return products.filter((product) =>
      product.name.toLowerCase().includes(search.toLowerCase())
    );
  }, [products, search]);

  return (
    <ul>
      {filteredProducts.map((product) => (
        <li key={product.id}>{product.name}</li>
      ))}
    </ul>
  );
}

What changed?

React recalculates filteredProducts when products or search changes.

If the component renders again while both dependencies remain unchanged, React can reuse the previous result.

For example:

Initial render
  └── products + search
        └── Calculate filtered products

Unrelated state changes
  └── products + search unchanged
        └── Reuse cached result

Search changes
  └── New search value
        └── Calculate filtered products again

An important limitation

useMemo does not make every search update faster.

When the user types another character, search changes. The filtering calculation must run again to produce the correct results.

Memoization is most useful when a calculation is expensive and its dependencies remain unchanged across renders.

3. `useCallback`: Cache a Function Reference

Now let's look at useCallback.

Consider a parent component that passes an event handler to a child:

function ProductPage() {
  const [count, setCount] = useState(0);

  const handleAddToCart = (productId: number) => {
    console.log("Added product:", productId);
  };

  return (
    <>
      <button onClick={() => setCount(count + 1)}>
        Count: {count}
      </button>

      <ProductCard onAddToCart={handleAddToCart} />
    </>
  );
}

Whenever ProductPage renders, the function expression creates a new function reference.

Even though the function's logic hasn't changed, the reference is different.

That matters if ProductCard is memoized and receives the handler as a prop.

const ProductCard = React.memo(function ProductCard({
  onAddToCart,
}: {
  onAddToCart: (productId: number) => void;
}) {
  console.log("ProductCard rendered");

  return (
    <button onClick={() => onAddToCart(42)}>
      Add to cart
    </button>
  );
});

By default, React.memo compares props. A new function reference means the handler prop is considered changed, so the child may render again.

We can stabilize the function reference with useCallback:

import { useCallback, useState } from "react";

function ProductPage() {
  const [count, setCount] = useState(0);

  const handleAddToCart = useCallback((productId: number) => {
    console.log("Added product:", productId);
  }, []);

  return (
    <>
      <button onClick={() => setCount(count + 1)}>
        Count: {count}
      </button>

      <ProductCard onAddToCart={handleAddToCart} />
    </>
  );
}

Because the callback doesn't depend on any reactive values from the component, its dependency array is empty.

Now, when count changes, React can reuse the same callback reference. That allows the memoized ProductCard to skip rendering if its other props also remain unchanged.

What about dependencies?

Consider this callback:

const handleAddToCart = useCallback(() => {
  setCartCount(cartCount + 1);
}, [cartCount]);

The callback depends on cartCount, so its reference changes whenever cartCount changes.

For state updates that depend on the previous state, a functional update can sometimes avoid that dependency:

const handleAddToCart = useCallback(() => {
  setCartCount((currentCount) => currentCount + 1);
}, []);

This works because the updater receives the latest state value.

Important: useCallback caches a function reference; it doesn't make the function's execution inherently faster.

If you're not passing the function to a memoized child or using it in another dependency-sensitive context, useCallback may provide no meaningful benefit.

4. `React.memo`: Skip Unnecessary Component Renders

React.memo is different from the two hooks.

It wraps a component and lets React skip rendering it when its props are unchanged, subject to React's normal rendering behavior.

For example:

const ProductCard = React.memo(function ProductCard({
  name,
  price,
}: {
  name: string;
  price: number;
}) {
  console.log("Rendering ProductCard:", name);

  return (
    <article>
      <h3>{name}</h3>
      <p>${price}</p>
    </article>
  );
});

Suppose the parent updates a separate counter:

function ProductPage() {
  const [count, setCount] = useState(0);

  return (
    <>
      <button onClick={() => setCount((current) => current + 1)}>
        Count: {count}
      </button>

      <ProductCard name="Keyboard" price={120} />
    </>
  );
}

The parent renders when the counter changes, but the ProductCard props remain the same.

React can skip rendering ProductCard.

However, React.memo is not an absolute rendering lock. The component can still render because of its own state changes, consumed context changes, or other React behavior.

A common mistake: unstable object props

Consider this example:

<ProductCard
  product={{
    id: 1,
    name: "Keyboard",
    price: 120,
  }}
/>

A new object is created whenever the parent renders.

Even if the object contains the same data, its reference is different.

Consequently, a memoized child can still render.

This is why understanding referential equality matters when optimizing React applications.

Two objects can contain identical properties and still be different references:

const first = { name: "Keyboard" };
const second = { name: "Keyboard" };

console.log(first === second); // false

Memoization works best when the values that cross component boundaries have the stability needed for the optimization to be effective.

5. How These Three APIs Work Together

Let's put the concepts together.

Imagine a dashboard with:

A product search field
A product list
A shopping cart counter
Expensive product filtering
Memoized product cards

A possible optimization strategy is:

ProductPage
    |
    ├── useCallback
    |      └── Stabilize a handler passed to a memoized child
    |
    ├── useMemo
    |      └── Cache filtered products when dependencies are unchanged
    |
    └── ProductList
           |
           └── React.memo
                  └── Skip rendering when props are unchanged

The APIs address different sources of repeated work:

API	What it caches or optimizes	Useful when
`useMemo`	A calculated value	A calculation is expensive and dependencies often stay unchanged
`useCallback`	A function reference	Stable identity helps a memoized child or dependency-sensitive hook
`React.memo`	A component's render work based on props	A component renders often with unchanged props and rendering is costly

The key is not to use all three together automatically. Use only the optimization that addresses the measured bottleneck.

6. When Memoization Doesn't Help

Memoization has costs too.

It adds some combination of dependency tracking, comparisons, cached values, and code complexity.

Consider this example:

const fullName = useMemo(() => {
  return `${firstName} ${lastName}`;
}, [firstName, lastName]);

Unless there is a specific reason to cache this value, the direct version is simpler:

const fullName = `${firstName} ${lastName}`;

Combining two strings is inexpensive. Memoizing it is unlikely to produce a measurable improvement.

Another example:

const handleClick = useCallback(() => {
  console.log("Clicked");
}, []);

If this function is used only by a regular button in the same component, stabilizing its identity may not improve anything.

The lesson is simple:

Not every calculation is expensive, not every render is a problem, and not every new function reference matters.

7. React Compiler Changes the Conversation

Modern React projects may use the React Compiler, which can automatically memoize components, values, and functions when it can safely do so.

This means manually adding useMemo, useCallback, and React.memo everywhere is less necessary in compiler-enabled applications.

However, the compiler does not eliminate the need to understand performance.

It cannot make every expensive algorithm cheap, remove the cost of rendering thousands of unnecessary elements, or guarantee that a slow interaction will become fast.

You should still understand:

What triggers a render
How props and references change
Which calculations are expensive
When state should live closer to the components that use it
How to measure actual rendering performance

If your project uses React Compiler, follow its guidance and avoid adding manual memoization without a reason. Manual memoization can still be useful in appropriate cases, but it shouldn't be automatic boilerplate.

8. Final Takeaway

Memoization is a tool, not a coding style, and the goal isn't to eliminate every render, the goal is to make the application responsive while keeping the code maintainable.

My preferred performance workflow remains:

Measure → Identify the bottleneck → Optimize → Measure again.

Don't optimize because a component rendered, optimize because you've found work that is unnecessarily expensive.

Your useEffect Search Bar Has a Race Condition, and It Only Shows Up When Users Type Fast

Thu, 08 Oct 2026 12:08:17 +0000

This is one of those bugs where the code looks completely reasonable, passes every manual test you'd naturally think to run, and still ships with a real defect that only shows up under a specific, very common usage pattern: someone typing faster than your network requests resolve.

The Setup

// components/SearchBox.tsx
'use client';

export function SearchBox() {
  const [query, setQuery] = useState('');
  const [results, setResults] = useState<Result[]>([]);

  useEffect(() => {
    if (!query) {
      setResults([]);
      return;
    }

    async function fetchResults() {
      const res = await fetch(`/api/search?q=${query}`);
      const data = await res.json();
      setResults(data.results);
    }

    fetchResults();
  }, [query]);

  return (
    <div>
      <input value={query} onChange={(e) => setQuery(e.target.value)} />
      <ul>
        {results.map((r) => (
          <li key={r.id}>{r.title}</li>
        ))}
      </ul>
    </div>
  );
}

Type slowly, pause between letters, and this works exactly as expected. It's also wrong in a way that's specifically invisible to that kind of careful, deliberate testing.

What Actually Breaks

Say a user types "react" quickly, letter by letter: r, re, rea, reac, react. Each keystroke triggers the effect, which fires a new fetch request for that exact partial query. These five requests are now all in flight simultaneously, and nothing about this code guarantees they resolve in the order they were sent.

Network conditions are not guaranteed to preserve request order. It's entirely possible, and in practice fairly common under real-world network jitter, for the request for "r" to resolve after the request for "react" does. When that happens, setResults(data.results) runs last for the "r" response, overwriting the correct, complete results for "react" with a handful of broad, barely-relevant matches for a single letter the user stopped looking at four keystrokes ago.

The user sees a results list that doesn't match what's sitting in the input field, with no error, no warning, nothing to indicate anything went wrong. It just looks like the search is broken or laggy, which is a uniquely frustrating kind of bug to report because it's intermittent and timing-dependent, not consistently reproducible by just repeating the same steps slowly.

Why This Specifically Survives Testing

Manual testing during development almost always involves typing at a normal, deliberate pace, often pausing to look at the screen between each change. That pace gives each request time to resolve well before the next one fires, which means the race condition's actual precondition, overlapping in-flight requests for different queries, simply never occurs during the kind of testing most developers naturally do. The bug needs genuinely fast typing, a slow or inconsistent network, or both, to reliably surface, and automated tests using scripted input often type unrealistically fast without that being the specific thing anyone's checking for.

The Fix: Ignore Stale Responses

useEffect(() => {
  if (!query) {
    setResults([]);
    return;
  }

  let ignore = false;

  async function fetchResults() {
    const res = await fetch(`/api/search?q=${query}`);
    const data = await res.json();

    if (!ignore) {
      setResults(data.results);
    }
  }

  fetchResults();

  return () => {
    ignore = true;
  };
}, [query]);

The ignore flag is set in the effect's cleanup function, which React runs right before the effect re-runs for a new query value, or when the component unmounts. Every in-flight request from a now-outdated query gets its ignore flag flipped to true the moment a newer request starts, so even if the old request resolves later, its result is silently discarded instead of overwriting the current, correct state.

A Cleaner Version With AbortController

The ignore-flag pattern works, but it still lets the outdated network request complete in the background, wasting bandwidth and a server round trip for a result nobody will ever see. AbortController actually cancels the request itself:

useEffect(() => {
  if (!query) {
    setResults([]);
    return;
  }

  const controller = new AbortController();

  async function fetchResults() {
    try {
      const res = await fetch(`/api/search?q=${query}`, {
        signal: controller.signal,
      });
      const data = await res.json();
      setResults(data.results);
    } catch (err) {
      if ((err as Error).name !== 'AbortError') {
        console.error('Search failed:', err);
      }
    }
  }

  fetchResults();

  return () => {
    controller.abort();
  };
}, [query]);

Now a stale request is actually cancelled, not just ignored, which both fixes the race condition and avoids burning server resources on searches the user has already moved past.

Where Else This Exact Pattern Bites

Any useEffect that fetches data based on a value that can change again before the fetch resolves has this same underlying issue, not just search boxes. A filter dropdown firing a new query on every change, a tab switcher loading different data per tab, pagination where a user clicks "next" rapidly, all of these share the identical race condition shape. It's the same category of timing bug I build defensively around in the dashboard and data-table components across my Next.js templates, same root cause, different trigger.

The Rule

Any effect that fetches data based on a value that can change again before the request resolves needs a way to discard or cancel the outdated response. Either an ignore flag or an AbortController, but not neither. The bug is invisible in slow, deliberate testing and reliably present the moment a real user interacts with your app faster than your network responds.

Get the templates: https://pixelanas.gumroad.com

Go check your own search boxes, filters, and tab switchers for a useEffect fetch with no cleanup-based cancellation. If you find one, try typing into it as fast as you actually can. Drop what you find in the comments.

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

🧠 Coder Legion Dev Log — Building the MyZubster Metaverse from the infrastructure up

Thu, 08 Oct 2026 02:32:06 +0000

🧠 Coder Legion Dev Log — Building the MyZubster Metaverse from the infrastructure up

I’ve been working on the MyZubster Metaverse with a very specific engineering approach:

do not start from the 3D layer. Start from identity, authorization, state, lifecycle and failure handling.

The current stack already includes several production-oriented building blocks.

Identity and session model

The Metaverse supports both:

guest characters
authenticated, account-linked identities

For authenticated users, canonical character data is resolved server-side so the client cannot freely override trusted identity state.

This matters because virtual-world logic becomes much harder to secure once identity, permissions and session state are mixed together.

Realtime authorization

One of the more important backend changes was introducing a fail-closed authorization path for community realtime channels.

If the membership authority is unavailable, access is denied instead of waiting on buffered database operations or leaving socket authorization in an ambiguous state.

I added coverage for:

disconnected MongoDB state
active persisted membership
membership query failures
unauthorized access attempts

This is a small change in code, but a meaningful system-design decision.

Room lifecycle

The room layer already supports:

public / authenticated / private access policies
invitations
session creation
participant join/leave
host controls
stage requests
speaker approval/revocation
participant moderation
message reporting
bounded moderation history

The important point is that the room is treated as a stateful system, not just a visual container.

Frontend state hardening

I’ve also been cleaning up React lifecycle behavior.

Recent fixes include:

reloading room state when authentication changes
stabilizing async data loading with useCallback
tightening effect dependencies
keeping UI state aligned with server-side session state

Example recent commits:

0b5e7fa — refresh Metaverse room when auth state changes
fa94a88 — stabilize frontend loading callback
0347827 — make paid analytics explicit instead of automatic

Auth and observability testing

I also aligned tests around:

authenticated Metaverse flows
server-backed sessions
auth expiry
same-origin authenticated requests
health endpoint behavior
storage failure semantics

A previous checkpoint also hardened realtime membership authorization and added test coverage around failure states:

0af298e — fail-closed realtime auth
9ac9f53 — auth session test alignment
5bf365d — auth + observability test alignment

Deployment discipline

Another part of the work was CI/CD hygiene.

I removed automatic activation of paid Vercel Web Analytics from the deployment workflow.

That means deployment stays deterministic and billing-related features remain explicit operational decisions.

Current architecture direction

The development sequence I’m following is:

identity
→ authorization
→ state
→ room lifecycle
→ moderation
→ observability
→ realtime rendering

This is intentional.

A visually impressive world with weak session handling, unclear authorization or fragile failure modes is still a fragile system.

So the current priority is to make the platform behavior coherent before connecting the final immersive realtime rendering layer.

Skills this work is exercising

This project has been a practical exercise in:

React hooks and state synchronization
Node.js backend architecture
REST API design
realtime authorization
authentication and session handling
MongoDB / Mongoose
fail-closed security patterns
moderation systems
automated testing
observability
CI/CD
Vercel deployment workflows
production debugging
incremental system hardening

The immersive layer is still the next milestone.

But the system underneath it is becoming much more real.

Build the world after the rules of the world are reliable.

CoderLegion #SoftwareEngineering #React #NodeJS #MongoDB #Realtime #SystemDesign #DevOps #WebDevelopment #Metaverse #OpenSource

useThisHook

Wed, 07 Oct 2026 12:03:22 +0000

Stop rewriting the same React hooks in every project.

Install once. Import only what you need — toggles, storage, forms, browser APIs, and dialogs. Live demos, clear APIs, copy-paste examples. Built for React 18+.

Why useThisHook:

Less boilerplate
Toggles, debounce, timers, forms, lists, and URL state — ready to import so you stop rewriting the same helpers.

Dialogs without a UI kit
Await confirm(), prompt(), overlays, and wizards in your click handler. Mount render() once. No modal library.

Zero runtime dependencies
The published package only peers on React 18+. Works with Vite, Next.js, CRA, and Module Federation.

Docs that match the code

Every page has a live preview, an argument/return reference, and an example you can paste into your app.

Cursor vs Offset Pagination: A Frontend Engineer's Perspective in 2026

Mon, 05 Oct 2026 08:51:24 +0000

We talk about pagination as if it's purely a backend concern – the database does the heavy lifting, the API returns pages, and the frontend just renders them. But in 2026, that mental model is outdated. The frontend now owns more of the data-fetching lifecycle than ever: server components prefetch, client caches hydrate, optimistic updates mutate, and streaming responses trickle in chunk by chunk.

The choice between cursor pagination and offset pagination has real consequences for how you write your React components, how your cache behaves, how scroll feels on the phone, and what happens when a user navigates back. This post is about those tradeoffs – from the frontend seat.

The Landscape Has Changed

A few things are different in 2026 that make this conversation more nuanced than it was three or four years ago:

React Server Components are mainstream. Data fetching happens on the server in many apps, which shifts where pagination state lives and how navigation works.
TanStack Query is the de-facto standard for client-side async state, with first-class infinite query support baked in.
The "infinite scroll vs pagination" debate is mostly settled — infinite scroll wins for feeds and content-heavy apps; numbered pages win for dense data tables. Your pagination strategy should serve that decision, not fight it.
LLM-powered search and filtering are becoming common, and those use cases have their own quirks around pagination stability.
Edge caching and CDN-level pagination mean that certain offset-paginated responses can be cached by URL – a genuine advantage offset still holds.

What Frontend Engineers Actually Care About

When you strip away the SQL theory, here's what the pagination choice actually affects on the frontend:

1. Cache Key Design

With offset pagination, the cache key is simple and predictable: posts?page=3&limit=20. Every page is independently cacheable by URL — your CDN loves this. TanStack Query, SWR, and Apollo all handle this naturally.

// Offset — clean, predictable cache keys
const { data } = useQuery({
  queryKey: ['posts', { page, limit }],
  queryFn: () => fetchPosts({ page, limit }),
});

With cursor pagination, the cache key depends on the previous response. You can't know page 3's key without having fetched pages 1 and 2. This is why TanStack Query has a dedicated useInfiniteQuery API — the standard useQuery just doesn't model this shape.

// Cursor — requires infinite query primitives
const { data, fetchNextPage, hasNextPage } = useInfiniteQuery({
  queryKey: ['posts'],
  queryFn: ({ pageParam }) => fetchPosts({ cursor: pageParam, limit: 20 }),
  getNextPageParam: (lastPage) => lastPage.pagination.nextCursor ?? undefined,
});

The tradeoff: Offset gives you individually shareable, bookmarkable, CDN-cacheable page URLs. Cursor gives you a stable, append-only data structure that's ideal for infinite scroll but harder to deep-link into.

This is where offset pagination has a quiet, underappreciated advantage: it maps onto URL state naturally.

/products?page=4&sort=price_asc

A user on page 4 can bookmark it, share it, or hit back and land exactly where they were. The server can render the correct page server-side with no hydration complexity.

With cursor pagination, you'd need to store the cursor in the URL too:

/products?cursor=eyJpZCI6MTIzfQ&sort=price_asc

That works – but it's opaque to users, it breaks if the cursor expires server-side (a real issue with time-limited cursors), and it requires your RSC or SSR layer to be cursor-aware. More importantly, if the user wants to share page 4 with a colleague, that cursor only means "after item 123" — not "the 4th page of results sorted by price." These are semantically different things, and users don't distinguish between them until something breaks.

The 2026 wrinkle: With React Server Components and the App Router, navigating back often re-fetches rather than restoring scroll position. Offset pagination + URL state handles this correctly out of the box. Cursor-based infinite scroll requires extra work — typically saving scroll position to sessionStorage and restoring it, or using the experimental_useOptimistic pattern with a pre-fetched cache.

3. Optimistic Updates and Mutations

Suppose a user creates a new post. With offset pagination:

The new post appears at position 1 in the sorted order.
Pages 1 through N all shift.
Any cached pages are now stale.
You invalidate all queries with queryClient.invalidateQueries(['posts']).
The user sees a brief loading state before the refetch.

With cursor pagination:

You prepend the new post optimistically to the top of the feed.
The cursor chain stays intact — future "load more" fetches are unaffected.
You can invalidate only the first page while keeping the rest of the cache valid.

// Optimistic prepend with cursor pagination
queryClient.setQueryData(['posts'], (old) => ({
  ...old,
  pages: [
    { data: [newPost, ...old.pages[0].data], pagination: old.pages[0].pagination },
    ...old.pages.slice(1),
  ],
}));

Cursor pagination is genuinely better here. Offset pagination invalidation is coarse — you either refetch everything or accept a stale cache. Cursor pagination lets you surgically update the head of the feed while trusting the tail.

4. Scroll Performance and Virtualization

For long feeds rendered in the browser, you'll eventually reach for a virtualizer — TanStack Virtual, React Window, or similar. The pagination strategy affects how you feed data into the virtualizer.

With offset pagination, you know the total count upfront. You can pre-size the scroll container and render placeholder rows for unloaded pages:

// You can pre-allocate rows because you know totalCount
const rowVirtualizer = useVirtualizer({
  count: totalCount,
  getScrollElement: () => parentRef.current,
  estimateSize: () => 72,
});

With cursor pagination, you don't know the total. You render what you have, append more as the user scrolls, and use a sentinel element to trigger the next fetch:

// Sentinel-based infinite scroll
const { ref: sentinelRef } = useIntersectionObserver({
  onChange: (inView) => { if (inView && hasNextPage) fetchNextPage(); },
});

// At the bottom of your list:
<div ref={sentinelRef} />

Neither is strictly better — they serve different UX patterns. But in 2026, the intersection observer + cursor pattern is so well-supported and so well-understood that it should be your default for any feed-like UI.

The 2026 Tradeoff Matrix

Concern	Offset	Cursor
URL shareability / deep linking	✅ Natural	⚠️ Possible but awkward
Infinite scroll UX	⚠️ Requires workarounds	✅ Native fit
Numbered page UI ("Page 3 of 47")	✅ Trivial	❌ Not supported
Back-button behavior (RSC/App Router)	✅ Works with URL state	⚠️ Needs extra work
CDN-level page caching	✅ URL is the cache key	❌ Cursor is opaque
Optimistic prepend on new items	⚠️ Invalidates full cache	✅ Surgical cache update
Stable results under concurrent writes	❌ Skips / duplicates	✅ Stable
TanStack Query / SWR compatibility	✅ `useQuery`	✅ `useInfiniteQuery`
LLM search result pagination	✅ Page-level caching useful	⚠️ Stream-based, different model
Large dataset performance (> 1M rows)	❌ Deep offset is slow	✅ O(log N) always
SSR / RSC initial render	✅ Simple prop passing	⚠️ Needs cursor threading

The Emerging Middle Ground: Hybrid Pagination

A pattern gaining traction in 2026 is the hybrid approach — especially in apps that have both a data-table view and a feed view of the same resource.

The idea: expose cursor pagination at the API level (for stability and performance), but compute and expose a virtual page number on top of it. The frontend stores a map of pageNumber → cursor:

// Client-side page-to-cursor map
const cursorMap = useRef<Map<number, string>>(new Map([[1, '']]));

function goToPage(pageNumber: number) {
  const cursor = cursorMap.current.get(pageNumber);
  if (cursor !== undefined) {
    setCurrentCursor(cursor);
  }
  // If not in map yet, must paginate forward to reach it
}

// After each page fetch, store the cursor for the next page
function onPageFetched(pageNumber: number, nextCursor: string) {
  cursorMap.current.set(pageNumber + 1, nextCursor);
}

This is more complex but gives you the best of both worlds: server-side cursor performance and stability, with a client-side illusion of numbered pages. Libraries like Relay have done a version of this for years; it's increasingly practical with modern client-side state tooling.

What About React Server Components Specifically?

RSC changes the calculus a bit. When the server renders the initial page, it can use a cursor or offset equally well — the component is async and can await either query. But navigation changes things.

With offset + URL params, navigation is a first-class RSC operation:

// app/posts/page.tsx
export default async function PostsPage({ searchParams }) {
  const page = Number(searchParams.page ?? 1);
  const posts = await fetchPosts({ page, limit: 20 });
  return <PostList posts={posts} />;
}

Navigating to ?page=4 re-runs the server component with new params — clean, cacheable at the RSC level, and SSR-friendly.

With cursors and RSC, you need the cursor in the URL or in a server-side session. The URL is simpler and more robust:

// app/posts/page.tsx
export default async function PostsPage({ searchParams }) {
  const cursor = searchParams.cursor ?? null;
  const { posts, nextCursor } = await fetchPosts({ cursor, limit: 20 });
  return <PostList posts={posts} nextCursor={nextCursor} />;
}

Both work. But the cursor approach requires your client to manage and push the cursor into the URL, which pushes complexity back toward the client. For RSC-heavy apps, offset pagination for paginated pages and cursor pagination for client-rendered feeds is a reasonable split.

Practical Recommendation for 2026

The decision tree is simpler than it used to be:

Use cursor pagination if:

The UI is a feed, timeline, or "load more" pattern
The dataset grows fast or has high write concurrency
You're building a mobile-first or infinite-scroll experience
Correctness under concurrent updates matters

Use offset pagination if:

The UI is a data table with numbered pages and sorting controls
Users need to deep-link to or bookmark a specific page
You need CDN-level caching of paginated responses
The dataset is bounded and relatively static

Use the hybrid approach if:

You have both UX patterns on the same data
You're building a high-quality admin interface with a public-facing feed

The old "just use offset, it's simple" advice is actively harmful at scale. But the opposite — "always use cursor, it's correct" — ignores real frontend constraints around navigation, SSR, and URL state that still matter in 2026.

Pick based on your UI pattern first, your dataset characteristics second, and your caching strategy third. The backend team will thank you for having a clear answer.

🔥 30 Days of Frontend — Day 3: React Fiber

Sun, 04 Oct 2026 16:46:36 +0000

You've probably heard about React Fiber.

But why does it matter?

And more importantly:

What problem was Fiber actually designed to solve?

Fiber is React's internal architecture for representing and processing the work needed to update the UI.

You don't normally interact with Fiber directly, but understanding the idea behind it gives you a much better mental model of how modern React rendering works.

A useful simplified mental model is:

Component Tree
      ↓
   Fiber Tree
      ↓
 Scheduled Work
      ↓
Render / Reconciliation
      ↓
    Commit
      ↓
 Updated UI

The important part isn't memorizing React's internal Fiber fields.

It's understanding why this architecture exists.

🧠 Why Did React Need Fiber?

Imagine a React application with a large component tree.

A state update happens:

State Update
     ↓
React needs to render
     ↓
Large component tree
     ↓
A lot of JavaScript work

Rendering isn't free.

React may need to evaluate components, compare the new result with the previous one, determine what changed, and eventually apply the required updates.

If a large amount of work has to happen as one uninterrupted operation, it can keep the browser's main thread busy.

And the main thread isn't only responsible for React.

It also needs to handle things like:

User interactions
JavaScript execution
Layout
Painting
Animations
Browser events

So the problem becomes:

How can React manage rendering work without allowing expensive updates to unnecessarily block more important work?

This is where Fiber becomes important.

⚙️ Fiber as a Unit of Work

One of the important ideas behind Fiber is that React can represent rendering work as smaller units rather than treating an entire update as one indivisible operation.

Conceptually:

Large Rendering Task
        ↓
┌───────────────────────┐
│ Work A                │
│ Work B                │
│ Work C                │
│ Work D                │
│ Work E                │
└───────────────────────┘

Instead of thinking only in terms of:

"Render the entire application"

React can reason about individual pieces of work.

That gives React more flexibility when deciding how and when that work should be processed.

This is one of the architectural ideas that enables React to support more sophisticated scheduling and concurrent rendering capabilities.

🌳 Component Tree vs Fiber Tree

As developers, we usually think about our application as a component tree:

App
├── Header
├── Sidebar
├── Dashboard
│   ├── Statistics
│   ├── Chart
│   └── ProductList
│       ├── ProductCard
│       ├── ProductCard
│       └── ProductCard
└── Footer

Internally, React maintains a corresponding structure involving Fiber nodes.

A simplified mental model is:

Your Components
      ↓
React's Fiber representation
      ↓
Units of rendering work

A Fiber node contains information React needs while processing a particular part of the tree.

As frontend developers, we normally don't need to interact with these nodes directly.

They're an implementation detail.

But understanding that this internal representation exists helps explain how React can perform reconciliation and manage rendering work.

🔄 Render Phase vs Commit Phase

Another important concept is that React's work can be understood through two major phases:

Update
  ↓
Render Phase
  ↓
Commit Phase

These phases have different responsibilities.

Render Phase

During the render phase, React determines what the next UI should look like.

Conceptually:

State / Props Change
        ↓
Component Rendering
        ↓
Reconciliation
        ↓
Determine what changed

React is essentially trying to answer:

"Given the new state and props, what should the UI look like?"

This is where React performs much of the computational work involved in rendering and reconciliation.

Importantly, rendering does not mean React has already changed the DOM.

It's primarily about figuring out the next result.

Commit Phase

Once React has finished determining the required changes, it can move to the commit phase.

Finished Render Work
        ↓
      Commit
        ↓
Apply Required Changes
        ↓
      DOM

The commit phase is where React applies the necessary changes to the host environment, such as the browser DOM.

This distinction is useful when thinking about React performance because expensive rendering work and the actual DOM mutations are not the same thing.

🚦 Scheduling and Prioritization

One of the most interesting ideas behind modern React is that not all updates necessarily have the same urgency.

Consider two updates:

User clicks a button
        ↓
Should feel responsive immediately

versus:

Large list needs to update
        ↓
Can potentially happen with lower urgency

A useful conceptual model is:

                    React Work
                        │
            ┌───────────┴───────────┐
            ↓                       ↓
       More urgent              Less urgent
            │                       │
            ↓                       ↓
    User interaction          Background UI work

This ability to reason about work and prioritize it is an important part of the architecture behind React's concurrent features.

It's worth being precise here:

Concurrent rendering does not mean React is rendering everything on multiple threads.

JavaScript in the browser still primarily runs on the main thread.

The important idea is that React has more flexibility around when rendering work is performed, interrupted, resumed, or abandoned before committing the final result.

🧩 Why This Matters for Performance

Understanding Fiber changes how you think about React performance.

It's easy to think:

"React is fast because it uses a Virtual DOM."

That's an oversimplification.

Modern React performance involves several different concepts:

State Updates
     ↓
Scheduling
     ↓
Rendering
     ↓
Reconciliation
     ↓
Commit
     ↓
Browser Rendering

Each stage can contribute to the overall cost of an interaction.

For example, imagine a product page rendering 2,000 product cards.

2,000 Products
      ↓
2,000 ProductCard components
      ↓
Large amount of rendering work
      ↓
Slower interaction

A developer might immediately think:

"I should add React.memo."

But profiling might reveal a more fundamental problem:

Why are we rendering 2,000 products in the first place?

If the user can only see 20 products at a time, reducing the number of rendered components can be much more effective than trying to make every individual component slightly faster.

That leads to an important performance principle:

Before optimizing individual units of work, ask whether you can reduce the amount of work altogether.

🔍 Fiber and React Profiler

This is also why tools such as the React Profiler are useful.

Instead of guessing:

"Maybe useMemo will fix it."
"Maybe React.memo will fix it."
"Maybe useCallback will fix it."

you can first ask:

What work is actually happening during this interaction?

For example, you might see something like:

ProductGrid        79.9ms
ProductCard          0.4ms
ProductCard          0.3ms
ProductCard          0.4ms
...

At first glance, you might think: "ProductGrid is slow", But if thousands of ProductCards are being processed underneath it, the real problem may be the quantity of work, rather than one particularly slow component.

After reducing the visible list:

ProductGrid         1.2ms
ProductCard         0.2ms
ProductGridHeader   0.1ms

Now the performance characteristics are completely different.

This is a good example of why performance optimization should usually follow this process:

Measure
   ↓
Identify the expensive work
   ↓
Understand why it happens
   ↓
Reduce unnecessary work
   ↓
Optimize what remains
   ↓
Measure again

🎯 The Important Takeaway

I don't think frontend developers need to memorize every Fiber field or understand every internal implementation detail.

The valuable part is understanding the reason Fiber exists.

Rendering UI can be expensive, so React needs an architecture that allows it to:

Represent rendering work
Break work into manageable units
Schedule work
Prioritize updates
Reconcile changes
Commit the final result

Instead of immediately asking:

"Which optimization should I use?"

I think a better first question is:

"What work is React doing, why is it doing that work, and can I reduce it?"

Understanding Fiber gives us a much stronger mental model for reasoning about all of those decisions.

Your Server Component Might Be Fetching Data Three Times Slower Than It Needs To

Fri, 02 Oct 2026 18:05:04 +0000

This is one of the easiest performance mistakes to write without noticing, since the code reads completely naturally, top to bottom, each line waiting for the one before it to finish, exactly the way most people learn to write async code in the first place.

The Setup That Reads Perfectly Naturally

// app/dashboard/page.tsx
export default async function DashboardPage() {
  const user = await getUser();
  const posts = await getPosts();
  const comments = await getComments();
  const analytics = await getAnalytics();

  return (
    <Dashboard
      user={user}
      posts={posts}
      comments={comments}
      analytics={analytics}
    />
  );
}

Four await calls, one after another. Clean, readable, and exactly how sequential code naturally gets written when each line is just "get the next thing I need." The problem is that none of these four calls actually depend on the results of the others, getPosts doesn't need anything from getUser, getComments doesn't need anything from getPosts, and so on. They're all independently fetchable at the same time, and writing them sequentially means the total page load time is the sum of all four, not the time of the single slowest one.

Why This Costs More Than It Looks Like It Should

If each of these four calls takes roughly 150 milliseconds, a genuinely reasonable time for a real database query, the sequential version takes roughly 600 milliseconds total, each one waiting for the previous one to fully complete before even starting. Run the same four calls concurrently instead, and the total time is roughly 150 milliseconds, the time of the single slowest call, since they're all genuinely happening at once rather than queued up one behind another for no actual reason.

This is a real, measurable difference on a page real users are waiting for, and it's entirely avoidable, since nothing about these four pieces of data actually requires this sequential order, the code just happens to be written in a shape that imposes one anyway.

The Actual Fix: Promise.all for Independent Fetches

export default async function DashboardPage() {
  const [user, posts, comments, analytics] = await Promise.all([
    getUser(),
    getPosts(),
    getComments(),
    getAnalytics(),
  ]);

  return (
    <Dashboard
      user={user}
      posts={posts}
      comments={comments}
      analytics={analytics}
    />
  );
}

Promise.all starts all four requests essentially simultaneously and waits for all of them to complete together, rather than starting each one only after the last one finished. Same data, same final render, a fraction of the total wait, purely by removing an ordering constraint that was never actually necessary in the first place.

Where This Gets Genuinely Trickier: Partial Dependencies

Not every case is this clean. Sometimes one piece of data genuinely depends on another, and mixing dependent and independent fetches needs a bit more care than a single flat Promise.all.

// ❌ Everything sequential, even though posts and analytics don't need each other
export default async function DashboardPage() {
  const user = await getUser();
  const posts = await getPostsForUser(user.id); // genuinely depends on user
  const analytics = await getAnalytics(); // does NOT depend on user at all
  return <Dashboard user={user} posts={posts} analytics={analytics} />;
}

// ✅ Only the genuine dependency stays sequential, everything else runs alongside it
export default async function DashboardPage() {
  const analyticsPromise = getAnalytics(); // starts immediately, not awaited yet

  const user = await getUser();
  const posts = await getPostsForUser(user.id); // genuinely needs user.id first

  const analytics = await analyticsPromise; // was already running this whole time

  return <Dashboard user={user} posts={posts} analytics={analytics} />;
}

Starting getAnalytics() without immediately awaiting it lets that request begin running in the background while getUser and getPostsForUser proceed through their genuine, necessary sequence. By the time the code actually needs the analytics result, it's very likely already finished, or at least has been running the whole time instead of only starting after everything else completed.

How to Actually Spot This in Your Own Code

Look for multiple await statements in a row where each one calls a genuinely independent function, nothing on the left side of an earlier line appears as an argument to a later one. That absence of a real data dependency is the signal, these calls have no actual reason to be sequential, and wrapping them in Promise.all is very likely a free, meaningful performance improvement with zero behavior change.

grep -B2 -A2 "await get" app/**/page.tsx

Scanning for clusters of consecutive await calls to different functions, then checking whether any of them genuinely reference the previous line's result, is a quick, practical way to find real waterfall candidates across an existing codebase.

Why This Matters More on Pages With Several Independent Data Sources

A dashboard, a page with several distinct widgets or sections each backed by their own query, is exactly where this pattern accumulates the most cost, since it's common to have four, five, or more genuinely independent pieces of data feeding one page, each one innocently written as its own await line, each one adding its full latency on top of all the others instead of overlapping.

The Actual Rule

Before awaiting multiple async calls sequentially, check whether any of them genuinely need a previous call's result. If none do, Promise.all turns their combined wait time from a sum into a maximum, for free, with no behavior change. For a genuine mix of dependent and independent calls, start the independent ones early without immediately awaiting them, so they run in the background while the real, necessary sequence proceeds.

I check every Server Component I write for exactly this pattern now, across client work and the dashboards and templates I build at pixelanas.com, since it's one of the highest-value, lowest-effort performance fixes available, and I've written about related data-fetching patterns on the blog too.

Go check your own dashboard or any data-heavy page for consecutive await calls with no genuine dependency between them. If you find some, wrapping them in Promise.all is very likely a free win sitting right there. Drop what you find in the comments.

Get the templates: https://pixelanas.gumroad.com

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Optimizing User Idle Detection in React

Fri, 02 Oct 2026 02:38:12 +0000

Managing user idle states efficiently is critical for performance-heavy applications. In the latest update to react-hook-lab, I have refined the useIdle hook to provide more granular control over event throttling.

What Changed?

Previously, the throttle mechanism was rigid. To prevent unnecessary re-renders during high-frequency events (like mouse movement), I have updated the logic to use a dynamic throttle window. The hook now calculates effectiveThrottle as the minimum of your defined timeout or half the total duration, ensuring responsiveness while keeping the main thread lean.

Implementation Examples

Basic Usage

Simply track when a user is inactive for 5 seconds:

const isIdle = useIdle(5000);

return <div>{isIdle ? 'User is away' : 'User is active'}</div>;

Custom Throttle Behavior

The hook now automatically balances the throttle duration based on your timeout setting to prevent performance bottlenecks:

// The hook will now self-adjust the throttle to be 
// more aggressive for shorter idle timeouts.
const isIdle = useIdle(1000);

Resources

Originally published on my blog. You can read the alternative breakdown here.

Searching a Billion Records: A Field Manual for Frontend Ninjas

Wed, 30 Sep 2026 14:48:26 +0000

Listen up, Ninjas.

If your plan is to drag a billion usernames into the browser and filter() them like a street brawl in the town square, just sheath that idea. That is not stealth. That is yelling your location at the enemy camp while carrying a temple bell.

A billion-row search is won in the shadows. The dojo rule is simple:

The server guards the treasure. The frontend throws one shuriken, then
vanishes.

You do not slay the whole army. You take the head that matters and you are gone before the lanterns flicker.

First law of the clan: the haystack is not your backpack

This scroll is forbidden:

js

// Dishonor.

// Your tab will join its ancestors.

const matches = allUsernames.filter((name) =>

  name.startsWith(query)

)

A billion handles is not a list. It is a mountain. Stuffing the mountain into RAM is how junior mercenaries become a loading spinner in the sky.

The Ninja does not carry the mountain. The Ninja asks the mountain a tiny question.

Know your quarry

Instagram-style handles are clean targets. Unique. Short. Prefix-shaped.

habeeb
habeeb_lateef
habitat.ng
habibi.eats

The civilian types hab and expects a whisper of names, exact blade first. They do not want you to recite the census.

Honorable question

Names that start with hab. Eight only. If hab itself lives, put it on the throne.

Dishonorable question

Walk every soul in the empire and see if hab hides in their robes.

Prefix plus a limit is a surgical strike when the store has an index. “Contains” on a billion rows is a siege. Ninjas do not lay sieges. That is army work. Leave it.

The silent kata (what your UI actually does)

keystroke → hide in the reeds → kill the old request → ask for a prefix → paint eight shadows

Four techniques. Master them and you look instant. Miss them and you look like a tourist with cymbals.

Technique 1: Patience of the reed — debounce

Civilians tap h a b e e b like rain on a tin roof. If you leap at every drop, you are not a Ninja. You are a doorbell.

Wait until the rain pauses. Then strike once.

js

function debounce(fn, ms) {

  let smokeBomb

  return (...args) => {

    clearTimeout(smokeBomb)

    smokeBomb = setTimeout(() => fn(...args), ms)

  }

}

const hunt = debounce((query) => {

  loadSuggestions(query)

}, 200)

input.addEventListener("input", (e) => {

  hunt(e.target.value.trim().toLowerCase())

})


200ms is a decent crouch. Too eager and you spam the dojo gates. Too sleepy and the user thinks you died behind the curtain.

Also: do not unsheathe the blade for one letter. h is not a mission. It is a rumor.

```js

if (query.length < 2) {

  renderEmpty("Keep typing, Ninja. The shadows need more letters.")

  return

}
Technique 2: Assassinate yesterday’s mission — abort

You sent a crow for hab. The civilian already typed habeeb. If the old crow lands last, your dropdown lies. Lying is for politicians. Ninjas deal in current intel.

js

let livingCrow = null

async function loadSuggestions(query) {

  if (livingCrow) livingCrow.abort() // one puff of smoke. gone.

  const controller = new AbortController()

  livingCrow = controller

  const url = /api/usernames?prefix=${encodeURIComponent(query)}&limit=8

  try {

    const res = await fetch(url, { signal: controller.signal })

    const data = await res.json()

    // The box may have changed while you were in the rafters

    if (query !== input.value.trim().toLowerCase()) return

    renderList(data.results)

  } catch (err) {

    if (err.name === "AbortError") return // honorable death

    renderEmpty("The crow never returned.")

  }

}
Clan proverb:

> The latest query wears the crown. Late mail is not wisdom. It is a ghost.

Technique 3: Pocket scrolls — cache

You already asked for hab ten seconds ago. Asking again is not diligence. It is amnesia.

js

const sleeve = new Map() // query → { inkedAt, results }

const FRESHNESS = 30_000

function peekScroll(query) {

  const scroll = sleeve.get(query)

  if (!scroll) return null

  if (Date.now() - scroll.inkedAt > FRESHNESS) {

    sleeve.delete(query)

    return null

  }

  return scroll.results

}

async function loadSuggestions(query) {

  const remembered = peekScroll(query)

  if (remembered) {

    renderList(remembered) // silent win

    return

  }

  // fetch, then tuck the answer into the sleeve

  sleeve.set(query, { inkedAt: Date.now(), results: data.results })

}
Cache the empty caves too. “Nobody named xyzzy99” is still intel. Do not kick the same hollow tree twice.

Keep the sleeve small. Fifty missions, then forget the oldest. You are hoarding whispers, not the imperial archive.

Technique 4: Eight shadows, not eight thousand

Your API should look like a note slipped under a door:

http

GET /api/usernames?prefix=hab&limit=8


{

  "query": "hab",

  "results": [

    { "username": "habeeb", "exact": true },

    { "username": "habeeb_lateef" },

    { "username": "habitat" },

    { "username": "habitat.ng" },

    { "username": "habibi.eats" }

  ]

}

Then you paint only what the night gave you:


function renderList(results) {

  list.innerHTML = ""

  if (results.length === 0) {

    list.textContent = "No clan member starts with that name."

    return

  }

  for (const row of results) {

    const item = document.createElement("li")

    item.textContent = "@" + row.username

    if (row.exact) item.dataset.soke = "true" // the true heir

    list.appendChild(item)

  }

}
Eight <li>s is a tea ceremony. A thousand DOM nodes is a parade. Virtualize only if some sensei demands an admin scroll that can grow. Even then: pages from the server, never “summon everyone.”

What the mountain does while you crouch (know your allies)

You do not build this in the browser. You should still understand why the strike is cheap.

Sorted names are a line of soldiers in alphabetical armor:

gabe
habitat

habitat.ng

habeeb

habeeb_lateef

habibi.eats

hackclub



“Starts with hab” is not “interview every soldier.” It is:

1. Leap to the first name ≥ hab (the index is your grappling hook).

2. Walk forward while the name still bows to hab.

3. Stop at eight. Disappear.

A trie is a tree of letters. h → a → b and you are already in the right branch. The rest of the forest never hears your footsteps.

Exact habeeb is even quieter: one hash, one kill, go home.

So the frontend’s job is not “be a database.” It is “throw a prefix, not a novel.

Two missions, two blades

The dropdown is reconnaissance. Opening a profile is the raid.

js

// Smoke bomb: names only

GET /api/usernames?prefix=hab&limit=8

// Katana: one soul, after they choose

GET /api/users/habeeb

Do not strap a biography, a portrait gallery, and a follower census to every suggestion. Fat payloads are clanking armor. Ninjas wear black for a reason.


list.addEventListener("click", (e) => {

  const name = e.target.textContent.replace(/^@/, "")

  window.location.href = "/u/" + name

})

Rank the squad you have, not the empire

Once eight names kneel before you, you may sort that squad:


function sortSuggestions(query, rows) {

  return [...rows].sort((a, b) => {

    if (a.username === query) return -1

    if (b.username === query) return 1

    return a.username.length - b.username.length

  })

}
Exact match on the throne. Short names next. Popularity if the API handed you a score.

Fuzzy “did you mean habeeb?” is dessert on those eight plates. Running Levenshtein across a billion rows in the tab is how you become a cautionary campfire story.

Empty air is still a message

js

function decideWhatToShow(query) {

  if (query.length === 0) return "recent"  // local ghosts

  if (query.length < 2)  return "hint"    // “more letters, traveler”

  return "network"

}

Recent hunts live in the village, not the mountain:


const recent = JSON.parse(localStorage.getItem("recentHandles") || "[]")

function remember(username) {

  const next = [username, ...recent.filter((x) => x !== username)].slice(0, 5)

  localStorage.setItem("recentHandles", JSON.stringify(next))

}


Five names in localStorage. That is a pocket. That is allowed.

The full night raid (assemble the forms)

js

const sleeve = new Map()
let livingCrow = null
const onType = debounce((raw) => {
  const query = raw.trim().toLowerCase()
  if (query.length < 2) {
    if (livingCrow) livingCrow.abort()
    renderHint("Two letters, Ninja. Then we hunt.")
    return
  }
  const scroll = sleeve.get(query)
  if (scroll && Date.now() - scroll.inkedAt < 30_000) {
    renderList(scroll.results)
    return
  }
  loadSuggestions(query)
}, 200)
async function loadSuggestions(query) {
  if (livingCrow) livingCrow.abort()
  const controller = new AbortController()
  livingCrow = controller
  renderHint("Moving through the trees…")
  const url =
    /api/usernames?prefix=${encodeURIComponent(query)}&limit=8
  try {
    const res = await fetch(url, { signal: controller.signal })
    const data = await res.json()
    if (query !== currentQuery()) return
    sleeve.set(query, { inkedAt: Date.now(), results: data.results })
    renderList(data.results)
  } catch (err) {
    if (err.name !== "AbortError") renderHint("The path is blocked.")
  }
} 
No mountain in the backpack. No honor lost.

Scroll of shame (do not)

| Tempting jutsu | Why the elders will sigh |

|---|---|

| Load all usernames locally | You become the mountain. The mountain wins. |

| Fetch on every key | You are a festival drum, not a Ninja. |

| Client-side %term% / regex over the world | Siege warfare. Resign. |

| Return 1,000 hits “just in case” | JSON avalanche. DOM parade. Shame. |

| Ignore abort | Ghost intel overwrites living intel. |

| Fuzzy-match the entire table in the tab | Your laptop achieves enlightenment, then death. |

Final proverb

A billion-row search is fast when the Ninja never meets a billion rows.

Crouch. Cancel. Ask for a prefix of eight names. Paint them. Disappear.

The index is the silent ally in the rafters. Your job is not to be louder than the database. Your job is to be narrower, later, and true.

Now go, Ninjas. Type hab. Take habeeb. Leave no footprints in the DOM.

Extracting a React presence hook from a production event app

Wed, 30 Sep 2026 14:10:55 +0000

How we turned a battle-tested Supabase Realtime Presence layer into react-supabase-presence
Real-time “who is in the room” sounds simple until you ship it on phones.

Tabs freeze. Networks drop. React Strict Mode double-mounts effects. Supabase will often restore the socket for you — but presence track state does not magically re-announce itself. If you do not re-track after resubscribe, other clients still think you are offline.

We hit that in production while building an event networking product (QR check-in, live roster, ephemeral rooms). The presence logic had to be honest in the UI: not a single boolean “connected,” but a small state machine the interface could show without lying.

That code is now open source:
npm: react-supabase-presence
GitHub: devhabeeblateef/react-supabase-presence
License: MIT

The problem we actually had
Supabase Realtime Presence is a good primitive. The gaps show up at the edges:

Lifecycle — subscribe → track → sync/join/leave. Miss a re-track after reconnect and your user vanishes for everyone else.
Mobile browsers — background tabs can freeze sockets without a clean CLOSED event. Coming back to the tab should re-announce.
UI honesty — “loading” vs “live” vs “trying again” are different states. Collapsing them into one spinner trains users to ignore the product.

App boundaries — roster, roles, and business logic should not live inside the presence hook. The hook should only answer: who is online, and is the channel healthy?

We implemented that as a React hook inside the product first, then extracted it so the package has zero knowledge of events, QR codes, or billing.

What the hook does

`import { useEventPresence } from "react-supabase-presence";
import type { EventPresence, PresenceStatus } from "react-supabase-presence";
TypeScriptconst { online, status, version } = useEventPresence(
  supabase,   // your browser Supabase client
  channelKey, // stable room / event id
  selfId      // stable presence key for the current user
);

Behaviour that mattered in production

Channel name is derived as presence:${channelKey} with config.presence.key = selfId.
On SUBSCRIBED, the hook tracks { user_id, at }.
On CHANNEL_ERROR / TIMED_OUT / CLOSED, status becomes reconnecting (the client library may still recover underneath).
On visibilitychange → visible, it re-tracks so a returning mobile tab reappears.

Cleanup removes the channel; no shared global channel name that breaks under Strict Mode remounts.

You own the SupabaseClient. The library does not create clients, read env vars, or assume your schema.

Minimal example

`"use client";
import { createClient } from "@supabase/supabase-js";
import { useEventPresence } from "react-supabase-presence";

const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!
);

export function Room({ roomId, userId }: { roomId: string; userId: string }) {
  const { online, status, version } = useEventPresence(
    supabase,
    roomId,
    userId
  );

  return (
    <div>
      <p>Status: {status}</p>
      <p>
        {online.size} online (v{version})
      </p>
      <ul>
        {[...online].map((id) => (
          <li key={id}>{id}</li>
        ))}
      </ul>
    </div>
  );
}

Install: npm install react-supabase-presence
Peer dependencies: react (≥18) and @supabase/supabase-js (^2.40).

Design choices (and non-goals)
In scope for v0.1

Presence subscribe + track + state aggregation
Explicit connection state for UI
Tab-visible re-track
TypeScript types exported from the package root

Out of scope (on purpose)
Authentication
Authorization / RLS policy design
Handshakes, chat, or matching
Rendering components (dots, avatars, lists)

Those belong in the product. Keeping them out is what makes the package reusable and reviewable.
The product that motivated this work still uses the published package for its live room roster — same API, one implementation path.

Why open source this slice
Presence is a sharp edge many Supabase + React apps re-implement poorly. Publishing a small, MIT-licensed hook:

Documents the reconnect and visibility behaviour in public
Gives others a starting point that is not tied to one startup’s domain model
Forces a clean boundary: if it needs your event table, it does not belong in the library

If you find bugs or want a multi-tab leader election helper, issues and PRs are welcome on the repo.

Links
npm: https://www.npmjs.com/package/react-supabase-presence
Source: https://github.com/devhabeeblateef/react-supabase-presence
License: MIT

Beyond a Country Explorer: Accessibility & Architecture in React

Tue, 29 Sep 2026 08:01:34 +0000

A country explorer can look like a simple React project: fetch some data, render a list of countries, and add a search field.

But building a frontend that remains accessible, predictable, and maintainable requires thinking beyond the visual interface.

Here is how I structured my Rest Countries application with a focus on component boundaries, user interaction, and accessibility.

⚡ The Architecture Highlights:

Feature-Oriented Structure: Country-related functionality is organized around the feature itself, separating the data layer, application logic, and UI components instead of grouping everything by file type.
Custom State Logic: Country filtering and selection are handled through a dedicated useCountries hook, keeping stateful behavior separate from presentation.
Keyboard-Accessible Region Selection: The custom region selector supports keyboard interaction including ArrowUp, ArrowDown, Home, End, and Escape, providing an interaction model closer to a native control.
Focus Management: Focus is deliberately managed when navigating between the country list and country details. When returning from a country detail view, focus can be restored to the element that originally triggered the navigation.
Semantic Interaction: Interactive elements use appropriate HTML semantics and accessible labels rather than relying only on visual styling to communicate their purpose.
Controlled UI Boundaries: The country grid, controls, and country detail view have separate responsibilities, making the interface easier to reason about and modify.
Intentional Interaction Design: Country information remains selectable and usable as text, while the country flag acts as the primary interactive target for opening details. This avoids turning an entire information card into an unnecessarily large interactive control.

The Result:

A React country explorer designed not only to display data, but to provide a more predictable experience for keyboard users while maintaining clear boundaries between state, UI, and interaction logic.

The project is built with accessibility as part of the architecture rather than as a final visual polish step.

Live Demo: https://ahmed-rest-countries.vercel.app/

GitHub Repo: https://github.com/a-sayed123/Rest_Countries_API

Forgetting default.tsx in a Next.js Parallel Route Can 404 Your Entire Page, Not Just One Slot

Sun, 27 Sep 2026 09:32:05 +0000

This is a genuinely surprising failure mode the first time you hit it, since the natural assumption is that an unmatched parallel route slot would just render nothing, not take down a page that has nothing to do with the slot in question.

The Setup From an Earlier Post, Extended

Building on the intercepting route modal pattern from an earlier post, the @modal slot renders the modal when a specific route is intercepted. But a parallel route slot needs to render something for every URL within its scope, not just the one specific route it was built for.

app/
├── @modal/
│   ├── (.)photo/
│   │   └── [id]/
│   │       └── page.tsx    // renders when a photo route is intercepted
│   └── (missing: default.tsx)
├── photo/
│   └── [id]/
│       └── page.tsx
├── settings/
│   └── page.tsx             // a completely unrelated route
├── layout.tsx
└── page.tsx

Why Visiting an Unrelated Page Can Break Entirely

The @modal slot is defined at the root layout level here, which means it's part of every route rendered under that layout, not just the photo routes it was actually built for. Next.js needs to know what @modal should render for every single route within its scope, including /settings, which has nothing to do with photos or modals at all. If there's no page.tsx inside @modal matching /settings, and critically, no default.tsx file to serve as a fallback for exactly this situation, Next.js has no content to render for that slot on that route, and without a fallback, it treats this as a genuine 404 for the entire page, not just an empty modal slot.

Why This Specific Failure Mode Is So Confusing

The intercepting modal pattern itself works perfectly, clicking a photo from the grid correctly shows the modal, refreshing correctly shows the full page, exactly the behavior covered in the earlier post. The /settings page, something that looks completely unrelated to any of that photo and modal logic, is what actually breaks, with a full 404, and nothing about that page's own code gives any indication why. The actual cause lives entirely in the parallel route configuration at the layout level, several files away from the page that's actually failing, which makes this a genuinely disorienting bug to trace the first time.

The Fix: A default.tsx for Every Parallel Slot

// app/@modal/default.tsx
export default function Default() {
  return null; // this slot simply renders nothing when there's no active modal
}

default.tsx tells Next.js exactly what to render for this slot whenever the current route doesn't match anything more specific within it. Returning null here is completely correct and intentional, for any route that isn't specifically showing a modal, @modal should render nothing, and default.tsx is what makes that an explicit, defined behavior instead of an unhandled gap that produces a full 404.

Why This Is Easy to Miss When First Setting Up Parallel Routes

Most tutorials and examples for intercepting routes focus entirely on the specific route being intercepted, since that's the actual feature being demonstrated, and default.tsx is easy to treat as an afterthought or skip in a quick example, since the demo itself often only ever navigates between the two or three routes that were actually set up correctly. The gap only becomes visible once someone navigates to a genuinely unrelated route that was never part of the original example, exactly the kind of route a real, full application has plenty of.

The Broader Rule

Every parallel route slot needs a default.tsx, without exception, the moment that slot exists anywhere in a layout that also renders routes the slot has no specific content for. This isn't an edge case fallback for rare situations, it's the default, expected behavior for the overwhelming majority of routes in any real application, since a slot built for one specific interaction, a modal, a sidebar variant, is inherently the exception, not the rule, across a site's full set of routes.

Checking Your Own Parallel Routes

find app -type d -name "@*"

For every parallel route slot this turns up, confirm a default.tsx exists directly inside it. If it doesn't, any route within that layout's scope that isn't specifically handled by that slot is at genuine risk of a full 404, not a minor rendering gap, the moment someone actually navigates there.

I set up a default.tsx as the very first file whenever I add a parallel route slot to any project now, client work included, for exactly this reason, it costs one trivial file and prevents a genuinely confusing, hard-to-trace production bug. If you're exploring more Next.js patterns like this, I write about them regularly at pixelanas.com/blog.

If you're using parallel routes anywhere, run the check above right now and confirm every slot has its fallback file. If one doesn't, you've got a real, ready-to-happen 404 waiting on some route you haven't tested yet. Drop what you find in the comments.

Get the templates: https://pixelanas.gumroad.com

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Why Your useEffect Runs Twice in Development (And Why You Shouldn't "Fix" It)

Sat, 26 Sep 2026 09:20:46 +0000

This causes a very specific, very common reaction, a developer sees a console.log inside useEffect fire twice in the browser console during local development, assumes something's genuinely broken, and starts debugging a bug that doesn't actually exist.

What's Actually Happening

'use client';
import { useEffect } from 'react';

export function Tracker() {
  useEffect(() => {
    console.log('Effect ran'); // logs twice in development, once in production
    trackPageView();
  }, []);

  return null;
}

In development, with React's Strict Mode enabled, which the Next.js App Router enables by default, React deliberately mounts a component, runs its effects, unmounts it, and immediately remounts it again, running the effects a second time. This is not a bug, and it's not accidental, it's a specific, intentional development-only behavior designed to help surface exactly the kind of bug this pattern causes in the first place, effects with real, unintended side effects or missing cleanup.

Why React Does This on Purpose

React is preparing for a future where components can be safely paused, discarded, and remounted, for features like offline support and certain rendering optimizations, and that capability genuinely requires effects to be safely re-runnable, mount, unmount, mount again, without producing broken or duplicated behavior. The double-invoke in development is a deliberate stress test, if your effect breaks when run twice in a row, mount, unmount, mount, it's revealing a genuine correctness gap, code that assumes it only ever runs once, which was never actually a safe assumption to begin with, even before Strict Mode made it visible.

Why the Instinct to "Fix" This Is Usually Wrong

Seeing double logs or double network calls in development and reaching for a way to suppress it, disabling Strict Mode entirely, or adding a fragile useRef guard specifically to prevent the second invocation, treats the symptom as the problem. The actual problem, if there is one, is that the effect wasn't written to safely handle being cleaned up and re-run, which is a real gap worth fixing properly, not hiding by preventing Strict Mode from ever revealing it again.

// ❌ A common "fix" that just hides the signal instead of addressing what it revealed
const hasRun = useRef(false);

useEffect(() => {
  if (hasRun.current) return;
  hasRun.current = true;
  trackPageView();
}, []);

This pattern specifically defeats the entire point of Strict Mode's double-invoke check, and worse, it can behave inconsistently across React versions and concurrent rendering scenarios in ways that are genuinely harder to reason about than just writing the effect correctly in the first place.

The Actual Fix: Write Effects That Are Safe to Run Twice

For something like an analytics call, the real question worth asking is whether firing it twice in development actually matters, and for most analytics providers, it doesn't, in production, without Strict Mode's double-invoke, it only fires once anyway. The development-only double log is not the same as double-counting real production analytics data, a distinction worth confirming directly rather than assuming.

useEffect(() => {
  // In production, this fires once. In development, Strict Mode fires it
  // twice, which is expected and does not reflect production behavior.
  trackPageView();
}, []);

For an effect that sets up something genuinely stateful, a subscription, an interval, an event listener, the actual fix is a real, correct cleanup function, which is precisely what Strict Mode's double-invoke is designed to verify you've written:

useEffect(() => {
  const interval = setInterval(() => {
    checkForUpdates();
  }, 5000);

  return () => clearInterval(interval); // correctly cleans up, safe to run twice
}, []);

With a correct cleanup function, the double-invoke in development runs cleanly, set up, tear down, set up again, exactly the pattern Strict Mode exists to confirm your code actually handles safely. If removing the cleanup function causes something to visibly break or duplicate in development, that's Strict Mode doing its job, not React misbehaving.

Where This Actually Matters for Real Bugs, Not Just Console Noise

This connects directly to the stale fetch race condition covered in an earlier post, an effect fetching data without a cleanup function that ignores stale responses is exactly the kind of effect that also breaks under Strict Mode's double-invoke in development, showing a flash of duplicated or incorrect state before settling, which is a genuine, useful early warning for a bug that would otherwise only surface in production under real network timing variance.

The Actual Rule

A useEffect that produces visibly different or broken behavior when Strict Mode runs it twice in development almost always has a real gap, missing or incorrect cleanup, not properly guarding against being re-invoked, that would eventually cause a genuine bug in production too, just under different, harder-to-reproduce conditions. The fix is writing the effect to genuinely handle mount, unmount, remount correctly, not suppressing the specific mechanism designed to reveal that it doesn't.

I keep Strict Mode enabled across every project I build, client work and the templates at pixelanas.com alike, specifically because catching this category of bug in development, as annoying as the double logs are at first, is far cheaper than debugging the same underlying issue once it surfaces as an intermittent, hard-to-reproduce production bug instead.

If you've disabled Strict Mode, or added a ref-based guard specifically to suppress double-invoked effects, worth reconsidering whether that's hiding a real, fixable gap rather than actually solving anything. Drop your own experience with this in the comments.

Get the templates: https://pixelanas.gumroad.com

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

🔥 30 Days of Frontend — Day 2: React Reconciliation

Fri, 25 Sep 2026 17:17:09 +0000

Why doesn't React update the entire UI after every state change?

Because React uses reconciliation.

When a component renders again, React produces a new element tree.

React then determines what changed compared with the previous result and prepares the necessary updates.

Think of it as:

Previous tree + New tree
          ↓
    Reconciliation
          ↓
   Required updates

🧠 A Simple Example

Imagine we have a list of todos:

function TodoList({ todos }) {
  return (
    <ul>
      {todos.map((todo) => (
        <TodoItem key={todo.id} todo={todo} />
      ))}
    </ul>
  );
}

Initially, our list looks like:

[A, B, C]

Then it changes to:

[A, B, D]

Because we're using stable keys, React can reason about the identity of each item:

A → same item
B → same item
C → removed
D → new item

The important part isn't just that the data changed.

It's that React can understand which elements represent the same identity across renders.

🔑 Why Do Keys Matter?

Consider this:

items.map((item) => (
  <Item key={Math.random()} />
))

Every render produces a different key.

That makes it difficult for React to identify the item as the same item from the previous render.

Instead, use a stable identifier:

items.map((item) => (
  <Item key={item.id} />
))

Now React has a stable way to understand:

"This is the same item as before."

This becomes especially important when components contain local state.

For example, if each Item contains an input field, unstable keys can cause component instances to be recreated and lead to unexpected state behavior.

🧩 A Useful Mental Model

When debugging list rendering, don't only ask:

"Why did this component render?"

Also ask:

"Does React know this is the same component as before?"

That question can help explain many confusing behaviors involving:

List keys
Component identity
Local state
Re-renders
Elements being added or removed

⚙️ Where Does Reconciliation Happen?

Reconciliation happens during React's render phase.

React determines what work needs to be done first. The resulting changes are then applied during the commit phase.

A simplified mental model is:

State Update
     ↓
Render
     ↓
Reconciliation
     ↓
Determine required changes
     ↓
Commit
     ↓
DOM updates

It's important to remember that rendering does not mean React immediately changes the DOM.

The render phase is where React figures out what the next UI should look like.

The commit phase is where React applies the necessary changes to the DOM.

🎯 The Takeaway

Reconciliation is one of the core ideas behind how React updates the UI efficiently.

Once you understand reconciliation, concepts like keys, component identity, and rendering behavior become much easier to reason about.

Your useEffect Data Fetch Might Show Stale Data If a User Navigates Quickly

Fri, 25 Sep 2026 13:18:13 +0000

This is a genuinely common race condition, and it's specifically the kind that only shows up under real usage conditions, someone clicking between items quickly, a slow network, exactly the situations casual development testing on a fast local connection rarely reproduces.

The Setup That Looks Completely Standard

'use client';
import { useState, useEffect } from 'react';

export function UserDetail({ userId }: { userId: string }) {
  const [user, setUser] = useState(null);

  useEffect(() => {
    fetch(`/api/users/${userId}`)
      .then((res) => res.json())
      .then((data) => setUser(data));
  }, [userId]);

  return <div>{user ? user.name : 'Loading...'}</div>;
}

This is close to the most common way to fetch data based on a changing prop in a Client Component, and it works completely correctly the vast majority of the time. It also has a real race condition that only shows up under a specific, genuinely common sequence of events.

The Exact Sequence That Triggers the Bug

A user clicks on user A in a list, userId becomes A's ID, the effect fires, a request for A's data starts. Before that request resolves, network latency, a slow connection, the user clicks user B instead, userId becomes B's ID, the effect fires again, a second, separate request for B's data starts. Now two requests are in flight simultaneously.

If B's request happens to resolve faster than A's, perfectly plausible depending on server load, caching, or just network variance, B's data renders correctly first. Then A's slower, now-stale request finally resolves, and its .then() callback runs setUser(data) with A's data, overwriting B's correct, current data with A's outdated, no-longer-relevant response. The component now displays user A's name and information while userId itself is actually set to B, a genuine, visible mismatch between what's shown and what's actually selected.

Why This Feels Random Rather Than Reliably Broken

This only manifests when the specific timing lines up, a slower first request resolving after a faster second one. On a fast, consistent local connection during development, requests often resolve close enough to their sending order that this exact interleaving rarely happens, which is exactly why it's easy to ship without ever seeing it locally, and exactly why it tends to surface first as a confusing, hard-to-reproduce bug report from a real user on a real, more variable connection.

The Actual Fix: Ignore Stale Responses Explicitly

'use client';
import { useState, useEffect } from 'react';

export function UserDetail({ userId }: { userId: string }) {
  const [user, setUser] = useState(null);

  useEffect(() => {
    let ignore = false;

    fetch(`/api/users/${userId}`)
      .then((res) => res.json())
      .then((data) => {
        if (!ignore) {
          setUser(data);
        }
      });

    return () => {
      ignore = true; // marks this specific effect's request as stale on cleanup
    };
  }, [userId]);

  return <div>{user ? user.name : 'Loading...'}</div>;
}

The ignore flag, scoped locally to each individual effect invocation, gets set to true in the cleanup function, which React runs automatically the moment userId changes again, before the next effect invocation starts. When A's slow request finally resolves, its specific closure's ignore flag is already true, since the effect was cleaned up the moment the user clicked B, and the stale setUser(data) call for A's outdated data simply never happens. Only B's request, whose ignore flag remains false because its effect was never cleaned up, actually updates state.

An Alternative Using AbortController

For fetch specifically, AbortController provides a more complete version of the same fix, actually canceling the in-flight request rather than just ignoring its eventual result:

useEffect(() => {
  const controller = new AbortController();

  fetch(`/api/users/${userId}`, { signal: controller.signal })
    .then((res) => res.json())
    .then((data) => setUser(data))
    .catch((err) => {
      if (err.name !== 'AbortError') {
        console.error(err); // genuinely handle real errors, ignore expected aborts
      }
    });

  return () => {
    controller.abort();
  };
}, [userId]);

This has a real advantage over the simple ignore flag, the actual network request gets canceled, not just its result discarded, which saves real bandwidth and server load for a request whose result was never going to be used anyway, particularly valuable for anything more expensive than a small JSON response.

Why This Matters More for Search and Filtering Specifically

This exact pattern shows up constantly in search-as-you-type and rapid filtering interactions, exactly the kind of interface covered in an earlier post on search and filtering patterns. A user typing quickly triggers a new request on every keystroke, and without this protection, a slower response to an earlier, now-outdated keystroke can overwrite the correct results for what the user is actually searching for right now, displaying results for a query they've already moved past.

The Actual Rule

Any effect that fetches data based on a value that can change again before the fetch resolves needs a way to distinguish a stale, no-longer-relevant response from a current one. A simple ignore flag set in the cleanup function handles this cheaply for most cases. AbortController handles it more completely, actually canceling the wasted request rather than just discarding its result, and is worth the small amount of extra code for anything with real cost behind each request, a genuinely expensive query, meaningful bandwidth, a rate-limited endpoint.

I handle this exact pattern, mostly with AbortController for anything backed by a real database query, across the dashboards and templates I build at pixelanas.com, since it's exactly the kind of subtle bug that looks fine in every casual test and only shows up once real users start clicking around at real speed.

If you've got a useEffect fetching data based on a changing prop with no stale-response handling, go test it specifically by clicking or navigating quickly between a few items in a row. If you see a flash of the wrong data settling in, that's this exact race condition. Drop what you find in the comments.

Get the templates: https://pixelanas.gumroad.com

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

The Secret to Clean React Code: Mastering Component Composition

Fri, 25 Sep 2026 09:06:38 +0000

If you have ever navigated a modern web application like Netflix or Spotify, you have experienced the magic of modular user interfaces. Under the hood, these interfaces are built using components—small, self-contained pieces of code that govern how a specific button, card, or menu looks and acts. However, as applications grow, keeping these components organized and easy to update becomes a massive challenge. This is where component composition comes into play.

Component composition is a fundamental software design pattern where you build complex user interfaces by combining small, focused, and self-contained parts. Instead of creating a single, massive block of code that tries to handle every layout and interactive detail, you nest simpler components inside one another. In modern web frameworks like React, this means designing elements to be flexible containers that can accept and display any content passed directly into them.

To understand this concept without writing a single line of code, think of a custom picture frame. The frame itself is a structured component. It has a physical border, a glass front, and a backing stand. Crucially, the frame manufacturer does not need to know what you plan to display inside it. You can insert a family photo, a watercolor painting, a motivational quote, or even a pressed leaf. The frame's only job is to provide the outer border and support whatever you place inside it. The frame "composes" the final product by holding whatever content you decide to supply.

In everyday software engineering, developers often fall into a trap called "prop drilling." "Props"—short for properties—are the configuration parameters passed from a parent component down to its children. When you have a deeply nested user interface, you might find yourself passing a user's login details through five intermediate layout elements that have absolutely no use for that information, just so a tiny avatar button at the very bottom can display the user's profile image.

This practice makes software highly brittle. If you ever need to change the format of that user data, you have to edit and test all five intermediary files. Component composition prevents this by letting engineers build the nested element at a higher level and pass the completed element directly to its destination container. This prevents engineers from spending hours fixing broken data pipelines, minimizes merge conflicts in collaborative teams, and ensures that a simple design change in one part of the app does not accidentally crash another.

Here is a simple example in React (a popular user interface library) demonstrating how to compose clean components using the special children property, which acts as a slot for whatever content we want to place inside:

import React from 'react';

// This structural container is completely decoupled from the data inside it
function CardContainer({ children }) {
  return (
    <div style={{ border: '1px solid #ccc', padding: '16px', borderRadius: '8px', margin: '10px' }}>
      {children}
    </div>
  );
}

// We can reuse the exact same container for entirely different features
function App() {
  return (
    <main>
      {/* Use case 1: User Profile */}
      <CardContainer>
        <h3>User Profile</h3>
        <p>Name: Alex Mercer</p>
        <button>Edit Profile</button>
      </CardContainer>

      {/* Use case 2: Shopping Cart Item */}
      <CardContainer>
        <h3>Shopping Cart</h3>
        <p>Item: Mechanical Keyboard</p>
        <p>Price: $120</p>
      </CardContainer>
    </main>
  );
}

export default App;

The major takeaway of component composition is that it shifts your mental model from creating all-in-one components to creating cooperative systems. By building layout shells that delegate their internal content to the parent that uses them, you create an adaptive, resilient codebase that can evolve effortlessly as your product requirements change.

Originally published on my blog. You can read the alternative breakdown here.

Building MetaMask Wallet Ownership Verification in MyZubster

Fri, 25 Sep 2026 04:23:07 +0000

Building MetaMask Wallet Ownership Verification in MyZubster

I’ve started implementing MetaMask / EVM wallet ownership verification inside MyZubster.

At first, this might sound like a simple “Connect Wallet” feature.

But I wanted to avoid one of the most common mistakes in Web3 UX:

treating “wallet connected” as if it automatically meant “identity verified”, “payment authorized”, or “transaction completed”.

For MyZubster, those states need to stay separate.

The architecture I’m building follows this rule:

CONNECTED
!=
VERIFIED
!=
SIGNED
!=
PAID
!=
SETTLED

That distinction is now becoming part of the product.

What we already had

MyZubster already had several EVM-related pieces in the codebase:

ethers
Ethereum Sepolia verification
Base Sepolia anchoring
Marketplace ETH support
NFT experiments
blockchain evidence flows

What was missing was the user-side ownership layer.

In other words:

How can a logged-in MyZubster user prove that they actually control a specific Ethereum wallet?

Without giving MyZubster the private key.

Without sharing a seed phrase.

Without sending ETH.

Without paying gas.

That became the first milestone.

The new flow

The flow now looks like this:

Authenticated MyZubster user

↓

Connect MetaMask

↓

eth_requestAccounts

↓

Read wallet address

↓

Read chain ID

↓

Request challenge from MyZubster

↓

Server creates short-lived nonce

↓

User signs message in MetaMask

↓

personal_sign

↓

Signature sent to backend

↓

Backend recovers signer

↓

Address matches?

↓

WALLET_VERIFIED

The important part is that verification happens server-side.

The frontend cannot simply tell MyZubster:

{
"walletVerified": true
}

and be trusted.

New API

I added four authenticated endpoints:

GET /api/wallet/me
POST /api/wallet/challenge
POST /api/wallet/verify
DELETE /api/wallet/disconnect

Their responsibility is intentionally narrow.

/challenge creates the ownership proof request.

/verify validates the signature.

/me returns the current wallet relationship.

/disconnect removes the verified association from the MyZubster account.

The challenge

The challenge includes context such as:

MyZubster account
wallet address
chain ID
domain
application URI
random nonce
issued time
expiration time
intended action

The intended action is currently:

LINK_WALLET

A simplified message looks like:

www.myzubster.com wants you to link your Ethereum account to MyZubster:

0x...

Sign this message to prove wallet control.
This is not a payment and does not spend ETH.

URI: https://www.myzubster.com
Version: 1
Chain ID: 1
Nonce: ...
Issued At: ...
Expiration Time: ...
Request ID: LINK_WALLET:user-id

That “not a payment” line is deliberate.

I don’t want a wallet signature to ever be confused with a transaction.

Why use a nonce?

Because the signature must not be reusable forever.

Each challenge is:

random
short-lived
account-bound
wallet-bound
action-bound

The backend checks:

challenge exists
↓
challenge is not expired
↓
wallet matches
↓
message matches
↓
signature is valid
↓
recovered signer matches wallet

Only then does the wallet become verified.

Signature verification

The backend uses ethers to recover the signer:

const recovered = verifyMessage(message, signature);

Then the recovered address is normalized and compared with the expected wallet.

If another wallet signs the challenge, verification fails.

What gets stored

MyZubster never stores:

private key
seed phrase
mnemonic
MetaMask password
wallet secret

Only wallet relationship metadata is persisted.

Conceptually:

evmWallet: {
walletType: 'EVM',
provider: 'metamask',
address: '0x...',
chainId: 1,
status: 'WALLET_VERIFIED',
verifiedAt: Date,
lastVerifiedAt: Date
}

Temporary challenge information is also stored server-side until verification or expiration.

Wallet state

I’m avoiding a single boolean like:

walletConnected = true

Instead, MyZubster has explicit states:

WALLET_NOT_CONNECTED
WALLET_CHALLENGE_PENDING
WALLET_VERIFIED
WALLET_DISCONNECTED

That becomes useful both for the UI and for Zorgax.

For example:

MetaMask connected

is not the same as:

wallet ownership verified

and neither means:

payment completed
Frontend

I extended the existing WalletHubPanel rather than creating a completely separate wallet system.

The user now gets a:

Connect MetaMask

action.

The frontend uses:

eth_requestAccounts

then:

eth_chainId

and finally:

personal_sign

The signature is then sent back to the backend for verification.

The UI explicitly explains that the signature:

does not transfer ETH
does not cost gas
does not authorize a payment
Preventing duplicate wallet ownership claims

Another issue is what happens if two MyZubster accounts try to link the same verified wallet.

The current behavior is:

Account A
→ verifies 0xABC

Account B
→ tries to verify 0xABC

Result:
WALLET_ALREADY_LINKED

This does not mean that MyZubster treats a wallet as a legal identity.

It simply prevents contradictory wallet-to-account relationships inside the application.

What changes in MyZubster

This creates a new trust layer.

MyZubster can already work with:

account identity
GitHub identity
community profile
Marketplace identity
Zorgax context

Now it can also say:

this account proved control
of this EVM wallet
at this time

That is a reusable building block.

The next milestone: signed Marketplace requests

This is where the wallet integration becomes much more useful.

The next step is to let a verified wallet sign a canonical Marketplace request.

Something like:

{
"schema": "myzubster.marketplace-request.v1",
"intent": "MARKETPLACE_REQUEST",
"listingId": "listing-123",
"quantity": 1,
"buyerAccountReference": "user-42",
"walletAddress": "0x...",
"nonce": "...",
"issuedAt": "...",
"expiresAt": "..."
}

The buyer signs it off-chain.

The server verifies it.

Then MyZubster can create:

MarketplaceOrder: REQUESTED

with cryptographic evidence attached.

No gas.

No blockchain transaction.

No payment.

Just signed intent.

Why not put every action on-chain?

Because not every interaction needs blockchain finality.

If every Marketplace request required a transaction, the UX would become unnecessarily heavy.

Instead, the architecture I’m aiming for is:

Marketplace request
↓
off-chain signature
↓
seller acceptance
↓
exchange lifecycle
↓
structured evidence
↓
optional blockchain anchor

Blockchain should be used where permanence adds value.

Not everywhere by default.

User wallet vs infrastructure wallet

This is also an important boundary.

MyZubster already has server-side blockchain infrastructure for evidence anchoring.

That wallet must stay completely separate from user wallets.

User MetaMask
!=
MyZubster infrastructure wallet

User-controlled wallet actions remain user-controlled.

Server-side evidence operations remain isolated.

How Zorgax can use this

Once the wallet state is explicit, Zorgax can explain it correctly.

For example:

User:
Is my wallet verified?

Zorgax:
Yes. Your MetaMask wallet ownership has been verified.

But if the user asks:

Did I pay?

Zorgax should answer:

No confirmed payment evidence exists.
Your wallet only signed the request.

That distinction is essential.

Security tests

I’ve added tests covering:

valid signer
wrong signer
expired challenge
non-payment message semantics
authenticated API wiring
MetaMask provider integration

The goal is not just to make the feature work.

The goal is to make it hard to misunderstand.

Current status

The first implementation is now open as:

PR #1385 — MetaMask wallet ownership linking

The PR adds:

wallet model
challenge service
signature verification
authenticated API
MetaMask UI
disconnect flow
security tests

This is not yet an ETH payment system.

It is the identity and ownership layer that payments or signed Marketplace actions can build on later.

Why this matters for MyZubster

The bigger change is architectural.

MyZubster is gradually moving toward a model where different kinds of evidence are handled by different layers:

MyZubster account

↓

wallet control

↓

signed intent

↓

Marketplace state

↓

payment evidence

↓

optional blockchain evidence

instead of:

connect wallet
↓
everything becomes blockchain

For me, that is the more useful direction.

MetaMask should not just be a button.

It should become a cryptographic tool that adds proof exactly where proof is useful.

Project: MyZubster
Stack: Node.js, Express, MongoDB, React, ethers, MetaMask
Current milestone: EVM wallet ownership verification
Next milestone: signed Marketplace requests without gas

Repository:

https://github.com/MyZubster-Ecosystem/myzubster

Implementation PR:

https://github.com/MyZubster-Ecosystem/myzubster/pull/1385

AI Can Generate More UI. Who Keeps It Consistent?

Thu, 24 Sep 2026 16:57:01 +0000

AI makes UI faster to produce — and easier to fragment. Why Vellira is building cross-platform components and developer tooling to keep growing UI systems coherent as humans and coding agents move faster.

AI can now generate UI faster than many teams can review it.

A developer can describe a component, ask a coding model to implement it, and get a plausible result in minutes. The same model can refactor nearby code, write tests, update types, and produce several variations before a traditional implementation would have reached its first review.

That is a real improvement.

But it also moves the bottleneck.

The hard question is becoming less:

How quickly can we create another component?

And more:

How do we keep the whole UI system coherent when humans and AI can change it this quickly?

That is one of the problems we are building Vellira around.

Generation is getting cheaper. Fragmentation is not.

Imagine an AI-generated component that looks good, compiles, and works in a local preview.

That still leaves a surprising number of questions unanswered.

Does it duplicate something the system already has? Does its API fit the surrounding components? Does it use the shared design foundations? Is the same product capability represented correctly on React Native? Are accessibility expectations covered? Did the documentation and examples move with the implementation? Will the next contributor understand how this component is supposed to evolve?

A locally correct component can still make the system around it less consistent.

That distinction matters more as generation gets faster.

When UI changes slowly, teams can compensate for weak system boundaries with review, documentation, and memory. Someone remembers which component should be reused. Someone catches the one-off visual value. Someone notices that Web changed but React Native did not. Someone remembers to update Storybook.

As the rate of change increases, that becomes harder to sustain.

More UI output creates more opportunities for small differences to accumulate:

APIs drift between similar components;
accessibility behavior becomes inconsistent;
local values bypass shared tokens;
documentation falls behind implementation;
Web and React Native diverge unintentionally;
similar capabilities get implemented more than once;
tests encode different expectations for comparable behavior;
package and public surfaces become harder to keep aligned.

None of these problems were invented by AI.

AI simply increases the rate at which they can appear.

If a team can create five or ten times more UI changes, the system around those changes has to become stronger too.

A component library is necessary. It is no longer sufficient.

Traditional design systems are often described as collections of reusable components, tokens, guidelines, and documentation.

Those foundations still matter. Vellira has them too.

But a catalog can only tell you so much.

It can show that Button, Select, or Tabs exists. It cannot, by itself, keep every future change aligned with the same expectations around APIs, accessibility, platforms, documentation, testing, and quality.

This becomes especially visible when UI work is shared between developers and coding agents.

A coding model can generate a perfectly reasonable component that does not quite belong to the system around it.

It may introduce a slightly different API. It may recreate a capability that already exists. It may look correct on Web while ignoring the native side of the project. It may use values that are visually close to existing tokens without actually using the shared token system.

The code is not necessarily bad.

The surrounding system is simply asking a larger question than "does this component work?"

It is asking:

Does this change still belong to the same product and engineering system?

That is the layer we are increasingly interested in with Vellira.

What Vellira is becoming

Vellira started as a cross-platform design system for React and React Native.

The public project still has that foundation: reusable components, shared tokens, documentation, Storybook, and cross-platform implementation work.

But building the component set exposed a second problem very quickly.

Creating components is only part of the work. Keeping all of them aligned as the system grows requires repeatable workflows and tooling around the components themselves.

Today the public Vellira project already combines:

reusable React and React Native components;
shared design tokens and cross-platform foundations;
Storybook and documentation for discovery and usage;
repeatable component-generation workflows;
automated component quality checks;
accessibility-focused validation and testing;
metadata-backed tooling that gives the project structured information about its own components.

None of those features alone is the point.

The interesting part is what they allow us to work toward together: a UI system that becomes easier to extend without becoming easier to fragment.

We do not want adding a component to mean only "these files compile."

We want the surrounding project to help keep that component connected to the same design foundations, the same platform expectations, the same documentation, and the same engineering standards as the rest of Vellira.

That is useful when a developer writes the code manually.

It becomes even more useful when an implementation can appear in seconds.

Vellira is not trying to out-code the coding model

This distinction is important.

Coding models are getting better quickly. They should be able to write more implementation code, understand larger codebases, make broader changes, and handle more routine engineering work over time.

That is good for Vellira.

We are not building the project around the assumption that AI will remain bad at writing components.

We are building around the opposite assumption: AI will get very good at producing and modifying UI.

If that happens, the surrounding system becomes more important, not less.

A model can generate a new component.

The project still needs to keep APIs coherent.

A model can change ten components in one pass.

The project still needs to keep accessibility, documentation, public surfaces, tokens, and platform behavior from drifting apart.

A model can become better at understanding context.

The repository still benefits from making its important expectations explicit and repeatable instead of depending on every author to remember them perfectly.

So the goal is not to slow AI-assisted development down.

The goal is to make that speed safer to absorb.

The author matters less than the result

There is a temptation to treat AI-generated code as a completely separate category that needs a special design-system workflow.

I do not think that is the most useful distinction.

Once code enters a repository, the important question is not who typed it.

The important question is whether it fits the project.

A human can introduce an inconsistent API.

A coding agent can follow the existing conventions perfectly.

A developer can forget documentation.

An automated workflow can keep it current.

The author is not a reliable measure of system quality. The resulting state of the project is.

That is why Vellira is investing in tooling around the component lifecycle rather than relying only on the intelligence or discipline of whichever author produced the latest change.

Humans and AI can both move faster when the project around them carries more of the consistency burden.

Cross-platform UI raises the stakes

Vellira targets both React and React Native.

That makes this problem even more visible because "the same component" does not always mean "the same source code."

Web and native platforms have different primitives, interaction models, accessibility APIs, and constraints. Some behavior should be shared. Some behavior needs to diverge intentionally.

A useful cross-platform design system therefore needs more than copied implementations.

It needs to keep one product language coherent while still respecting each platform.

Faster code generation does not remove that challenge.

It can amplify it.

An AI tool can create two implementations very quickly, but speed alone cannot tell a team whether those implementations still represent one coherent component system.

That is why the tooling around Vellira's components matters as much as the component count itself.

The bottleneck is moving from production to coordination

This is the part of AI-assisted frontend development that I find most interesting.

Better coding models reduce the cost of producing code.

When producing UI is expensive, teams naturally make fewer changes. When producing UI becomes cheap, experimentation increases, more contributors can work in parallel, and automated agents can make changes of their own.

The limiting resource starts moving away from typing speed.

It moves toward coordination, consistency, review, and maintenance.

That creates a different kind of leverage for developer tooling.

If ten changes can be produced in the time it previously took to produce one, tooling that helps those ten changes remain part of the same system becomes more valuable.

This is the bet behind the direction Vellira is taking:

AI can generate more UI. Vellira is being built to help keep that UI coherent.

The better generation becomes, the more important the system around generation becomes.

Where Vellira is today

We are still building the foundation, and I want to be precise about that.

The immediate work is concrete: expand the cross-platform component set, strengthen component workflows, improve quality and accessibility checks, and make the public project easier to adopt and use.

We are proving these ideas inside Vellira itself before making broader claims about what the tooling can understand or manage outside the project.

That constraint is intentional.

It is easy to describe an ambitious future for developer tooling. It is more useful to earn that future by making the current system work reliably first.

But the product direction is already clear.

Frontend teams are going to work with more generated code, more automation, and more AI-assisted changes — not less.

The answer should not be to slow those tools down.

It should be to make the UI system around them stronger.

If you are building React or React Native interfaces and thinking about how AI changes design-system workflows, follow Vellira as we build this in public:

AI can help us build UI faster.

Vellira is being built so that faster does not have to mean more fragmented.

This is how I added an in-browser auto captions feature to my YouTube Shorts converter web application using Whisper AI and ffmpeg.wasm

Thu, 24 Sep 2026 16:02:33 +0000

A few weeks ago I launched Convert to Shorts — a free browser-based tool that converts horizontal videos to YouTube Shorts format (9:16) without uploading anything to a server. I wrote about the ffmpeg.wasm + Vite setup in a previous article.

The most requested feature after launch was auto captions. Captions significantly boost Shorts engagement since most people watch without sound, and manually typing captions is tedious.

The challenge: how do you add free auto captions to a privacy-first tool that never uploads your video to a server?

The answer: run Whisper AI in the browser.

The stack -

Transformers.js (@xenova/transformers) — Hugging Face's JavaScript port of the Transformers library, runs ONNX models in the browser via WebAssembly
Whisper tiny — OpenAI's speech recognition model, 75MB, surprisingly accurate for clear speech
Web Audio API — for extracting and resampling audio from the video file
ffmpeg.wasm — for burning captions into the video
ASS subtitles — the subtitle format libass (inside ffmpeg.wasm) understands.

Step 1: Audio extraction

Whisper expects mono 16kHz audio as a Float32Array. The Web Audio API handles this cleanly:

async function extractAudio(
  file: File,
  trimStart: number,
  trimEnd: number
): Promise<Float32Array> {
  const arrayBuffer = await file.arrayBuffer();
  const audioContext = new AudioContext({ sampleRate: 16000 });
  const audioBuffer = await audioContext.decodeAudioData(arrayBuffer);

  const sampleRate = audioContext.sampleRate;
  const startSample = Math.floor(trimStart * sampleRate);
  const endSample = Math.floor(trimEnd * sampleRate);

  // Mix down to mono, slice to trim range
  const channelData = audioBuffer.getChannelData(0);
  const trimmed = channelData.slice(startSample, endSample);
  await audioContext.close();
  return trimmed;
}

Creating the AudioContext at 16kHz means the browser automatically resamples from whatever the source rate is (usually 44.1kHz or 48kHz). No manual resampling needed.

Step 2: Running Whisper

Transformers.js makes this surprisingly straightforward:

const { pipeline, env } = await import("@xenova/transformers");

env.useBrowserCache = true;

const transcriber = await pipeline(
  "automatic-speech-recognition",
  "Xenova/whisper-tiny",
  {
    progress_callback: (p) => {
      if (p.status === "downloading") {
        setModelProgress(Math.round((p.loaded / p.total) * 100));
      }
    },
  }
);

const result = await transcriber(audioFloat32Array, {
  return_timestamps: true,
  chunk_length_s: 30,
  stride_length_s: 5,
});

return_timestamps: true gives you back an array of segments with text and timestamp: [start, end] — exactly what you need for timed captions.

env.useBrowserCache = true means the model downloads once and is stored in IndexedDB. Every subsequent use loads from cache — no 75MB download each time.

Step 3: Burning captions with ffmpeg.wasm

This is where it got interesting. My first instinct was to use ffmpeg's drawtext filter with an enable='between(t,start,end)' expression for each caption segment — one filter per caption, chained with commas.

This failed in multiple ways:

The comma inside between(t,start,end) was interpreted as a filter separator
Escaping with \\, didn't work in ffmpeg.wasm's argument parsing
Using gte(t,start)*lte(t,end) instead of between also failed at the filter chain level
Chaining 20+ drawtext filters caused ffmpeg.wasm to abort

The reliable solution was ASS subtitles. ASS (Advanced SubStation Alpha) is a subtitle format that ffmpeg's built-in ass filter handles natively via libass:

function buildAssSubtitles(segments, color, size) {
  function toAssTime(seconds) {
    const h = Math.floor(seconds / 3600);
    const m = Math.floor((seconds % 3600) / 60);
    const s = Math.floor(seconds % 60);
    const cs = Math.round((seconds % 1) * 100);
    return `${h}:${String(m).padStart(2,"0")}:${String(s).padStart(2,"0")}.${String(cs).padStart(2,"0")}`;
  }

  const header = `[Script Info]
ScriptType: v4.00+
PlayResX: 1080
PlayResY: 1920
WrapStyle: 1
ScaledBorderAndShadow: yes

[V4+ Styles]
Format: Name, Fontname, Fontsize, PrimaryColour, ...
Style: Default,Roboto Bold,75,&H00FFFFFF,...

[Events]
Format: Layer, Start, End, Style, Text
`;

  const events = segments
    .map(seg =>
      `Dialogue: 0,${toAssTime(seg.start)},${toAssTime(seg.end)},Default,${seg.text}`
    )
    .join("\n");

  return header + events;
}

Step 4: The font problem

libass needs a font to render subtitles. In a normal environment it uses system fonts. In ffmpeg.wasm's WebAssembly sandbox there are no system fonts.

Three approaches I tried:

Approach 1: Embed font as Base64 in the ASS file
The ASS format supports a [Fonts] section with Base64-encoded font data split into 80-character lines. This failed with a libass assertion error in ass.c about Base64 padding — the ffmpeg.wasm build of libass appears to have a bug in its font decoder.

Approach 2: Write font to ffmpeg.wasm virtual filesystem and use fontsdir

ass=captions.ass:fontsdir=/fonts

Write the font file to /fonts/Roboto-Bold.ttf in the virtual filesystem before running ffmpeg. This worked.

await ffmpeg.createDir("/fonts");
const fontResponse = await fetch("/Roboto-Bold.ttf");
const fontBuffer = await fontResponse.arrayBuffer();
await ffmpeg.writeFile("/fonts/Roboto-Bold.ttf", new Uint8Array(fontBuffer));

The key insight: ffmpeg.wasm has a full virtual filesystem (Emscripten's FS). You can create directories and write files to it just like a real filesystem, and ffmpeg commands can reference those paths.

As a result the full caption pipeline added roughly 10-30 seconds to the export time for a 30-60 second clip. The Whisper tiny model is surprisingly accurate for clear English speech. Multiple languages work out of the box since Whisper was trained on multilingual data.

What I learned

Transformers.js is genuinely production-ready. The API is clean, browser caching just works, and the ONNX runtime handles the WebAssembly execution reliably.

ASS subtitles are more robust than drawtext filter chains. If you're burning timed text into video with ffmpeg.wasm, reach for the ass filter before trying to chain multiple drawtext filters.

ffmpeg.wasm's virtual filesystem is powerful. You're not limited to just reading and writing video files — you can create directory structures, write fonts, write subtitle files, and reference them all from ffmpeg commands exactly as you would on a real filesystem.

libass has quirks in the WASM build. The embedded font Base64 decoding in the WASM build of libass appears broken. Use fontsdir instead.

Try it

converttoshorts.com — free, no account, no upload. Auto captions are in the export panel.

Why I stopped using online image compressors and built a CLI instead

Thu, 24 Sep 2026 07:44:12 +0000

Four years of optimizing React and Next.js projects taught me one thing: unoptimized images are everywhere, and nobody wants to fix them.

Every project has the same pattern. Heavy PNG and JPG files are sitting inside /public, there is no consistent image pipeline, and some of those files have no business being that large in a production codebase.

This is especially common in small and mid-sized projects. There is no CDN transformation layer or dedicated asset pipeline. Images get added while the product is moving quickly, and the cleanup becomes a task for “later.”

Later, of course, never comes.

Then, at 1am, while refactoring an extremely vibe-coded Next.js project, I found myself doing the cleanup manually again.

Find an image. Upload it to an online compressor. Hit the free limit. Open another tool. Convert a few more. Download everything. Replace the original files. Hunt through the codebase for every import and src path. Hope I did not miss one.

And I finally thought: I am a developer. Why am I doing this by hand?

So I built pixcrush.

npx pixcrush .

One command to convert the images, compress them, and update their matching code references automatically.

“But doesn’t Next.js already optimize images?”

Yes, and if your application uses next/image consistently, you should absolutely take advantage of it.

The Next.js <Image> component can resize images for different devices, lazy-load them, and serve modern formats such as WebP. Files inside /public can be referenced from the root URL, while statically imported images also give Next.js access to their intrinsic dimensions. The official Next.js image documentation explains these runtime optimizations in detail.

But that solves a different layer of the problem.

I wanted to clean up the source assets themselves:

Replace heavy PNG and JPG files with smaller WebP files when conversion is worthwhile.
Update existing imports and string-based image paths across the repository.
Identify images that are no longer referenced.
Make the migration reviewable before touching any files.
Keep the process useful for projects that do not consistently use next/image.

This was not about replacing the Next.js image pipeline. It was about making a tedious codebase migration safe and repeatable.

Why a simple format conversion becomes a code migration

Consider a small project with images referenced in a few different ways:

import hero from './assets/hero.png';

export function HomePage() {
  return (
    <main>
      <Image src={hero} alt="" />
      <img src="/images/team.jpg" alt="Our team" />
    </main>
  );
}

Converting hero.png and team.jpg is only half of the job. The code now points to files that no longer represent the desired output.

After the migration, the references need to become:

import hero from './assets/hero.webp';

export function HomePage() {
  return (
    <main>
      <Image src={hero} alt="" />
      <img src="/images/team.webp" alt="Our team" />
    </main>
  );
}

Now multiply that across .js, .jsx, .ts, .tsx, .html, and .json files, plus nested apps inside a Turborepo.

That is no longer an image-conversion task. It is a codemod with image processing attached.

The workflow I wanted

I wanted the tool to perform five clear phases:

Scan the repository for supported images and source files.
Determine which images are actually referenced.
Convert used PNG and JPG files to WebP.
Update only the references connected to successful conversions.
Report what changed, what was skipped, and what needs human review.

The default command is intentionally small:

npx pixcrush .

For a first pass on an unfamiliar project, I prefer starting with a dry run:

npx pixcrush . --dry-run

This previews the migration without writing files.

Step 1: Find the images and their references

pixcrush scans for PNG, JPG, and JPEG files while ignoring directories such as node_modules, .next, dist, build, and .git.

It separately collects the source files that may contain references:

.js  .jsx  .ts  .tsx  .html  .htm  .json

Finding image files is easy. Determining whether they are used is the interesting part.

For JavaScript and TypeScript, pixcrush parses the source with Babel using the JSX and TypeScript plugins. Babel’s parser produces an abstract syntax tree, which makes it possible to inspect actual string literals instead of blindly replacing every .png substring. Babel documents its JSX and TypeScript parsing support in the @babel/parser reference.

The tracker resolves several common patterns:

import logo from './logo.png';

<Image src="/images/hero.jpg" alt="" />

const imagePath = '@/assets/product.png';

It also handles image-bearing values in HTML and JSON, including srcset-style strings and query parameters.

For absolute paths such as /images/hero.jpg, pixcrush reconciles the reference with matching public directories. This matters in monorepos, where the real file may be located at something like:

apps/web/public/images/hero.jpg

Images without a resolved reference are reported as unused instead of being converted automatically.

Step 2: Convert in memory, and keep the original when WebP is larger

The actual image conversion uses Sharp, which supports WebP output and exposes a configurable quality setting.

The important part is not just calling .webp(). pixcrush creates the WebP data in memory first:

const webpBuffer = await sharp(imagePath)
  .webp({ quality })
  .toBuffer();

Sharp’s toBuffer() documentation confirms that WebP output can be generated directly as a buffer. That lets pixcrush compare the proposed output with the original before writing anything.

if (webpBuffer.length >= originalSize) {
  // Skip this conversion.
}

WebP is often smaller, but “modern format” does not automatically mean “smaller file” for every source image. If the generated WebP would be the same size or larger, pixcrush skips it.

More importantly, skipped images are not added to the rewrite map. Their code references remain unchanged.

The default WebP quality is 80, and it can be adjusted:

npx pixcrush . --quality 90

Step 3: Rewrite code without reformatting the entire file

The riskiest part of the migration is not creating a .webp file. It is changing the code safely.

A global find-and-replace is tempting:

.png → .webp

It is also far too broad. It can modify unrelated text, references to images that were skipped, or paths that do not resolve to a file pixcrush converted.

Instead, pixcrush builds a map containing only successful conversions:

/absolute/path/hero.png → /absolute/path/hero.webp

It parses each JavaScript or TypeScript source file, visits its string literals, resolves candidate image paths, and creates targeted text replacements only for matches in that conversion map.

The replacements are applied from the end of the file toward the beginning. This prevents an earlier edit from shifting the offsets required by a later edit.

There is another subtle benefit: pixcrush does not regenerate the entire source file from the AST. It replaces only the extension inside the matched string. Existing formatting, comments, quote styles, and surrounding code remain untouched.

Query strings are preserved too:

/images/hero.png?v=2

becomes:

/images/hero.webp?v=2

The safety rules matter more than the happy path

Code-modifying tools should be conservative. I would rather have pixcrush warn about one path than confidently break a project.

These are the guardrails I added:

Dry runs do not write files

npx pixcrush . --dry-run

This runs the analysis, conversion calculation, and reference-matching flow without writing the WebP files or modified source.

Dynamic paths are reported, not guessed

pixcrush can understand a static value:

<img src="/products/shoe.png" alt="" />

It cannot safely resolve every runtime value:

<img src={`/products/${product.slug}.png`} alt="" />

Dynamic template paths are warned about so they can be reviewed manually.

Parse failures block destructive cleanup

If a source file cannot be parsed, pixcrush records the failure. When --delete-originals is enabled, original and unused images are deleted only if both the analysis and rewrite phases completed without parse failures.

Framework metadata images are excluded

Files such as favicons, Apple touch icons, Open Graph images, Twitter images, and common PWA manifest icons may be discovered through framework conventions rather than ordinary source references.

pixcrush excludes these patterns from the migration instead of incorrectly treating them as orphans.

External and inline images are left alone

HTTP URLs and data: values are not local assets, so the tracker ignores them.

Running the full migration

My preferred workflow is:

# 1. Preview the migration
npx pixcrush . --dry-run

# 2. Review the reported conversions, warnings, and unused files

# 3. Run the migration
npx pixcrush .

# 4. Run the application and its tests

# 5. Remove converted originals only when ready
npx pixcrush . --delete-originals

The final summary includes:

Images converted
Space saved
Source files updated
Unused images detected
Dynamic references or parsing issues requiring review

I still recommend running this on a clean Git branch. A dry run reduces surprises; Git gives you the final, exact review surface.

What pixcrush does not handle yet

The current limitations are intentional and worth stating clearly:

CSS files are not parsed, so references inside url(...) are not rewritten. An image referenced only from CSS may also appear in the unused-image report; review that list carefully before using --delete-originals.
Dynamic paths are detected but not automatically converted.
The image inputs are currently PNG, JPG, and JPEG.
Framework-convention metadata images are excluded for safety.

If a project relies heavily on CSS backgrounds or dynamically generated filenames, expect some manual work after the automated pass.

“Automated” should not mean “pretend every edge case is safe.”

What changed for me

The biggest improvement is not that Sharp can produce a WebP file. The biggest improvement is that the full cleanup is now one reviewable operation.

The old workflow looked like this:

find → upload → hit a limit → try another tool → download
→ replace files → search the codebase → update paths → repeat

The new workflow is:

npx pixcrush . --dry-run
npx pixcrush .

That is the kind of automation I like: not a new platform, dashboard, subscription, or upload queue. Just a local tool that removes a chore and then gets out of the way.

Try it

pixcrush is open source and runs locally:

npx pixcrush .

If you try it on a real React, Next.js, or Turborepo project, I would especially love feedback on path-resolution edge cases and file types worth supporting next.

Connect with me ✌🏻:

LinkedIn: Karishma garg
Twitter: _karishma10
GitHub: karishma-dev
Portfolio: www.karishma.dev

@seosiri/developer-ui-kit — a zero-dependency React licensing guard for SaaS dashboards

Thu, 24 Sep 2026 03:38:24 +0000

TL;DR: @seosiri/developer-ui-kit (v1.0.1, MIT, 0 dependencies) is a framework-agnostic React component library with a built-in Flexible Licensing Guard for gating PRO/ENT features in SaaS dashboards. Works with Vite, Next.js, Electron, and Atlassian Forge out of the box.

Why this exists

Every SaaS dashboard eventually needs to answer: is this user allowed to see this feature? Usually that turns into a one-off component, duplicated across every internal tool a team ships. This package makes that component reusable and auditable instead of reinvented per project.

How it works

The UniversalSaaSWidget component takes a license token, checks its prefix (PRO_ or ENT_) either locally or against a backend gateway, and renders the corresponding tier — with a real-time telemetry state (verifying / verified / error) so the UI never sits in an ambiguous loading state.

npm install @seosiri/developer-ui-kit

import { UniversalSaaSWidget } from '@seosiri/developer-ui-kit';

<UniversalSaaSWidget
  productName="SEOSiri Analytics Panel"
  productVersion="1.0.1"
  accentColor="#0284c7"
  theme="dark"
  onProTask={() => alert('Executing secure enterprise pipeline task...')}
/>

What's actually notable here

0 dependencies — verifiable on the npm page itself, not a marketing claim.
Framework-agnostic by construction — no CSS provider, no context wrapper; it's pure React with encapsulated inline styles, which is why it compiles across Vite/Next.js/Electron/Forge without extra config.
MIT licensed, source on GitHub — open core, with the licensing guard controlling feature access, not code access.

Worth discussing

If you're doing something similar — gating features by license tier in a React dashboard — how are you currently handling it? Custom hook, context provider, or something like this baked into a component? Curious what other teams have converged on.

Full technical breakdown (with architecture diagram and a build-vs-buy comparison table): https://www.seosiri.com/2026/09/developer-ui-kit.html

🔥 30 Days of Frontend - Day 1

Wed, 23 Sep 2026 20:38:13 +0000

What Actually Happens When State Changes in React?

When state changes, many developers think:

setState() → React updates the DOM

That's a useful simplified model, but there's more happening in between.

A better mental model is:

State / Props change
        ↓
React schedules a render
        ↓
Component runs again
        ↓
React reconciles the new tree
        ↓
React commits the required DOM changes

1. State or props change

For example:

const [count, setCount] = useState(0);

setCount(count + 1);

The state update tells React that the component needs to be rendered again.

2. The component runs again

React calls the component function again using the new state:

function Counter() {
  const [count, setCount] = useState(0);

  return <button>{count}</button>;
}

This is what we commonly call a re-render.

3. React creates the new element tree

The component produces a new React element tree based on the current state and props.

React now has:

Previous tree
      ↓
New tree

It needs to determine what actually changed.

4. React reconciles the trees

React compares the new result with the previous one.

For example:

Before: <button>0</button>
After:  <button>1</button>

React doesn't need to recreate the entire DOM.

It determines the necessary update.

5. React commits the changes

After React determines what needs to change, it commits those changes to the actual DOM.

So remember:

A re-render does NOT mean the entire DOM is recreated.

This distinction is important when thinking about React performance.

A component rendering again isn't automatically a performance problem.

Instead, ask:

Did this render produce unnecessary work?

That's where tools such as React DevTools Profiler become useful. They can help you identify expensive or unnecessary rendering before you start adding optimizations.

The mental model

Keep this simple flow in mind:

Update
  ↓
Render
  ↓
Reconcile
  ↓
Commit

Understanding this flow makes React performance optimization much easier to reason about.

Before reaching for useMemo, useCallback, or React.memo, understand what is actually causing the work.

Profile first. Optimize second.

Optimizing User Idle Detection in React

Tue, 22 Sep 2026 17:38:46 +0000

The Challenge of Responsive Idle Tracking

Tracking user inactivity is essential for modern web applications—whether it's auto-saving drafts, timing out sessions, or pausing resource-heavy animations. However, naïve implementations of activity listeners often lead to performance bottlenecks due to excessive event firing.

In the latest update to react-hook-lab, I have refined the useIdle hook to implement dynamic throttling, ensuring that your state updates remain performant even during high-frequency user interactions.

What Changed?

The useIdle hook now calculates its throttle threshold dynamically based on your defined timeout. By capping the throttle at half the duration of your timeout, we ensure the hook stays responsive while preventing unnecessary render cycles.

Usage Example

Basic usage to track inactivity after 5 seconds:

import { useIdle } from 'react-hook-lab';

const App = () => {
  const isIdle = useIdle(5000);

  return <div>User is {isIdle ? 'Idle' : 'Active'}</div>;
};

For scenarios with shorter timeouts, the logic automatically adjusts the throttle to maintain accuracy:

// Automatically scales throttling for a 1s timeout
const isQuickIdle = useIdle(1000);

Resources

Originally published on my blog. You can read the alternative breakdown here.

Why Your Next.js Modal Route Works Perfectly Until Someone Refreshes the Page

Tue, 22 Sep 2026 08:14:06 +0000

This one isn't really a bug, it's a genuinely common point of confusion about a feature working exactly as designed, and understanding why it behaves this way changes how you'd actually build around it, rather than fighting it.

Intercepting routes are what makes an Instagram-style interaction possible in the App Router, click a photo in a grid, it opens as a modal overlay on top of the current page, without a full navigation, while the URL still updates to something shareable and bookmarkable.

app/
├── @modal/
│   ├── default.tsx
│   └── (.)photo/
│       └── [id]/
│           └── page.tsx    // renders as a modal when intercepted
├── photo/
│   └── [id]/
│       └── page.tsx        // the actual full page
├── layout.tsx
└── page.tsx                 // the grid

Click a photo from the grid, and the (.)photo/[id] route intercepts the navigation, rendering the modal version in the @modal slot on top of the grid, without a full page transition. The URL correctly updates to /photo/123. It feels seamless, and it's a genuinely well-built pattern for exactly this kind of interaction.

Where the Confusion Starts

Someone building this, testing by clicking through the grid, sees exactly the intended modal behavior. Then they refresh the page while the modal is open, or share that /photo/123 URL with someone else, or that someone else pastes it directly into a new browser tab, and instead of the modal, they get the full, standalone photo/[id]/page.tsx page, no grid behind it, no modal chrome, just the plain page rendering on its own.

The natural first reaction is that something's broken, the modal "isn't working" on refresh. It's actually working exactly as designed, just not in the way that first reaction assumes.

Why This Is Correct, Not Broken

Interception is specifically a client-side navigation behavior. It only intercepts a navigation that happens through Next.js's client-side router, clicking a <Link>, calling router.push(), moving from one already-loaded page to another within the same app session. A hard refresh, a direct URL visit, or someone opening that link in a completely fresh browser tab isn't a client-side navigation at all, it's a fresh, full server request for that specific URL, with no prior page state to intercept from, no grid already rendered behind it to interrupt. Next.js correctly falls back to rendering the actual underlying route, the full page, because that's genuinely the only thing that makes sense in a context where there's no previous client-side navigation to interrupt in the first place.

This is why the folder structure includes both the intercepted route ((.)photo/[id], the modal version) and the actual route (photo/[id], the full page) as separate, real routes. The full page isn't a fallback or an error state, it's the intended, correct experience for anyone arriving at that URL directly, someone who shared or bookmarked the link, a search engine crawling it, anyone without an existing client-side session to interrupt.

The Actual Design Implication

This isn't something to work around, it's something to design for deliberately. The full, non-modal version of the route needs to be a genuinely complete, standalone page on its own merits, not a stripped-down fallback that only half-works, since a real share of your actual traffic to that URL, direct visits, refreshes, shared links, search engines, will land there specifically, not on the modal version.

// app/photo/[id]/page.tsx
// This needs to be a genuinely complete page, not an afterthought,
// since direct visits, refreshes, and shared links all land here specifically
export default async function PhotoPage({ params }) {
  const { id } = await params;
  const photo = await getPhoto(id);

  return (
    <div>
      <BackToGridLink /> {/* since there's no grid rendered behind this version */}
      <PhotoDisplay photo={photo} />
      <PhotoMetadata photo={photo} />
    </div>
  );
}

Including something like a clear way back to the grid, since this version genuinely doesn't have the grid rendered behind it the way the modal does, treats this as the real, complete experience it needs to be for a meaningful share of actual visitors, rather than assuming everyone always arrives via the modal path.

Why This Actually Matters for SEO Too

This split has a genuine upside worth being deliberate about. Since the full page is a real, standalone route, it's exactly what search engines actually crawl and index, a real, complete, server-rendered page for that specific photo, with its own metadata, its own content, rather than something only reachable through a client-side modal interaction a crawler would never trigger. Building the full page version to be genuinely complete isn't just handling an edge case gracefully, it's the version doing real SEO work for that specific piece of content.

The Actual Rule

Intercepting routes are a client-side navigation enhancement layered on top of real, independently functional routes, not a replacement for them. The full, non-intercepted version of the route needs to be built as a genuinely complete experience on its own, since refreshes, direct visits, shared links, and search engine crawlers all land there specifically, not on the modal version, and treating it as an afterthought means a real share of your actual traffic gets an incomplete experience.

If you're building or have built an intercepting route pattern, worth checking whether the full, non-modal version genuinely stands on its own, or was built assuming everyone always arrives through the modal. Drop your experience with this pattern in the comments, curious how many people hit this exact confusion the first time before understanding why it's actually correct.

Get the templates: https://pixelanas.gumroad.com

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Building an Interactive Knowledge Graph with React: The MyZubster MONERO Implementation

Mon, 21 Sep 2026 10:19:43 +0000

Building an Interactive Knowledge Graph with React: The MyZubster MONERO Implementation

We recently added an interactive Knowledge Graph to MyZubster, starting with the MONERO / ART-001 knowledge node.

The objective was straightforward: move beyond isolated documentation pages and create a navigable network connecting articles, concepts, sources, and related topics.

You can explore the first node here:

https://myzubster-knowledge.vercel.app/conoscenze?domain=MONERO&id=ART-001

The problem

Traditional documentation usually follows a hierarchical structure:

Category
└── Article
    └── Content

This works for reading individual pages, but it does not clearly reveal how knowledge is connected.

An article about Monero may be related to:

privacy;
open-source development;
transaction mechanisms;
official documentation;
other MyZubster articles.

We wanted the interface to expose these relationships directly.

The resulting model looks more like this:

ART-001
├── related → ART-002
├── related → ART-003
├── source → monero-docs
├── concept → Privacy
└── concept → Open Source

Stable knowledge URLs

Each article is identified by two parameters:

domain + id

For example:

domain = MONERO
id = ART-001

The public URL becomes:

/conoscenze?domain=MONERO&id=ART-001

This approach gives every knowledge node a stable and shareable address.

The same frontend can later support additional domains:

MONERO / ART-001
KEFIR / ART-001
PERMACULTURE / ART-001
SOUND-SYSTEM / ART-001
CYBERSECURITY / ART-001

The user interface does not need a separate implementation for every domain.

Current knowledge nodes

The initial MONERO graph includes three articles:

ART-001 — Introduction to Monero

https://myzubster-knowledge.vercel.app/conoscenze?domain=MONERO&id=ART-001

This is the root node. It connects the introductory article to its sources, concepts, and related articles.

ART-002 — Privacy in Monero

https://myzubster-knowledge.vercel.app/conoscenze?domain=MONERO&id=ART-002

This node introduces the privacy-related branch of the graph.

ART-003 — Monero Transactions

https://myzubster-knowledge.vercel.app/conoscenze?domain=MONERO&id=ART-003

This node provides the initial connection to transaction-related knowledge.

The React implementation

MyZubster currently uses React 18 with Create React App.

The Knowledge Graph feature introduced:

frontend/src/data/knowledge.js
frontend/src/pages/KnowledgeGraphPage.js
frontend/src/pages/KnowledgeGraphPage.css

The main application route was also updated in:

frontend/src/App.js

Both of these paths open the graph:

/conoscenze
/knowledge

The data model

The current implementation stores structured knowledge records in the frontend.

A simplified article looks like this:

'MONERO:ART-001': {
  id: 'ART-001',
  domain: 'MONERO',
  title: 'Introduction to Monero',
  summary: 'Fundamental concepts of Monero, privacy, and connected documentation.',

  tags: [
    'monero',
    'privacy',
    'open-source'
  ],

  relations: [
    {
      id: 'ART-002',
      label: 'Privacy'
    },
    {
      id: 'ART-003',
      label: 'Transactions'
    }
  ],

  sources: [
    {
      id: 'SRC-001',
      title: 'monero-docs',
      url: 'https://www.getmonero.org/resources/user-guides/'
    }
  ],

  concepts: [
    {
      id: 'CON-PRIVACY',
      title: 'Privacy'
    },
    {
      id: 'CON-OSS',
      title: 'Open Source'
    }
  ]
}

The lookup key combines the domain and article ID:

const article = knowledgeArticles[`${domain}:${id}`];

This avoids collisions between articles belonging to different domains.

Reading the URL

The page reads the selected article from the query string:

const params = new URLSearchParams(window.location.search);

const domain = (
  params.get('domain') || 'MONERO'
).toUpperCase();

const id = (
  params.get('id') || 'ART-001'
).toUpperCase();

If no parameters are supplied, the interface opens MONERO / ART-001.

If the requested record does not exist, the page returns a clear article-not-found state.

Generating graph nodes

The page converts the selected knowledge record into visual nodes.

The root article becomes the central node:

{
  key: `a:${article.id}`,
  id: article.id,
  type: 'article',
  title: article.title,
  description: article.summary
}

Related articles, sources, and concepts are then added around it.

Different prefixes prevent identifier collisions:

a:ART-001
s:SRC-001
c:CON-PRIVACY

This is important because an article, source, and concept could theoretically use similar identifiers.

Graph interaction

Users can:

select a node;
inspect its title, type, identifier, and description;
filter nodes by type;
open related articles;
open external sources;
share the current article URL.

The available filters are:

All
Articles
Sources
Concepts

A related article is opened by updating the URL:

window.location.assign(
  `/conoscenze?domain=${domain}&id=${node.id}`
);

This reloads the same React page with another knowledge record.

How to explore the graph

Open the root node:

https://myzubster-knowledge.vercel.app/conoscenze?domain=MONERO&id=ART-001
Select one of the surrounding nodes.
Read its metadata in the information panel.
Use the filters to isolate articles, sources, or concepts.
Select a related article and choose “Open article.”
Copy the browser URL to share that exact knowledge node.

How developers can add an article

Open:

frontend/src/data/knowledge.js

Add a new record:

'MONERO:ART-004': {
  id: 'ART-004',
  domain: 'MONERO',
  title: 'New Monero Article',
  summary: 'A concise explanation of the subject.',

  tags: [
    'monero',
    'documentation'
  ],

  relations: [
    {
      id: 'ART-001',
      label: 'Introduction'
    }
  ],

  sources: [
    {
      id: 'SRC-002',
      title: 'Source title',
      url: 'https://example.org/source'
    }
  ],

  concepts: [
    {
      id: 'CON-EXAMPLE',
      title: 'Example concept'
    }
  ]
}

The article will then be available at:

/conoscenze?domain=MONERO&id=ART-004

To make it discoverable from another node, add a reciprocal or relevant relationship to an existing article.

Build and verification

After modifying the knowledge data, run:

cd frontend
npm run build

The production build should complete without compilation errors.

Then test the new route:

/conoscenze?domain=MONERO&id=ART-004

Before submitting the change, verify that:

the article ID is unique within its domain;
every related article exists;
source URLs are correct;
titles and summaries are clear;
the mobile layout remains usable;
unsupported claims are not presented as verified facts.

Contribution guidelines

A useful knowledge contribution should include:

a stable article ID;
the correct domain;
a descriptive title;
a concise summary;
relevant tags;
relationships with existing nodes;
reliable sources;
clearly named concepts;
limitations or uncertainty where appropriate.

A graph relationship indicates that two subjects are connected. It does not automatically prove a claim or imply scientific validation, partnership, or endorsement.

Source provenance and review status remain essential.

Deployment workflow

The feature was developed on a dedicated Git branch:

feature/knowledge-graph-monero

The frontend production build was verified before the branch was rebased onto the latest main.

The final implementation was merged into main and pushed to the public repository.

Source repository:

https://github.com/MyZubster-Ecosystem/myzubster

Implementation commit:

https://github.com/MyZubster-Ecosystem/myzubster/commit/43c7d966

Next steps

The current version uses frontend data to establish the interaction model.

A future version can move the knowledge records into a dedicated API or versioned content repository.

Potential improvements include:

server-side schema validation;
automatic backlinks;
multi-level graph expansion;
full-text search;
contributor attribution;
review and publication states;
source provenance;
revision history;
API-driven graph generation;
integration with Zorgax;
support for additional knowledge domains.

The long-term objective is not simply to collect articles. It is to create a community knowledge network where people can explore how information, evidence, concepts, and practical experience relate to one another.

Try the first node:

https://myzubster-knowledge.vercel.app/conoscenze?domain=MONERO&id=ART-001

Repository:

https://github.com/MyZubster-Ecosystem/myzubster

React #JavaScript #KnowledgeGraph #OpenSource #WebDevelopment #Monero #KnowledgeManagement #MyZubster

⚛️ Controlled vs Uncontrolled Components in React – A Deep Dive

Sat, 19 Sep 2026 19:08:29 +0000

When building forms in React, you’ll inevitably come across controlled and uncontrolled components.
At first glance, they look similar — both accept user input and manage form data.
But how they manage that data under the hood can significantly impact performance, maintainability and UX.

In this blog, let’s break down the difference, see them in action, explore real-world issues (like cursor position and undo/redo bugs), and understand when to use each.

🧠 What Are Controlled Components?

In controlled components, React state is the single source of truth.
That means every keystroke or change updates the component’s state and that state determines what’s rendered.

Example:

import { useState } from "react";

function ControlledInput() {
  const [name, setName] = useState("");

  return (
    <input
      value={name}
      onChange={(e) => setName(e.target.value)}
      placeholder="Type your name"
    />
  );
}

Here, the <input> value is fully controlled by React via the name state.
Each keystroke triggers setName(), re-rendering the component with the updated value.

✅ Pros

Easy to validate or transform input on change.
Centralized state makes debugging and unit testing easier.
Integrates seamlessly with complex UIs or form libraries (Formik, React Hook Form).

⚠️ Cons

Frequent re-renders can impact performance in large forms.
Need to carefully manage performance and input lag.
Cursor position bugs can occur with advanced state management.

🧩 What Are Uncontrolled Components?

In uncontrolled components, the DOM maintains its own state — React just references it.
You don’t handle every keystroke; instead, you access the value when needed.

Example:

import { useRef } from "react";

function UncontrolledInput() {
  const inputRef = useRef();

  const handleSubmit = () => {
    alert(`Input value: ${inputRef.current.value}`);
  };

  return (
    <>
      <input ref={inputRef} placeholder="Type your name" />
      <button onClick={handleSubmit}>Submit</button>
    </>
  );
}

✅ Pros

Better performance for simple forms.
Minimal React re-renders.
Perfect when you just need the final value.

⚠️ Cons

Harder to validate or modify values dynamically.
Not ideal when input data must always reflect application state.

⚔️ Controlled vs Uncontrolled: Key Differences

Feature	Controlled	Uncontrolled
Data Source	React State	DOM (via refs)
Performance	May re-render often	Faster for simple inputs
Validation	Easy to handle dynamically	Requires manual check
Use Case	Complex, validated forms	Simple or performance-critical inputs

⚡ Valtio & Controlled Inputs: Why Cursor Jumps Happen

When you use a state library like Valtio in a React controlled input, you might encounter this issue: you edit text in the middle of the input, but the cursor jumps to the end. This frustrates users and breaks the typing experience.

🔍 What’s going on?

By default, Valtio batches updates before triggering re-renders. The documentation states:

“By default, state mutations are batched before triggering re-render. Sometimes, we want to disable the batching.”
Because of this batching behavior, when you type and update the proxy state, multiple changes may be queued and then re-rendered in one go. During that delay, the browser loses context of the input cursor position, so after render the input’s value is applied and the cursor jumps to the end.

✅ The fix: { sync: true }

Valtio provides the option to disable batching for specific use-cases like inputs:

const snap = useSnapshot(state, { sync: true });

With sync: true, updates go through immediately rather than being deferred/batched. This keeps the input cursor where the user expects it.

⚠️ Trade-off:

Using sync: true disables batching optimizations, which can reduce render efficiency in large/complex components. Therefore:

Use sync: true only in input fields where cursor behaviour matters.
Avoid it for general state where performance is more important than instantaneous update.

🔁 Undo/Redo (Cmd+Z / Cmd+Shift+Z) in Controlled Components

Another subtle but important issue:
Undo (Cmd+Z) and Redo (Cmd+Shift+Z) might not work as expected in controlled inputs.

Why?
Because React replaces the entire value on every keystroke rather than letting the browser handle native input history.

This means the browser sometimes loses the input undo stack, especially if re-renders happen between updates.

🧪 What to do:

Test undo/redo behavior in all input fields before handing over to QA.
If using a state library or custom hooks, check whether it maintains the input history properly.
In cases where it fails and browser-native undo is critical (e.g., long text editors), consider using uncontrolled inputs or controlled wrappers that debounce updates.

🧰 Best Practices for React Forms

✅ Use controlled inputs when you need validation, dynamic control or shared state.
✅ Use uncontrolled inputs when performance and simplicity matter.
✅ For state libraries like Valtio, test cursor and undo behaviors thoroughly.
✅ Avoid unnecessary re-renders – use React.memo, useCallback or split components.
✅ Always test form UX — typing, cursor and undo/redo should feel native and fluid.

🎯 Final Thoughts

Controlled vs Uncontrolled Components seem like a small React concept, but they can deeply impact user experience, especially in complex form-heavy applications.

💡 Understanding these nuances (like cursor handling, undo/redo, and batching) helps you ship smoother, bug-free UIs that feel professional and reliable.

🚀 Whether you use plain React or libraries like Valtio, always test the real typing experience — that’s where users feel the difference.

💬 Have you ever faced cursor or undo issues in your React forms? Drop your experience or workaround below — let’s learn together! 👇

How to Build a Full-Stack AI Tools Directory App (Next.js 14 + Supabase)

Sat, 19 Sep 2026 17:02:52 +0000

Looking to build a production-ready web application or launch a SaaS directory? In this comprehensive guide, we build a scalable AI Tools Directory from scratch using a modern tech stack.

Here is what you will learn in this step-by-step guide:

🏗️ Tech Stack & Setup: Setting up Next.js 14 (App Router), Tailwind CSS, and TypeScript from scratch.

🗄️ Database Architecture: Designing PostgreSQL schemas in Supabase with proper indexing and Row Level Security (RLS) policies.

⚡ API Routes & Filtering: Creating dynamic Next.js API endpoints that support real-time search, category filters, and pagination.

🎨 Modern UI Components: Building responsive, interactive UI components with Tailwind CSS and Lucide React.

🔍 SEO Optimization: Implementing dynamic metadata generation and Structured Data (JSON-LD) for tool pages to maximize organic search traffic.

🚀 Deployment: Deploying the application seamlessly on Vercel with full environment security.

Check out the full tutorial below and start building your own AI directory today!

👉 Read the full tutorial here: [https://www.thefluxread.com/2026/09/how-to-build-full-stack-ai-tools.html]

nextjs #supabase #webdev #react #javascript #ai #tailwindcss

Project LifeOps (Part 5): 24/7 Zero-Cost Cloud Deployment ($0/month), Mobile Optimization, and PWA

Sat, 19 Sep 2026 10:13:09 +0000

We have arrived at the grand finale of our engineering series. Across the four previous installments, we designed the database architecture and FastAPI backend, crafted the Glassmorphism Dark Mode React interface, built the interactive fitness, reading, cinema, and Kanban modules, and developed the in-memory Word and Excel reporting engine.

Yet in software development, a sobering pattern exists: countless extraordinary personal projects wither and die on localhost:3000 or localhost:8000.

The obstacle is almost always the same: production cloud deployment is often perceived as a labyrinth of daunting server configurations, mounting database subscription fees, or the burden of maintaining live virtual machines. And when aiming to bring web apps to smartphones, developers frequently encounter costly gatekeepers: Apple Developer fees ($99/year), Google Play fees, opaque store review cycles, and massive hybrid frameworks.

In this final installment, we demonstrate a far more elegant, sustainable path:

Deploying the entire full-stack architecture 24/7 at exactly $0.00/month.
Seamlessly handling free cloud container sleep cycles (cold-starts) on the client side.
Engineering an ultra-ergonomic touch experience optimized for modern smartphones (Android / Samsung Galaxy and iPhone).
Transforming the application into an installable Progressive Web App (PWA) added directly to home screens.

[!TIP]
Test the live app: You can explore the final production release of LifeOps at https://datalaria.com/apps/lifeops/.

🗺️ Complete LifeOps Series Roadmap

With this post, the full 5-part blueprint is complete:

🟢 Part 1: Personal Operating System Architecture and FastAPI + Supabase Backend
🟢 Part 2: React Frontend with Glassmorphism, 360° Dashboard, and Design System
🟢 Part 3: Core Interactive Modules: Fitness, Library, Cinema, and Professional Kanban Board
🟢 Part 4: Executive Word (.docx) Reporting Engine and Multi-Sheet Excel (.xlsx) Export
🟢 Part 5 (This article): 24/7 Zero-Cost Cloud Deployment ($0/month), Mobile UX, and PWA

1. Production Cloud Topology ($0/month) 🌐☁️

To guarantee that LifeOps remains online 24/7 without recurring cloud invoices, we strategically leverage the most generous free tiers available:

┌─────────────────────────────────────────────────────────────┐
│                       CLIENT DEVICE                         │
│           Web Browser / Installed Home Screen PWA           │
│            [https://datalaria.com/apps/lifeops/](https://datalaria.com/apps/lifeops/)              │
└──────────────────────────────┬──────────────────────────────┘
                               │
                               ▼
┌─────────────────────────────────────────────────────────────┐
│               FRONTEND: Netlify Edge CDN ($0/month)         │
│   • Vite build with Rollup Code Splitting (vendor-*)        │
│   • Instant global edge delivery via Gzip / Brotli          │
│   • Transparent proxy rewrite under Datalaria domain        │
└──────────────────────────────┬──────────────────────────────┘
                               │
            JWT Bearer Tokens  │  HTTPS REST Calls
                               ▼
┌─────────────────────────────────────────────────────────────┐
│               BACKEND: Render.com Web Service ($0/month)    │
│   • FastAPI + Uvicorn container (Python 3.11 / 3.13)        │
│   • Endpoint: [https://lifeops-api.onrender.com](https://lifeops-api.onrender.com)              │
│   • Anti-DoS Rate Limiting (slowapi) + Strict CORS          │
│   • Auto-spins down after 15 minutes of inactivity          │
└──────────────────────────────┬──────────────────────────────┘
                               │
                               ▼
┌─────────────────────────────────────────────────────────────┐
│              DATABASE: Supabase Cloud ($0/month)            │
│   • Managed PostgreSQL 15+ database instance                │
│   • Isolated `lifeops` schema with Row Level Security (RLS) │
│   • Cryptographic JWT session validation                    │
└─────────────────────────────────────────────────────────────┘

1.1. Vite Bundle Optimization (`vite.config.js`)

To guarantee sub-second initial loads across 4G and 5G mobile networks, we configured Rollup manual chunking:

import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';

export default defineConfig({
  plugins: [react()],
  base: './', // Enables serving the SPA from any nested route (/apps/lifeops/)
  build: {
    rollupOptions: {
      output: {
        manualChunks(id) {
          if (id.includes('node_modules')) {
            if (id.includes('react') || id.includes('react-dom') || id.includes('react-router-dom')) {
              return 'vendor-react';
            }
            if (id.includes('lucide-react')) {
              return 'vendor-icons';
            }
            if (id.includes('@supabase')) {
              return 'vendor-supabase';
            }
            return 'vendor-libs';
          }
        },
      },
    },
    chunkSizeWarningLimit: 600,
  },
});

By segmenting vendor-react and @supabase, user browsers permanently cache stable external dependencies. When application features update, visitors download only a lightweight diff of new business logic.

2. Conquering Cold-Starts: Client-Side Resilience 🛡️⏱️

The only operational tradeoff on Render's free tier is container hibernation after 15 minutes of zero traffic.

When an end-user opens LifeOps after hours of downtime, the first HTTP request requires 25 to 45 seconds while Render allocates a container and initializes Uvicorn. Without proactive client-side handling, users face gateway timeouts (HTTP 504) or frozen interfaces.

In LifeOps, we turned this limitation into an informative, guided user experience:

// lifeops-app/src/components/Dashboard/SystemHealth.jsx
const checkHealth = async (isAutoRetry = false) => {
  setLoading(true);
  if (!isAutoRetry) setError(null);

  try {
    const data = await api.getHealth();
    setHealth(data);
    setError(null);
  } catch (err) {
    setError(err.message || 'Connecting to API...');
    
    // Auto-retry loop up to 3 times with 6-second delay while Render awakens
    if (retryCount < 3) {
      setTimeout(() => {
        setRetryCount((prev) => prev + 1);
      }, 6000);
    }
  } finally {
    setLoading(false);
  }
};

What happens behind the scenes?

The initial health check dispatches a wake-up ping to the backend.
The UI renders a friendly, transparent notification: "Render instance waking up (Cold start)... retrying automatically".
The frontend retries in the background every 6 seconds without interrupting client navigation.
As soon as FastAPI responds with HTTP 200, the badge shifts to green ("FastAPI Online • Supabase Connected"), fetching data without requiring a manual page refresh.

3. Thumb-Accessible Mobile Ergonomics (Android & iOS) 📱👍

Over 70% of daily interactions with a personal operating system occur on smartphones: logging a workout right after a run, cataloging a book during a commute, or reviewing Kanban deliverables from the couch.

On a 6.5-inch device held in one hand, forcing the user's thumb to reach all the way to the top-left corner for a hamburger menu is poor ergonomic design.

We anchored the mobile user experience on three ergonomic pillars:

┌─────────────────────────────────────────────────────────────┐
│ 📱 SMARTPHONE VIEWPORT (<= 768px)                           │
├─────────────────────────────────────────────────────────────┤
│  [Top Header]: LifeOps Logo       [Locale ES/EN] [User Icon]│
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌───────────────────────────────────────────────────────┐  │
│  │ 🪟 FLOATING MODAL (React Portal)                      │  │
│  │ ───────────────────────────────────────────────────── │  │
│  │ [=== Drag Handle: slide down to dismiss ===]          │  │
│  │                                                       │  │
│  │  Title: Log Workout Session                           │  │
│  │  • 16px font inputs (prevents iOS Safari auto-zoom)   │  │
│  │  • Smooth touch scroll (touch-action: pan-y)          │  │
│  │                                                       │  │
│  │ ───────────────────────────────────────────────────── │  │
│  │ [📌 STICKY FOOTER ACTIONS: [ Cancel ] [ Save Record ]]│  │
│  └───────────────────────────────────────────────────────┘  │
│                                                             │
├─────────────────────────────────────────────────────────────┤
│ 📌 FIXED BOTTOM NAVIGATION BAR (Height: 64px)               │
│ [ 📊 Dashboard ] [ 🏃 Personal ] [ 💼 Tasks ] [ ⚙️ Settings ]│
└─────────────────────────────────────────────────────────────┘

3.1. Fixed Bottom Navigation Bar (`BottomNav.jsx`)

Stationed permanently along the screen footer (position: fixed; bottom: 0; z-index: 1000;), it houses 5 prominent touch targets (48x48px touch bounding boxes following Apple and Google accessibility standards), allowing instantaneous section transitions with a thumb tap.

3.2. Off-Canvas Sliding Drawer

The primary navigation sidebar (Sidebar.jsx) switches behavior based on screen real estate:

On Desktop (> 768px): Expands to 260px or collapses to a slim 72px icon bar with floating tooltips, persisted in localStorage.
On Mobile (<= 768px): Becomes an Off-Canvas drawer sliding in over a frosted backdrop (backdrop-filter: blur(8px)), auto-dismissing on link navigation.

3.3. Viewport-Anchored Modals with `React.createPortal` (`Modal.jsx`)

Form modals in mobile CSS are notorious for layout bugs: getting clipped by ancestor containers, misaligning behind virtual keyboards, or burying save buttons beneath the fold.

In LifeOps, we engineered a clean architectural solution:

// Rendered directly into document.body via React Portal
export function Modal({ isOpen, onClose, title, children }) {
  ...
  if (!isOpen) return null;

  return createPortal(
    <div className="modal-backdrop" onClick={onClose}>
      <div className="modal-content" onClick={(e) => e.stopPropagation()}>
        {/* Touch drag handle for swipe-to-close */}
        <div className="modal-drag-handle-area" onTouchStart={handleTouchStart} onTouchMove={handleTouchMove} onTouchEnd={handleTouchEnd}>
          <div className="modal-drag-pill" />
        </div>
        <div className="modal-header">...</div>
        <div className="modal-body">{children}</div>
      </div>
    </div>,
    document.body
  );
}

/* Precise Mobile Viewport Anchoring (Modal.css) */
@media (max-width: 768px) {
  .modal-backdrop {
    padding: 12px 10px calc(64px + 12px) 10px; /* Terminates exactly above the bottom nav */
    height: 100dvh; /* Dynamic Viewport Height handles mobile address bars */
  }

  .modal-body {
    touch-action: pan-y !important; /* Smooth touch gesture scrolling */
  }

  .form-group input, .form-group select {
    font-size: 16px !important; /* Prevents unwanted iOS Safari viewport auto-zooming */
  }

  /* Action buttons remain permanently docked in view */
  .form-actions {
    position: sticky !important;
    bottom: 0 !important;
    background: #111827 !important;
    z-index: 30;
  }
}

With createPortal, modals break free from ancestor stacking contexts. And thanks to calc(64px + 12px) and sticky footers, the Cancel and Save buttons remain permanently anchored in thumb view, regardless of form length.

4. Progressive Web App (PWA) Transformation 📲✨

For an application to feel native on a mobile device, it must install without store middlemen.

We configured modern meta tags and web app standards in index.html:

<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no, viewport-fit=cover" />
<meta name="theme-color" content="#111827" />
<meta name="apple-mobile-web-app-capable" content="yes" />
<meta name="apple-mobile-web-app-status-bar-style" content="black-translucent" />
<link rel="icon" type="image/svg+xml" href="favicon.svg" />

Key Benefits as an Installed PWA:

Home Screen Presence: High-resolution branded icon sitting alongside native apps on Android and iOS.
Fullscreen Standalone Mode: Browser URL bars and navigation chrome disappear, reclaiming 15% of vertical screen space.
Status Bar Theming: Device battery and clock bars harmonize seamlessly with the #111827 glassmorphic palette via theme-color.
Instant Updates: New builds deploy live over Git without waiting days for third-party store approvals.

5. Retrospective: Lessons Learned from the LifeOps Blueprint 🎓💡

Architecting and engineering LifeOps from the ground up has been one of the most rewarding journeys documented on Datalaria.

To conclude our technical journey, here are the three foundational takeaways:

Relational modeling outperforms flat schemas as telemetry matures:
Structuring general events in lifeops.activities with 1-to-1 extension tables (workouts, books, films) and employing JSONB for progress timelines delivered superior maintainability over sprawling, null-riddled tables.
Deliberate design fosters consistent user adherence:
Investing in visual polish (Glassmorphism, hardware-accelerated blurs, Outfit typography, and consistent Lucide iconography) transforms daily logging into an enjoyable ritual rather than a chore.
Modern serverless tooling enables $0/month production without compromises:
The pairing of FastAPI + Supabase + React (Vite) + Render + Netlify provides reliability, speed, and cryptographic security rivaling commercial SaaS platforms charging $15/month per seat.

Series Conclusion & Complete Index 🚀

With this fifth installment, the official LifeOps series stands complete. You have access to the complete source code, architectural rationales, and production implementation details step by step.

I invite you to try the live application, experiment with its modules, and draw inspiration to build your own bespoke systems guided by Datalaria's core motto: "Learn by building".

Complete Series Reference & Links 🔗

🚀 LifeOps Live Application: datalaria.com/apps/lifeops.
🌐 Interactive OpenAPI Docs: lifeops-api.onrender.com/docs.
📚 Part 1: Personal Operating System Architecture and FastAPI + Supabase Backend.
🎨 Part 2: React Frontend with Glassmorphism, 360° Dashboard, and Design System.
📋 Part 3: Core Interactive Modules: Fitness, Library, Cinema, and Professional Kanban Board.
📊 Part 4: Executive Word (.docx) Reporting Engine and Multi-Sheet Excel (.xlsx) Export.
☁️ Part 5 (This article): 24/7 Zero-Cost Cloud Deployment ($0/month), Mobile UX, and PWA.

Thank you for following along throughout this series! If you are building your own personal operating systems or have ideas for enhancements, share your insights in the comments below. 👇

Taming Async Race Conditions and Unmounted State in React: What's New in react-hook-lab

Fri, 18 Sep 2026 20:26:15 +0000

Taming Async Race Conditions and Unmounted State in React: What's New in react-hook-lab

Every React developer has encountered the dreaded console warning: "Can't perform a React state update on an unmounted component." Or worse, subtle race conditions where an earlier slow network response resolves after a newer one and overwrites valid user data.

In the latest release of react-hook-lab, we focused on hardening our async and browser hooks against edge cases, memory leaks, and unmounted component state updates.

Here is a breakdown of the notable updates, behavioral fixes, and how you can leverage them in your applications.

1. What Changed Across the Suite?

Async Hooks (`useAsync`, `useAsyncDebounce`, `useDebounce`)

Request Invalidation: useAsync now tracks request sequences using internal identifiers. If dependencies change or a component unmounts while a promise is in flight, the stale response is safely discarded without mutating component state.
Controlled Debounce Dependencies: useAsyncDebounce now supports an explicit dependency list alongside internal ref synchronizations to avoid unnecessary re-triggers or missed parameter updates.
Preserving Whitespace with useDebounce: By default, useDebounce trims whitespace on strings. You can now pass { trim: false } to strictly preserve raw input spacing—critical for live text editors and formatted inputs.

Browser & DOM Hooks (`useClipboard`, `useCamera`, `useDownload`, `useFullscreen`, `useCookie`)

Unmount-Safe Timers: useClipboard now exposes a manual reset() helper and safely tears down pending timeout handlers on unmount, preventing lingering timeouts from calling unmounted state setters.
Target-Aware Fullscreen: useFullscreen now strictly tracks whether the active fullscreen element matches the specific target element reference rather than any element on the page.
Path-Aware Cookie Verification: useCookie now accounts for route scopes before attempting verification checks against client-side cookies.

2. Practical Examples

Example 1: Robust Copy to Clipboard with Manual Reset

The updated useClipboard hook guarantees that component unmounts will not leave orphan timers behind, and provides an explicit reset trigger for complex UI states.

import React from "react";
import { useClipboard } from "react-hook-lab";

export function ApiKeyCard({ apiKey }: { apiKey: string }) {
  const { copied, error, copy, reset } = useClipboard(2500);

  return (
    <div className="api-key-container">
      <code>{apiKey}</code>
      <button onClick={() => copy(apiKey)} disabled={copied}>
        {copied ? "Copied!" : "Copy Key"}
      </button>
      {copied && (
        <button onClick={reset} className="secondary-btn">
          Dismiss
        </button>
      )}
      {error && <span className="error-text">Failed to copy: {error.message}</span>}
    </div>
  );
}

Example 2: Debounced Text Input with Preserved Spaces

When debouncing search inputs or markdown editors, trimming trailing spaces prematurely breaks the typing flow. The new trim configuration in useDebounce lets you keep input spacing intact:

import React, { useState } from "react";
import { useDebounce } from "react-hook-lab";

export function RealtimeNotePreview() {
  const [content, setContent] = useState("");

  // Preserve active trailing whitespace while the user pauses
  const debouncedContent = useDebounce(content, 400, {
    trim: false,
  });

  return (
    <div>
      <textarea
        value={content}
        onChange={(e) => setContent(e.target.value)}
        placeholder="Type markdown notes here..."
      />
      <div className="preview">
        <h3>Parsed Output</h3>
        <pre>{debouncedContent}</pre>
      </div>
    </div>
  );
}

3. Upgrading

These updates are backward compatible for the vast majority of consumers while eliminating ghost state updates under heavy re-renders.

npm install react-hook-lab@latest

Resources

GitHub Repository: Saurav-TB-Pandey/react-hook-lab
NPM Package: react-hook-lab
Author LinkedIn: Saurav Pandey

Originally published on my blog. You can read the alternative breakdown here.

Project LifeOps (Part 3): Core Interactive Modules: Fitness, Library, Cinema, and Professional Kanba

Tue, 15 Sep 2026 06:12:43 +0000

In earlier installments, we engineered the foundational backbone of LifeOps: in Part 1 we designed the polymorphic PostgreSQL schema and modular FastAPI backend, and in Part 2 we brought the Glassmorphism Dark Mode design system and global 360° Dashboard to life.

Now comes the most defining phase of development: the day-to-day functional modules.

A personal operating system fails if it forces users into rigid input forms or scatters daily data across disconnected views. The challenge was articulating three completely disparate life areas under unified design and performance standards:

🏃 Health & Physical Fitness: Workout logging across sports with dynamic metrics (distance volume, calories, pace calculations, and Personal Bests).
📚 Intellectual Culture & Media: Book tracking with interactive reading progress bars and an entertainment catalog organized by streaming platform.
💼 Professional Execution: An agile 4-column Kanban board mapped to projects, equipped with a chronological progress log powered by PostgreSQL JSONB.

[!TIP]
Test the live app: You can explore the production build of LifeOps directly at https://datalaria.com/apps/lifeops/.

🗺️ LifeOps Series Roadmap

To understand how every architectural layer fits together, this series spans 5 structured installments:

🟢 Part 1: Personal Operating System Architecture and FastAPI + Supabase Backend
🟢 Part 2: React Frontend with Glassmorphism, 360° Dashboard, and Design System
🟢 Part 3 (This article): Core Interactive Modules: Fitness, Library, Cinema, and Professional Kanban Board
⚪ Part 4: In-Memory Word Dossiers (.docx) & Multi-Sheet Excel Engine (.xlsx)
⚪ Part 5: 24/7 Zero-Cost Cloud Deployment ($0/month), Mobile UX, and PWA

1. The UX Dilemma: Dual View Mode (Inspiring Cards vs. Synthesized Table) 🎴📊

When building data-intensive dashboards, designers face a classic user experience tradeoff:

The Grid / Cards View: Visually engaging, spacious, and inspiring. It highlights book covers, movie posters, and workout chips at a glance.
The Data Table View: Irreplaceable when auditing timestamps, comparing heart rates, or scanning through an entire month of logs without endless vertical scrolling.

Instead of forcing a single opinionated view, I built a persistent dual-mode toggle stored in localStorage:

const [viewMode, setViewMode] = useState(() => {
  return localStorage.getItem('lifeops_view_sport') || 'grid';
});

const handleViewChange = (mode) => {
  setViewMode(mode);
  localStorage.setItem('lifeops_view_sport', mode);
};

In the header of each module, two unobtrusive buttons with LayoutGrid and Table icons toggle the presentation mode instantly. Thanks to React and Vite's build architecture, view switches execute in sub-milliseconds without triggering redundant server roundtrips.

2. Fitness & Performance Module (`SportModule.jsx`) 🏃💨

The fitness module caters to multi-sport athletes practicing running, road cycling, gym strength sessions, and swimming.

┌────────────────────────────────────────────────────────────────────────┐
│  🏃 Sport & Fitness                    [ + Log Workout ]       [⊞|≡]   │
├─────────────────┬─────────────────┬─────────────────┬──────────────────┤
│ TOTAL DISTANCE  │ ACTIVE TIME     │ CALORIES        │ PERSONAL BESTS   │
│   142.5 km      │   18.4 hours    │   12,450 kcal   │    4 PBs 🏅      │
├─────────────────┴─────────────────┴─────────────────┴──────────────────┤
│                                                                        │
│ ┌───────────────────────────┐         ┌──────────────────────────────┐ │
│ │ 🏃 RUNNING         🏅 PB  │         │ 🚴 CYCLING                   │ │
│ │ Sunday Long Run           │         │ Mountain Pass Century Ride   │ │
│ │ 2026-09-10                │         │ 2026-09-08                   │ │
│ │ [📍 21.1 km] [⏱️ 1h 48m]  │         │ [📍 65.0 km] [⏱️ 2h 45m]     │ │
│ │ [🔥 1,420 kcal] [❤️ 152bpm]│        │ [🔥 1,890 kcal] [⛰️ +950m]    │ │
│ └───────────────────────────┘         └──────────────────────────────┘ │
└────────────────────────────────────────────────────────────────────────┘

2.1. Aggregated High-Level KPIs

Before rendering individual activity items, we compute cumulative totals using in-memory array reducers:

const totalKm = workouts.reduce((sum, act) => sum + (act.workout?.distance_km || 0), 0);
const totalMinutes = workouts.reduce((sum, act) => sum + (act.duration_minutes || 0), 0);
const totalCalories = workouts.reduce((sum, act) => sum + (act.workout?.calories || 0), 0);
const pbCount = workouts.filter((act) => act.workout?.personal_best).length;

2.2. Segregated FastAPI Payload

When an athlete records an exercise, the client dispatches a structured contract that FastAPI parses into the master table lifeops.activities and the child table lifeops.workouts:

const payload = {
  activity: {
    activity_type: 'sport',
    title: formData.title,
    date: formData.date,
    duration_minutes: parseInt(formData.duration_minutes),
    description: formData.notes,
  },
  workout: {
    workout_type: formData.workout_type, // 'running' | 'cycling' | 'gym'
    distance_km: parseFloat(formData.distance_km) || null,
    calories: parseInt(formData.calories) || null,
    avg_heart_rate: parseInt(formData.avg_heart_rate) || null,
    elevation_m: parseInt(formData.elevation_m) || null,
    personal_best: formData.personal_best,
    notes: formData.notes,
  },
};

This ensures shared attributes (dates, general durations, notes) remain globally indexable for the 360° Dashboard, while biometric attributes (elevation gain, heart rate, personal bests) reside in their specialized child table with cascading foreign key guarantees.

3. Culture & Media Tracking: Books & Cinema 📚🎬

For cultural tracking, the goal was leaving behind fragmented mobile notes in favor of an enriched visual library.

3.1. Interactive Reading Progress (`BooksModule.jsx`)

On each book card, we calculate page completion percentages in real time:

const percentage = b.pages_total > 0 
  ? Math.min(100, Math.round((b.pages_read / b.pages_total) * 100)) 
  : 0;

<div className="book-progress-wrapper">
  <div className="progress-info">
    <span>{b.pages_read} / {b.pages_total} pages</span>
    <span className="percentage-tag">{percentage}%</span>
  </div>
  <div className="progress-bar-bg">
    <div 
      className="progress-bar-fill" 
      style={{ 
        width: `${percentage}%`,
        background: percentage === 100 ? 'var(--accent-emerald)' : 'var(--grad-primary)'
      }} 
    />
  </div>
</div>

A status filter organizes titles into reading, completed, and wishlist, paired with an interactive 5-star rating system using lucide-react icons.

3.2. Streaming Media Catalog (`FilmsModule.jsx`)

The cinema module tracks movies, TV series, and documentaries cataloged by streaming provider (Netflix, HBO Max, Prime Video, Disney+, Cinema). Each entry logs release year, director, rating, and personal review notes, answering: "What were the best films I watched this past quarter?".

4. Professional Execution: The Kanban Board (`KanbanBoard.jsx`) 📋

For professional tasks, I implemented a full Kanban board featuring 4 columns reflecting agile task lifecycles:

📝 To Do (todo): Backlog tasks queued for upcoming execution.
⚡ In Progress (in_progress): Active work during the current sprint.
🔍 In Review (review): Tasks pending review, testing, or third-party feedback.
✅ Done (done): Completed deliverables.

┌──────────────────┬──────────────────┬──────────────────┬──────────────────┐
│ 📝 TO DO (3)     │ ⚡ IN PROGRESS (2)│ 🔍 IN REVIEW (1) │ ✅ DONE (8)      │
├──────────────────┼──────────────────┼──────────────────┼──────────────────┤
│ ┌──────────────┐ │ ┌──────────────┐ │ ┌──────────────┐ │ ┌──────────────┐ │
│ │ Refactor API │ │ │ Frontend UI  │ │ │ E2E Test Run │ │ │ DB Migration │ │
│ │ 🚨 Critical  │ │ │ 🟡 Medium    │ │ │ 🟢 Low       │ │ │ 2026-09-02   │ │
│ │ 📅 Sep 18    │ │ │ 💬 3 notes   │ │ │ 📅 Today     │ │ │ 💬 5 notes   │ │
│ │ [→ Move]     │ │ │ [←]      [→] │ │ │ [←]      [→] │ │ │ [← Move]     │ │
│ └──────────────┘ │ └──────────────┘ │ └──────────────┘ │ └──────────────┘ │
└──────────────────┴──────────────────┴──────────────────┴──────────────────┘

4.1. Optimistic UI Updates for Tactile Fluidity

When moving a task from in_progress to review, waiting for the entire roundtrip (browser → Render API → Supabase → response) introduces an undesirable delay of several hundred milliseconds.

To deliver an instantaneous tactile feel, we execute an optimistic state update in React:

const handleMoveTask = async (taskId, currentStatus, direction) => {
  const statusOrder = ['todo', 'in_progress', 'review', 'done'];
  const currentIndex = statusOrder.indexOf(currentStatus);
  const targetIndex = direction === 'next' ? currentIndex + 1 : currentIndex - 1;

  if (targetIndex < 0 || targetIndex >= statusOrder.length) return;
  const targetStatus = statusOrder[targetIndex];

  // 1. Instantaneous optimistic update

What I Learned Integrating AI Into My React App

Tue, 15 Sep 2026 00:46:58 +0000

While building Chef Claude, a small React application where users enter the ingredients they have and receive an AI-generated recipe, I started wondering how this would actually work.

Should I store recipes somewhere in my code? Or use a recipe API?

Since every user could enter a different combination of ingredients, I couldn't rely on a fixed list of recipes.

That's when I thought of integrating AI into the app.

What I Was Building

The flow of Chef Claude was simple.

Users add ingredients based on what they have available. Every ingredient is stored in state, and after adding at least four ingredients, the "Get a Recipe" button appears.

When the user clicks the button, the ingredient list is sent to the AI model. The model uses those ingredients to generate a recipe and sends the response back.

But the response comes back as Markdown.

Displaying that raw response directly in the UI didn't look good, so I used react-markdown to render the Markdown properly in my React app.

Getting a Hugging Face Access Token

Before connecting my app to an AI model, I needed a Hugging Face access token.

Creating one only took a few minutes:

Create a Hugging Face account.
Open Access Tokens.
Create a new fine-grained token.
Enable inference permissions.
Copy the token.

Setting Up the Environment Variable

After getting my Hugging Face token, I needed to use it inside my React application.

Instead of hardcoding my API key directly into my React code, I stored it in a .env file to keep my configuration separate from the source code.

VITE_HF_ACCESS_TOKEN=YOUR_API_KEY

Then I accessed it inside my application using:

const token = import.meta.env.VITE_HF_ACCESS_TOKEN;

At first, I thought keeping my token in a .env file meant it was completely safe.

But after learning how Vite handles environment variables, I realized that wasn't true.

Since my React application needs the token to make the API request, Vite exposes VITE_ environment variables to the frontend during the build process. That also means the browser has access to them.

One thing that confused me was this: if my .env file wasn't part of my application code, then how was the browser still getting my API key?

After understanding how Vite builds the application, it finally clicked. The .env file helps keep my configuration separate from the source code, but VITE_ variables are still injected into the frontend because the browser needs them to make the API request.

That's when I realized my API key wasn't actually secret anymore.

While researching this, I also understood why backend applications are important. Instead of letting the browser call the Hugging Face API directly, the better approach is to keep the API key on the backend. The frontend sends the user's ingredients to the backend, the backend talks to the AI using the secret API key, and only the generated recipe is returned to the frontend.

Even though I haven't learned backend development yet, this was the moment I finally understood why developers keep saying that secret API keys should never live in the frontend.

One thing I learned: Keeping .env out of your source code and keeping an API key secret are two different things. If the frontend needs the key, the browser will eventually have access to it. That's why sensitive API keys should be kept on a backend or serverless function.

Connecting the Model

After setting up the API key, the next step was connecting my React application to an AI model.

import { HfInference } from "@huggingface/inference";

const SYSTEM_PROMPT = `
You are an assistant that receives a list of ingredients that a user has and suggests a recipe they could make with some or all of those ingredients. You don't need to use every ingredient they mention in your recipe. The recipe can include additional ingredients they didn't mention, but try not to include too many extra ingredients. Format your response in markdown to make it easier to render to a web page
`;

const hf = new HfInference(import.meta.env.VITE_HF_ACCESS_TOKEN);

export async function getRecipeFromMistral(ingredientsArr) {
    const ingredientsString = ingredientsArr.join(", ");

    const response = await hf.chatCompletion({
    // I'm using Qwen 2.5 7B Instruct, but you can replace it with any compatible Hugging Face model.
        model: "Qwen/Qwen2.5-7B-Instruct",
        messages: [
            { role: "system", content: SYSTEM_PROMPT },
            {
                role: "user",
                content: `I have ${ingredientsString}. Please give me a recipe I'd recommend!`,
            },
        ],
    });

    return response.choices[0].message.content;
}

Let's break down what each part is doing.

`HfInference`

Instead of manually sending HTTP requests to the Hugging Face API, the SDK provides a client that makes interacting with AI models much simpler.

`SYSTEM_PROMPT`

The system prompt tells the AI how it should behave.

In my project, I wanted the AI to act like a recipe assistant. It should take the user's ingredients, suggest a recipe, and return the response in Markdown so I could render it nicely in my UI.

Without a system prompt, the AI still responds, but it doesn't have clear instructions about the format or the type of answer I expect.

`ingredientsArr.join(", ")`

The ingredients entered by the user are stored as an array.

["Rice", "Egg", "Onion", "Tomato"]

Before sending them to the AI, I converted them into a single string using .join(", ").

Rice, Egg, Onion, Tomato

This creates a natural sentence that becomes part of the user's prompt.

`chatCompletion()`

This is the function provided by the Hugging Face SDK that sends my prompt to the selected AI model and returns its response.

In simple words, this is where my React application actually talks to the AI.

Returning the recipe

Finally, I return:

response.choices[0].message.content

This gives me the generated recipe, which I later render in my React application using react-markdown.

The Response Was Markdown

After connecting the AI model, I thought the hard part was over.

The user clicked the "Get a Recipe" button, the AI generated a recipe, and everything worked.

But there was one small problem.

The response didn't look good in the UI.

The AI was already returning a well-structured Markdown response, and when I rendered it directly, it looked like plain text instead of a nicely formatted recipe.

That's when I discovered react-markdown.

Instead of manually formatting the response, I used react-markdown to render the Markdown as React elements.

The difference was immediately noticeable. Headings, bullet points, and formatting started looking like a proper recipe instead of a block of text.

That small library made the final output look much better without adding much extra code.

Final Thoughts

When I started this project, I thought integrating AI simply meant sending a prompt and getting a response.

By the end, I realized there was much more involved—structuring prompts, handling responses, understanding how environment variables work, and presenting the AI's output in a way that feels polished to the user.

This project also reminded me that every library solves a specific problem. Instead of building everything from scratch, knowing when to use the right tool is just as important.

If you've built something similar or have suggestions, I'd love to hear them in the comments.

Coder Legion - Recent posts tagged react

What I've Been Improving Behind the Scenes

Giving the watchlist a better starting point

Making navigation feel smoother

Spending more time on the details

What's next?

Stop Syncing State With useEffect: 4 Bugs That Disappear When You Delete the Effect

Why These Effects Cause Bugs

Case 1: Derived Values

Case 2: Resetting State When a Prop Changes

Case 3: Logic That Belongs in an Event Handler

Case 4: Notifying a Parent

So When Is an Effect Right?

Quick Checklist Before You Write an Effect

The Rule

Mastering the Native Drag and Drop API in React

What is the Drag and Drop API?

A Real-Life Analogy: The Corkboard and Sticky Notes

Why It Matters in Tech Today

Building a Drag and Drop Task List in React

Key Takeaway

Redux Refactoring Playbook: From Action-Types Soup to RTK Query — Without Rewriting the App

Rule 1 — Strangle, don't rewrite

Rule 2 — Selectors are the API. Freeze them first.

Rule 3 — Kill loading flags with RTK Query, not with better thunks

Rule 4 — Polling moves from timers to tags

What stayed in Redux core

The honest ledger

What I'd do differently

Your refactoring checklist

LifeOps Project (Part 6): 360° Analytics Dashboard with Multi-Dimensional Filtering, Recharts and Co

1. Architecture Decision: External BI (Grafana / Metabase) vs. Native React Engine (ADR-013) ⚖️

Data Flow Architecture

2. Multi-Dimensional Cascading Filters & Period-over-Period Deltas ⏱️📊

A. Timeframe Resolution

B. Invariant INV-8: Safe Percentage Delta Calculation (Δ%)

3. The Visual Suite with Recharts: Contextual KPIs, Time-Series & Donut Charts 📈🍩

4. 16-Week Consistency Daily Heatmap (Strava / GitHub Style) 🔥🗓️

5. Overcoming the Free-Tier Cloud UX Challenge: Cold-Start Mitigation ⚡🛡️

Layer 1: Silent Pre-Warming (wakeUpServer)

Layer 2: User-Scoped Stale-While-Revalidate (SWR) Local Cache

Layer 3: Foreground Synchronization Banner and Skeletons

6. Conclusions & Links 🚀

You Upgraded to Next.js 15 and Your Site Got Slower. The Caching Defaults Flipped

What Changed

Why It Is Easy to Miss

How to See It in 30 Seconds

Fix 1: Cache One Request on Purpose

Fix 2: Cache With an Expiry

Fix 3: Set It Once for the Whole Page

Fix 4: Route Handlers Need Their Own Opt-In

The Part People Forget: Your Database Was Never Covered

Should You Cache Everything Again?

The Rule

How to Build a Real Time Activity Log for Your Web App

1. Understanding Real-Time Activity Logs

Common use cases

2. Choosing the Technology Stack

Frontend: React

Backend: Python and FastAPI

Database: PostgreSQL

Real-time communication: WebSockets

Optional infrastructure: Redis

3. Designing the Activity Log Database

Creating the database table

4. Defining Consistent Activity Events

5. Building the FastAPI Activity Service

Recording an activity

6. Connecting Business Operations to the Activity Log

Which actions should be recorded?

7. Building the WebSocket Endpoint

8. Implementing the React Activity Timeline

Improving the user experience

9. Retrieving Historical Activities with Pagination

10. Handling Real-Time Events Reliably

11. Security and Access Control

Authenticate every request

Enforce authorization

Prevent tampering

Minimize sensitive data

Layer 1: Silent Pre-Warming (`wakeUpServer`)