DEV Community: Learcise

🧩 A Complete Guide to React Testing: From Unit Tests to E2E, Snapshots, and Test Doubles

Learcise — Tue, 07 Oct 2025 02:26:40 +0000

When developing with React, have you ever wondered:

“Where should I even start with testing?”

This article walks you through unit tests, integration tests, end-to-end (E2E) tests, snapshot tests, and test doubles,

focusing on tools like Jest, React Testing Library, and Playwright.

🧠 Why Write Tests?

Writing tests isn’t just about reducing bugs.

It brings lasting benefits to your development team:

✅ Enables safe refactoring
✅ Serves as living documentation for expected behavior
✅ Helps maintain code quality over time

React apps often deal with complex state and side effects (like useEffect), making them prone to hidden bugs.

That’s why having a solid testing strategy is crucial.

⚙️ The Three Layers of Testing: Unit, Integration, and E2E

🔹 Unit Tests

Unit tests focus on the smallest pieces of your application — functions, components, or custom hooks.

They check whether a given input produces the expected output.

// useCounter.test.ts
import { renderHook, act } from '@testing-library/react';
import useCounter from './useCounter';

test('increments the count by 1', () => {
  const { result } = renderHook(() => useCounter());
  act(() => result.current.increment());
  expect(result.current.count).toBe(1);
});

🔹 Integration Tests

Integration tests verify how multiple components or functions work together.

For example: form input → validation → API call.

import { render, screen, fireEvent, waitFor } from '@testing-library/react';
import Form from './Form';

test('calls API on form submit', async () => {
  const mockSubmit = jest.fn();
  render(<Form onSubmit={mockSubmit} />);

  fireEvent.change(screen.getByLabelText(/Name/), { target: { value: 'Taro' } });
  fireEvent.click(screen.getByText('Submit'));

  await waitFor(() => expect(mockSubmit).toHaveBeenCalledWith('Taro'));
});

🔹 End-to-End (E2E) Tests

E2E tests simulate real user interactions in the browser, covering the entire app flow.

Common tools include Playwright and Cypress.

// login.e2e.ts
import { test, expect } from '@playwright/test';

test('logs in and redirects to the dashboard', async ({ page }) => {
  await page.goto('/login');
  await page.fill('#email', 'test@example.com');
  await page.fill('#password', 'password');
  await page.click('button[type="submit"]');
  await expect(page).toHaveURL('/dashboard');
});

🧪 The Role of Jest and React Testing Library

✅ What is Jest?

Jest is a testing framework developed by Facebook.

It provides everything you need for testing JavaScript apps:

Test runner
Mocks and spies
Snapshot testing

It’s commonly used together with React Testing Library.

✅ What is React Testing Library?

Instead of directly manipulating the DOM, React Testing Library focuses on testing the app from the user’s perspective — by simulating clicks, typing, and other interactions.

import { render, screen, fireEvent } from '@testing-library/react';
import Counter from './Counter';

test('increments the counter when button is clicked', () => {
  render(<Counter />);
  fireEvent.click(screen.getByText('+'));
  expect(screen.getByText('1')).toBeInTheDocument();
});

📸 What Is a Snapshot Test?

A snapshot test saves a “picture” of a component’s rendered output and compares it on future test runs to detect unexpected UI changes.

It’s powered by Jest’s toMatchSnapshot() function.

✅ Example

// Button.tsx
export const Button = ({ label }: { label: string }) => {
  return <button>{label}</button>;
};

// Button.test.tsx
import renderer from 'react-test-renderer';
import { Button } from './Button';

test('matches the snapshot', () => {
  const tree = renderer.create(<Button label="Send" />).toJSON();
  expect(tree).toMatchSnapshot();
});

When you run the test for the first time, Jest stores a snapshot like this under __snapshots__:

exports[`Button snapshot 1`] = `
<button>
  Send
</button>
`;

If the component’s output changes later, Jest will show a diff:

- <button>
+ <button className="primary">

✅ If the change is intentional, update the snapshot with npm test -- -u.

⚖️ Pros and Cons

Type	Description
✅ Pros	Catches unintended UI changes, easy to set up
⚠️ Cons	Can produce noisy diffs, not suitable for dynamic elements
💡 Best Practice	Use for small, stable UI parts only

🧩 Using React Testing Library for Snapshots

import { render } from '@testing-library/react';
import Button from './Button';

test('Button matches snapshot', () => {
  const { asFragment } = render(<Button label="Send" />);
  expect(asFragment()).toMatchSnapshot();
});

🧱 Understanding Test Doubles: Mocks, Stubs, Fakes, and Dummies

While snapshot tests detect visual changes,

test doubles help you “recreate and control” external behavior to make your tests safe and reliable.

🔸 What Is a Test Double?

In React testing, components often depend on external systems — APIs, databases, or browser APIs.

Using real ones makes tests slow and flaky.

A test double is a fake replacement for those dependencies that lets you simulate external behavior safely.

🧩 Example: When API Responses Affect the UI

Let’s say you have a component that fetches user data and displays it.

💡 Original Code

// UserInfo.tsx
import { useEffect, useState } from 'react';
import { fetchUser } from './api';

export const UserInfo = () => {
  const [user, setUser] = useState(null);

  useEffect(() => {
    fetchUser().then(setUser);
  }, []);

  if (!user) return <p>Loading...</p>;
  return <p>Hello, {user.name}!</p>;
};

If you test this with a real API:

The test fails when the API is down
It takes time due to network latency
Results vary depending on live data

✅ Using a Test Double

import { render, screen, waitFor } from '@testing-library/react';
import { UserInfo } from './UserInfo';
import { fetchUser } from './api';

jest.mock('./api'); // Mock the API module

test('displays the user name', async () => {
  fetchUser.mockResolvedValue({ name: 'Hanako' });

  render(<UserInfo />);

  await waitFor(() =>
    expect(screen.getByText('Hello, Hanako!')).toBeInTheDocument()
  );
});

Here, the API response is simulated inside the test.

No real network requests are made, and results are always consistent.

🧭 Why Use Test Doubles?

Goal	Benefit
Isolate external dependencies	No need for real APIs or databases
Speed up tests	Responses are instant
Ensure consistency	Same result every time
Reproduce special cases	e.g. simulate API errors easily

🎯 Key idea: Test doubles let you mimic real-world behavior and take full control of the testing environment.

🧩 Types of Test Doubles and Examples

Type	Definition	Use Case	Example (React/Jest)
Mock	A fake object that tracks how it’s used (calls, args)	Verify function calls	`js\nconst mockFn = jest.fn();\nfireEvent.click(button);\nexpect(mockFn).toHaveBeenCalledTimes(1);\n`
Stub	Returns fixed values; doesn’t record history	Simulate API responses	`js\njest.spyOn(api, 'fetchUser').mockResolvedValue({ name: 'Taro' });\n`
Fake	A lightweight working version of a dependency	Replace local DB or storage	`js\nclass FakeLocalStorage {\n setItem(k,v){this.store[k]=v;}\n getItem(k){return this.store[k];}\n}\n`
Dummy	Placeholder objects that aren’t actually used	Required arguments	`js\nrender(<UserCard user={null} onClick={() => {}} />);\n`
Spy	Observes calls to real functions	Monitor logs or side effects	`js\nconst spy = jest.spyOn(console, 'log');\nlogMessage('Hello');\nexpect(spy).toHaveBeenCalledWith('Hello');\n`

🧩 Designing a Testing Strategy

🔺 The Testing Pyramid

   ▲  E2E Tests (few)
  ▲▲  Integration Tests (some)
 ▲▲▲ Unit Tests (many)

Unit tests: small, fast, and plentiful
Integration tests: verify key workflows
E2E tests: ensure the entire user experience

🧠 Continuous Testing

Automate tests in CI/CD (e.g., GitHub Actions)
Use snapshot tests to catch unintended UI changes early

🏁 Summary

Test Type	Purpose	Tools
Unit Test	Verify functions/components individually	Jest / React Testing Library
Integration Test	Test multiple units together	Jest / RTL
E2E Test	Simulate real user flows	Playwright / Cypress
Snapshot Test	Detect unintended UI changes	Jest
Test Double	Simulate and control external dependencies	Jest.mock / Spy / Stub

🧑‍💻 Final Thoughts

Testing doesn’t slow development down —

it’s a tool for building safely and refactoring with confidence.

Start small with unit tests, then add snapshots and test doubles as your project grows.

Common React Anti-Patterns and How to Fix Them

Learcise — Fri, 26 Sep 2025 00:37:40 +0000

React is a powerful and flexible library. But that flexibility also makes it easy to fall into anti-patterns—habits that seem fine at first but hurt readability, maintainability, and performance over time.

In this post, we’ll walk through common pitfalls, show bad code examples, explain why they’re bad, and then demonstrate better approaches.

1. Overusing `useState` and Scattering State

Bad: multiple related states separated

