DEV Community: Janarthanan Soundararajan (Jana)

What Became Hard to Change as Our React App Grew

Janarthanan Soundararajan (Jana) — Fri, 09 Oct 2026 12:59:16 +0000

A small React app feels friendly. A few screens, a few components, and you know where everything lives.

Then more features arrive.

You change one field and discover it has a social life across the entire codebase. A shared form needs another special case. A button disappears because a condition changed somewhere else.

With vibe coding, it's easy to keep adding features once the screen works. Without checking how the new code fits into the app, repeated rules and extra copies of data can go unnoticed. As the app grows, those small problems become harder to find and fix.

The app still works. Making even a small change can turn into a treasure hunt.

Here are a few places where things get harder to change, and what can help keep them manageable.

🧩 The shared component that tried to do everything

A shared form starts with a reasonable goal: reuse the same fields across two screens.

Then one screen needs different validation. Another hides a section. Another submits to a different endpoint.

Soon, the component has so many true-or-false props that using it feels like filling out a questionnaire.

Sharing UI pieces that work the same way helps. Sharing a whole form gets harder when each screen needs different behavior.

Share common inputs and layouts. Let each feature decide its own rules. Build each screen from smaller components, so one shared form doesn't need to handle every case.

A little duplication can be easier to maintain than a growing collection of special cases.

📦 The same data, now available in several flavours

For example, a customer list loads from the API. The selected customer's details are copied into a global store and reused on the details or edit page.

The idea is to save another fetch because the data is already available.

After an update, the query cache has the latest details, but the separate copy still has the old ones. Same customer, two different stories.

Store the selected customer's ID and read their details through the query layer. It can reuse cached data and refresh it when needed, based on its settings. Using an ID doesn't automatically mean another request.

Keep temporary UI state near the component. A form can also keep its own draft while the user edits. Just decide what happens when they save, cancel, or receive newer data.

🔄 The field rename that became a group project

Reading API fields directly inside components feels convenient.

Until a backend field changes and several screens need edits.

If several screens turn an API response into the same display data, move that work into one function near the API call. Components can use the result without repeating those steps.

Do this when it reduces repeated work. Adding a layer that only renames fields can give you more code to maintain.

TypeScript won't check whether incoming JSON matches your types. You need to validate the response while the app is running if you want that check.

📋 The same rule, three different versions

An invoice can be edited only while its status is DRAFT. That check appears in the table's Edit button, the details page, and the edit form.

Later, the rule changes: locked invoices cannot be edited, even when they're drafts.

The table and form get updated. The details page gets missed. It still offers an Edit button for locked invoices. Apparently, it didn't get the memo.

Keep the shared check in one function inside the invoice feature:

function canEditInvoice(invoice: Invoice) {
  return invoice.status === "DRAFT" && !invoice.isLocked;
}

Each screen uses canEditInvoice(invoice), so the rule has one place to change and test.

The backend must check the rule too. Hiding the Edit button doesn't stop someone sending an API request.

🕸️ The import that brought its whole family

A feature imports a hook from another feature. That hook imports a store from somewhere else.

Now a small change comes with a guided tour of the application.

Keep related code together. Decide which functions and components other features can import. Move code used by several features into shared modules when it makes sense.

Folders help people find code. Code reviews and rules about allowed imports help keep features from depending on each other's internal code.

🧪 The tests that objected to moving furniture

You refactor a component. The screen behaves exactly as before.

The tests disagree.

Tests that check internal state or replace most hooks with fake versions can break when you change how a component works.

Test what the user can do: entering data, submitting a form, and seeing the expected result. Test business rules directly, and use end-to-end tests to check important tasks across the app.

A refactor should feel safer because the tests exist.

🔧 One smaller fix before the grand rewrite

When changes become difficult, a rewrite can sound tempting. So can a new state library.

Start with one awkward change instead. Look at the code it depends on. Find the repeated rule or the value that several places try to manage.

Fix that part, then see whether the next similar change takes less effort.

What became unexpectedly difficult to change in your React app?

5 Places Custom React Hooks Make Your Code Better

Janarthanan Soundararajan (Jana) — Thu, 01 Oct 2026 08:39:48 +0000

You add a search box to a page. A timer delays the search until the user stops typing.

Then another page needs the same behavior. You copy the timer, the effect, and the cleanup.

A few weeks later, someone changes the delay in one place. Another search box behaves differently. A third forgets to clear its timer.

The problem isn't that the code is long. It's that the same behavior now has several owners.

That's where a custom hook helps.

In this article, we'll build five hooks for situations that show up in real applications:

Hook	Coordinates	Primary Real-World Use Case
⏱️ `useDebouncedValue`	Input value & timer	Delaying network searches & heavy validation
🌐 `useOnlineStatus`	Browser connectivity store	Showing "Offline" alerts & pausing remote sync
📱 `useMediaQuery`	Media query matches	Adapting layout logic & honoring `prefers-reduced-motion`
💾 `useLocalStorageState`	React state & storage	Persisting drafts, filters, and UI preferences safely
👁️ `useInView`	DOM element & `IntersectionObserver`	Scroll-triggered animations, lazy widgets, & impression tracking

We'll also cover when a hook is the wrong abstraction.

🧩 First: what belongs in a custom hook?

A custom hook is a function that uses React hooks to package reusable behavior. Its name starts with use:

function useSomething() {
  // React hooks can be used here.
}

But adding use to a function name doesn't make it a useful hook.

If you're calculating a total, use a regular function:

function calculateTotal(items) {
  return items.reduce(
    (total, item) => total + item.price,
    0
  );
}

If you're managing a timer, subscribing to a browser event, or coordinating state and cleanup, a hook may be appropriate.

A useful hook usually has a clear contract:

Given these inputs, expose this state or behavior, and manage its lifecycle.

For example:

const delayedSearch = useDebouncedValue(search, 350);

The component shouldn't need to know how the timer is created or cleaned up.

One important distinction: custom hooks share logic, not automatically state. Two calls to a hook containing useState normally have independent state. Hooks subscribing to the same external source can observe the same underlying data. React's custom hook guide

Call hooks at the top level of a component or another hook, not inside conditions, loops, or event handlers.

The examples below use JavaScript. They are deliberately small, with their limitations explained rather than hidden behind a "production-ready" label.

⏱️ 1. `useDebouncedValue`: wait until input settles

The problem

A user types:

r → re → rea → reac → react

If every change triggers expensive work, you may perform five operations when the user only wanted the final result. Debouncing waits for a quiet period.

Implementation

import { useEffect, useState } from "react";

export function useDebouncedValue(value, delay = 350) {
  const [debouncedValue, setDebouncedValue] =
    useState(value);

  useEffect(() => {
    const timeoutId = setTimeout(() => {
      setDebouncedValue(value);
    }, delay);

    return () => {
      clearTimeout(timeoutId);
    };
  }, [value, delay]);

  return debouncedValue;
}

How it works

The hook keeps two values:

value: the latest input.
debouncedValue: the last input that stayed unchanged long enough.

When the input changes, the effect starts a timer.

If the input changes again before the delay ends, cleanup cancels the previous timer. A new timer starts for the new value.

The same cleanup also cancels a pending timer when the component unmounts. Both value and delay are dependencies because changing either should restart the waiting period.

Usage

Keep the input responsive. Debounce the work that follows it.

import { useMemo, useState } from "react";
import { useDebouncedValue } from "./useDebouncedValue";

export function ProductSearch({ products }) {
  const [search, setSearch] = useState("");
  const debouncedSearch =
    useDebouncedValue(search, 350);

  const results = useMemo(() => {
    const query =
      debouncedSearch.trim().toLowerCase();

    return products.filter((product) =>
      product.name.toLowerCase().includes(query)
    );
  }, [products, debouncedSearch]);

  return (
    <section>
      <label>
        Search products
        <input
          value={search}
          onChange={(event) =>
            setSearch(event.target.value)
          }
        />
      </label>

      <p>{results.length} products found</p>

      <ul>
        {results.map((product) => (
          <li key={product.id}>{product.name}</li>
        ))}
      </ul>
    </section>
  );
}

For a small local list, immediate filtering may feel better. Debouncing becomes useful when the work is expensive or involves a request.

What this hook does not solve

Debouncing doesn't cancel a request that has already started.

If a request for "rea" is still running when a request for "react" begins, the older response could arrive last. For network searches, also handle cancellation or stale responses—often with an AbortController or a data-fetching library.

[!NOTE]
useDebouncedValue vs. React's useDeferredValue

useDeferredValue (built into React 18+) addresses CPU-bound rendering responsiveness. It tells React to keep the input responsive while deferring an expensive list re-render in the background without any fixed delay.

useDebouncedValue addresses I/O, network requests, and timers. It enforces a fixed quiet period (e.g. 350ms) before triggering remote API requests, database queries, or server-side validations.

Good uses: search requests, delayed previews, validation after typing pauses.

Avoid: debouncing the input's own displayed value. That makes typing feel broken.

🌐 2. `useOnlineStatus`: subscribe to connection changes

The problem

Several components may need to show a connection warning. You could add online and offline listeners inside each component. A hook gives those components one consistent interface.

Here, the browser is the source of truth. useSyncExternalStore is designed for subscribing to state outside React. React's external-store reference

Implementation

import { useSyncExternalStore } from "react";

function subscribe(onStoreChange) {
  window.addEventListener("online", onStoreChange);
  window.addEventListener("offline", onStoreChange);

  return () => {
    window.removeEventListener(
      "online",
      onStoreChange
    );

    window.removeEventListener(
      "offline",
      onStoreChange
    );
  };
}

function getSnapshot() {
  return typeof navigator !== "undefined" ? navigator.onLine : true;
}

function getServerSnapshot() {
  return true;
}

export function useOnlineStatus() {
  return useSyncExternalStore(
    subscribe,
    getSnapshot,
    getServerSnapshot
  );
}

How it works

There are three pieces:

subscribe tells React when the browser's status changes.
getSnapshot reads the current value.
getServerSnapshot supplies a value during server rendering and initial hydration.

The server cannot inspect the user's browser connection. Returning true is our chosen initial assumption, not a measurement.

The subscription functions live outside the hook because they don't depend on component props. Their identities remain stable between renders.

Usage

import { useOnlineStatus } from "./useOnlineStatus";

export function ConnectionNotice() {
  const isOnline = useOnlineStatus();

  if (isOnline) {
    return null;
  }

  return (
    <p role="status">
      You appear to be offline. Recent changes may
      not have synced yet.
    </p>
  );
}

The important limitation

navigator.onLine is a hint, not proof that your API is reachable. A device may have a network connection while your server is unavailable. VPNs and other network conditions can also affect the result. MDN's explanation of navigator.onLine

Use this hook for helpful UI messaging. Don't use it as the only reason to disable a submit button. Try the operation and handle its actual result.

Good uses: connection banners, offline indicators, explaining delayed synchronization.

Avoid: treating it as a backend health check.

📱 3. `useMediaQuery`: use browser preferences in component behavior

The problem

CSS handles responsive presentation well:

.cards {
  display: grid;
  grid-template-columns: 1fr;
}

@media (min-width: 900px) {
  .cards {
    grid-template-columns: repeat(3, 1fr);
  }
}

You don't need a hook for that.

But sometimes a browser preference changes JavaScript behavior. For example, you may want to stop a canvas animation when the user prefers reduced motion.

matchMedia exposes a media query's current result and change events. MDN's matchMedia reference

Implementation

import {
  useCallback,
  useMemo,
  useSyncExternalStore,
} from "react";

export function useMediaQuery(
  query,
  serverFallback = false
) {
  const mediaQuery = useMemo(() => {
    if (typeof window === "undefined") {
      return null;
    }

    return window.matchMedia(query);
  }, [query]);

  const subscribe = useCallback(
    (onStoreChange) => {
      if (!mediaQuery) {
        return () => {};
      }

      mediaQuery.addEventListener(
        "change",
        onStoreChange
      );

      return () => {
        mediaQuery.removeEventListener(
          "change",
          onStoreChange
        );
      };
    },
    [mediaQuery]
  );

  const getSnapshot = useCallback(
    () => mediaQuery?.matches ?? serverFallback,
    [mediaQuery, serverFallback]
  );

  const getServerSnapshot = useCallback(
    () => serverFallback,
    [serverFallback]
  );

  return useSyncExternalStore(
    subscribe,
    getSnapshot,
    getServerSnapshot
  );
}

How it works

The query creates a MediaQueryList. The hook subscribes to its change event and exposes its boolean matches value.

If the query changes, the hook creates a new subscription and removes the old one.

The server fallback matters because a server doesn't know the browser's viewport or preferences. Use the same fallback on the server and client for initial hydration.

Usage

import { useMediaQuery } from "./useMediaQuery";

export function Hero() {
  const prefersReducedMotion = useMediaQuery(
    "(prefers-reduced-motion: reduce)",
    true
  );

  return (
    <section>
      <h1>Build something worth showing.</h1>

      {prefersReducedMotion ? (
        <StaticIllustration />
      ) : (
        <AnimatedIllustration />
      )}
    </section>
  );
}

StaticIllustration and AnimatedIllustration represent your application's illustration components.

Here, true is a conservative initial fallback: start with the static illustration until the browser's preference is available.

What to avoid

Don't replace every CSS media query with React state. Use CSS for spacing, columns, font sizes, and element positioning.

Use this hook when JavaScript behavior genuinely depends on the query.

Also remember that conditionally replacing components can discard their local state. Switching between a mobile and desktop form should not accidentally erase the user's input.

Good uses: reduced-motion behavior, enabling an interactive visualization, adapting controls.

Avoid: measuring viewport width in React just to change a margin.