function ProfileForm() {
  const [firstName, setFirstName] = React.useState('');
  const [lastName, setLastName] = React.useState('');
  const [age, setAge] = React.useState(0);
  // and it keeps growing...
  return (
    <>
      <input value={firstName} onChange={e => setFirstName(e.target.value)} />
      <input value={lastName}  onChange={e => setLastName(e.target.value)} />
      <input value={age}       onChange={e => setAge(Number(e.target.value))} />
    </>
  );
}

Why is this bad?

Update logic gets scattered across multiple setters.
Hard to keep values consistent (e.g. resetting all fields at once).
More states = more dependency management and risk of bugs.

Good: group related state in an object

function ProfileForm() {
  const [profile, setProfile] = React.useState({ firstName: '', lastName: '', age: 0 });
  const update = (key) => (e) => setProfile(p => ({
    ...p,
    [key]: key === 'age' ? Number(e.target.value) : e.target.value
  }));
  return (
    <>
      <input value={profile.firstName} onChange={update('firstName')} />
      <input value={profile.lastName}  onChange={update('lastName')} />
      <input value={profile.age}       onChange={update('age')} />
    </>
  );
}

2. Monster Components

Bad: everything stuffed into one component

function TodoApp() {
  const [text, setText] = React.useState('');
  const [todos, setTodos] = React.useState([]);
  const add = () => { if (text.trim()) setTodos(t => [...t, { id: Date.now(), text }]); setText(''); };
  const remove = (id) => setTodos(t => t.filter(x => x.id !== id));
  return (
    <div>
      <h1>Todos</h1>
      <input value={text} onChange={e => setText(e.target.value)} />
      <button onClick={add}>add</button>
      <ul>
        {todos.map(t => <li key={t.id}><span>{t.text}</span><button onClick={() => remove(t.id)}>x</button></li>)}
      </ul>
    </div>
  );
}

Why is this bad?

Mixes input, list rendering, add/remove logic in one file.
Hard to test or reuse pieces.
Any small change risks breaking unrelated logic.

Good: split responsibilities into smaller components

const TodoInput = ({ text, setText, onAdd }) => (
  <div>
    <input value={text} onChange={e => setText(e.target.value)} />
    <button onClick={onAdd}>add</button>
  </div>
);

const TodoList = ({ todos, onRemove }) => (
  <ul>{todos.map(t => <li key={t.id}>{t.text}<button onClick={() => onRemove(t.id)}>x</button></li>)}</ul>
);

function TodoApp() {
  const [text, setText] = React.useState('');
  const [todos, setTodos] = React.useState([]);
  const add = () => { if (text.trim()) setTodos(t => [...t, { id: crypto.randomUUID(), text }]); setText(''); };
  const remove = id => setTodos(t => t.filter(x => x.id !== id));
  return (
    <div>
      <h1>Todos</h1>
      <TodoInput text={text} setText={setText} onAdd={add} />
      <TodoList todos={todos} onRemove={remove} />
    </div>
  );
}

3. Components Doing Too Much Logic

Bad: fetching data directly inside a UI component

function Users() {
  const [users, setUsers] = React.useState([]);
  React.useEffect(() => {
    fetch('/api/users').then(r => r.json()).then(setUsers);
  }, []);
  return <ul>{users.map(u => <li key={u.id}>{u.name}</li>)}</ul>;
}

Why is this bad?

Couples data fetching with UI rendering.
Harder to test in isolation.
Makes the component harder to reuse.

Good: move logic into a custom hook

function useUsers() {
  const [users, setUsers] = React.useState([]);
  React.useEffect(() => {
    let aborted = false;
    (async () => {
      const r = await fetch('/api/users');
      const data = await r.json();
      if (!aborted) setUsers(data);
    })();
    return () => { aborted = true; };
  }, []);
  return users;
}

function Users() {
  const users = useUsers();
  return <ul>{users.map(u => <li key={u.id}>{u.name}</li>)}</ul>;
}

4. Reversing Data Flow (Child Updating Parent)

Bad: child updates parent’s state directly

function Child() {
  // Imagine directly importing parent’s setter or using context incorrectly
  // ❌ breaks one-way data flow
  return null;
}

Why is this bad?

Breaks React’s one-way data flow.
Debugging becomes painful because updates happen in unexpected places.
Creates tight coupling.

Good: Lift state up, pass down via props

function Parent() {
  const [value, setValue] = React.useState('');
  return <Child value={value} onChange={setValue} />;
}
const Child = ({ value, onChange }) => (
  <input value={value} onChange={e => onChange(e.target.value)} />
);

5. Storing Derived State

Bad: storing values you could calculate

function Cart({ items }) {
  const [total, setTotal] = React.useState(0);
  React.useEffect(() => {
    setTotal(items.reduce((s, it) => s + it.price, 0));
  }, [items]);
  return <div>Total: {total}</div>;
}

Why is this bad?

Two sources of truth → data inconsistency risk.
Extra state → extra re-renders.
Harder to debug.

Good: compute when needed

function Cart({ items }) {
  const total = React.useMemo(() => items.reduce((s, it) => s + it.price, 0), [items]);
  return <div>Total: {total}</div>;
}

6. Abusing `useEffect` for Calculations

Bad: using useEffect + setState just for filtering

function Filtered({ list, q }) {
  const [filtered, setFiltered] = React.useState([]);
  React.useEffect(() => {
    setFiltered(list.filter(x => x.includes(q)));
  }, [list, q]);
  return <ul>{filtered.map(x => <li key={x}>{x}</li>)}</ul>;
}

Why is this bad?

Triggers extra render cycles.
Makes simple logic look like a side effect.
Harder to reason about.

Good: useMemo for derived data

function Filtered({ list, q }) {
  const filtered = React.useMemo(() => list.filter(x => x.includes(q)), [list, q]);
  return <ul>{filtered.map(x => <li key={x}>{x}</li>)}</ul>;
}

7. Wrong `key` Usage

Bad: using index as key

items.map((item, i) => <li key={i}>{item.name}</li>);

Why is this bad?

When list order changes, React can’t track items correctly.
Leads to bugs like losing focus or input values jumping around.

Good: use stable, unique keys

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

8. Forgetting Cleanup in Effects

Bad: leaking event listeners

function WindowSize() {
  const [w, setW] = React.useState(window.innerWidth);
  React.useEffect(() => {
    const onResize = () => setW(window.innerWidth);
    window.addEventListener('resize', onResize);
    // ❌ forgot to remove
  }, []);
  return <div>{w}</div>;
}

Why is this bad?

Causes memory leaks.
Can trigger updates after unmount → warnings/errors.

Good: return cleanup

function WindowSize() {
  const [w, setW] = React.useState(window.innerWidth);
  React.useEffect(() => {
    const onResize = () => setW(window.innerWidth);
    window.addEventListener('resize', onResize);
    return () => window.removeEventListener('resize', onResize);
  }, []);
  return <div>{w}</div>;
}

9. Defining Components Inside Components

Bad: redefining child every render

function Parent({ items }) {
  const Item = ({ item }) => <li>{item.name}</li>; // ❌ new component each time
  return <ul>{items.map(i => <Item key={i.id} item={i} />)}</ul>;
}

Why is this bad?

Creates a new function reference on every render.
Memoization breaks, causing unnecessary re-renders.
Harder to debug.

Good: define outside, memoize if needed

const Item = React.memo(({ item }) => <li>{item.name}</li>);

function Parent({ items }) {
  return <ul>{items.map(i => <Item key={i.id} item={i} />)}</ul>;
}

10. No Error Boundaries

Bad: one error kills the entire app

function App() {
  return <ProblemChild />; // throw → blank screen
}

Why is this bad?

Terrible UX: user sees nothing.
Errors don’t get logged or handled gracefully.
Can’t recover or retry.

Good: wrap with an Error Boundary

import { ErrorBoundary } from 'react-error-boundary';

function ErrorFallback({ error, resetErrorBoundary }) {
  return (
    <div role="alert">
      <p>Something went wrong</p>
      <pre>{error.message}</pre>
      <button onClick={resetErrorBoundary}>Retry</button>
    </div>
  );
}

function App() {
  return (
    <ErrorBoundary FallbackComponent={ErrorFallback}>
      <ProblemChild />
    </ErrorBoundary>
  );
}

11. Ignoring "State is a Snapshot" (Stale Closures)

Bad: using outdated state inside interval

function Counter() {
  const [count, setCount] = React.useState(0);
  React.useEffect(() => {
    const id = setInterval(() => {
      console.log('tick uses stale count:', count); // ❌ stale value
      setCount(c => c + 1); // functional update works
    }, 1000);
    return () => clearInterval(id);
  }, []); // missing dependency
  return <div>{count}</div>;
}

Why is this bad?

Closures capture old state.
Leads to confusing, inconsistent logs and behaviors.

Good: use refs or functional updates

function Counter() {
  const [count, setCount] = React.useState(0);
  const ref = React.useRef(count);
  React.useEffect(() => { ref.current = count; }, [count]);

  React.useEffect(() => {
    const id = setInterval(() => {
      console.log('fresh count:', ref.current);
      setCount(c => c + 1);
    }, 1000);
    return () => clearInterval(id);
  }, []);

  return <div>{count}</div>;
}

12. Wrong Dependency Arrays in `useEffect`

Bad: missing dependencies

function Search({ query, fetcher }) {
  const [result, setResult] = React.useState(null);
  React.useEffect(() => {
    fetcher(query).then(setResult);
  }, []); // ❌ ignores query and fetcher
  return <div>{JSON.stringify(result)}</div>;
}

Why is this bad?

Effect doesn’t rerun when query changes → stale data.
Bugs that only appear in specific cases, hard to trace.

Good: declare dependencies properly

function Search({ query }) {
  const [result, setResult] = React.useState(null);
  const fetcher = React.useCallback(
    (q) => fetch(`/api?q=${encodeURIComponent(q)}`).then(r => r.json()),
    []
  );
  React.useEffect(() => {
    let ignore = false;
    fetcher(query).then(r => { if (!ignore) setResult(r); });
    return () => { ignore = true; };
  }, [query, fetcher]);
  return <div>{JSON.stringify(result)}</div>;
}

Takeaways

To write cleaner, more maintainable React code:

Keep state minimal and consistent.
Follow the single responsibility principle.
Use useEffect only for syncing with the outside world.
Always provide proper keys and error boundaries.
Treat state as a snapshot per render, not as a mutable variable.

These small improvements add up to code that’s easier to debug, test, and evolve. 🚀

Understanding the Browser: From DNS Resolution to DOM and Rendering

Learcise — Wed, 24 Sep 2025 03:06:54 +0000

We use web browsers on a daily basis. When we type in a URL, the page appears within seconds, but behind the scenes, a huge number of processes are happening simultaneously.

In this article, we’ll break down the flow from DNS resolution to DOM tree construction, rendering, and compositing. We’ll also clearly explain the often-confused difference between the DOM (API specification) and the DOM tree (data structure).

Browser Architecture and the First Communication

A browser is not just an “app that displays pages.” It consists of multiple components working together. The main components are as follows:

User Interface

The part the user directly interacts with:

Address bar, back/forward buttons, tab switching, bookmark management, etc.
It doesn’t directly participate in internal processing, but it passes user actions to the browser engine.

Browser Engine

The “conductor” that coordinates the whole system:

Bridges user actions (URL input, scrolling, etc.) to the respective modules.
Instructs the rendering engine to “parse the retrieved HTML and display it.”

Networking Module

The “communication clerk” of the browser, responsible for internet communication.

When you enter a URL, the networking module is the first to start working. Inside the browser, it functions as the communication handler, and operates as follows:

DNS Resolution
- Extracts the hostname (e.g., example.com) from the URL and converts it into an IP address.
- If the information is in cache, it’s used. Otherwise, it queries step by step: root DNS → TLD DNS → authoritative DNS to obtain the final IP.
  
  👉 The networking module translates the “human-readable address (hostname)” into the “machine-usable address (IP address).”
TCP/TLS Connection
- Once the IP address is known, the networking module establishes a TCP connection with the server.
- If using HTTPS, it also performs a TLS handshake to set up secure, encrypted communication.
HTTP Request and Response
- After the connection is established, the networking module sends an HTTP request to the server.
- The server responds with HTML, followed by CSS, JavaScript, images, and other resources.
Hand-off to the Rendering Engine
- The networking module’s role is to pass the received HTML, CSS, etc., to the rendering engine.
- From here, DOM tree construction begins.

Rendering Engine

The core component that parses HTML and CSS, and paints them onto the screen.

Chrome/Edge → Blink
Safari → WebKit
Firefox → Gecko

JavaScript Engine

The component that interprets and executes JavaScript.

Manipulates the DOM tree through the DOM API.
Handles event processing and asynchronous communication (e.g., fetch).
Examples: V8 (Chrome/Edge), SpiderMonkey (Firefox), JavaScriptCore (Safari).

Data Storage

Stores data for users and websites.

Cookies: Session management, login information.
LocalStorage / SessionStorage: Key-value storage accessible from JavaScript.
IndexedDB: A database for handling large-scale data.
Cache: Stores images and HTML for faster reloads.

Understanding the DOM

“What exactly is the DOM? And how is it different from the DOM tree?”

This is a common source of confusion for many developers.

DOM = API Specification

DOM (Document Object Model) is an API specification for manipulating documents from programs.
Methods like document.getElementById() and document.querySelector() in JavaScript are part of the DOM API.
In other words, DOM is the “system that lets the browser expose the document as objects.” It’s closer to a set of rules (a spec) than an actual data structure.

DOM Tree = Actual Data Structure

The DOM tree is what the browser (rendering engine) builds by parsing HTML.
It has a hierarchical tree structure:
- <html> is the root
- <head> and <body> are children
-  elements and text nodes form the leaves

DOM Manipulation = DOM Tree Manipulation

When developers talk about “manipulating the DOM,” what they’re really doing is using the DOM API to modify the DOM tree.

Example:

document.body.appendChild(document.createElement("div"));

This creates a new node and attaches it to the tree.

👉 The key takeaway: DOM is the concept (API spec), while the DOM tree is the actual data structure.

DOM Tree Construction Process

So how is the DOM tree actually built?

The rendering engine processes the received HTML as follows:

Receive HTML
- HTML file data arrives from the networking module.
Tokenization
- Breaks HTML into tokens (building blocks).
- Example: Hello → start tag , text Hello, end tag .
Parsing
- Analyzes tokens according to grammar rules, generating corresponding objects.
Node Creation
- Tag → Element node
- Text → Text node
- Comment → Comment node
Tree Construction
- Connects nodes into a parent-child hierarchy to complete the DOM tree.
- When this DOM tree is ready, the DOMContentLoaded event fires.
- At this point, developers can safely manipulate the DOM with JavaScript.

👉 Note: The DOM tree is built incrementally as the HTML stream arrives, not all at once.

Rendering Engine and the DOM

Now that we understand what the DOM is and how the DOM tree is built, let’s look at its relationship with the rendering engine.

Rendering Engine Responsibilities

Parse HTML to build the DOM tree.
Parse CSS to build the CSSOM tree.
Combine them to create the render tree.
Perform layout, paint, and compositing to display the page.

Relationship with the DOM

The DOM tree is a product of the rendering engine.
Developers don’t directly control the rendering engine; instead, they manipulate the DOM tree via the DOM API.
Changes to the DOM tree trigger the rendering engine to update the screen.

👉 Think of it like this:

Rendering Engine = Factory
DOM Tree = Product made by the factory
DOM API = Remote control to operate the product

Rendering Pipeline Overview

A DOM tree alone isn’t enough to display the page. With CSS added, the rendering engine proceeds as follows:

Build the DOM tree
Build the CSSOM tree
Generate the Render tree (DOM + CSSOM, excluding invisible elements)
Layout: Calculate positions and sizes
Paint: Convert styles into pixel instructions
Composite: Merge multiple layers on the GPU and display the final result

👉 This is the browser’s rendering pipeline.

Compositing in Detail

Compositing is the final stage of rendering.

Layering System

The page isn’t drawn on a single canvas; it’s split into multiple layers.
Example:
- Background → Layer 1
- Body text → Layer 2
- Fixed header → Layer 3
- CSS animation element → Layer 4

Why Compositing Matters

Redrawing the entire page is expensive.
By managing layers, only the parts that change need to be updated, then everything is merged at the end.
Crucial for smooth scrolling and animations.

Developer Optimization Tips

Use transform and opacity to trigger “composite-only” updates (no reflow/paint).
Use will-change in CSS to pre-promote elements to their own layers.
But don’t overuse it—too many layers consume memory.

👉 Understanding compositing is key to smooth animations and performance.

JavaScript and Rendering

JavaScript DOM manipulations directly affect rendering.

Reflow (Layout recalculation)

Happens when element position/size changes.
Forces recalculation of the entire layout.
Example: element.style.width = "500px";

Repaint (Redraw)

Happens when only visual properties (color, background, etc.) change.
No layout recalculation, but pixels are repainted.
Example: element.style.backgroundColor = "red";

Composite-only

transform and opacity changes don’t require reflow or repaint.
Handled in the compositing stage only → fastest.

👉 Key takeaway:

Know which operations cause reflow/repaint.
Prefer composite-only operations whenever possible.

Performance Optimization Tips

Optimize JavaScript loading
- Use defer / async to avoid blocking rendering.
Lazy load images and videos
- Use loading="lazy" to defer unnecessary resources.
Batch DOM operations
- Modify elements in bulk instead of one by one.
- Use DocumentFragment or batch updates.
Use transform/opacity for animations
- Avoid triggering layout and paint.
Avoid unnecessary layers
- Don’t overuse will-change.