💾 4. `useLocalStorageState`: remember a preference or draft

The problem

A user selects a preference or writes a draft. Refreshing the page loses it. A storage hook can coordinate React state with browser persistence.

But this hook needs more care than:

localStorage.setItem(key, JSON.stringify(value));

Reading can fail. Writing can fail. Stored JSON can be invalid. And an initial render must not overwrite an existing saved value before it has been read.

Implementation

This version keeps component-local state and persists changes after loading.

import {
  useCallback,
  useEffect,
  useState,
} from "react";

export function useLocalStorageState(
  key,
  initialValue
) {
  const [fallback] = useState(() => initialValue);

  const [record, setRecord] = useState(() => ({
    key,
    value: fallback,
    ready: false,
    dirty: false,
  }));

  const [error, setError] = useState(null);

  useEffect(() => {
    let value = fallback;
    let readError = null;

    try {
      const stored = window.localStorage.getItem(key);

      if (stored !== null) {
        value = JSON.parse(stored);
      }
    } catch (caught) {
      readError = caught;
    }

    setError(readError);

    setRecord({
      key,
      value,
      ready: true,
      dirty: false,
    });
  }, [key, fallback]);

  useEffect(() => {
    if (
      record.key !== key ||
      !record.ready ||
      !record.dirty
    ) {
      return;
    }

    try {
      if (record.value === undefined) {
        window.localStorage.removeItem(key);
      } else {
        const serialized = JSON.stringify(record.value);

        if (serialized === undefined) {
          throw new Error(
            "The value cannot be stored as JSON."
          );
        }

        window.localStorage.setItem(
          key,
          serialized
        );
      }

      setError(null);
    } catch (caught) {
      setError(caught);
    }
  }, [key, record]);

  const setValue = useCallback(
    (nextValue) => {
      setRecord((previous) => {
        if (
          previous.key !== key ||
          !previous.ready
        ) {
          return previous;
        }

        const value =
          typeof nextValue === "function"
            ? nextValue(previous.value)
            : nextValue;

        return {
          ...previous,
          value,
          dirty: true,
        };
      });
    },
    [key]
  );

  const isReady =
    record.key === key && record.ready;

  return {
    value:
      record.key === key
        ? record.value
        : fallback,
    setValue,
    isReady,
    error,
  };
}

Why the extra state?

ready means the initial read has finished. dirty means the user has changed the value.

Keeping those separate prevents the default value from immediately replacing a saved value.

It also means that invalid stored JSON is not silently overwritten during loading. The fallback is shown, an error is exposed, and a subsequent user edit can replace the invalid value.

The record includes its storage key so a key change cannot accidentally write the previous key's value into the new key.

Like useState, this hook treats initialValue as an initial fallback—not a prop that continuously resets the value.

Usage

import {
  useLocalStorageState,
} from "./useLocalStorageState";

export function ArticleDraft() {
  const {
    value: draft,
    setValue: setDraft,
    isReady,
    error,
  } = useLocalStorageState(
    "article-draft:v1",
    ""
  );

  return (
    <section>
      <label>
        Your draft
        <textarea
          value={draft}
          disabled={!isReady}
          onChange={(event) =>
            setDraft(event.target.value)
          }
        />
      </label>

      {!isReady && <p>Loading saved draft…</p>}

      {error && (
        <p role="status">
          Browser storage is unavailable or the
          saved draft could not be read. You can
          keep editing, but changes may not persist.
        </p>
      )}
    </section>
  );
}

If a write fails, React state still updates. The user can keep typing, but the interface warns that persistence may have failed.

Know the boundaries

localStorage stores strings, is synchronous, and may be unavailable because of browser policies. It is not a database or a guaranteed backup. MDN's localStorage reference

This implementation also:

Accepts JSON-compatible values, not arbitrary JavaScript objects.
Does not validate the shape of parsed data.
Does not synchronize separate hook instances or browser tabs.
Does not guarantee the latest edit survives an immediate unmount.
Does not make sensitive data safe to store.

For object data, validate the parsed structure and plan migrations. A versioned key such as "preferences:v2" can help, but changing a key is not itself a migration strategy.

If you need cross-tab updates, subscribe to storage changes. Remember that the browser's storage event fires in other documents—not the window that performed the write. Same-page synchronization needs an additional mechanism. MDN's storage event reference

[!TIP]
Cross-Tab Synchronization Tip:
To sync state between open browser tabs in real-time, add an effect that listens to window.addEventListener("storage", (e) => { if (e.key === key) { ... } }). When a user toggles dark mode or updates a preference in Tab A, Tab B updates automatically.

Good uses: lightweight preferences, dismissed notices, non-sensitive drafts.

Avoid: passwords, tokens, large frequently updated datasets, or business-critical persistence.

👁️ 5. `useInView`: observe visibility without scroll calculations

The problem

You want to start an animation or mount an expensive preview when a section becomes visible.

One approach is to listen to every scroll event and calculate element positions. Another is to let the browser observe the element.

IntersectionObserver reports changes in an element's intersection with a viewport or specified root. MDN's Intersection Observer guide

Implementation

This hook accepts configuration options including an optional triggerOnce flag:

import { useEffect, useState } from "react";

export function useInView({
  root = null,
  rootMargin = "0px",
  threshold = 0.25,
  triggerOnce = false,
} = {}) {
  const [element, setElement] = useState(null);
  const [isInView, setIsInView] = useState(false);

  useEffect(() => {
    setIsInView(false);

    if (!element) {
      return;
    }

    if (
      typeof IntersectionObserver === "undefined"
    ) {
      setIsInView(true);
      return;
    }

    let active = true;

    const observer = new IntersectionObserver(
      ([entry]) => {
        if (!active) {
          return;
        }

        const inView =
          entry.isIntersecting &&
          entry.intersectionRatio >= threshold;

        setIsInView(inView);

        if (inView && triggerOnce) {
          observer.disconnect();
        }
      },
      {
        root,
        rootMargin,
        threshold,
      }
    );

    observer.observe(element);

    return () => {
      active = false;
      observer.disconnect();
    };
  }, [element, root, rootMargin, threshold, triggerOnce]);

  return {
    ref: setElement,
    isInView,
  };
}

How it works

The returned callback ref (ref: setElement) tells the hook which element to observe. Using a callback ref is important: unlike a standard useRef(), whose .current assignment does not notify React or trigger effects, a callback ref guarantees that React runs your setup effect as soon as the DOM node attaches or detaches.

When the target element changes, the old observer disconnects and a new one starts.

The active flag prevents a late callback from an obsolete observer from updating the current state. If triggerOnce is set to true, the observer disconnects after its first intersection, keeping the element active (ideal for one-time enter animations).

For this hook, "in view" means:

The element is intersecting, and its visible ratio meets the configured threshold.

That explicit ratio check matters. isIntersecting alone does not mean the element has reached a threshold such as 25%.

Usage

import { useInView } from "./useInView";

export function DemoSection() {
  const { ref, isInView } = useInView({
    threshold: 0.25,
  });

  return (
    <section
      ref={ref}
      style={{ minHeight: 360 }}
    >
      <h2>Try the interactive demo</h2>

      {isInView ? (
        <ExpensivePreview />
      ) : (
        <p>The preview loads as you scroll here.</p>
      )}
    </section>
  );
}

ExpensivePreview represents your application's interactive preview component.

The stable wrapper height matters. If mounting and unmounting the preview changes the section's geometry dramatically, visibility can oscillate.

This example unmounts the preview when it leaves view. If the preview has state that should survive, keep it mounted after the first visit or pause its work instead.

What to avoid

Don't hide essential content permanently if observation is unavailable. This implementation falls back to true.

For infinite scrolling, visibility is only one signal. You also need guards such as:

if (isInView && hasNextPage && !isFetching) {
  // Request the next page.
}

Otherwise, repeated visibility updates can trigger duplicate requests.

For ordinary images, native lazy loading may be enough:

<img
  src="/preview.webp"
  alt="Application preview"
  loading="lazy"
/>

Good uses: optional previews, scroll-triggered animation, pausing offscreen work.

Avoid: replacing simpler browser features without a reason.

Writing a useful hook is about its contract

These five hooks wrap different things:

Hook	What it coordinates
`useDebouncedValue`	A value and a timer
`useOnlineStatus`	Browser connection events
`useMediaQuery`	A browser query subscription
`useLocalStorageState`	Local state and persistence
`useInView`	A DOM element and an observer

Before extracting a hook, answer these questions:

What does it own?
What inputs can change?
What does it return?
What must be cleaned up?
What happens if the browser feature fails?
Are separate callers independent or synchronized?

Naming helps reveal the contract. useInView tells the caller what it provides. useMountEffect mostly tells the caller when something runs, while hiding what it does.

Prefer hooks organized around a behavior rather than wrappers that obscure effect dependencies.

A hook is not an excuse to add another effect

Some values should simply be calculated during rendering:

const fullName = `${firstName} ${lastName}`;

They don't need another state variable, effect, or custom hook.

Likewise, behavior caused directly by a user action often belongs in the event handler.

Effects are most useful when coordinating React with something outside it: a timer, event subscription, observer, or browser storage. React's guide to avoiding unnecessary effects

In frameworks with React Server Components, use these hooks within the appropriate client-component boundary. Browser APIs should not be assumed to exist on the server.

TypeScript definitions

For TypeScript projects, here are the ready-to-use type signatures for all five hooks:

View TypeScript signatures

// 1. useDebouncedValue
export function useDebouncedValue(value: T, delay?: number): T;

// 2. useOnlineStatus
export function useOnlineStatus(): boolean;

// 3. useMediaQuery
export function useMediaQuery(
  query: string,
  serverFallback?: boolean
): boolean;

// 4. useLocalStorageState
export interface LocalStorageStateReturn {
  value: T;
  setValue: (value: T | ((prev: T) =&gt; T)) =&gt; void;
  isReady: boolean;
  error: Error | null;
}

export function useLocalStorageState(
  key: string,
  initialValue: T
): LocalStorageStateReturn;

// 5. useInView
export interface UseInViewOptions {
  root?: Element | Document | null;
  rootMargin?: string;
  threshold?: number;
  triggerOnce?: boolean;
}

export interface UseInViewReturn {
  ref: (node: Element | null) =&gt; void;
  isInView: boolean;
}

export function useInView(
  options?: UseInViewOptions
): UseInViewReturn;

Before you reuse a hook, test its awkward cases

The happy path is usually easy. Cleanup and failure cases deserve attention.

For these examples, check:

Debounce: rapid changes cancel older timers; unmounting cancels pending work.
Online status: listeners are removed; request failures are handled independently.
Media query: changing the query removes the previous subscription.
Storage: existing values are preserved; invalid JSON and failed writes are surfaced.
In view: changing the target disconnects the old observer; unavailable APIs have a safe fallback.

You don't need a hook for every repeated expression.

You need one when several components should rely on the same behavior—and you want that behavior's lifecycle, assumptions, and limitations maintained in one place.

What behavior have you copied between React components that would make a good custom hook?

Why I Built a Code-Native Visual Studio for My Developer Posts

Janarthanan Soundararajan (Jana) — Fri, 25 Sep 2026 06:05:33 +0000

Over the past year, AI image tools have become amazing. Being able to type a prompt and get a detailed picture in seconds feels like magic.

Like a lot of developers who post on LinkedIn, X, and Dev.to, I started using AI to create header images and diagrams for my technical write-ups.

But the more I posted, the more I ran into a few small, frustrating problems that made me rethink my workflow:

1. That "Typical AI Look"

You probably know what I mean: glowing neon spheres, futuristic 3D glass cubes, and floating holograms. They look cool at first, but they didn’t feel like me. When I write about system design or web dev, I want visuals that feel real and grounded — like an engineer sketching architecture on an office whiteboard.

2. Keeping a Consistent Style

When you publish a series of posts or tutorials, you want them to feel connected. You want the same colors, the same fonts, and the same recognizable card styles every week. With text-to-image prompts, every generation is a fresh roll of the dice. A button that was purple yesterday turns neon blue today.

3. Small Typos Shouldn't Ruin an Entire Image

This was my biggest headache:

Imagine making a detailed architecture diagram. Everything looks great, but you spot a tiny mistake: proccess instead of process, or a port number that says 8080 instead of 443.

With standard AI image generators, you can’t just click the text and fix it. You have to re-prompt from scratch. That means your whole layout shifts, colors change, and you have to start over.

With code, fixing a typo takes 2 seconds: you change the text in the editor, and the canvas updates in 16 milliseconds.

What About AI? (Working With It, Not Fighting It)

To be completely honest: I still use AI all the time.

I often ask ChatGPT or Gemini to draft the initial HTML and Tailwind layout for an idea.

In fact, I built a dedicated "Prompt AI" button right inside Yuwbrndr’s sidebar. It generates a ready-to-use prompt that tells your LLM exactly how to write compatible HTML, Tailwind, and Rough.js code.

The big difference is where the control lives:

With text-to-image tools, you are stuck with flat, uneditable pixels.
With Yuwbrndr, the AI writes the code once, and from that point on, you own the canvas. You can tweak margins, fix typos, adjust colors, and re-export as many times as you want without burning a single credit.

Enter Yuwbrndr: Code as Your Canvas

These experiences led me to build Yuwbrndr — a free, browser-native studio where developers design visuals directly with HTML, Tailwind CSS, and Canvas.

Here are a few ways it changed my day-to-day workflow:

1. Multi-Slide Carousels in 1 Click (LinkedIn & Social)

One of my favorite features in Yuwbrndr is the native Slide Deck mode.

On LinkedIn, multi-slide document carousels get significantly more attention than static single images because readers swipe through them step-by-step.