👉 The golden rule: Don’t break the rendering pipeline.

Conclusion

The DOM is the “API specification,” while the DOM tree is the “actual structure built by the browser.”
The rendering engine parses HTML → builds DOM tree → builds CSSOM → generates render tree → layout → paint → composite → display.
Compositing is crucial for performance.
By understanding how DOM operations affect rendering, developers can build faster, smoother web experiences.

Next time you open a web page, remember: behind the scenes, the entire flow from DNS resolution to compositing is happening. And with that in mind, the browser will feel much less of a black box.

Introduction to Prisma: An ORM for Type-Safe and Efficient Database Operations

Learcise — Tue, 23 Sep 2025 14:59:32 +0000

In recent years, using databases has become essential in web application development.

However, you may have encountered issues such as:

“Writing raw SQL easily leads to bugs.”
“Existing ORMs feel inconvenient to use.”

Prisma solves these problems.

Prisma is a next-generation ORM designed for the Node.js/TypeScript ecosystem. It provides type safety, intuitive usability, and powerful migration features.

2. Benefits of Prisma

The main advantages of Prisma can be grouped into three categories:

Type-Safe & Auto-Completion

With Prisma Client, TypeScript types are automatically generated.

This enables IDE code completion, making it harder to write invalid queries and greatly improving development productivity.

Automatic Migrations

Traditionally, developers had to manage tables by manually writing SQL. With Prisma, you can easily run migrations using prisma migrate.

Since schemas are centrally managed, conflicts in database design during team development are much easier to avoid.

Broad Database Support

Prisma supports major databases such as MySQL, PostgreSQL, SQLite, and MongoDB.

It also integrates seamlessly with popular frameworks like Next.js and NestJS.

3. Key Components to Understand Before Starting with Prisma

Before introducing Prisma into your project, it’s important to understand the following components:

schema.prisma

A file where you define your data models — the core of Prisma’s configuration.
Prisma Client

An auto-generated, type-safe database client.
Prisma Migrate

A migration tool for applying schema changes to your database.
Prisma Studio

A handy GUI tool for browsing and editing data.

Installation Flow

npm install prisma --save-dev
npx prisma init

This generates a prisma/schema.prisma file, where you can set up your database connection.

4. Practical Example: Using Prisma with Next.js (TypeScript)

Let’s walk through a concrete example of integrating Prisma with Next.js.

Database Connection

import { PrismaClient } from '@prisma/client'
const prisma = new PrismaClient()

Seeding Initial Data

async function main() {
  await prisma.user.create({
    data: {
      name: 'Taro',
      email: 'taro@example.com',
    },
  })
}
main()

By running npx prisma db seed, you can easily insert initial data.

Prisma Studio

npx prisma studio

This allows you to intuitively manage your database through a browser-based UI.

5. Efficient Database Design and Migrations

One of Prisma’s most powerful features is its migration system.

Example Model Definition

model User {
  id    Int     @id @default(autoincrement())
  name  String
  email String  @unique
  posts Post[]
}

By simply defining a model and running npx prisma migrate dev, SQL is automatically generated for you.

In team development, migration histories are stored in Git, which improves transparency in database design.

6. Conclusion

Prisma addresses the shortcomings of traditional ORMs and enables type-safe, efficient, and intuitive database operations.

For beginners, IDE auto-completion and GUI tools provide great support.
For production use, automated migrations and version control become powerful allies.

If you’re developing with frameworks like Next.js or NestJS, Prisma is definitely worth considering.

Mastering Terraform: From IaC Basics to the Real Difference Between variable and locals

Learcise — Sun, 21 Sep 2025 01:19:44 +0000

Automating the construction and operation of cloud environments is where Terraform truly shines.

In this article, we’ll organize Terraform’s fundamental concepts and usage, and then dive into one of the most common stumbling blocks: the difference between variable and locals. We’ll explain this in comparison to scoping in JavaScript, with concrete AWS examples so you can easily picture real-world usage.

Why use Terraform?

Traditionally, when building AWS infrastructure manually through the console or CLI, teams often ran into the following issues:

Human error: manual operations are prone to mistakes
Lack of reproducibility: it’s hard to quickly rebuild the same environment for disaster recovery or new deployments
Knowledge silos: build procedures often live only in someone’s head
Scaling limitations: managing large-scale environments manually is not feasible
Opaque change management: difficult to track who changed what, and when

The solution is Infrastructure as Code (IaC): defining infrastructure in code, enabling reproducibility, automation, and auditability of change history. Terraform is one of the most widely used tools for this.

Key features of Terraform

Multi-cloud support: not only AWS, Azure, and GCP, but also Kubernetes, GitHub, and many other providers
Declarative syntax: you declare what you want to build, and Terraform resolves dependencies automatically
State management: tracks infrastructure state in terraform.tfstate, ensuring differences between code and reality are clear
Modularization: encapsulate common setups as modules for reuse

Core building blocks

Here are the main constructs you need to understand Terraform:

Element	Role
provider	Configures the cloud or service you’ll use (e.g., AWS region, credentials)
resource	Defines the infrastructure resources (e.g., EC2, S3, VPC)
data	References existing resources
variable	Accepts values from outside Terraform
locals	Defines reusable values inside the code
module	A reusable collection of resources
output	Exposes values externally (e.g., an EC2 public IP)

Diving deeper into variable and locals

Key differences

variable
- The entry point for external input
- Accepts values from CLI flags, environment variables, or tfvars files
- Used to handle differences between environments (region, env name, instance type, etc.)
locals
- Values for reuse inside the code
- Cannot be overridden externally
- Improves readability by centralizing common tags or naming rules

Example in AWS

# variables.tf
variable "region" {
  description = "AWS region"
  type        = string
  default     = "ap-northeast-1"
}

variable "env" {
  description = "Environment name"
  type        = string
  default     = "dev"
}

# locals.tf
locals {
  common_tags = {
    Project     = "sample-app"
    Environment = var.env
  }
}

# s3.tf
provider "aws" {
  region = var.region
}

resource "aws_s3_bucket" "this" {
  bucket = "${var.env}-app-bucket"
  tags   = local.common_tags
}

👉 In this example:

region and env can be switched externally
common_tags is an internal value reused across resources

Difference from scoping in languages like JavaScript or Python

This is a common point of confusion.

In JavaScript or Python, a variable defined inside a function cannot be referenced outside of it. Terraform’s locals, however, can be referenced across files within the same module (module scope).

Referencing within a module

# locals.tf
locals {
  prefix = "demo"
}

# ec2.tf
resource "aws_instance" "this" {
  ami           = "ami-123456"
  instance_type = "t2.micro"
  tags = {
    Name = "${local.prefix}-server"
  }
}

👉 Even if the files are separate, they belong to the same module, so local.prefix is available everywhere inside that module.

Referencing across modules

However, you cannot reference locals directly from another module.

In such cases, you need to expose values via outputs.

# modules/network/locals.tf
locals {
  vpc_cidr = "10.0.0.0/16"
}

output "vpc_cidr" {
  value = local.vpc_cidr
}

# main.tf
module "network" {
  source = "./modules/network"
}

resource "aws_subnet" "this" {
  cidr_block = module.network.vpc_cidr
}

👉 Remember: locals are module-scoped, not file-scoped.

Essential Terraform commands

Command	Description
`terraform init`	Initializes the project and downloads provider plugins
`terraform plan`	Shows a preview of changes before applying
`terraform apply`	Applies the changes and builds infrastructure
`terraform destroy`	Destroys managed resources
`terraform fmt`	Formats the code
`terraform validate`	Validates syntax
`terraform output`	Displays output values
`terraform state`	Inspects and manages the state file

Example project structure (with modules)

.
├── environments
│   ├── dev
│   │   └── main.tf
│   └── prod
│       └── main.tf
└── modules
    └── nginx
        ├── main.tf
        ├── variables.tf
        └── locals.tf

environments/dev and environments/prod absorb environment-specific differences
modules/nginx encapsulates common logic
Use variable for environment-dependent values
Use locals to centralize common handling (tags, naming rules)

Best practices

Manage state files remotely (e.g., S3 with DynamoDB lock, or Terraform Cloud)
Pin provider and Terraform versions
Split modules by responsibility for clarity
Centralize naming/tagging rules with locals
Automate terraform fmt, validate, and plan checks in CI/CD

Conclusion

Terraform is a powerful tool for managing infrastructure as code
variable is the entry point for external input
locals centralizes shared internal values
Scoping is module-level: accessible across files within a module, but requires outputs when crossing module boundaries
Unlike JavaScript’s function scope, Terraform’s locals follow module scope, which makes reuse across files easier

✅ Would you like me to also make this “polished blog-ready version” with a more natural, engaging tone (like for Medium/Zenn) — or keep it as a straightforward technical translation?

Understand React Hooks the Right Way: From Basics to Bug Prevention & Design Decisions

Learcise — Sat, 20 Sep 2025 03:13:48 +0000

0. Introduction

React Hooks are a way to manage state and lifecycle without classes (since 16.8).

Simpler than class syntax
Easier to reuse logic (custom hooks)
Easier to test

👉 Goals of this article:

Beginners: Use useState / useEffect correctly
Intermediate: Understand render/commit, stale closures, and re-renders caused by function props to make sound design decisions

1. Visualize Render vs. Commit

Render: React calls your component function to produce virtual DOM.
Commit: The diff is applied to the real DOM.

👉 The component function is invoked by React itself—internally as part of the lifecycle, not by your code directly.

2. Core Hooks

2-1. useState

const [user, setUser] = useState({ name: "Taro", age: 20 });

// ❌ setUser replaces the whole state
setUser({ age: 21 });
// => { age: 21 } (name is gone)

// ✅ Spread to keep the rest
setUser(prev => ({ ...prev, age: 21 }));

useState — Key Points

Holds state inside a component
setState replaces the value (no partial merge)
Updates are async; prefer the functional updater when you need the latest value
Use it for data that should be reflected in the UI

2-2. useEffect

useEffect(() => {
  const id = setInterval(() => console.log("tick"), 1000);
  return () => clearInterval(id);
}, []);

useEffect — Key Points

Runs side effects after render
Control when it runs with the dependency array
Return a cleanup function to release resources
Great for async calls, subscriptions, DOM operations, etc.

2-3. useContext

const ThemeContext = createContext("light");
const theme = useContext(ThemeContext);

useContext — Key Points

Share values with descendants without prop drilling
When the value changes, all consumers re-render
Handy for global settings (theme, auth info, etc.)
For large-scale state, consider Redux or Zustand

3. Effect Dependencies, Stale Closures, and Solving Them with useRef

What is a stale closure?

Function components create a new function scope on every render.
As a result, callbacks that captured variables at render time may keep reading old values—that’s a stale closure.

❌ Bug caused by a stale closure

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

  function tick() {
    // ❌ 'count' may be stale here
    setCount(count + 1);
  }

  useEffect(() => {
    const id = setInterval(tick, 1000);
    return () => clearInterval(id);
  }, []); // 'tick' not in deps
}

👉 tick keeps referring to the initial count, so it never increments beyond 0.

✅ Avoid it with a functional update

useEffect(() => {
  const id = setInterval(() => {
    setCount(c => c + 1); // ✅ always uses the latest value
  }, 1000);
  return () => clearInterval(id);
}, []);

✅ Avoid it with useRef

function Timer() {
  const [count, setCount] = useState(0);
  const countRef = useRef(0);

  useEffect(() => {
    const id = setInterval(() => {
      countRef.current += 1;
      setCount(countRef.current);
    }, 1000);
    return () => clearInterval(id);
  }, []);
}

useRef — Key Points

Holds a mutable value in .current
Updating it does not trigger a re-render
Also used for DOM element refs
Prevents stale closures by always reading the latest value
Great for values not needed in the UI or temporary values

4. useCallback and Re-renders Caused by “Functions Are Objects”

What happens when passing a function to a child?

The parent re-renders.
The parent’s function definition runs again, creating a new function object.
The child sees a new prop reference.
The child re-renders.

👉 If the child is heavy, unnecessary re-renders make the UI feel sluggish.

In JS, functions are objects

function a() {}
function b() {}
console.log(a === b); // false

→ A newly created function is a different object each time.

✅ Optimize with useCallback + React.memo

const Child = React.memo(({ onClick }) => {
  console.log("Child render");
  return <button onClick={onClick}>Click</button>;
});

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

  const handleClick = useCallback(() => {
    setCount(c => c + 1);
  }, []);

  return <Child onClick={handleClick} />;
}

useCallback — Key Points

Memoizes a function so its reference stays stable
Prevents unnecessary child re-renders when passing callbacks
Stabilizes functions used inside useEffect dependency arrays
Works best together with React.memo

5. useEffect × useReducer: Handling Function Dependencies & Multi-step State

Function dependency example

function Child({ onData }) {
  useEffect(() => {
    const id = setInterval(() => {
      onData(new Date().toLocaleTimeString());
    }, 1000);
    return () => clearInterval(id);
  }, [onData]); // include the function dependency
}

👉 In the parent, use useCallback to stabilize onData.

Multi-step transitions with useReducer

const initialState = { status: "idle", data: null, error: null };

function reducer(state, action) {
  switch (action.type) {
    case "FETCH_START":   return { status: "loading", data: null, error: null };
    case "FETCH_SUCCESS": return { status: "success", data: action.payload, error: null };
    case "FETCH_ERROR":   return { status: "error", data: null, error: action.error };
    default:              return state;
  }
}

useReducer — Key Points

Great for complex, multi-step state transitions
Name actions to clarify logic
Often dispatch from inside useEffect
Ideal for forms, data fetching, step flows
Frequently combined with function dependencies

6. Custom Hooks

function useWindowWidth() {
  const [width, setWidth] = useState(window.innerWidth);

  useEffect(() => {
    const handler = () => setWidth(window.innerWidth);
    window.addEventListener("resize", handler);
    return () => window.removeEventListener("resize", handler);
  }, []);

  return width;
}

Custom Hooks — Key Points

Combine multiple hooks to build reusable logic
Must be named starting with use
Extract UI-agnostic logic for reuse
Perfect for common tasks (window size, fetching, auth checks)

7. Hooks Summary Table

Hook	Primary Use	Caveats / Pitfalls
useState	Simple state management	`setState` replaces the value. Spread objects yourself when updating.
useEffect	Side effects (fetching, subscriptions, DOM)	Wrong deps cause stale closures or infinite loops.
useContext	Avoid prop drilling	Value changes re-render all consumers.
useRef	DOM refs / non-UI mutable values	Updates don’t re-render. Useful against stale closures.
useCallback	Memoize functions / stable props	Functions are objects; new ones re-render children. Use with `React.memo`.
useReducer	Complex state (multi-step transitions)	More setup (actions), but clearer and more readable state.
Custom Hooks	Share & reuse logic	Must start with `use`. Best for UI-agnostic, reusable behavior.

📌 How to choose

Small features → useState + useEffect
Global shared values → useContext
Perf issues from prop functions → useCallback + React.memo
Complex flows → useReducer
Reusable logic → Custom hooks

Next.js App Router Deep Dive: Evolution from Pages Router and Its Latest Features

Learcise — Fri, 19 Sep 2025 01:13:04 +0000

Introduced as stable in Next.js 13.4, the App Router represents a major leap forward compared to the traditional Pages Router. Built on React Server Components (RSC), this new architecture enhances performance, enables more complex UI patterns, and completely refreshes the developer experience.

In this article, we’ll cover a comparison between Pages Router and App Router, file conventions, Suspense and Streaming, Parallel Routes and Intercepting Routes, the <Link> component, and middleware—all the practical points you should know.

1. Comparison: Pages Router vs App Router

Let’s start by comparing the legacy Pages Router with the new App Router to get the big picture.

Feature	Pages Router	App Router
Directory	`pages/`	`app/`
Component Type	Client Components by default	Server Components by default (`use client` to switch)
Data Fetching	`getStaticProps` / `getServerSideProps`	Direct `fetch` calls on the server
Layouts	`_app.tsx` / `_document.tsx`	`layout.tsx` (nested layouts supported)
Routing	Flat, file-based	Folder hierarchy-based, supports Route Groups
Delayed UI	Manual implementation	`Suspense` + `loading.tsx` + Streaming
Error Handling	`_error.tsx` / `404.tsx`	`error.tsx` / `not-found.tsx`
API Routes	`pages/api/*.ts`	`route.ts`
Complex UI / Modals	Implemented with state logic and conditions	Officially supported with Parallel Routes / Intercepting Routes
SEO / Metadata	`next/head`	`metadata` API with type safety

👉 App Router evolves toward clear separation of responsibilities and official support for complex UI patterns.

2. App Router File Conventions

In App Router, placing special files inside the app/ directory defines routing and UI behavior.

File	Purpose
`page.tsx`	The main page component, mapped to the URL.
`layout.tsx`	Shared layout. Nested and persistent across page transitions.
`template.tsx`	Similar to `layout.tsx` but re-mounts on navigation (e.g., resets forms).
`loading.tsx`	Loading UI during data fetching. Works with Suspense automatically.
`error.tsx`	Error boundary for the route.
`not-found.tsx`	Custom 404 UI for the route.
`route.ts`	Defines API routes by exporting functions for HTTP methods.
`default.tsx`	Default UI for Parallel Routes when nothing is selected.
`(group)` directory	Grouping for organizational purposes without affecting the URL.
`[param]` directory	Dynamic routes, e.g., `/users/[id]`.