In Yuwbrndr:

Switch from Single design to Slide deck.
Add up to 6 structured slides (Hook, Problem, Code, Solution, Summary).
Click Export PDF: Yuwbrndr renders every slide at 2x Retina resolution and compiles them into a clean, ready-to-upload PDF.
Need separate images for an X/Twitter thread? Click Export ZIP to download all slides as numbered PNGs in one click.

The Numbers: Why Format Matters

Here is what surprised me when I looked into recent publishing data:

According to Socialinsider’s analysis of 1.4 million LinkedIn posts, multi-slide document carousels achieve a 5.48% average engagement rate, compared to 2.14% for single image posts — more than 2.5x higher.
Reader dwell time is 3.2x longer on carousels because people swipe through instead of scrolling right past.
Over 82% of social feed impressions happen on mobile phones, meaning tiny 12px text in complex diagrams gets completely skipped.

I actually designed this benchmark summary card directly in Yuwbrndr using the preset below:

<div class="relative w-full h-full bg-[#0c0d12] text-slate-100 flex flex-col justify-between p-10 overflow-hidden font-sans select-none border border-slate-800">

  <!-- Subtle Monotone Technical Grid (No colored glowing blur orbs) -->
  <div class="absolute inset-0 bg-[linear-gradient(to_right,#ffffff04_1px,transparent_1px),linear-gradient(to_bottom,#ffffff04_1px,transparent_1px)] bg-[size:32px_32px] pointer-events-none"></div>

  <!-- Top Metadata Bar: Editorial Data Header -->
  <div class="relative z-10 flex items-center justify-between pb-4 border-b border-slate-800/80 text-xs font-mono">
    <div class="flex items-center gap-3">
      <span class="px-2.5 py-1 rounded bg-slate-800 text-slate-200 font-semibold tracking-wide">
        BENCHMARK REPORT
      </span>
      <span class="text-slate-400">Sample: 1,400,000+ LinkedIn Posts</span>
    </div>
    <div class="text-slate-500 flex items-center gap-2">
      <span>Source: Socialinsider Study</span>
      <span>•</span>
      <span class="text-slate-400">2026 Data</span>
    </div>
  </div>

  <!-- Main Section: Clean Editorial Title & Comparative Vertical Chart -->
  <div class="relative z-10 grid grid-cols-12 gap-10 items-end my-auto py-2">

    <!-- Left Column: Title & Key Findings (5 cols) -->
    <div class="col-span-5 space-y-4">
      <h1 class="text-3xl font-extrabold text-white tracking-tight leading-tight">
        Document Carousels Outperform Single Images
      </h1>

      <p class="text-slate-400 text-sm leading-relaxed">
        Multi-slide technical decks generate <strong class="text-white font-semibold">2.56x higher engagement</strong> than static screenshots because readers actively swipe rather than scroll past.
      </p>

      <div class="pt-2 space-y-2 text-xs font-mono text-slate-300">
        <div class="flex items-center gap-2">
          <span class="w-1.5 h-1.5 rounded-full bg-emerald-400"></span>
          <span>Carousel Engagement: <strong class="text-emerald-400">5.48%</strong></span>
        </div>
        <div class="flex items-center gap-2">
          <span class="w-1.5 h-1.5 rounded-full bg-slate-500"></span>
          <span>Single Image Engagement: <strong class="text-slate-300">2.14%</strong></span>
        </div>
        <div class="flex items-center gap-2">
          <span class="w-1.5 h-1.5 rounded-full bg-slate-600"></span>
          <span>Text-Only Engagement: <strong class="text-slate-400">1.92%</strong></span>
        </div>
      </div>
    </div>

    <!-- Right Column: Authentic Vertical Bar Chart with Y-Axis (7 cols) -->
    <div class="col-span-7 bg-[#13151f] border border-slate-800 rounded-xl p-6">

      <div class="flex justify-between items-center text-xs font-mono text-slate-400 mb-6">
        <span class="uppercase tracking-wider">Average Engagement Rate by Post Format</span>
        <span class="text-emerald-400 font-semibold">+156% Lift</span>
      </div>

      <!-- Vertical Bar Chart Area -->
      <div class="h-44 flex items-end justify-around gap-6 pt-4 border-b border-slate-700/60 relative">

        <!-- Y-Axis Gridlines & Ticks -->
        <div class="absolute inset-x-0 top-0 border-b border-dashed border-slate-800/80 flex justify-between text-[10px] font-mono text-slate-600">
          <span>6.0%</span>
        </div>
        <div class="absolute inset-x-0 top-1/2 border-b border-dashed border-slate-800/80 flex justify-between text-[10px] font-mono text-slate-600">
          <span>3.0%</span>
        </div>

        <!-- Bar 1: Multi-Slide Carousel (Winner) -->
        <div class="flex-1 flex flex-col items-center h-full justify-end group">
          <span class="font-mono text-sm font-bold text-emerald-400 mb-1.5">5.48%</span>
          <div class="w-full max-w-[84px] h-[91%] bg-emerald-500 rounded-t-md relative">
            <div class="absolute top-1 inset-x-1 h-1 bg-white/20 rounded-sm"></div>
          </div>
        </div>

        <!-- Bar 2: Single Image -->
        <div class="flex-1 flex flex-col items-center h-full justify-end group">
          <span class="font-mono text-xs font-semibold text-slate-300 mb-1.5">2.14%</span>
          <div class="w-full max-w-[84px] h-[36%] bg-slate-600 rounded-t-md"></div>
        </div>

        <!-- Bar 3: Text Only -->
        <div class="flex-1 flex flex-col items-center h-full justify-end group">
          <span class="font-mono text-xs font-semibold text-slate-400 mb-1.5">1.92%</span>
          <div class="w-full max-w-[84px] h-[32%] bg-slate-700 rounded-t-md"></div>
        </div>

      </div>

      <!-- X-Axis Labels -->
      <div class="flex justify-around gap-6 pt-3 text-center text-xs font-mono">
        <div class="flex-1 font-bold text-white">Multi-Slide PDF</div>
        <div class="flex-1 text-slate-400">Single Image</div>
        <div class="flex-1 text-slate-500">Text Only</div>
      </div>

    </div>

  </div>

  <!-- Bottom Data Takeaways: 3 Grounded Metrics -->
  <div class="relative z-10 grid grid-cols-3 gap-4 pt-4 border-t border-slate-800/80 text-xs font-mono">
    <div class="flex items-center gap-3">
      <span class="text-xl font-black text-emerald-400">2.56x</span>
      <span class="text-slate-400 leading-tight">Higher average engagement vs single image</span>
    </div>
    <div class="flex items-center gap-3">
      <span class="text-xl font-black text-white">3.2x</span>
      <span class="text-slate-400 leading-tight">Longer reader dwell time per swipe</span>
    </div>
    <div class="flex items-center gap-3">
      <span class="text-xl font-black text-amber-400">82%</span>
      <span class="text-slate-400 leading-tight">Mobile readers require bold slide text</span>
    </div>
  </div>
</div>

2. Hand-Drawn Whiteboard Art with Rough.js

To move away from generic AI visuals, I integrated Rough.js directly into the studio.

Instead of writing complex canvas math, you can draw sketchy whiteboard boxes using simple HTML attributes:

<!-- Hand-drawn sketchy box with cross-hatch fill -->
<svg 
  data-rough-rect="fill: #8b5cf6; fillStyle: cross-hatch; roughness: 2; stroke: #a78bfa" 
  class="absolute inset-0 w-full h-full -z-10"
></svg>

<div class="p-6 font-comic text-white">
  <h3 class="text-xl font-bold">API Gateway & Edge Proxy</h3>
  <p class="text-slate-300">Rate limiting, SSL termination, JWT checks</p>
</div>

Paired with open-source fonts like Comic Neue, Caveat, and Patrick Hand, your diagrams feel personal and human — like notes from a real engineering whiteboard session.

3. Share Everything in the URL (Zero Server Storage)

Most tools make you sign up for an account, log in with Google, and save everything to their database.

I wanted Yuwbrndr to be 100% private and client-side:

When you click Share, your entire design (HTML, CSS, aspect ratio, theme) is compressed directly into the URL hash using the browser’s native CompressionStream (#share=v1z...).
Anyone who opens your link gets the exact same code and live preview loaded instantly.
No database, no accounts, and no data tracking.

The Engineering Trade-off:

For short snippets, this works like magic — the link is compact and completely self-contained. But for designs with lots of code, the URL hash can become massive. I’m actively working on a better alternative to handle sharing for larger designs while keeping user privacy first.

4. Privacy First: No Trackers, No Cookies

Yuwbrndr does not use Google Analytics or tracking cookies.

Everything you type, upload, or render stays strictly in your browser’s local memory. For basic traffic numbers, we use GoatCounter — a lightweight, open-source, cookie-free tool that only counts anonymous page views. Your designs and code never leave your machine.

It’s 100% Free & Open Source (MIT)

Yuwbrndr is completely free to use and open source under the MIT license:

🚀 Try the Live Studio: techaaroorian.github.io/yuwbrndr
⭐ GitHub Repository: github.com/TechAaroorian/yuwbrndr

If you write technical posts, share architecture diagrams, or just want full control over your visuals without subscription limits, give it a spin.

I’d love to hear your feedback: How do you currently create visuals for your technical posts and tutorials?

Never Use a Display Name for Authorization: Secure Anonymous Editing

Janarthanan Soundararajan (Jana) — Tue, 22 Sep 2026 05:28:23 +0000

Public polls, surveys, and collaborative boards often ask participants for a name. The name helps other people understand who submitted each response.

It should not grant permission to edit that response.

A display name helps humans identify a participant. It does not prove that an incoming HTTP request came from the person who created the record. Treating identification as authorization creates a serious security flaw in applications that allow anonymous participation.

Anonymous editing needs a separate credential. One practical option is a cryptographically random token stored in an HttpOnly cookie, with only its SHA-256 hash saved in the database.

Identification and authorization

Consider a row of lockers. Each locker has a name written on it.

The name helps you locate the correct locker. It cannot open the door. You still need the key.

┌────────────────────────────────────────────────────────┐
│                      THE LOCKER                        │
│                                                        │
│  Label (Display Name)  ──▶  Identifies the record      │
│  Key (Session / Token) ──▶  Authorizes modifications   │
│  Interior (Choices/Data)──▶  The protected resource    │
└────────────────────────────────────────────────────────┘

The same distinction applies to application data:

A display name tells people which participant submitted a response.
A session or token proves that the current request may modify it.

Code such as this treats public user input as an authorization credential:

// ❌ Dangerous: Treating user input as an authorization credential
await db.availability.deleteMany({
  where: {
    pollId,
    userId: null,
    participantName: {
      equals: participantName,
      mode: "insensitive",
    },
  },
});

Anyone who knows or guesses the participant’s name could overwrite that person’s response.

Display names are unsuitable for authorization because they are publicly visible, easy to guess, and often shared by multiple people. They also introduce casing and formatting ambiguities.

Identification answers: “Which record are you referring to?”
Authorization answers: “Are you allowed to modify it?”

Two ownership paths

An application that supports both accounts and anonymous participation needs separate authorization paths:

Incoming Request
       │
       ├─▶ Has Session? ──────▶ Verify session userId
       │
       └─▶ Anonymous Guest? ──▶ Verify HttpOnly edit token hash

Authenticated participants

For signed-in users, the server reads the user ID from the active session. It should never trust a user ID supplied in the request body or query parameters.

A composite unique constraint on pollId and userId can enforce one participant record per authenticated user:

const participant = await tx.pollParticipant.upsert({
  where: {
    pollId_userId: {
      pollId,
      userId,
    },
  },
  update: {
    displayName: participantName,
    email: participantEmail ?? null,
    responseStatus: "RESPONDED",
    respondedAt: new Date(),
  },
  create: {
    pollId,
    userId,
    displayName: participantName,
    email: participantEmail ?? null,
    responseStatus: "RESPONDED",
    respondedAt: new Date(),
  },
});

The participant can later change their display name without losing ownership. Their edit permission depends on the immutable userId, not the name shown in the interface.

Anonymous participants

An anonymous participant has no account or server session. The server therefore needs to issue a separate credential that grants access to that participant’s response.

Generate the credential with a cryptographically secure random-number generator:

import { randomBytes, createHash } from "node:crypto";

// Generate 32 bytes of cryptographically secure entropy
const editToken = randomBytes(32).toString("base64url");

Store the raw token in a restricted browser cookie:

cookieStore.set(cookieName, editToken, {
  httpOnly: true,
  sameSite: "lax",
  secure: process.env.NODE_ENV === "production",
  path: "/",
  maxAge: 60 * 60 * 24 * 90, // 90 days
});

Each cookie option has a specific purpose:

httpOnly prevents client-side JavaScript from reading the token. This reduces direct token exfiltration through XSS, although it does not remove every XSS risk.
secure restricts the cookie to HTTPS connections in production.
sameSite: "lax" helps block common cross-site request forgery attempts.
maxAge limits how long the participant can use the token to edit the response.

Store the hash, not the raw token

A raw edit token is a bearer credential. Anyone who obtains it can use it.

Saving raw tokens in the database creates unnecessary exposure. If an attacker gains read access to the database, they could copy those tokens and edit active responses.

Hash the token before storing it:

const hashEditToken = (token: string) =>
  createHash("sha256").update(token).digest("hex");

The request flow then looks like this:

Browser                           Server                         PostgreSQL
   │                                │                                │
   │── Send Cookie (Raw Token) ────▶│                                │
   │                                │── SHA-256(Raw Token) ─────────▶│
   │                                │                                │
   │                                │◀─ Find record matching hash ───│
   │                                │                                │
   │◀── Allow / Reject Mutation ────│                                │

When the participant returns:

The browser sends the raw token through the HttpOnly cookie.
The server hashes the token with SHA-256.
The database query searches for an anonymous participant matching both the pollId and editTokenHash.
The server permits the update only when that record exists.

const participant = await tx.pollParticipant.findFirst({
  where: {
    pollId,
    editTokenHash: hashEditToken(existingEditToken),
  },
});

Why SHA-256 is suitable here

Argon2 and bcrypt are deliberately slow because human-created passwords usually have limited entropy. Their cost makes dictionary attacks more expensive.

A token generated from 32 random bytes has 256 bits of entropy. It is not vulnerable to the same kind of password guessing, assuming it was generated securely. SHA-256 is therefore suitable for storing a lookup value without adding the CPU cost of password hashing.

Example: Normalized Polling Architecture in SlotSyncro

To see this pattern in practice, consider SlotSyncro, an open-source meeting poll application built with Prisma and PostgreSQL.

In SlotSyncro, participants vote on meeting options using three preference states: Yes, If needed, and No. To keep authorization checks independent of voting preferences, the participant record is stored separately from individual slot choices:

model PollParticipant {
  id             String             @id @default(cuid())
  pollId         String
  userId         String?
  displayName    String
  email          String?
  responseStatus PollResponseStatus @default(PENDING)
  respondedAt    DateTime?
  editTokenHash  String?            @unique

  poll        Poll             @relation(fields: [pollId], references: [id])
  preferences PollPreference[]

  @@unique([pollId, userId])
}

model PollPreference {
  id            String             @id @default(cuid())
  pollId        String
  participantId String
  candidateId   String
  status        AvailabilityStatus @default(YES)

  participant PollParticipant @relation(
    fields: [participantId, pollId],
    references: [id, pollId]
  )
  candidate PollCandidate @relation(
    fields: [candidateId, pollId],
    references: [id, pollId]
  )

  @@unique([participantId, candidateId])
}

This separation gives the application a clear ownership boundary. The server first verifies access to PollParticipant. After that check succeeds, it can modify preferences through the validated participant ID.

The composite relationships also prevent cross-poll mismatches. A preference associated with Poll A cannot reference a participant or candidate belonging to Poll B.

Preference replacement happens inside one database transaction:

await db.$transaction(async (tx) => {
  // 1. Clear existing choices for this validated participant
  await tx.pollPreference.deleteMany({
    where: { participantId },
  });

  // 2. Insert new selections
  await tx.pollPreference.createMany({
    data: votes.map(({ slotId, status }) => ({
      pollId,
      participantId,
      candidateId: slotId,
      status,
    })),
  });
});

If either operation fails, the transaction rolls back. The response cannot be left with its old preferences deleted and only some of the new preferences inserted.

Limitations of cookie-backed editing

The token protects anonymous responses from name-based hijacking, but it ties edit access to one browser profile.

A participant may lose access when:

They switch to another device or browser.
They clear their cookies.
They use a private browsing window that is later closed.

Creating a new response is safer than falling back to an unverified name or email address.

Applications that need cross-device editing without requiring a full account can add an out-of-band recovery mechanism. Options include a signed, time-limited edit link sent by email or a flow that lets a signed-in user claim an anonymous response.

Rate limiting can also reduce automated response creation and token-generation abuse. It should be treated as an abuse-control measure, not proof of ownership.

Authorization checklist

Property	Display Name	Opaque Edit Token
Primary role	Identification (UI context)	Authorization (permission to edit)
Entropy	Extremely low (human-selected)	Cryptographically secure (32 bytes)
Visibility	Public to all viewers	Private (client cookie and hash in database)
Collisions	Common	Mathematically negligible

Keep display names as labels for people.

Any request that modifies an existing anonymous response must present a credential that the server can verify. Depending on the application, that credential may be an authenticated session, an opaque edit token, or a signed edit link. A publicly visible name is never enough.

How to Avoid Unnecessary Re-renders in React Without Memoizing Everything

Janarthanan Soundararajan (Jana) — Wed, 16 Sep 2026 10:40:55 +0000

Add a console.log() inside a React component and you may see it run more often than expected. The first reaction is often to add React.memo, useMemo, and useCallback everywhere.

That usually treats the symptom before finding the cause.

A re-render is also not the same as a DOM update. During rendering, React calls components to calculate the next UI. During the commit phase, it updates only the DOM nodes that changed. A component running again can therefore be harmless. The optimization matters when repeated work is expensive or makes an interaction feel slow.

Before changing the code, identify why the component rendered and how much work that render performs.

Why does a React component re-render?

A component can render again for several reasons:

Its own state changed.
One of its ancestors rendered, causing the normal render cascade through descendants.
A context it reads received a different value.
An external store subscription returned an updated value.

Props need a small clarification. Changed props do not independently schedule a normal child component to render. The parent renders first and supplies those props. Without memoization, the child normally renders as part of that parent render whether its props changed or not.

Prop equality becomes important when the child is wrapped in React.memo. React can then compare each prop with its previous value using Object.is and skip the child when they are equal.

React's render and commit documentation explains this sequence in more detail.

First, decide whether the render needs fixing

A render is unnecessary from a performance perspective only when it repeats work that has a measurable cost without producing a useful change. A small component rendering after its parent is normal React behavior. If the interaction remains responsive, adding memoization may give the code more complexity than speed.

The same caution applies to inline values. An inline callback, object, or array is not automatically a performance problem. Its changing identity matters when another part of the program observes that identity, such as a memoized child, an Effect dependency, or a store subscription.

The techniques below are options to apply after identifying a specific source of wasted work. They are not rules that every component should follow.

1. Move state closer to where it is used

Start with component structure. If an input owns the only state that changes while someone types, the page does not need to own that state.

// Typing causes Dashboard and its descendants to render.
function Dashboard() {
  const [query, setQuery] = useState("");

  return (
    <div>
      <input
        value={query}
        onChange={(event) => setQuery(event.target.value)}
      />
      <VeryExpensiveTree />
    </div>
  );
}

Move the state into a smaller component:

function SearchInput() {
  const [query, setQuery] = useState("");

  return (
    <input
      value={query}
      onChange={(event) => setQuery(event.target.value)}
    />
  );
}

function Dashboard() {
  return (
    <div>
      <SearchInput />
      <VeryExpensiveTree />
    </div>
  );
}

Now the state update starts inside SearchInput. React does not need to render Dashboard or VeryExpensiveTree for every keystroke.

This applies to other temporary UI state too. If only a modal uses a form value, it can usually own that state. A tooltip can usually own its open state. Moving either value upward is still correct when another part of the tree needs to read or control it.

Yes. The idea is useful, but the explanation can be shorter. I would replace it with this:

2. Keep expensive content outside the stateful wrapper

If a wrapper has local state, pass large child content through children instead of creating it inside the wrapper.

import { type ReactNode, useState } from "react";

type InteractivePanelProps = {
  children: ReactNode;
};

function InteractivePanel({ children }: InteractivePanelProps) {
  const [highlighted, setHighlighted] = useState(false);

  return (
    <section className={highlighted ? "highlighted" : ""}>
      <button onClick={() => setHighlighted((value) => !value)}>
        Toggle highlight
      </button>

      {children}
    </section>
  );
}

function Dashboard() {
  return (
    <InteractivePanel>
      <VeryExpensiveTree />
    </InteractivePanel>
  );
}

When highlighted changes, InteractivePanel re-renders. Dashboard does not, so React can reuse the same children element without rendering VeryExpensiveTree again.

This only isolates updates caused by the wrapper's local state. VeryExpensiveTree can still render when:

Dashboard re-renders.
Its own state or context changes.
It is removed and mounted again through conditional rendering.

{isOpen && children}

Use composition to limit how far a local state update travels. It is a structural optimization, not a replacement for React.memo in every case.

The main improvement is the heading: “Keep expensive content outside the stateful wrapper” explains the technique more directly than “Pass stable content through composition.”

3. Skip expensive cascade renders with `React.memo`

When a parent renders, its child components normally render too. React.memo can skip a child when all its props remain equal.

import { memo } from "react";

type ItemListProps = {
  items: readonly string[];
};

export const ItemList = memo(function ItemList({ items }: ItemListProps) {
  return (
    <ul>
      {items.map((item) => (
        <li key={item}>{item}</li>
      ))}
    </ul>
  );
});

React.memo is a reasonable option when these conditions are true:

The parent renders frequently.
The child often receives the same props.
Rendering the child performs enough work to matter.

It does not block every render. The component still renders when its own state changes or when a context it consumes changes. React also describes memoization as a performance optimization rather than a guarantee in the memo documentation.

Wrapping every component in memo adds prop comparisons and can make the code harder to follow without improving the user experience. In a component with cheap rendering or frequently changing props, skipping memoization may be the better choice.

4. Keep function props stable with `useCallback`

JavaScript creates a new function whenever the parent executes this line:

<MemoizedItem onDelete={(id) => deleteItem(id)} />

The function reference is different on every parent render. If MemoizedItem is wrapped in React.memo, that new reference prevents React from skipping it.

useCallback can keep the reference stable until one of its dependencies changes:

function Parent() {
  const [count, setCount] = useState(0);

  const handleDelete = useCallback((id: string) => {
    deleteItem(id);
  }, []);

  return (
    <>
      <button onClick={() => setCount((value) => value + 1)}>
        Count: {count}
      </button>

      <MemoizedItem onDelete={handleDelete} />
    </>
  );
}

The empty dependency array is correct only because this example uses a stable deleteItem function declared outside the component. If the callback reads props or state, include those reactive values in its dependency list.

useCallback does not stop Parent from rendering, and caching a callback has little value when it is passed to a non-memoized child. Its common use is keeping a function prop stable for a memoized component or satisfying another Hook's dependency requirements. See the useCallback reference for the full behavior.

5. Use `useMemo` for calculations and reference stability

Arrays and objects have the same reference problem as functions:

const visibleItems = items.filter((item) => item.isActive);

filter() returns a new array on every render. That new array breaks the prop comparison of a memoized list even if items did not change.

type Item = {
  id: string;
  isActive: boolean;
};

function Parent({ items }: { items: Item[] }) {
  const visibleItems = useMemo(() => {
    return items.filter((item) => item.isActive);
  }, [items]);

  return <MemoizedList items={visibleItems} />;
}

This has two possible benefits. It avoids repeating a costly calculation, and it preserves the array reference so MemoizedList can be skipped.

Do not use useMemo for every small calculation. The cache also has a cost, and React may discard cached values in some situations. Use it for performance, not correctness. The useMemo documentation recommends measuring whether the calculation is expensive enough to justify caching.

Sometimes the cleaner fix is to pass smaller props. If a child only needs user.name, pass the name instead of the full user object. Primitive props are often easier to keep stable.

6. Split contexts to reduce subscriptions

React.memo cannot protect a component from updates to a context that it reads. When the provider receives a different value, consumers of that context render again.

One large context makes unrelated consumers depend on the same update:

<AppContext.Provider value={{ user, theme, notifications, dispatch }}>
  {children}
</AppContext.Provider>

Changing notifications can cause a component that only reads theme to render. Splitting unrelated values into separate contexts narrows the update.

State and dispatch can also be separated:

import {
  createContext,
  type Dispatch,
  type ReactNode,
  useContext,
  useReducer,
} from "react";

type AppState = {
  count: number;
};

type AppAction = {
  type: "RESET";
};

const StateContext = createContext<AppState | null>(null);
const DispatchContext = createContext<Dispatch<AppAction> | null>(null);

function AppProvider({ children }: { children: ReactNode }) {
  const [state, dispatch] = useReducer(reducer, initialState);

  return (
    <DispatchContext.Provider value={dispatch}>
      <StateContext.Provider value={state}>
        {children}
      </StateContext.Provider>
    </DispatchContext.Provider>
  );
}

function ActionButton() {
  const dispatch = useContext(DispatchContext);

  if (!dispatch) {
    throw new Error("ActionButton must be used inside AppProvider");
  }

  return (
    <button onClick={() => dispatch({ type: "RESET" })}>
      Reset
    </button>
  );
}

The dispatch function returned by useReducer has a stable identity. ActionButton can therefore dispatch actions without subscribing to the state context.

This split does not solve every context render. A component reading StateContext still renders whenever the state object changes. For a large shared state, split contexts by concern or use a store that supports selecting a smaller state slice. React's guide on scaling with reducer and context uses the same state-and-dispatch separation.

7. Use `useRef` for data that does not affect the UI

State should represent data used during rendering. If changing a value should not change the JSX, a ref may be a better fit.

function Tracker() {
  const clickCount = useRef(0);

  const handleClick = () => {
    clickCount.current += 1;
  };

  return <button onClick={handleClick}>Track click</button>;
}

Updating clickCount.current does not schedule a render. Refs are useful for timer IDs, DOM nodes, previous values, and mutable tracking data.

Do not move visible data into a ref just to avoid rendering. If the count must appear on screen, it belongs in state. React will not update the UI when only ref.current changes. The useRef documentation makes this distinction explicit.

8. Remove Effects that only derive state

An Effect that calculates one piece of state from another often creates an avoidable second render.

function Profile({ firstName, lastName }: ProfileProps) {
  const [fullName, setFullName] = useState("");

  useEffect(() => {
    setFullName(`${firstName} ${lastName}`);
  }, [firstName, lastName]);

  return <h2>{fullName}</h2>;
}

The component first renders with the old fullName. React commits that result, runs the Effect, updates state, and renders again.

Calculate the value during rendering instead:

function Profile({ firstName, lastName }: ProfileProps) {
  const fullName = `${firstName} ${lastName}`;

  return <h2>{fullName}</h2>;
}

Use useMemo only if the derived calculation is expensive. React's You Might Not Need an Effect guide covers this pattern and other unnecessary Effect chains.

9. Subscribe to the smallest store value you need

The same principle applies to Redux, Zustand, and other external stores. A component that subscribes to a large object may render for changes it never displays.

// Broad subscription
const user = useSelector((state: RootState) => state.user);

// Narrow subscription
const userName = useSelector((state: RootState) => state.user.name);

The second component depends only on user.name. Whether a render is skipped depends on the store library's selector and equality behavior, so check that library's documentation before adding custom comparison functions. For example, Redux useSelector and Zustand selectors do not have identical APIs or defaults.

Also avoid returning a fresh object from a selector unless the library provides shallow comparison or memoized selectors:

// New object on every selector call
const userSummary = useSelector((state: RootState) => ({
  name: state.user.name,
  role: state.user.role,
}));

Selecting primitives separately or using a memoized selector gives the subscription a stable result when the underlying values have not changed.

10. Profile before and after optimizing

Console logs can show that a component rendered, but they do not show whether the render was expensive. React Strict Mode may also call component functions more than once during development to detect impure rendering. That can make logs look worse than production behavior.

Use React DevTools Profiler or React's <Profiler> API to answer more useful questions:

Which interaction feels slow?
Which components rendered during it?
How long did they take?
Did memoization reduce the work?

Measure a production build when comparing performance. Development checks and tooling add overhead.

Small details that can change the diagnosis

A few cases can make render behavior look different from the simplified examples:

Setting state to its current value can let React skip the update. You may still see the component function called in some cases before React discards the result.
A memoized component still renders when its own state changes or a context it reads changes.
A custom comparison function for React.memo can cost more than rendering the component. Deep comparisons are especially risky when the data structure can grow.
Changing a component's key resets its identity and state. Keys are useful for reconciliation, but changing them is not a general re-render optimization.
Conditionally removing a component unmounts it. Showing it again creates a new instance, even when its JSX was previously passed through children.
Suspense, transitions, hydration, and concurrent rendering can cause React to start, pause, retry, or discard render work. A function call in a log does not prove that React committed a DOM update.

These cases do not invalidate the earlier techniques. They explain why a small demo, development log, and production profile may show different numbers.

Quick diagnostic matrix

Scenario	Likely cause	First option to consider
Typing in one input renders a large page	Input state is owned too high in the tree	Move the state into the input or form subtree
Expensive child renders when its parent changes unrelated state	Normal parent-to-child render cascade	Use composition or `React.memo` if the child's props remain stable
Memoized child still renders because of a callback prop	A new function reference is passed each time	Consider `useCallback` if stable identity lets that child skip work
Memoized list still renders with unchanged source data	Filtering creates a new array	Consider `useMemo` when the calculation or stable reference matters
A theme consumer renders after an unrelated context update	One context contains unrelated changing values	Split the context by concern
Updating a tracking value renders the component	Non-visual data is stored in state	Use `useRef` if the value does not affect JSX
Component renders twice after props change	An Effect copies or derives state	Calculate the value during rendering

What about React Compiler?

When React Compiler is enabled and successfully compiles the relevant components, it can apply memoization automatically and reduce the need for manual React.memo, useMemo, and useCallback. That does not make state placement, context boundaries, or unnecessary Effects irrelevant. Those choices determine how much of the tree participates in an update and how easy the code is to understand.

If the compiler is not enabled in your project, manual memoization remains useful when profiling identifies repeated expensive work.

A practical order for optimization

When a screen feels slow, work through the problem in this order:

Confirm which interaction is slow with the Profiler.
Move temporary state closer to the components that use it.
Remove Effects that derive state unnecessarily.
Split broad contexts and store subscriptions.
Consider React.memo for expensive children that often receive unchanged props.
Consider useCallback or useMemo when unstable references are defeating that memoization or the calculation itself is expensive.

The shortest rule is: reduce the scope of the update before caching values and functions.

React is designed to re-render components. The goal is not to reach zero re-renders. The goal is to prevent expensive work that produces no useful change for the user.

What to Check When Reviewing AI-Generated UI

Janarthanan Soundararajan (Jana) — Wed, 09 Sep 2026 06:05:57 +0000

AI can help us build a form, a modal, or a dashboard quickly.

The result may look good. The inputs accept text. The buttons respond. The layout fits the screen.

But before merging the code, there is another question to ask:

Does the UI work well beyond the happy path?

Some details are easy to miss during a visual review. A label may not be connected to its input. An icon button may have no accessible name. A secondary button may submit a form by accident.

These are review checkpoints, not claims that every AI tool makes these mistakes. They apply to code we write ourselves too.

The examples below use React, but most of the ideas come from HTML and apply across frameworks. The snippets focus on individual details rather than a complete application.

1. Are labels connected to their inputs?

This looks reasonable:

<label>Email address</label>
<input type="email" />

The text is visible, but the label and input are not connected. In JSX, use htmlFor with a matching input id:

<label htmlFor="email">Email address</label>
<input id="email" name="email" type="email" />

This gives the input an accessible name. Clicking the label also focuses the input. In plain HTML, the attribute is for; React uses htmlFor.

Wrapping an input inside its label is another valid approach. The point is to create the association, not to add htmlFor everywhere.

Also, remember that a placeholder is a hint. It should never replace a visible label.

2. Will IDs stay unique when components are reused?

A hardcoded id="email" can work for one field. But what happens when the same component appears twice on the same screen?

Duplicate IDs break label associations and assistive technology references. For reusable React components, React's useId hook ensures instance-level uniqueness:

import { useId } from "react";

function EmailField() {
  const id = useId();

  return (
    <div>
      <label htmlFor={id}>Email address</label>
      <input
        id={id}
        name="email"
        type="email"
        autoComplete="email"
      />
    </div>
  );
}

Each instance gets its own unique ID for the label connection.

Rule of thumb: useId is for accessibility relationships. List keys should come from your underlying data.

3. Do icon-only buttons have accessible names?

A magnifying glass icon may clearly mean “Search” to someone looking at the screen. Make sure the button also provides a programmatic name for screen readers, as well as a visual cue for sighted users who might find the icon ambiguous:

<button type="button" aria-label="Search" title="Search">
  <svg aria-hidden="true" viewBox="0 0 24 24">
    <circle cx="10" cy="10" r="6" fill="none" stroke="currentColor" />
    <path d="m15 15 6 6" stroke="currentColor" />
  </svg>
</button>

Here, aria-label supplies the accessible name, while aria-hidden="true" hides the decorative SVG to avoid redundant announcements. Adding title or a tooltip gives sighted mouse and keyboard users clarity on hover and focus.

If a button already contains visible text:

<button type="submit">Save changes</button>

It does not need an additional aria-label. Prefer visible text whenever the design allows.

4. Are button types intentional?

Inside a <form>, an ordinary <button> without an explicit type defaults to type="submit".

That becomes an immediate issue when its purpose is “Cancel” or “Show password.” Make the intention explicit on every button:

<button type="button" onClick={onCancel}>
  Cancel
</button>

<button type="submit">
  Create account
</button>

Review every secondary button inside a form. A single missing type="button" attribute can trigger accidental form submissions.

5. Are we using the right HTML elements?

A clickable <div> can look identical to a button:

<div onClick={openSettings}>Settings</div>

However, a <div> does not provide native button keyboard handling, focusability, or form integration. Adding role="button" without implementing Enter and Space key handlers still leaves keyboard users stranded.

Use native semantic elements:

{/* For an action */}
<button type="button" onClick={openSettings}>
  Settings
</button>

{/* For navigation */}
<a href="/settings">Settings</a>

Native HTML elements give you focus management, accessibility traits, and keyboard operability for free before you write a single line of extra script.

6. Can someone use the UI with a keyboard?

Set your mouse aside and test the page using only Tab, Shift + Tab, Enter, Space, and Escape:

Can you clearly see which element currently has focus?
Can you open, navigate, and close custom dropdowns and dialogs?
When a modal opens, does focus move inside and stay trapped within it?
Does focus return to the trigger element when the modal closes?

When styling focus states in CSS, prefer :focus-visible over :focus:

/* Better: Shows strong outline only during keyboard navigation */
button:focus-visible {
  outline: 2px solid #2563eb;
  outline-offset: 2px;
}

Never set outline: none without providing a prominent, high-contrast :focus-visible replacement.

7. Are validation errors connected and useful?

A red border alone does not explain the issue to users. An error message should identify what went wrong and be programmatically tied to the field:

import { useId } from "react";

function UsernameField({ error }) {
  const id = useId();
  const errorId = `${id}-error`;

  return (
    <div>
      <label htmlFor={id}>Username</label>
      <input
        id={id}
        name="username"
        aria-invalid={error ? true : undefined}
        aria-describedby={error ? errorId : undefined}
      />
      {error && (
        <p id={errorId} role="alert">
          {error}
        </p>
      )}
    </div>
  );
}

aria-invalid flags the field's state to assistive technology.
aria-describedby associates the error text with the input so it reads aloud when the field receives focus.
Adding role="alert" or using aria-live="polite" ensures dynamically rendered client-side errors are announced immediately, even if the input is already focused.

8. What happens while data loads or when a request fails?

Review more than just the successful response.

Ask:

Is it obvious that a network request is running?
Can a user accidentally submit multiple times?
Does a failed submission preserve the user's filled-in data?
If a search input fires rapid requests, can an older response overwrite newer results?

When indicating submission progress:

<button type="submit" disabled={isSubmitting} aria-busy={isSubmitting}>
  {isSubmitting ? "Saving…" : "Save changes"}
</button>

Note on disabled buttons: Adding disabled directly to a focused button can cause screen readers to immediately drop focus back to the top of the <body>. For critical flows, consider keeping the button focusable with aria-disabled="true" while ignoring pointer and click events in your handler.

9. Does the layout survive real content?

AI prompts and sample mocks often feature convenient, short text. Real production data is messy:

Test extreme character lengths, such as very long email addresses, multiline error messages, and long URLs.
Test localized strings that might expand by 30% or more.
Test zoom up to 200% to ensure text does not clip or overflow out of containers.
For images, ensure non-decorative images have descriptive alt text, while decorative illustrations use alt="" to avoid cluttering screen readers.

Before merging: quick checklist

Use this checklist during code review:

[ ] Inputs have programmatically connected labels (htmlFor / useId).
[ ] Generated IDs remain unique when components repeat.
[ ] Icon-only controls have accessible names (aria-label) and visual tooltips.
[ ] Buttons have explicit type="button" or type="submit".
[ ] Interactive actions use <button>, while navigation uses <a>.
[ ] Keyboard navigation works smoothly with visible :focus-visible indicators.
[ ] Field errors use aria-invalid and aria-describedby.
[ ] Loading, disabled, empty, and failure states are explicitly handled.
[ ] Layout holds up under browser zoom and long, unexpected text strings.

Turn the checklist into agent instructions

This checklist does not have to remain a manual reference. You can also include it in your coding agent’s review instructions.

Ask the agent to check generated UI for:

Connected labels and unique IDs
Accessible names for icon-only controls
Explicit button types
Native semantic elements
Keyboard and focus handling
Programmatically connected validation errors
Loading, empty, disabled, and failure states
Long content, zoom, and responsive-layout issues

An agent can catch many code-level problems before a pull request reaches manual review. However, it cannot fully reproduce how the interface feels with a keyboard, screen reader, browser zoom, or real production content. Use agent review as an additional review layer, then verify the important interactions manually.

Uniqueness Pre-Checks vs. Database Constraints: Why You Need Both

Janarthanan Soundararajan (Jana) — Wed, 02 Sep 2026 02:55:08 +0000

Many applications need to make sure that a value is unique.

Examples include:

Email addresses
Usernames
Phone numbers
Product slugs
Invitation codes

A common approach is to check whether the value already exists before saving it.

That check is useful, but it is not enough.

A uniqueness pre-check improves UX.

A unique database constraint protects data integrity.

You usually want both.

The uniqueness pre-check

Suppose a user is registering with an email address.

Before creating the account, the application can check whether the email already exists:

const existingUser = await db.user.findUnique({
  where: {
    email: input.email,
  },
});

if (existingUser) {
  return {
    error: "This email is already registered.",
  };
}

This allows the application to show a clear message:

This email cannot be used.

That is more helpful than showing:

Something went wrong.

The pre-check improves the user experience because it explains the problem early.

Security note: Be careful with email availability messages. Saying “This email is already registered” can reveal whether someone has an account. In sensitive flows, use a more general message, such as:

“This email cannot be used.”
“If an account exists for this email, you will receive further instructions.”

But a pre-check is not a guarantee

A pre-check asks the database a question first:

Does this email already exist?

Then, in a separate operation, the application creates the record:

Create the user.

There is a small gap between these two operations.

During that gap, another request can create the same value.

A simple race-condition example

Imagine two people submit the same username at almost the same time:

Request A: Is "alex" available? → Yes
Request B: Is "alex" available? → Yes

Request A: Create "alex" → Success
Request B: Create "alex" → Success

If the database does not enforce uniqueness, both requests may succeed.

This is called a race condition.

The username was available when both requests checked it. But both requests checked it before either request saved it.

This is also known as a TOCTOU problem:

Time Of Check
        ↓
Time Of Use

The result of the check can become outdated before the actual write happens.

The database constraint

A unique database constraint makes the database responsible for enforcing the rule.

For example, in Prisma:

model User {
  id       String @id @default(cuid())
  username String @unique
  email    String @unique
}

Now the database guarantees that two users cannot have the same username or email address.

Even if two requests arrive at the same time, only one can successfully create the record.

The other request will fail.

This protects the data even when the write comes from:

A web form
An API client
A background job
An admin tool
A migration
A webhook
A script

The database enforces the rule for every write path.

Handling the database error

The database constraint protects the data, but users should not see a raw database error.

The server should catch the unique-constraint error and return a friendly response.

With Prisma:

try {
  await db.user.create({
    data: {
      username: input.username,
      email: input.email,
    },
  });

  return {
    success: true,
  };
} catch (error) {
  if (
    error instanceof Prisma.PrismaClientKnownRequestError &&
    error.code === "P2002"
  ) {
    return {
      error: "That username or email is already in use.",
    };
  }

  throw error;
}

The pre-check gives an early explanation in normal situations.

The database constraint handles the situations that the pre-check cannot guarantee.

Why not use only the database constraint?

You can rely only on the database constraint for data integrity.

Your data will still be safe.

However, the user experience may be less helpful.

The user might submit a form and receive an error only after the request finishes.

A pre-check can provide earlier feedback:

This username is already taken.

That is better than:

Unique constraint violation.

Why not use only the pre-check?

A pre-check alone cannot protect your data.

It can fail because:

Two requests can arrive at the same time.
A different API may skip the check.
A background job may write directly to the database.
A bug may bypass the application validation.
A malicious client may send requests directly.

Application-level checks are useful, but they are not the final authority.

The recommended flow

A robust implementation usually follows this flow:

User submits the form
        ↓
Application performs a pre-check
        ↓
If the value exists, show a friendly message
        ↓
If it appears available, attempt the insert
        ↓
Database constraint enforces uniqueness
        ↓
If a race occurs, catch the error
        ↓
Show a friendly message

The pre-check and the database constraint are not competing solutions.

They solve different problems:

Layer	Purpose
Application pre-check	Gives users early and helpful feedback
Database constraint	Guarantees that duplicate data cannot be stored
Error handling	Converts conflicts into a friendly response

One detail about checking while typing

Some applications check username availability while the user is typing.

For example:

alex
alex_
alex_d
alex_de
alex_dev

This can create many database requests.

If you use this approach, consider:

Debouncing the request
Checking only after a minimum number of characters
Rate-limiting the endpoint
Checking again when the form is submitted

Availability shown in the UI can become outdated.

The final database write must still rely on the unique constraint.

Final takeaway

A uniqueness pre-check is helpful, but it is only a preview of the current state.

A unique database constraint is the actual rule.

The pre-check improves the user experience.

The constraint protects the truth of your data.

Pre-checks communicate.

Constraints enforce.

For reliable applications, use the pre-check to guide users, use the database constraint to protect your data, and handle the final conflict gracefully.

Monorepo, Turborepo, Modular Monolith, and Microservices: What Actually Changes?

Janarthanan Soundararajan (Jana) — Tue, 25 Aug 2026 18:08:36 +0000

A Turborepo can contain multiple applications under apps/. If those applications can be built and deployed separately, does that mean the system uses microservices?

Not necessarily. Multiple applications in one repository tell us how the source code is organized. Microservices are defined by runtime and operational boundaries.

Consider this small structure:

platform/
├── apps/
│   ├── marketing/
│   └── app/
└── packages/
    └── db/

Is this a monorepo, a modular monolith, or a microservices architecture?

It is clearly a monorepo. It might contain a modular-monolith application. The tree alone, however, cannot prove that any microservices exist.

While formalizing the architecture of SlotSyncro, a portfolio application, I wanted to sharpen how I distinguished these familiar concepts. They are often discussed together, even though each describes a different layer of a system. Placing them at their correct layers turns a broad understanding into a more precise architectural model.

Four concepts at four different layers

Here is the central distinction:

Concept	What it describes	Primary question
Monorepo	Repository organization	Where does the code live?
Turborepo	Task orchestration	How are builds, tests, and other tasks coordinated?
Modular monolith	Internal application design	How is one deployable application divided?
Microservices	Runtime architecture	How are services deployed, scaled, and connected?

Turbopack is related by name, but it solves another problem:

Repository organization → Monorepo
Task orchestration      → Turborepo
Application structure   → Modular monolith
Runtime architecture    → Microservices
Compilation             → Turbopack

Turborepo coordinates tasks across workspaces. Turbopack bundles a Next.js application. These concepts do not occupy the same architectural layer, so they are not direct alternatives.

That is why questions such as “Should I use a monorepo or microservices?” are difficult to answer as stated. A team can use both, either, or neither.

What makes SlotSyncro a monorepo?

A monorepo is one repository that contains multiple related projects. Those projects might be applications, shared libraries, configuration packages, or services. They share Git history and can be changed together, but they can still have separate dependencies, scripts, and release processes.

SlotSyncro currently has this workspace structure:

slotsyncro/
├── apps/
│   ├── marketing/    # Public marketing website
│   └── app/          # Scheduling product
├── packages/
│   └── db/           # Prisma and database infrastructure
├── package.json
├── pnpm-workspace.yaml
└── turbo.json

The examples in this article are based on SlotSyncro, a scheduling product I am creating as a portfolio application. The repository is publicly viewable as a practical implementation reference: SlotSyncro.

This is a monorepo because multiple identifiable projects live in one Git repository. The applications and database package have their own package.json files, while pnpm workspaces connect them. A change to the product and its database package can be reviewed and committed together.

A workspace is one project recognized and managed by the repository's package manager. In this example, apps/app, apps/marketing, and packages/db are separate pnpm workspaces. Each can define its own package name, dependencies, and commands, while using another local workspace as a dependency without publishing it to a package registry.

The monorepo label does not tell us how many production processes exist. It does not mean every folder is independently deployed, every application is a microservice, or every shared file needs its own package.

Turborepo is not required either. A repository can be a monorepo using only pnpm, npm, or Yarn workspaces. Turborepo is an additional task runner, not the feature that makes it a monorepo.

What Turborepo actually does

In this repository, the tools sit roughly in this order:

Git repository
      ↓
pnpm workspaces
      ↓
Turborepo
      ↓
Next.js, Prisma, Vitest, and other workspace tools

The root commands delegate work across the repository. Typical Turborepo commands look like this:

turbo run build
turbo run test
turbo run lint

Turborepo understands workspace dependencies, schedules tasks in the right order, caches successful outputs, avoids repeated work, and can filter execution to selected workspaces. For example, a task graph can ensure that database-client generation runs before dependent application builds.

None of this provides service-to-service communication. Turborepo does not create API gateways, message queues, independent databases, distributed transactions, container orchestration, or production scaling rules.

Turborepo knows that one workspace depends on another. It does not decide whether those workspaces become separate production services.

In current Next.js versions, Turbopack is the default bundler for development and production builds unless Webpack is explicitly selected. The similar names can make the tools sound interchangeable, but their scopes are different: Turborepo operates on the repository's task graph, while Turbopack operates on an application's module graph.

A modular monolith inside a monorepo

Now move one level inward, from the repository to apps/app.

A modular monolith is one deployable application organized into distinct business modules. The modules have defined responsibilities and controlled ways to interact, but they remain part of the same application boundary instead of becoming independently operated network services. It keeps the operational simplicity of a monolith while making internal ownership and dependencies clearer.

SlotSyncro’s current product code is still mainly grouped by technical concerns such as routes, actions, components, and utilities. The accepted direction is to evolve it incrementally into business modules. A possible target shape is:

apps/app/
├── app/                       # Next.js routes
└── modules/                   # Proposed structure
    ├── identity/
    ├── availability/
    ├── booking/
    ├── polls/
    ├── meetings/
    └── notifications/

These would be business modules, not microservices. They would have clear responsibilities and controlled interfaces, but remain part of the same Next.js application, deploy together, and use one PostgreSQL database.

The runtime remains simple:

Monorepo
├── Marketing application
└── Scheduling application ───────── one deployment boundary
    ├── Identity module
    ├── Availability module
    ├── Booking module
    ├── Polls module
    └── Notifications module
                 ↓
             PostgreSQL

The boundaries are architectural, but they are not network boundaries. A booking operation can call availability logic as a typed function and update related state in one local database transaction.

That is the useful middle ground of a modular monolith: explicit ownership without immediately accepting the operational cost of a distributed system. A monolith is not synonymous with unstructured legacy code. It can have deliberate, well-tested internal boundaries.

Folder names are not module boundaries

A booking module might eventually use a small internal structure like this:

modules/booking/
├── domain/
│   ├── booking.ts
│   └── booking-rules.ts
├── application/
│   ├── create-booking.ts
│   └── cancel-booking.ts
├── infrastructure/
│   └── booking-repository.ts
├── ui/
│   └── booking-form.tsx
└── index.ts

The exact folders matter less than the ownership they express. The module’s index.ts can act as its public API:

import { createBooking } from "@/modules/booking";

Code outside the module should avoid reaching through that API into implementation details:

// Avoid reaching into another module's internals.
import { bookingRepository } from
  "@/modules/booking/infrastructure/booking-repository";

Folders help people see the intended boundary, but they do not enforce it. Public APIs, code review, dependency rules, and tests make the boundary real. Modular-monolith architecture depends more on enforced boundaries than on folder names.

Why multiple applications still do not mean microservices

Return to the original two applications:

apps/
├── marketing/
└── app/

marketing presents public product information. app owns authentication, availability, bookings, polls, and other scheduling workflows. They are different user-facing surfaces, and the repository can build them independently.

That still says nothing about the product’s internal business capabilities being independently operated services. Its booking, polls, and notification concerns currently belong to the same product application. No internal network call is required merely because the repository contains two Next.js apps.

“Multiple applications” is a repository observation. “Microservices” is a runtime conclusion.

Even independent deployment of the marketing and product sites would not make either one a microservice architecture. They may simply be two deployable web applications with different purposes.

What would actually create microservices?

Imagine the repository later changed to this:

platform/
├── apps/
│   ├── marketing/
│   ├── web/
│   ├── scheduling-service/
│   ├── billing-service/
│   ├── notification-service/
│   └── background-worker/
└── packages/
    ├── contracts/
    ├── observability/
    └── config/

The names suggest microservices, but the folders still do not prove it. These components become services through meaningful operational independence: they run as separate processes, deploy and scale independently, communicate through APIs or messages, isolate at least some failures, and have intentionally defined business and data ownership.

A simplified runtime might look like this:

┌─────────────────────┐
│   Web application   │  Deployment A
└──────────┬──────────┘
           │ HTTPS
┌──────────▼──────────┐
│ Scheduling service │  Deployment B
└──────────┬──────────┘
           │ MeetingScheduled event
┌──────────▼──────────┐
│Notification service│  Deployment C
└─────────────────────┘

Now the boundaries are also network and deployment boundaries. That creates capabilities such as independent scaling and release ownership, but it also introduces timeouts, retries, message delivery, distributed tracing, versioned contracts, and consistency decisions.

The trade-off is easier to see side by side:

Modular monolith	Microservices
Modules call one another in-process	Services communicate over a network or queue
Usually deployed together	Independently deployable
Easier cross-module transactions	Distributed consistency must be handled
One primary runtime unit	Multiple runtime units
Lower operational complexity	Higher operational complexity
Boundaries enforced in code	Boundaries also enforced by the network

Independent deployment is important, but it is not the whole definition. If several processes must always release together, share unclear data ownership, and cannot fail independently, the system may be a distributed monolith instead.

Microservices are not the inevitable final stage of a successful modular monolith. For SlotSyncro’s current scale and requirements, local calls and transactions are valuable, while independent service operation has not earned its cost.

Turborepo supports either runtime architecture

Turborepo can coordinate a modular-monolith repository:

apps/marketing
apps/app
packages/db
packages/ui       # possible future extraction

It can also coordinate a repository containing services:

apps/web
apps/scheduling-service
apps/notification-service
apps/worker
packages/contracts

In both cases, it can run the complete build or target a workspace:

turbo run build
turbo run build --filter=scheduling-service

The second repository may use microservices because of how those applications run, communicate, and deploy—not because Turborepo launched their build tasks. Turborepo can manage a repository containing microservices, but it does not turn applications into microservices.

A monorepo can therefore contain a marketing application, a modular-monolith product, and several genuine services at the same time. Repository boundaries and runtime boundaries do not need to match one-to-one.

Keep dependency direction clear

One general monorepo rule prevents a great deal of confusion:

Applications may import packages.
Packages must not import applications.
Good: apps/app → packages/db
Bad:  packages/db → apps/app

If packages/db imports application authentication code, the dependency becomes circular:

apps/app → packages/db → apps/app

The package is no longer reusable infrastructure; it secretly depends on one consumer. Ownership becomes unclear, and isolated testing becomes harder.

For example, database infrastructure should not retrieve application-specific session context:

// Bad: packages/db knows about an application's authentication.
import { getCurrentUser } from "../../apps/app/auth";

Instead, the database package can expose infrastructure without importing from an application:

// packages/db
export { db } from "./client";

The booking module can own its product-specific query while depending on that infrastructure:

// apps/app/modules/booking/infrastructure/booking-repository.ts
import { db } from "@slotsyncro/db";

export function findBookings(userId: string) {
  return db.booking.findMany({ where: { userId } });
}

The application layer supplies the authentication context it owns:

// apps/app/modules/booking/application/list-my-bookings.ts
const user = await getCurrentUser();
const bookings = await findBookings(user.id);

This principle applies to monorepos generally. Turborepo can understand a dependency graph, but it cannot decide whether that graph represents sensible ownership.

When should a module become a package?

Once developers see a packages/ directory, it is tempting to move every cleanly named capability into it. That usually creates boundaries before there is evidence for them.

Application module	Shared package
Belongs to one application	Lives outside a specific application
Represents a product capability	Provides a reusable capability
May depend on application conventions	Should expose a stable interface
Usually has one consumer	Often has multiple consumers
Deploys with its application	May be consumed by several applications

For example, SlotSyncro should begin with booking behavior close to its only consumer:

apps/app/modules/booking/

It should not create packages/booking merely to make the repository tree look more sophisticated. Keeping code inside its only consumer is not poor architecture. It is often the clearest expression of ownership.

Possible future extractions include:

packages/
├── domain/    # Framework-independent scheduling rules
├── email/     # Shared templates or rendering infrastructure
└── ui/        # Components genuinely shared by both applications

These are proposals, not current SlotSyncro workspaces. packages/domain becomes useful if scheduling calculations need to run in the product, a worker, and isolated tests. packages/email becomes useful after multiple notification workflows need common rendering. packages/ui becomes especially useful when the marketing and product applications share a maintained design system, or when the component system has meaningful independent development and testing value.

A practical extraction test

A package should have at least one strong justification, and preferably more than one.

More than one consumer

Two applications or runtimes need the same capability. Reuse is real, not predicted from one similar-looking component.

Framework-independent domain value

Scheduling calculations can run without React, Next.js, Prisma, or a provider SDK. That isolation makes the code easier to reuse and reason about.

Stable inputs and outputs

The capability exposes a small, intentional API instead of importing application internals. If its interface changes with every feature, extraction may be premature.

Independent testing value

Its behavior can be tested meaningfully without starting the complete application. This is especially useful for scheduling, timezone, or consensus rules.

Different build or deployment concerns

Database generation, email rendering, shared contracts, or worker code may need distinct tasks. A workspace boundary can make those workflows explicit.

Do not extract code merely because packages/ makes the repository look more sophisticated. Extraction should clarify ownership or enable a real workflow.

A decision framework

When the terminology starts to blur, I return to these questions:

Do multiple related projects need to live together?
→ Consider a monorepo.
Do you need caching and coordinated workspace tasks?
→ Consider Turborepo.
Does one deployable application need stronger internal boundaries?
→ Use a modular monolith.
Does one capability require independent deployment, scaling,
failure isolation, data ownership, or team autonomy?
→ Consider extracting a service.
Is some code used by only one application?
→ Keep it close to that application for now.

This sequence avoids using a runtime solution for a repository problem—or creating a network boundary when a code boundary is enough.

Repository note: SlotSyncro is a public portfolio and reference repository, not an open-source project or starter template. Some modules and packages discussed in this article are architectural proposals and do not exist in the current implementation.

The complete mental model

A monorepo organizes where code lives.

A modular monolith organizes boundaries inside one application.

Microservices define independently operated runtime boundaries.

Turborepo coordinates tasks across the repository.

Turbopack compiles a Next.js application.

The number of folders under apps/ does not determine the runtime architecture. Deployment, communication, scaling, and ownership boundaries do.

I thought Vite broke my 3D physics. It actually taught me how tree-shaking really works.

Janarthanan Soundararajan (Jana) — Sun, 16 Aug 2026 09:05:54 +0000

In modern browser-based game development, every kilobyte matters. Larger JavaScript payloads increase download, parse, compile, and execution times, which can delay interactivity—especially on slower devices or networks.

To enforce a strict, lightweight architecture for our latest project at techaaroorian-games, we utilized Babylon's ES module packages (@babylonjs/core). For a modular application, this structure gives the bundler as much opportunity as possible to remove code the application doesn't actively use.

We set up Vite, TypeScript, Babylon.js, and the Havok WebAssembly physics engine.

Then, the engine crashed.
Error: `No Physics Engine available.`

Here is the debugging story of why our physics vanished, and what it teaches us about modern web bundlers.

1. The Simple Tree-Shaking Model

To understand why my game crashed, I had to look at how modern bundlers view our code. Vite uses Rolldown for its production builds—it doesn't read our minds; it reads the module graph.

Is the code reachable and needed? → Keep it.
Can the bundler safely determine it's unnecessary? → Remove it.

But what happens when a module doesn't export an API you need to call, but instead contains module-level registration code you need to run?

2. The Wasm Trap

My first hurdle wasn't even tree-shaking; it was dependency optimization. My terminal completely froze when I tried to start the development server.

@babylonjs/havok ships JavaScript alongside WebAssembly assets, and in my setup, Vite's dependency optimization stalled while processing the package.

I fixed it by telling Vite not to pre-bundle that dependency:

// vite.config.ts
export default defineConfig({
  optimizeDeps: { 
    exclude: ["@babylonjs/havok"] 
  },
});

This lets Vite handle the package outside the dependency pre-bundling step.

With the server finally running, I expected to see my 3D sphere bouncing with gravity. Instead, I got a blank canvas and the fatal error: No Physics Engine available.

3. The "Aha!" Moment: Vite Didn't Break My Physics

Vite didn't break my physics. It exposed an architectural design I didn't know existed.

To keep base payloads lightweight, highly optimized frameworks separate their pure implementation logic from their runtime registration.

Because I only imported the core Scene and Mesh builders, I never directly referenced the physics module's exported API. My import graph didn't establish a need for that registration module to execute. Because its runtime registration wasn't reachable through the imports I had written, the production build could treat it as unnecessary.

The physics code wasn't missing because it was broken. It was missing because its only purpose was to execute registration code, and I didn't tell my bundler that mattered!

4. The Fix: Side-Effect Imports

To fix this, I had to learn the difference between asking a bundler for an API versus asking it for an action.

The Normal Import:

import { Mesh } from "@babylonjs/core";
// Translation: "I need to use the Mesh API."
// Bundler trace: API is used, preserve the module.

The Side-Effect Import:

import "@babylonjs/core/Physics/physicsEngineComponent";
// Translation: "I don't need an exported API from this module, but I do need its module-level registration code to execute."

By adding that single side-effect import, the module executes immediately upon loading. It performs the registration necessary for Babylon's physics functionality to be available at runtime, while still allowing the bundler to aggressively tree-shake everything else.

The Result

The Big Lesson

As I continue building out techaaroorian-games, this completely changed how I look at build tools.

Static dependency → Bundler can trace it → Keep what's reachable
Module-level side effect → Execution itself matters → Make that dependency explicit

Tree-shaking isn't magic. It's static analysis. And once I understood that, "unused code" became a much more interesting concept. The bundler isn't trying to understand what my game means; it is analyzing what my module graph tells it.

(I am documenting my whole journey learning WebGPU and game dev. You can clone the full working engine setup we built today in the techaaroorian-games GitHub repository!)

The DOM Is Lying to Your Types: 3 Subtle React + Zod Validation Traps

Janarthanan Soundararajan (Jana) — Thu, 13 Aug 2026 06:38:47 +0000

A common production stack for React forms is React Hook Form for client-side state, Zod for schema validation, and Next.js Server Actions for the backend mutation.

It feels incredibly robust. But beneath these excellent tools, a subtle friction point is waiting to corrupt your data: Native form values are transport-oriented, not domain-oriented.

Prefer a visual explanation? https://youtu.be/eyE8JeGp2CI?si=s9s4yoNKM4BeuvC1

Even when the browser exposes typed helpers like input.valueAsNumber or input.checked, the raw values crossing a form boundary rarely match your application's domain model directly. React Hook Form can help normalize some primitives at registration (e.g., { valueAsNumber: true }), but this doesn't eliminate the need for boundary validation: NaN, empty values, optional semantics, and unexpected server-side inputs still require explicit handling.

When engineers rush to bridge the gap between transport data and strict TypeScript domain logic, it’s incredibly easy to implement "quick fixes" (like Zod's z.coerce) that make the TypeScript compiler happy but introduce silent data corruption.

To build robust systems, we need to internalize a core architectural principle:
Validation ≠ Type Conversion ≠ Normalization.

Look at the modern form pipeline:

DOM
 ↓
React Hook Form / FormData (Transport Representation)
 ↓
Normalization (Where "30" becomes 30)
 ↓
Validation (Does 30 meet our business rules?)
 ↓
Domain Value (Strictly Typed)
 ↓
Persistence (Database)

Whether you pull data from React Hook Form state or native FormData, your transport representation is limited. It contains strings and File objects, while missing fields are represented by the absolute absence of an entry.

As engineers, our golden rule at the normalization boundary should be: Don't ask "How do I make Zod accept this?" Ask "What does this external value actually mean in my domain?"

Here are three subtle data-boundary traps in the React/Zod ecosystem that happen when those responsibilities blur, and how to design reliable pipelines to prevent them.

Trap 1: The Number Coercion "Zero-Bypass" (Semantic Loss)

The Scenario: You are building a scheduling app and have an optional "Buffer Time" input (<input type="number" name="buffer" />). Because the DOM sends a string, z.number().optional() fails. To fix it, you reach for Zod's coercion API.

// ❌ The Trap
const schema = z.object({
  bufferTime: z.coerce.number().optional()
});

The Actual Problem: This isn't just a type error; it's semantic data loss.
In JavaScript, Number("") evaluates to 0. If a user leaves the input blank because they don't want a buffer, Zod intercepts the empty string, coerces it to 0, and validates it. Because 0 is a valid number, the .optional() check is bypassed entirely.

User Intent	DOM Input	Naive Coercion	Real Problem
No buffer configured	`""`	`0`	Semantic Loss
Explicit 0 minutes	`"0"`	`0`	-

You just erased the semantic distinction between "not provided" (undefined) and "explicitly provided as zero minutes" (0).

The Fix:
Define explicit normalization semantics using z.preprocess() before Zod attempts to validate. Crucially, if the user submits garbage data (like "banana"), we must not silently swallow it—we pass it through so z.number() can properly reject it.

// ✅ Explicit Normalization
const optionalNumberSchema = z.preprocess((val) => {
  // 1. Preserve the semantic meaning of "empty"
  if (val === "" || val === null || val === undefined) {
    return undefined;
  }

  // 2. Safely attempt conversion
  if (typeof val === "string" && val.trim() !== "") {
    const parsed = Number(val);
    return Number.isNaN(parsed) ? val : parsed; // Pass bad data through
  }

  return val;
}, z.number().int().min(0).optional());

(Note: Normalization answers "What value is this?" by intentionally accepting JavaScript's flexible numeric string syntax, like "+30". If your domain requires stricter constraints—for example, whole integers only—you enforce that as a **Validation* rule: z.number().int().min(0)).*

Trap 2: The Boolean Checkbox Nightmare

The Scenario: You have a checkbox for an event setting (<input type="checkbox" name="isPrivate" />). You grab the value from React Hook Form or FormData and pass it to Zod.

// ❌ The Trap
const schema = z.object({
  isPrivate: z.coerce.boolean()
});

The Actual Problem: Native HTML checkboxes do not submit false when unchecked; the field is omitted entirely. Calling formData.get("isPrivate") therefore returns null.

Furthermore, if you are passing JSON payloads from a client UI, passing the string "false" through Boolean("false") actually evaluates to true (because it's a non-empty string). Zod's z.coerce.boolean() is blind to your domain intent.

The Fix:
Don't use arbitrary form strings for boolean coercion. Normalize the transport representation explicitly, and—just like with numbers—don't silently swallow invalid data.

// ✅ Explicit Normalization
const checkboxSchema = z.object({
  isPrivate: z.preprocess((val) => {
    // Recognize explicit truthy transport values
    if (val === "on" || val === "true" || val === true) return true;

    // Recognize explicit falsy transport values
    if (val === "false" || val === false || val == null) return false;

    // Let unexpected values pass through so z.boolean() can catch and reject them!
    return val; 
  }, z.boolean())
});

This guarantees that expected inputs map cleanly to true or false, but if a bad actor or a bug sends "banana", it reaches z.boolean() and gets properly rejected. Unknown ≠ false. Normalization should not silently destroy information.

Trap 3: The Timezone Date Parse (Ambiguous Instants)

The Scenario: A user selects a date and time for an event using <input type="datetime-local" />. It outputs a string like "2026-08-15T09:00".

// ❌ The Trap
const schema = z.object({
  startTime: z.coerce.date()
});

The Actual Problem: A JavaScript Date object represents an absolute instant in time (milliseconds since the epoch). But a user's selection of "August 15, 09:00" is a local wall-clock time.

If a user in New York submits "2026-08-15T09:00" and the server interprets the value using its own runtime timezone, the application has created an absolute instant without knowing which timezone the user intended. You've created an ambiguous point in time.

(Note: This is one of the exact problems the JavaScript Temporal proposal is designed to model explicitly: separating a PlainDateTime from a ZonedDateTime.)

The Fix:
Never parse localized date strings natively in your schema without explicitly capturing and applying the timezone context.

// ✅ The Fix
const schema = z.object({
  // Accept the raw wall-clock time string (e.g., "2026-08-15T09:00")
  localTime: z.string().regex(/^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}$/),
  // Accept the user's explicit timezone (e.g., "America/New_York")
  timeZone: z.string() 
}).transform((data) => {
  // Explicitly combine the wall-clock time and timezone 
  // into an absolute UTC instant before saving to the database
  return {
    absoluteUtcInstant: convertToUtcInstant(data.localTime, data.timeZone)
  };
});

The Takeaway

Validation isn't just about rejecting invalid input. At application boundaries, it's also where we define how external, untyped representations officially become typed domain values.

By explicitly separating normalization from validation—and paying attention to semantic zero-bypasses, truthy strings, and wall-clock ambiguity—you can build resilient systems that prevent data corruption before it ever reaches your database.

Why Vite Asked Me to Choose Between Oxlint and ESLint

Janarthanan Soundararajan (Jana) — Sat, 08 Aug 2026 10:39:44 +0000

While initializing a new Vite project (npx create-vite), I hit an interactive CLI prompt that paused my standard workflow:

◆ Which linter to use?
  ● Oxlint
  ○ ESLint

Having relied on ESLint as my default linter for years, this piqued my curiosity. The filled bullet (●) wasn't a formal endorsement from Vite—it was simply where the CLI cursor landed—but it made me pause. Why is Vite offering Oxlint alongside ESLint, and when does it make sense to use it?

Here are my first impressions after looking into what Oxlint is, how it works under the hood, and how I plan to test it out.

❓ Why Is Vite Offering Oxlint?

Vite doesn't recommend Oxlint over ESLint—it simply presents both as first-class options during project creation. Given the growing adoption of native tooling such as SWC, Biome, and Rolldown, adding Oxlint feels consistent with the broader direction of the frontend ecosystem, while still leaving the choice to developers.

Rather than forcing one choice, Vite simply lets developers decide which workflow best fits their needs.

🔍 What is Oxlint?

From my preliminary research, Oxlint is a linter developed as part of the Oxc (Oxidized Compiler) project.

The core difference seems to be the engine: while ESLint runs on Node.js/JavaScript, Oxlint is written in Rust. Because Oxlint is a native executable rather than a JavaScript package running inside Node.js, it can reduce startup overhead and take advantage of parallel execution on modern CPUs.

Rather than trying to replace every custom rule or plugin in the JavaScript ecosystem on day one, Oxlint's current focus appears to be catching common correctness bugs, React hook pitfalls, and type safety issues with minimal setup overhead.

⚔️ How They Seem to Compare

Here is a high-level snapshot based on the documentation and early community feedback I've gathered so far:

Metric / Feature	ESLint	Oxlint
Runtime Engine	Node.js / JavaScript	Rust (Oxidized)
Execution Speed	Varies by project size, plugins, and custom rules	Official Oxlint benchmarks report significantly faster execution than ESLint, and early community feedback has generally reflected similar experiences, though results depend on the project.
Setup & Config	Requires `eslint.config.js`	Designed around sensible zero-config defaults
Plugin Ecosystem	Very mature and extensive	Smaller plugin ecosystem, with built-in support for many common React, TypeScript, JSX, and Jest rules
Primary Value	Deep customization & strict team policies	Fast local feedback and low initial setup friction

⚡ Why the Speed Pitch Caught My Eye

What made me want to investigate Oxlint further is the promise of shorter developer feedback loops.

In past projects, running pre-commit hooks (husky / lint-staged) or saving files during local hot reloading (HMR) sometimes created a small delay while validating code:

# Typical local feedback loop:
# 1. Save or stage a file.
# 2. Run the linting process.
# 3. Wait for rule validation before moving on.

If Rust-based linters can make that validation step feel nearly instant during active coding, that could be a subtle but nice improvement in daily flow. I'm curious to see if that holds true as my project grows from a fresh scaffold into a complete application.

🏗️ The Hybrid Idea I'm Curious to Try

As I read through discussions on how developers are approaching this, one approach I came across repeatedly was a hybrid setup:

For local dev & pre-commit hooks: Use Oxlint as a lightweight frontline defender to catch common mistakes instantly without slowing down commits.
For CI/CD pipelines: Keep ESLint running in GitHub Actions if complex, custom ESLint plugins or team-wide policies are required later on.

// package.json - Conceptual hybrid setup I may experiment with
{
  "scripts": {
    // Frontline check for local HMR & pre-commit hooks
    "lint:fast": "oxlint --deny-warnings",
    // Deep structural audit for CI/CD pipelines
    "lint:ci": "eslint ."
  }
}

🧪 Next Steps & What I'm Testing Next

I decided to select Oxlint for this new Vite build as an initial experiment. Since this is a brand-new project, it felt like a good opportunity to evaluate a newer tool without worrying about migrating an existing lint configuration.

Right now, the codebase is in its early stages, so getting started required virtually no configuration. As I build out components, integrate state management, and add visualizations (like D3 charts), I'm planning to observe:

How well Oxlint catches real React/TypeScript errors during active development.
Whether I run into any rule limitations that force me to bring ESLint back into the loop.

I'll be keeping notes as the project develops and might share a follow-up post with actual hands-on impressions once the site is fully built!

Update: If my experience changes after building a larger React application, I'll publish a follow-up comparing Oxlint and ESLint with real-world usage rather than first impressions.

Fixing Vitest CI Worker Crashes by Switching from jsdom to happy-dom

Janarthanan Soundararajan (Jana) — Fri, 07 Aug 2026 10:43:45 +0000

Our Vitest suite passed every time locally, but GitHub Actions failed before executing a single test. Instead of failed assertions, every test worker crashed during startup, leaving us with 0% coverage and a broken CI pipeline.

After narrowing the issue down to our test environment, we replaced jsdom with happy-dom. That change resolved the worker crashes in our environment and restored a stable GitHub Actions pipeline.

Environment Context

To help determine if this applies to your setup, here is the stack where we encountered this:

Framework: Next.js (App Router)
Testing: Vitest, @testing-library/react
Package Manager: pnpm (Workspace / Monorepo)
CI Environment: GitHub Actions (ubuntu-latest, Node.js 20)

1. The Error: Unhandled Worker Failures in CI

During the pnpm --filter app test:coverage step in GitHub Actions, Vitest failed immediately upon initializing the worker pool:

Vitest caught 7 unhandled errors during the test run.

⎯⎯⎯⎯⎯⎯ Unhandled Error ⎯⎯⎯⎯⎯⎯⎯
Error: [vitest-pool]: Failed to start forks worker for test files /apps/app/__tests__/poll.test.ts.

Caused by: TypeError: webidl.util.markAsUncloneable is not a function
 ❯ new CacheStorage ../node_modules/jsdom/node_modules/undici/lib/web/cache/cachestorage.js:20:17
 ❯ Object.<anonymous> ../node_modules/jsdom/node_modules/undici/index.js:179:25
 ❯ Object.<anonymous> ../node_modules/jsdom/lib/api.js:12:33

 Test Files  no tests
      Tests  no tests
     Errors  7 errors

ERROR: Coverage for lines (0%) does not meet global threshold (80%)

If you encounter errors such as webidl.util.markAsUncloneable is not a function or Failed to start forks worker in a vitest-pool setup, the problem may lie in your test environment's dependency tree rather than in your test code.

2. The Investigation

At first, we assumed one of the test files was failing or throwing an uncaught exception.

But the stack trace told a different story. None of the 7 test files had actually started executing. Every failure occurred while Vitest was initializing worker processes, which meant the problem was happening before our application code even loaded.

The stack trace pointed directly into jsdom's internal undici dependency during worker initialization (jsdom/node_modules/undici/lib/web/cache/cachestorage.js). Rather than a bug in our application code, this suggested an environment-level compatibility issue involving the test environment rather than our application code.

Beyond initial loading issues, jsdom emulates a large portion of standard browser behavior and maintains a detailed DOM object model. In resource-constrained CI environments (like standard Linux runners in GitHub Actions), this extra memory footprint can increase resource usage and startup time, especially during coverage runs.

We could have spent more time investigating the exact dependency mismatch, but since our tests only required standard DOM APIs, switching to a lighter implementation was the simpler and lower-risk solution.

3. The Switch: Moving to `happy-dom`

Why `happy-dom` Worked

Unlike jsdom, happy-dom focuses specifically on implementing the browser APIs commonly needed by modern frontend unit tests (such as React synthetic events and DOM queries) rather than reproducing every full browser behavior. Because of its smaller scope, happy-dom generally starts faster and has a lower resource footprint than jsdom for many component-testing scenarios, making it a good fit for React component testing in Vitest.

Step 1: Replace Dependencies

pnpm --filter app remove jsdom
pnpm --filter app add -D happy-dom @vitest/coverage-v8

Step 2: Update Vitest Configuration

Update vitest.config.ts to use happy-dom:

import { defineConfig } from 'vitest/config';
import react from '@vitejs/plugin-react';
import path from 'path';

export default defineConfig({
  plugins: [react()],
  resolve: {
    alias: {
      '@': path.resolve(__dirname, './src'),
    },
  },
  test: {
    environment: 'happy-dom',
    globals: true,
    setupFiles: ['./vitest.setup.ts'],
    coverage: {
      provider: 'v8',
      reporter: ['text', 'json', 'html', 'json-summary'],
      exclude: [
        'node_modules/',
        '.next/',
        'vitest.config.ts',
        'vitest.setup.ts',
        '**/*.d.ts',
      ],
    },
  },
});

Step 3: Recommended Test Setup

In vitest.setup.ts, ensure component trees are explicitly unmounted after each test block:

import '@testing-library/jest-dom/vitest';
import { cleanup } from '@testing-library/react';
import { afterEach } from 'vitest';

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

Note: This cleanup setup was not required to fix the worker initialization issue, but we keep it to ensure each test runs with a clean DOM and to avoid state leaking between tests.

4. Results

Metric	Before (`jsdom`)	After (`happy-dom`)
Worker Initialization	❌ Failed across all 7 test files	✅ All workers started successfully
Code Coverage	❌ 0% (Threshold failure)	✅ Coverage generated successfully
Pipeline Status	❌ CI failed consistently	✅ CI passed consistently
Execution	❌ Failed during worker initialization	⚡ Entire suite finished in ~15 seconds

While we didn't identify the exact package combination that triggered the incompatibility, replacing jsdom removed the issue entirely for our CI environment, making further investigation unnecessary for our use case.

5. When Should You Keep `jsdom`?

Every tool comes with trade-offs, and happy-dom isn't a 1:1 replacement for every project:

Keep jsdom if: Your tests depend on advanced browser APIs that happy-dom doesn't fully implement, or you are testing behavior that closely mirrors browser layout and parsing internals.
Use happy-dom if: You are primarily running React, Vue, or Svelte component tests with @testing-library, where rendering components and asserting on DOM output is all you need.

6. Lessons Learned & Takeaways

Key Takeaway: Before changing test code, check whether the failure occurs before the first test executes. If worker initialization fails, the root cause is often the test environment, dependency graph, or runtime—not your application logic.

The lesson wasn't that happy-dom is universally better than jsdom.

It was that your test environment should match your testing needs. For our React component tests, a lightweight DOM implementation was enough—and choosing the simplest test environment that satisfied our requirements made the CI pipeline both faster and more reliable.

Sometimes the quickest path to a stable CI pipeline isn't finding the perfect root cause—it's choosing the simplest tool that satisfies your testing requirements.

DEV Community: Janarthanan Soundararajan (Jana)

What Became Hard to Change as Our React App Grew

🧩 The shared component that tried to do everything

📦 The same data, now available in several flavours

🔄 The field rename that became a group project

📋 The same rule, three different versions

🕸️ The import that brought its whole family

🧪 The tests that objected to moving furniture

🔧 One smaller fix before the grand rewrite

5 Places Custom React Hooks Make Your Code Better

🧩 First: what belongs in a custom hook?

⏱️ 1. useDebouncedValue: wait until input settles

The problem

Implementation

How it works

Usage

What this hook does not solve

🌐 2. useOnlineStatus: subscribe to connection changes

The problem

Implementation

How it works

Usage

The important limitation

📱 3. useMediaQuery: use browser preferences in component behavior

The problem

Implementation

How it works

Usage

What to avoid

💾 4. useLocalStorageState: remember a preference or draft

The problem

Implementation

Why the extra state?

Usage

Know the boundaries

👁️ 5. useInView: observe visibility without scroll calculations

The problem

Implementation

How it works

Usage

What to avoid

Writing a useful hook is about its contract

A hook is not an excuse to add another effect

TypeScript definitions

Before you reuse a hook, test its awkward cases

Why I Built a Code-Native Visual Studio for My Developer Posts

1. That "Typical AI Look"

2. Keeping a Consistent Style

3. Small Typos Shouldn't Ruin an Entire Image

What About AI? (Working With It, Not Fighting It)

Enter Yuwbrndr: Code as Your Canvas

1. Multi-Slide Carousels in 1 Click (LinkedIn & Social)

The Numbers: Why Format Matters

2. Hand-Drawn Whiteboard Art with Rough.js

3. Share Everything in the URL (Zero Server Storage)

The Engineering Trade-off:

4. Privacy First: No Trackers, No Cookies

It’s 100% Free & Open Source (MIT)

Never Use a Display Name for Authorization: Secure Anonymous Editing

Identification and authorization

Two ownership paths

Authenticated participants

Anonymous participants

Store the hash, not the raw token

Why SHA-256 is suitable here

Example: Normalized Polling Architecture in SlotSyncro

Limitations of cookie-backed editing

Authorization checklist

How to Avoid Unnecessary Re-renders in React Without Memoizing Everything

Why does a React component re-render?

First, decide whether the render needs fixing

1. Move state closer to where it is used

2. Keep expensive content outside the stateful wrapper

3. Skip expensive cascade renders with React.memo

4. Keep function props stable with useCallback

5. Use useMemo for calculations and reference stability

6. Split contexts to reduce subscriptions

7. Use useRef for data that does not affect the UI

8. Remove Effects that only derive state

9. Subscribe to the smallest store value you need

⏱️ 1. `useDebouncedValue`: wait until input settles

🌐 2. `useOnlineStatus`: subscribe to connection changes

📱 3. `useMediaQuery`: use browser preferences in component behavior

💾 4. `useLocalStorageState`: remember a preference or draft

👁️ 5. `useInView`: observe visibility without scroll calculations

3. Skip expensive cascade renders with `React.memo`

4. Keep function props stable with `useCallback`

5. Use `useMemo` for calculations and reference stability

7. Use `useRef` for data that does not affect the UI