👉 The ability to separate loading, error, and not-found handling per route is a huge step forward in clarity and maintainability.

3. Suspense and Streaming

Suspense

<Suspense> displays a fallback UI while data is being fetched or components are being lazily loaded.

<Suspense fallback={<p>Loading comments...</p>}>
  <Comments />
</Suspense>

👉 While fetching, it shows “Loading comments...,” then seamlessly swaps in the final UI when ready.

Streaming

Streaming sends HTML to the client as soon as each part is ready, rather than waiting for the entire page.

This eliminates the dreaded “blank screen wait,” leading to a much smoother UX.

4. Parallel Routes and Intercepting Routes

Parallel Routes

Allows rendering multiple routes simultaneously.

Example: In an email app, render “inbox” and “details” side by side.

// layout.tsx
export default function Layout({ inbox, detail }: { inbox: React.ReactNode, detail: React.ReactNode }) {
  return (
    <div className="grid grid-cols-2">
      <div>{inbox}</div>
      <div>{detail}</div>
    </div>
  );
}

Intercepting Routes

Intercepts navigation and replaces it with an alternative view, such as a modal.

Example: Show a product detail page inside a modal when clicked.

👉 This combines SPA-style modal navigation with full-page rendering when accessed directly.

5. `<Link>` Component and Prefetching

The <Link> component enables fast client-side navigation in Next.js.

How It Works

When a <Link> enters the viewport, Next.js prefetches the resources for the target page.
On click, the preloaded resources are used instantly.
Page navigation completes nearly instantly.

👉 Thanks to prefetching, navigation feels like instant page switching.

6. Middleware

Overview

middleware.ts runs immediately after a request reaches the server, before rendering a page or API route.

Common Use Cases

Authentication check: Redirect unauthenticated users to /login.
Locale detection: Redirect based on Accept-Language headers.
A/B testing: Split traffic between variants.
Access control: Block requests based on IP or user-agent.

Example

import { NextResponse } from "next/server";
import type { NextRequest } from "next/server";

export function middleware(request: NextRequest) {
  const token = request.cookies.get("token");

  if (!token && request.nextUrl.pathname.startsWith("/dashboard")) {
    return NextResponse.redirect(new URL("/login", request.url));
  }

  return NextResponse.next();
}

export const config = {
  matcher: ["/dashboard/:path*"],
};

👉 This lets you enforce authentication and redirects before any page logic runs.

Conclusion

App Router advancements
- Nested layouts, clearer file conventions, and Streaming/Suspense for improved UX.
- Complex UI officially supported with Parallel Routes and Intercepting Routes.
<Link> advantages
- Prefetching enables instant-feeling client-side navigation.
Middleware power
- Perform auth checks, redirects, and locale detection right after the request arrives.

👉 For new projects, App Router is strongly recommended. For existing projects, migrate step by step to avoid risks.

References

Why Does a Small Reorder Require Massive Updates? Fix It with LexoRank

Learcise — Thu, 18 Sep 2025 13:08:50 +0000

“Why do I have to update tens of thousands of rows every time, when all I want is to reorder tasks a little?” — Are you tired of this kind of database design?

Many developers initially choose the simple method of assigning sequence numbers (1,2,3…) to each item. However, as the system grows, this approach runs into serious problems. In this article, we’ll look at those limitations and introduce LexoRank, the solution used in Atlassian’s Jira.

💡 Who benefits from this?

Developers managing ordering in a database
People building their own task management or backlog systems
Anyone who has suffered through the “renumbering hell” of order management

😵 Limitations of the sequence number approach

1. The renumbering nightmare

Every time you insert a new element in the middle of the list, you have to update all subsequent elements.

Example:

[1: Requirements] [2: Design] [3: Implementation] [4: Testing]

Insert “Review” between Design and Implementation…

[1: Requirements] [2: Design] [3: Review] [4: Implementation] [5: Testing]

All items after Implementation must be updated. With tens of thousands of rows, this becomes extremely costly.

2. Performance degradation

In lists with thousands or tens of thousands of items, running hundreds or thousands of UPDATEs each time quickly overwhelms database performance. For systems like task management or backlogs, where reordering is frequent, this is fatal.

3. Concurrency conflicts

When multiple users reorder simultaneously, the sequence can break. If you tighten locks, scalability suffers; loosen them, and consistency suffers. Either way, you lose.

4. Lack of flexibility

A simple operation like “insert between item 2 and 3” can’t be expressed with integers. Using decimals (e.g., 2.5, 2.25, 2.125…) works temporarily, but precision quickly breaks down.

🚧 What happens as a result

Data updates become too slow
User experience becomes unstable
Database design grows more complex and harder to maintain

The sequence number approach feels intuitive, but it doesn’t scale to large datasets or frequent reordering.

✨ The savior: LexoRank

Enter LexoRank, the system used in Atlassian Jira.

Jira uses LexoRank to solve exactly these problems. The name “LexoRank” comes from two parts:

Lexo — short for lexicographical, meaning dictionary/alphabetical ordering
Rank — the order or ranking of items

What is LexoRank?

In LexoRank, each item is assigned a rank value represented as an alphanumeric string. When the order of items changes, the rank value is updated to be larger than the previous item and smaller than the next one.

Example with real data

Suppose you have:

[Task A: rank=aaa]
[Task B: rank=ccc]

If you want to insert “Task X” between them, the sequence number approach would require mass updates. With LexoRank, you just compute a middle value:

[Task A: rank=aaa]
[Task X: rank=bbb]
[Task B: rank=ccc]

No need to update everything else — only the new item is added.

Rebalancing example

However, if you keep inserting — “aaa”, “aab”, “aac”… — eventually you run out of space for middle values. At that point, rebalancing occurs.

Example:

[Task A: rank=aaa]
[Task B: rank=aab]
[Task C: rank=aac]
[Task D: rank=aad]
...

When all values starting with “a” are filled, LexoRank reorganizes everything to create wider gaps.

After rebalancing:

[Task A: rank=aaa]
[Task B: rank=gaa]
[Task C: rank=maa]
[Task D: rank=taa]

This restores plenty of space for future insertions and keeps ordering stable.

Conclusion

If you’re stuck thinking, “I just want to reorder a little, but every time I have to update tens of thousands of rows…”, it’s time to adopt the LexoRank approach. It frees you from renumbering hell and gives you scalable, reliable order management.

Updating But Not Reflecting!? React’s Common State 'Stale Closure' Pitfall

Learcise — Sat, 13 Sep 2025 00:04:27 +0000

Have You Ever Experienced This When Using React?

You call setState, but inside an event handler the value is still old
Inside a setInterval, reading state always gives you the initial value
“It should be updating, but nothing changes!”

One culprit behind this is the stale closure problem.

In this article, we’ll cover:

Basics of scope and closures
Why stale closures happen in React
Typical examples where it occurs
Ways to fix it
The role of useRef

1. A Refresher on Scope and Closures

What Is Scope?

Scope is “the range where a variable lives.”

For example, variables created inside a function cannot be accessed from outside.

function foo() {
  const x = 10;
  console.log(x); // 10
}
foo();

console.log(x); // ❌ Error: x doesn’t exist here

What Is a Closure?

A closure is “the mechanism where a function remembers the variables from the environment in which it was created.”

function outer() {
  const message = "Hello";

  function inner() {
    console.log(message);
  }

  return inner;
}

const fn = outer();
fn(); // "Hello"

Normally, when outer finishes, message should disappear.

But since inner remembers the scope at the time it was created, it can still access message.

Think of a function as a time capsule carrying a box of variables from the moment it was created.

2. Why Stale Closures Happen in React

React components are functions, so a new scope is created on every render.

For example:

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

  useEffect(() => {
    const id = setInterval(() => {
      console.log("count:", count); // ← stays 0 forever
    }, 1000);
    return () => clearInterval(id);
  }, []);

  return <button onClick={() => setCount(c => c + 1)}>+1</button>;
}

Clicking the button updates count
But inside setInterval, count remains the initial 0

That’s because the closure created in useEffect([]) holds onto the initial scope forever.

In other words, you’re stuck with a stale closure — a closure trapped with old scope.

3. Common Scenarios Where It Happens

Callbacks for setInterval / setTimeout
Loops with requestAnimationFrame
Event handlers from WebSocket or addEventListener
Async callbacks (then, async/await) reading state

The common theme: a function registered once keeps living for a long time.

4. How to Fix It

① Specify Dependencies Correctly

The simplest fix is to include state in the dependency array of useEffect.

useEffect(() => {
  const id = setInterval(() => {
    console.log("count:", count); // always the latest value
  }, 1000);
  return () => clearInterval(id);
}, [count]);

But beware: the effect re-subscribes on every change, which may affect performance or resource management.

② Use Functional setState

For state updates, you can use the functional form of setState, which always receives the latest value regardless of closures.

setCount(prev => prev + 1);

This avoids stale closures and is the safest pattern.

③ Use `useRef` (a powerful stale closure workaround)

Here’s where useRef shines.

5. How `useRef` Helps Avoid Stale Closures

What Is useRef?

useRef creates a box that persists across renders.

const ref = useRef(0);

ref.current = 123;
console.log(ref.current); // 123

Store values in ref.current
Updating it does not trigger re-renders
Useful not only for DOM refs, but also for persisting variables

Example: Fixing a Stale Closure

function Counter() {
  const [count, setCount] = useState(0);
  const countRef = useRef(count);

  // Mirror latest count into ref
  useEffect(() => {
    countRef.current = count;
  }, [count]);

  useEffect(() => {
    const id = setInterval(() => {
      console.log("Latest count:", countRef.current); // always up to date
    }, 1000);
    return () => clearInterval(id);
  }, []);

  return <button onClick={() => setCount(c => c + 1)}>+1</button>;
}

Inside setInterval, read countRef.current
No more stale closure — always the latest value

Advanced: Storing Functions in useRef

You can also store functions inside a ref to always call the latest logic.

const callbackRef = useRef<(val: number) => void>(() => {});

useEffect(() => {
  callbackRef.current = (val: number) => {
    console.log("Latest count:", count, "val:", val);
  };
}, [count]);

// Example: called from external events
socket.on("message", (val) => {
  callbackRef.current(val);
});

6. Summary

Closures remember the scope from when the function was created
Stale closures are closures stuck with old scope
In React, they often show up in intervals, event handlers, async callbacks, etc.
Solutions:
1. Correctly specify dependencies
2. Use functional setState
3. Use useRef to persist latest values or functions

👉 A stale closure is like a “time-traveling bug in React.”

A function keeps carrying an old scope into the future — and that’s why your state “doesn’t update.”

What is Shadow DOM and How It’s Used in Chrome Extensions

Learcise — Fri, 12 Sep 2025 02:22:07 +0000

Introduction

If you’ve done any web development, you’ve probably come across the term “Shadow DOM.”

Shadow DOM is one of the core technologies behind Web Components. It provides a mechanism to encapsulate DOM structure and styles, isolating them from the rest of the page.

In this article, we’ll go over the basics of Shadow DOM and how it can be effectively used in Chrome extensions.

What is Shadow DOM?

Basic Mechanism

Shadow DOM allows you to attach a shadow tree to a regular DOM element. This shadow tree contains its own independent DOM structure and style scope.

Shadow host: The element that owns the Shadow DOM
Shadow root: The root of the shadow tree
Shadow tree: The DOM tree inside the shadow root
Shadow boundary: The boundary between the light DOM (normal DOM) and the shadow tree

In a normal DOM, CSS and JavaScript apply globally, which makes it difficult to prevent components from interfering with one another. By introducing Shadow DOM, we gain the following advantages:

Hide internal structure from the outside
Protect against external CSS overriding internal styles
Prevent internal styles or structure from leaking outside

Styles and Events

CSS defined inside a Shadow DOM is scoped locally and won’t be affected by external styles.
By default, events do not cross the shadow boundary. If you want them to propagate outside, you need to set composed: true.

Chrome Extensions and Shadow DOM

In Chrome extensions, content scripts often inject DOM elements or UI directly into web pages. For example, you might want to place a custom button at the bottom-right corner of the page.

However, this approach leads to common issues:

Page CSS breaks the extension’s UI
Conflicts with existing class names or IDs defined in the extension
Interference between page scripts/events and the extension’s UI

Shadow DOM is a powerful solution to these problems.

Benefits of Using Shadow DOM in Chrome Extensions

Prevent CSS Pollution

The page’s styles won’t affect the extension’s UI, and vice versa.
Avoid DOM Conflicts

Even if the same class names or IDs are used, they won’t collide.
Improve UI Stability

Frameworks like React, Vue, or Chakra UI can run inside Shadow DOM without being disrupted by page-specific CSS.

Technical Implementation Points

Let’s walk through the basic flow of using Shadow DOM in a Chrome extension.

1. Creating a Shadow Root

const host = document.createElement('div');
host.id = 'my-extension-shadow-host';
document.body.appendChild(host);

const shadowRoot = host.attachShadow({ mode: 'open' });

Using open mode makes debugging easier during development.
Using closed mode increases isolation but also restricts access.

2. Applying Styles

const styleEl = document.createElement('style');
styleEl.textContent = `
  :host {
    all: initial;
    font-family: Arial, sans-serif;
    display: block;
    position: fixed;
    bottom: 20px;
    right: 20px;
    z-index: 999999;
  }
  button {
    padding: 8px 12px;
    font-size: 14px;
  }
`;
shadowRoot.appendChild(styleEl);

all: initial; ensures the extension’s UI won’t be affected by the page’s reset CSS.
If you’re using a UI library, import its styles into the shadow root as needed.

3. Adding UI Elements

const button = document.createElement('button');
button.textContent = 'My Button';
shadowRoot.appendChild(button);

Conclusion

Shadow DOM provides a mechanism to encapsulate DOM structure and styles
In Chrome extensions, it’s very effective at protecting UI from interference by the page
When implementing, pay attention to attachShadow, all: initial, and event propagation handling

By understanding Shadow DOM, you can make your Chrome extension UI much more stable and maintainable. If you’re developing extensions, it’s definitely worth adopting.

What is Blue/Green Deployment?

Learcise — Wed, 10 Sep 2025 12:24:40 +0000

1. Introduction

In system releases, minimizing downtime—ideally bringing it down to zero—has always been a never-ending challenge for engineers. If users experience downtime, it directly impacts both revenue and trust.

One approach to solving this problem is Blue-Green Deployment.

In this article, we will first go over the basics of Blue-Green Deployment and examine the differences between its application to applications versus databases. Then, we will look at AWS RDS Blue/Green Deployment, explaining in detail how it works, including the role of binlogs (binary logs) and cost considerations.

2. What is Blue-Green Deployment?

Blue-Green Deployment is a release strategy that runs two production environments in parallel and switches traffic between them to swap the old and new versions. The existing environment is called “Blue,” while the new version is called “Green.”

You deploy your application to the Green environment and test it under production-like conditions. If no issues are found, you switch traffic from Blue to Green. If a problem arises, you can simply switch back to Blue, allowing for a safe release without impacting users.

The strategy has some major benefits:

No downtime during release
Immediate rollback in case of issues
Ability to test in a production-equivalent environment

However, since two environments must be maintained, costs increase. Moreover, for stateful systems such as databases, keeping both environments perfectly synchronized is a major challenge.

3. Implementation in Applications

At the application layer, Blue-Green Deployment is relatively simple to implement.

On AWS, a common method is switching target groups on an ALB (Application Load Balancer), or updating DNS records using Route 53. In Kubernetes, switching Service labels or updating Ingress resources achieves the same effect.

Furthermore, combining with CI/CD tools allows for automation of the entire process: deployment to Green, testing, and traffic switching. With GitHub Actions or AWS CodePipeline, release workflows can be streamlined while reducing risk.

4. Challenges in Databases

Things become more complicated with databases. A database is a stateful system, so simply cloning the environment is not enough—synchronization must be maintained. For example, if a user registers in the Blue environment, that change must also be reflected in Green. Otherwise, switching traffic would risk losing data.

Traditionally, the following approaches have been used:

Manual binary log replication: flexible, but complex to operate
RDS Read Replicas: simple, but limited in scope
AWS DMS: supports heterogeneous DB migrations, but complicated to set up

All of these approaches have limitations, particularly when aiming for truly zero downtime.

5. How RDS Blue/Green Deployment Works

AWS RDS Blue/Green Deployment is a managed service designed to solve these challenges. It automatically creates a Green clone of the Blue environment and maintains synchronization through logical replication using binary logs (binlogs).

What is a binlog?

A binlog is a log of data change operations maintained by MySQL-based databases. It records operations such as INSERT, UPDATE, and DELETE. Replicas read these logs and apply the same changes to their own database, ensuring the primary and replicas remain consistent.

Why is the ROW format required?

Binlogs can be written in three formats:

STATEMENT: records the SQL statements themselves
ROW: records which rows were changed and how
MIXED: a combination of the two

RDS Blue/Green Deployment requires ROW format. The reason is that STATEMENT-based logs can cause inconsistencies—for example, with SQL functions like NOW() or RAND() that may produce different results in different environments. With ROW format, each row-level change is recorded explicitly, ensuring Blue and Green environments remain perfectly synchronized.

Why costs increase

With RDS Blue/Green Deployment, an entire Green environment is spun up with the same configuration as Blue. This includes instances, storage, and Multi-AZ setups. As a result, until the switch is complete, your database costs are effectively doubled. Any release plan must account for this temporary cost increase.

6. Benefits and Limitations

This approach allows traffic switching to complete in 30–60 seconds, drastically reducing downtime. In case of failure, rolling back to Blue is immediate.

However, there are some limitations:

Destructive schema changes (such as column drops or renames) are not supported
Binlogs must be enabled in ROW format
Maintaining two environments means higher costs

7. Use Cases

RDS Blue/Green Deployment is especially useful in cases such as:

Major or minor database version upgrades
Schema extensions such as adding columns or creating indexes
Pre-release testing in a production-equivalent environment

On the other hand, it may not be suitable for scenarios involving destructive schema changes or environments with frequent small releases.

8. Conclusion

Blue-Green Deployment is a powerful strategy to achieve zero-downtime releases. While it is relatively easy to adopt for applications, databases have historically posed significant synchronization challenges.

With RDS Blue/Green Deployment, many of these challenges are greatly reduced. By leveraging binlogs for reliable replication, Blue and Green can remain in sync, enabling safe, fast switches. That said, it’s important to understand the requirements—ROW-format binlogs and temporary cost increases—and incorporate them into system design.

[Complete Guide] React Basics: From jQuery to React, Function Components, JSX, Hooks, and Re-Rendering Optimization

Learcise — Tue, 09 Sep 2025 12:39:11 +0000

When it comes to frontend development, one of the names you will always hear is React.

Today, many services and apps are built on React — but why has it become so widely adopted?

In this article, we’ll explore the evolution from jQuery to React, break down React’s fundamentals (function components, JSX, virtual DOM), and then dive into Hooks and re-rendering optimizations.

1. The Relationship Between JavaScript and React

JavaScript is the foundation for dynamic behavior on the web.

React is a JavaScript library designed to build user interfaces more efficiently.

Unlike jQuery, which directly manipulates the DOM, React provides a system to synchronize state and UI, which makes it far easier to build scalable, maintainable apps.

2. From jQuery to React

Advantages of jQuery

Simplified DOM manipulation ($("#id"))
Cross-browser compatibility
Perfect for small websites with quick effects and Ajax

Disadvantages of jQuery

Hard to manage state in large applications
Code often turns into “spaghetti” as the app grows
Performance issues due to direct DOM manipulation

Why Developers Moved to React

The rise of Single Page Applications (SPAs) required better state management
A need for reusable, component-based UI development
Virtual DOM provided faster rendering and better performance

👉 Small-scale = jQuery worked fine.

Large-scale = React became the natural choice.

3. What is React?

React (React.js) is a UI library developed by Meta (formerly Facebook).

It allows developers to build apps with a component-based architecture, making UI reusable and easier to maintain.

Advantages of React

Component-based design
Declarative UI (describe what UI should look like for a given state)
Multi-platform (e.g., React Native for mobile)
Fast rendering with Virtual DOM

Disadvantages of React

Steep learning curve (JSX, ES6, Hooks)
Initial setup can be complex (Webpack, Babel required)
Doesn’t always play well with jQuery plugins

4. What is a Function Component?

In React, UI is divided into components, reusable pieces of the interface.

There are two ways to define them: function components and class components.

Function Component

function Hello({ name }) {
  return <h1>Hello, {name}!</h1>;
}

Defined as a simple JavaScript function
Accepts props as arguments and returns JSX

Class Component

class Hello extends React.Component {
  render() {
    return <h1>Hello, {this.props.name}!</h1>;
  }
}

Differences and Today’s Standard

In the past, only class components could manage state and lifecycle methods
With Hooks, function components can now manage state too
Function components are simpler, lighter, and now the preferred standard

5. DOM vs Virtual DOM

DOM

The tree structure generated by the browser from HTML and CSS.

Direct manipulation is possible, but expensive in terms of performance.

Virtual DOM

React maintains a lightweight copy of the DOM in memory.

When updates happen, React compares the new Virtual DOM with the old one and applies only the differences to the real DOM.

👉 This makes rendering much faster.

6. JSX (JavaScript XML)

What is JSX?

JSX allows you to write HTML-like code directly inside JavaScript.

const name = "React";
const element = <h1>Hello, {name}!</h1>;

Behind the scenes, this is transformed into:

const element = React.createElement("h1", null, `Hello, ${name}!`);

JSX Features

Must return a single root element
JavaScript expressions can be embedded with {}
Attributes use camelCase (className, onClick)

Benefits of JSX

Intuitive, HTML-like syntax
Strong integration with JavaScript
Works well with IDEs and type-checking tools

7. Introduction to Hooks

Hooks allow function components to manage state and side effects.

useState (State Management)

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

Updating state triggers re-rendering of the component.

useEffect (Side Effects)

useEffect(() => {
  console.log("Runs after initial render");
}, []);

Handles effects like API calls, timers, and cleanup.

useMemo (Memoization)

const result = useMemo(() => heavyCalc(num), [num]);

Caches expensive calculations to avoid unnecessary recomputation.

useCallback & React.memo

useCallback: memoizes functions so props don’t change unnecessarily
React.memo: prevents child components from re-rendering unless props change

8. Re-Rendering and Optimization

What Re-Rendering Means

When you update state via useState, the function component runs again
React generates new JSX, compares Virtual DOM, and updates only the differences in the real DOM

Parent and Child Components

If a parent’s state updates, the parent re-renders → the child is re-evaluated too
However, if props don’t change, the actual DOM update is skipped

When to Use React.memo

✅ Expensive-to-render child components
✅ Parent re-renders often but child props rarely change
❌ Small or frequently changing components don’t benefit much

9. Conclusion

Moving from jQuery to React solved problems of state management and DOM performance
React’s core features: component-based architecture, declarative UI, virtual DOM
Function components + Hooks are the modern standard for building React apps
JSX makes UI description intuitive and tightly integrated with JavaScript
Re-rendering is unavoidable, but you can optimize it with React.memo, useMemo, and useCallback

👉 The essence of React is “synchronizing state and UI in a simple, efficient way.”

We’ve evolved from jQuery’s manual DOM manipulation to React’s declarative model, achieving cleaner, more scalable development.

If you’re comfortable with these basics, the next step is exploring React Router (for routing) and Redux or Context (for advanced state management).

DEV Community: Learcise

🧩 A Complete Guide to React Testing: From Unit Tests to E2E, Snapshots, and Test Doubles

🧠 Why Write Tests?

⚙️ The Three Layers of Testing: Unit, Integration, and E2E

🔹 Unit Tests

🔹 Integration Tests

🔹 End-to-End (E2E) Tests

🧪 The Role of Jest and React Testing Library

✅ What is Jest?

✅ What is React Testing Library?

📸 What Is a Snapshot Test?

✅ Example

⚖️ Pros and Cons

🧩 Using React Testing Library for Snapshots

🧱 Understanding Test Doubles: Mocks, Stubs, Fakes, and Dummies

🔸 What Is a Test Double?

🧩 Example: When API Responses Affect the UI

💡 Original Code

✅ Using a Test Double

🧭 Why Use Test Doubles?

🧩 Types of Test Doubles and Examples

🧩 Designing a Testing Strategy

🔺 The Testing Pyramid

🧠 Continuous Testing

🏁 Summary

Common React Anti-Patterns and How to Fix Them

1. Overusing useState and Scattering State

2. Monster Components

3. Components Doing Too Much Logic

4. Reversing Data Flow (Child Updating Parent)

5. Storing Derived State

6. Abusing useEffect for Calculations

7. Wrong key Usage

8. Forgetting Cleanup in Effects

9. Defining Components Inside Components

10. No Error Boundaries

11. Ignoring "State is a Snapshot" (Stale Closures)

12. Wrong Dependency Arrays in useEffect

Takeaways

Understanding the Browser: From DNS Resolution to DOM and Rendering

Browser Architecture and the First Communication

User Interface

Browser Engine

Networking Module

Rendering Engine

JavaScript Engine

Data Storage

Understanding the DOM

DOM = API Specification

DOM Tree = Actual Data Structure

DOM Manipulation = DOM Tree Manipulation

DOM Tree Construction Process

Rendering Engine and the DOM

Rendering Engine Responsibilities

Relationship with the DOM

Rendering Pipeline Overview

Compositing in Detail

Layering System

Why Compositing Matters

Developer Optimization Tips

JavaScript and Rendering

Reflow (Layout recalculation)

Repaint (Redraw)

Composite-only

Performance Optimization Tips

Conclusion

Introduction to Prisma: An ORM for Type-Safe and Efficient Database Operations

2. Benefits of Prisma

Type-Safe & Auto-Completion

Automatic Migrations

Broad Database Support

3. Key Components to Understand Before Starting with Prisma

Installation Flow

4. Practical Example: Using Prisma with Next.js (TypeScript)

Database Connection

Seeding Initial Data

Prisma Studio

5. Efficient Database Design and Migrations

Example Model Definition

6. Conclusion

1. Overusing `useState` and Scattering State

6. Abusing `useEffect` for Calculations

7. Wrong `key` Usage

12. Wrong Dependency Arrays in `useEffect`

5. `<Link>` Component and Prefetching