DEV Community: Kushang Tailor

React in Production — Ship It, Monitor It, Sleep at Night

Kushang Tailor — Tue, 23 Jun 2026 04:06:58 +0000

Read Time: ~15 minutes | The gap between "it works on my machine" and "it works for everyone, always"

Prerequisites: The full React Mastery Series — Parts 1–5

Part 6: The Finale 🎉

📌 What You'll Learn

By the end of this guide, you'll be able to:

✅ Implement authentication with JWT and session cookies
✅ Add OAuth (Google / GitHub login) in minutes
✅ Set up CI/CD with GitHub Actions to automate your deployments
✅ Catch and monitor errors in production with Sentry
✅ Protect routes and handle auth state globally
✅ Avoid the most common production mistakes React developers make
✅ Understand what "production-ready" actually means in practice

🏁 You Made It Here — Now What?

Five articles in, you can build fast, well-structured, testable React apps. You know your hooks, your state patterns, your performance levers, and your Next.js data flows.

What you haven't done yet is ship something real, break it, watch it burn, and fix it gracefully — that's what production is.

This final part covers the things that separate a side project from a product people actually rely on: authentication that doesn't embarrass you, a CI/CD pipeline that ships your code automatically, and error monitoring that tells you something broke before your users do.

🔐 Authentication: JWT vs Session Cookies

Authentication is one of those topics where developers either overcomplicate it or cut too many corners. Let's get the fundamentals right first.

The Two Main Approaches

JWT (JSON Web Token)
└─ Token stored on client (localStorage or cookie)
└─ Server is stateless — doesn't store sessions
└─ Fast to verify (no DB lookup per request)
└─ Hard to invalidate before expiry (logout is tricky)

Session Cookies
└─ Session ID stored in an httpOnly cookie
└─ Session data lives on the server (DB or cache)
└─ Easy to invalidate (delete the session record)
└─ Requires DB lookup on every authenticated request

Recommendation for most apps: session cookies with httpOnly — more secure by default, easier logout, slightly more setup.

JWT makes sense when: you have multiple services that need to verify auth without sharing a database (microservices, third-party APIs).

Building JWT Auth in Next.js

Install dependencies:

npm install jsonwebtoken bcryptjs
npm install --save-dev @types/jsonwebtoken @types/bcryptjs

Step 1 — User login API route:

// app/api/auth/login/route.ts
import { NextRequest, NextResponse } from 'next/server';
import jwt from 'jsonwebtoken';
import bcrypt from 'bcryptjs';

const JWT_SECRET = process.env.JWT_SECRET!;

export async function POST(request: NextRequest) {
  const { email, password } = await request.json();

  // 1. Find user in database
  const user = await db.users.findUnique({ where: { email } });

  if (!user) {
    return NextResponse.json({ error: 'Invalid credentials' }, { status: 401 });
  }

  // 2. Compare hashed password
  const isValid = await bcrypt.compare(password, user.passwordHash);

  if (!isValid) {
    return NextResponse.json({ error: 'Invalid credentials' }, { status: 401 });
  }

  // 3. Create token (expires in 7 days)
  const token = jwt.sign(
    { userId: user.id, email: user.email },
    JWT_SECRET,
    { expiresIn: '7d' }
  );

  // 4. Set token in httpOnly cookie (safer than localStorage)
  const response = NextResponse.json({ success: true });
  response.cookies.set('auth-token', token, {
    httpOnly: true,   // JS can't read this cookie
    secure: true,     // HTTPS only
    sameSite: 'lax',  // CSRF protection
    maxAge: 60 * 60 * 24 * 7, // 7 days in seconds
  });

  return response;
}

Step 2 — Verify token in middleware:

// middleware.ts (runs before every request)
import { NextRequest, NextResponse } from 'next/server';
import { jwtVerify } from 'jose'; // jose works in Edge runtime; jsonwebtoken doesn't

const JWT_SECRET = new TextEncoder().encode(process.env.JWT_SECRET!);

export async function middleware(request: NextRequest) {
  const token = request.cookies.get('auth-token')?.value;

  // Protect /dashboard and all routes under it
  if (request.nextUrl.pathname.startsWith('/dashboard')) {
    if (!token) {
      return NextResponse.redirect(new URL('/login', request.url));
    }

    try {
      await jwtVerify(token, JWT_SECRET);
      return NextResponse.next(); // Token valid — let the request through
    } catch {
      // Token invalid or expired
      const response = NextResponse.redirect(new URL('/login', request.url));
      response.cookies.delete('auth-token');
      return response;
    }
  }

  return NextResponse.next();
}

export const config = {
  matcher: ['/dashboard/:path*'], // Only run middleware on these routes
};

Step 3 — Logout:

// app/api/auth/logout/route.ts
import { NextResponse } from 'next/server';

export async function POST() {
  const response = NextResponse.json({ success: true });
  response.cookies.delete('auth-token');
  return response;
}

🌐 OAuth: Google & GitHub Login in Minutes

OAuth is the "Sign in with Google" button your users already expect. In Next.js, NextAuth.js (Auth.js v5) handles the entire OAuth dance for you.

npm install next-auth@beta

Configure Auth.js:

// auth.ts (project root)
import NextAuth from 'next-auth';
import Google from 'next-auth/providers/google';
import GitHub from 'next-auth/providers/github';

export const { handlers, auth, signIn, signOut } = NextAuth({
  providers: [
    Google({
      clientId: process.env.GOOGLE_CLIENT_ID!,
      clientSecret: process.env.GOOGLE_CLIENT_SECRET!,
    }),
    GitHub({
      clientId: process.env.GITHUB_CLIENT_ID!,
      clientSecret: process.env.GITHUB_CLIENT_SECRET!,
    }),
  ],
  callbacks: {
    // Add custom data to the session
    session({ session, token }) {
      if (session.user && token.sub) {
        session.user.id = token.sub;
      }
      return session;
    },
  },
});

Mount the handler:

// app/api/auth/[...nextauth]/route.ts
import { handlers } from '@/auth';
export const { GET, POST } = handlers;

Protect a page with the session:

// app/dashboard/page.tsx
import { auth } from '@/auth';
import { redirect } from 'next/navigation';

export default async function DashboardPage() {
  const session = await auth();

  if (!session) {
    redirect('/login'); // Not signed in — send them away
  }

  return (
    <div>
      <h1>Welcome, {session.user?.name}</h1>
      <p>Logged in as {session.user?.email}</p>
    </div>
  );
}

Sign in / sign out buttons:

'use client';
import { signIn, signOut } from 'next-auth/react';

export function AuthButtons() {
  return (
    <div>
      <button onClick={() => signIn('google')}>Sign in with Google</button>
      <button onClick={() => signIn('github')}>Sign in with GitHub</button>
      <button onClick={() => signOut()}>Sign Out</button>
    </div>
  );
}

Add GOOGLE_CLIENT_ID, GOOGLE_CLIENT_SECRET, GITHUB_CLIENT_ID, GITHUB_CLIENT_SECRET, and NEXTAUTH_SECRET to your .env.local, and you have fully working social login.

🔄 CI/CD with GitHub Actions

Shipping manually is how bugs reach production. A CI/CD pipeline runs your tests, checks your build, and deploys automatically — every single time you push code.

What the Pipeline Does

Developer pushes code to GitHub
         ↓
GitHub Actions triggers automatically
         ↓
Install dependencies
         ↓
Run linter (ESLint)
         ↓
Run type checker (TypeScript)
         ↓
Run test suite (Jest)
         ↓
Build the app
         ↓
If all green → Deploy to Vercel ✅
If any red   → Block deploy, notify developer ❌

Full GitHub Actions Workflow

# .github/workflows/ci.yml

name: CI / CD Pipeline

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  quality:
    name: Lint, Type Check & Test
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Run ESLint
        run: npm run lint

      - name: Run TypeScript check
        run: npx tsc --noEmit

      - name: Run tests
        run: npm test -- --coverage --watchAll=false
        env:
          CI: true

      - name: Build app
        run: npm run build
        env:
          NEXT_PUBLIC_API_URL: ${{ secrets.NEXT_PUBLIC_API_URL }}

  deploy:
    name: Deploy to Vercel
    needs: quality          # Only runs if the quality job passes
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main' # Only deploy from main branch

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Deploy to Vercel
        uses: amondnet/vercel-action@v25
        with:
          vercel-token: ${{ secrets.VERCEL_TOKEN }}
          vercel-org-id: ${{ secrets.VERCEL_ORG_ID }}
          vercel-project-id: ${{ secrets.VERCEL_PROJECT_ID }}
          vercel-args: '--prod'

Add VERCEL_TOKEN, VERCEL_ORG_ID, and VERCEL_PROJECT_ID to your GitHub repository's Secrets (Settings → Secrets and variables → Actions). Get the token from Vercel's dashboard.

Now every pull request runs the full quality check. Only clean, tested, built code reaches production.

🚨 Error Monitoring with Sentry

Tests catch bugs before users see them. Sentry catches the ones that slip through anyway — and tells you exactly where, why, and how often.

Setup

npm install @sentry/nextjs
npx @sentry/wizard@latest -i nextjs

The wizard creates sentry.client.config.ts, sentry.server.config.ts, and sentry.edge.config.ts automatically. You just need your DSN from the Sentry dashboard.

sentry.client.config.ts:

import * as Sentry from '@sentry/nextjs';

Sentry.init({
  dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
  tracesSampleRate: 0.1,     // Capture 10% of transactions for performance
  replaysSessionSampleRate: 0.1,
  replaysOnErrorSampleRate: 1.0, // Always capture replay when there's an error
  environment: process.env.NODE_ENV,
});

Capturing Errors Manually

import * as Sentry from '@sentry/nextjs';

async function processPayment(orderId: string) {
  try {
    const result = await paymentGateway.charge(orderId);
    return result;
  } catch (error) {
    // Send to Sentry with context
    Sentry.captureException(error, {
      tags: { component: 'checkout', action: 'processPayment' },
      extra: { orderId },
    });
    throw error; // Re-throw — don't silently swallow it
  }
}

Setting User Context

After login, tell Sentry who the user is — errors become instantly attributable:

import * as Sentry from '@sentry/nextjs';

function onLoginSuccess(user: User) {
  Sentry.setUser({
    id: user.id,
    email: user.email,
    username: user.name,
  });
}

function onLogout() {
  Sentry.setUser(null); // Clear on logout
}

Now when an error hits Sentry, you see exactly which user experienced it, what they were doing, and the full stack trace — no guessing.

🗂️ Production Environment Variables

Your app has three environments, and each needs its own config:

# .env.local (development — never commit this)
DATABASE_URL=postgresql://localhost:5432/myapp_dev
NEXT_PUBLIC_API_URL=http://localhost:3000
JWT_SECRET=dev-secret-not-for-production

# Vercel → Project Settings → Environment Variables → Preview
DATABASE_URL=postgresql://host/myapp_staging
NEXT_PUBLIC_API_URL=https://staging.myapp.com
JWT_SECRET=staging-secret-32-chars-minimum

# Vercel → Project Settings → Environment Variables → Production
DATABASE_URL=postgresql://host/myapp_prod
NEXT_PUBLIC_API_URL=https://myapp.com
JWT_SECRET=prod-secret-64-chars-cryptographically-random

Rules to live by:

// ✅ NEXT_PUBLIC_ prefix = visible in the browser (safe for public URLs)
const apiUrl = process.env.NEXT_PUBLIC_API_URL;

// ✅ No prefix = server-only (safe for secrets, DB URLs, API keys)
const dbUrl = process.env.DATABASE_URL;

// ❌ Never put secrets in NEXT_PUBLIC_ variables
// ❌ Never commit .env.local to Git (add it to .gitignore)
// ❌ Never hardcode secrets — even "temporarily"

🧱 Production-Ready Checklist

Before you consider any app production-ready, run through this honestly:

Security

□ All auth routes protected by middleware
□ Passwords hashed with bcrypt (never stored plain)
□ httpOnly cookies used (not localStorage for tokens)
□ Environment variables never committed to Git
□ API routes validate and sanitize all input
□ Rate limiting on login and sensitive endpoints
□ HTTPS enforced (Vercel does this automatically)

Reliability

□ Error Boundaries wrap independent UI sections
□ Sentry (or equivalent) capturing all unhandled errors
□ API routes return meaningful error messages + HTTP codes
□ Loading and error states handled in every data component
□ CI pipeline blocks deploys when tests fail

Performance

□ Images use next/image (WebP, lazy loading, no CLS)
□ Fonts loaded via next/font (no layout shift)
□ Route-based code splitting in place
□ No console.log left in production code
□ Largest Contentful Paint (LCP) < 2.5s

Observability

□ Error monitoring active (Sentry)
□ Performance monitoring configured
□ Structured logging in API routes
□ Alerts set up for error spikes

💣 Production Mistakes Worth Learning From

These are real patterns that get real apps in trouble — most of them avoidable with about 20 minutes of setup.

Mistake 1: Storing tokens in localStorage

// ❌ XSS attack can steal this
localStorage.setItem('token', jwtToken);

// ✅ httpOnly cookie — JavaScript can't touch it
response.cookies.set('auth-token', token, { httpOnly: true, secure: true });

Mistake 2: Not validating API inputs

// ❌ Trusting anything the client sends
export async function POST(req: NextRequest) {
  const { email, role } = await req.json();
  await db.users.create({ data: { email, role } }); // 😱 user just gave themselves 'admin'
}

// ✅ Validate the shape and strip unexpected fields
export async function POST(req: NextRequest) {
  const body = await req.json();
  const email = String(body.email ?? '').trim();

  if (!email || !email.includes('@')) {
    return NextResponse.json({ error: 'Invalid email' }, { status: 400 });
  }

  await db.users.create({ data: { email, role: 'user' } }); // role is hardcoded
}

Mistake 3: Exposing server errors to clients

// ❌ Leaks your stack trace and internals
return NextResponse.json({ error: error.message }, { status: 500 });

// ✅ Log the real error server-side, send a generic message
console.error('[API Error]', error);
Sentry.captureException(error);
return NextResponse.json({ error: 'Something went wrong.' }, { status: 500 });

Mistake 4: No rate limiting on auth routes

// Install: npm install @upstash/ratelimit @upstash/redis
import { Ratelimit } from '@upstash/ratelimit';
import { Redis } from '@upstash/redis';

const ratelimit = new Ratelimit({
  redis: Redis.fromEnv(),
  limiter: Ratelimit.slidingWindow(5, '1 m'), // 5 attempts per minute
});

export async function POST(request: NextRequest) {
  const ip = request.ip ?? '127.0.0.1';
  const { success } = await ratelimit.limit(ip);

  if (!success) {
    return NextResponse.json({ error: 'Too many attempts.' }, { status: 429 });
  }

  // ... rest of login logic
}

Mistake 5: Forgetting to handle token expiry on the client

// ✅ Intercept 401 responses globally and redirect to login
export async function fetchWithAuth(url: string, options?: RequestInit) {
  const response = await fetch(url, options);

  if (response.status === 401) {
    // Token expired — send user back to login
    window.location.href = '/login';
    return;
  }

  return response;
}

🎓 The Full Journey — What You've Built Over This Series

You started with "What is React?" and you're finishing with production deployments, auth systems, and error monitoring. That's not a small leap. Here's everything you've learned across all six parts:

Part 1 — Foundations
   React, components, hooks, setup, file structure

Part 2 — Advanced Hooks & State
   Custom hooks, useReducer, Context, Redux, Zustand, Jotai

Part 3 — Performance
   React.memo, useMemo, useCallback, code splitting, virtualization

Part 4 — Full-Stack with Next.js
   App Router, Server Components, API routes, deployment

Part 5 — Testing & Debugging
   Jest, React Testing Library, async tests, Error Boundaries

Part 6 — Production
   Auth, OAuth, CI/CD, Sentry, security, production patterns

You now have the full picture. Not just "React developer" — full-stack, production-capable, test-covered React engineering.

🔗 Quick Resources

Auth.js (NextAuth v5): authjs.dev
Sentry for Next.js: docs.sentry.io/platforms/javascript/nextjs
GitHub Actions: docs.github.com/actions
Upstash Rate Limiting: upstash.com/docs/ratelimit
Vercel Environment Variables: vercel.com/docs/environment-variables

💬 You've Reached the End — What's Next for You?

Six articles. A complete React engineering curriculum. What are you building with it?

If you've followed this series from Part 1, I'd genuinely love to hear what you took away most — a concept that finally clicked, a project you shipped, or even something I got wrong. Drop it in the comments.

And if you're hungry for what comes after production React, the natural next steps are: React Native for mobile, Turborepo for monorepos, and tRPC for end-to-end type safety without REST boilerplate.

Go build something real. 🚀

Testing & Debugging React Apps — Write Code You Can Actually Trust

Kushang Tailor — Thu, 18 Jun 2026 04:26:01 +0000

Read Time: ~14 minutes | Ship with confidence — because guessing is not a strategy

Prerequisites: React fundamentals, hooks, state management, Next.js basics (Parts 1–4)

📌 What You'll Learn

By the end of this guide, you'll be able to:

✅ Understand the three layers of testing and what each one covers
✅ Set up Jest and React Testing Library from scratch
✅ Write unit tests for components, hooks, and utility functions
✅ Write integration tests that test real user flows
✅ Test async behaviour — API calls, loading states, and errors
✅ Debug like a pro with React DevTools and browser tools
✅ Use Error Boundaries to catch crashes gracefully in production

🤔 Why Testing Feels Painful (And Why It Doesn't Have To)

Let's be real — most developers skip testing early on. Not because they don't care about quality, but because they were introduced to testing the wrong way: abstract theory, complicated setup, and tests that take longer to write than the code itself.

Here's the shift in mindset that makes it click:

You're not writing tests for the computer. You're writing tests for Future You.

Future You, at 2 AM, having just changed a utility function, needs to know if something broke without manually clicking through 40 screens. Tests are that safety net.

The other thing nobody tells you: you don't need to test everything. You test the things that would hurt if they broke.

🏗️ The Three Layers of Testing

Think of testing as a pyramid. Wide base, narrow top.

        /‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾\
       /   E2E Tests (few) \     → Cypress, Playwright
      /‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾\
     /  Integration Tests (some) \  → React Testing Library
    /‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾\
   /    Unit Tests (many)         \  → Jest
  /‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾\

Layer	What It Tests	Speed	Confidence
Unit	One function or component in isolation	Fast (~ms)	Low–Medium
Integration	Multiple parts working together	Medium (~s)	High
E2E	Full app in a real browser	Slow (~min)	Highest

For most React projects, you want lots of unit tests, a solid set of integration tests, and a handful of E2E tests for critical flows like login and checkout. This article focuses on unit and integration — the layer that gives you the best return on time invested.

⚙️ Setup: Jest + React Testing Library

If you created your project with Create React App, Jest is already configured. For Vite or Next.js, here's the setup.

For Next.js

npm install --save-dev jest jest-environment-jsdom @testing-library/react @testing-library/jest-dom @testing-library/user-event

Create jest.config.ts in your project root:

// jest.config.ts
import type { Config } from 'jest';
import nextJest from 'next/jest.js';

const createJestConfig = nextJest({ dir: './' });

const config: Config = {
  testEnvironment: 'jsdom',
  setupFilesAfterFramework: ['<rootDir>/jest.setup.ts'],
  moduleNameMapper: {
    '^@/(.*)$': '<rootDir>/$1', // Resolve @ path aliases
  },
};

export default createJestConfig(config);

Create jest.setup.ts:

// jest.setup.ts
import '@testing-library/jest-dom';
// This gives you matchers like .toBeInTheDocument(), .toHaveTextContent() etc.

Add the test script to package.json:

{
  "scripts": {
    "test": "jest",
    "test:watch": "jest --watch",
    "test:coverage": "jest --coverage"
  }
}

Run your first test:

npm test

✅ Unit Testing: Components

The golden rule of React Testing Library: test what the user sees, not implementation details.

That means — test for text on screen, buttons, inputs, and form behaviour. Don't test state variables, component internals, or CSS class names.

Testing a Simple Component

// components/Greeting.tsx
interface Props {
  name: string;
  isLoggedIn: boolean;
}

export default function Greeting({ name, isLoggedIn }: Props) {
  if (!isLoggedIn) {
    return <p>Please log in to continue.</p>;
  }
  return <h1>Welcome back, {name}!</h1>;
}

// components/Greeting.test.tsx
import { render, screen } from '@testing-library/react';
import Greeting from './Greeting';

describe('Greeting', () => {
  it('shows a welcome message when the user is logged in', () => {
    render(<Greeting name="Kushang" isLoggedIn={true} />);

    expect(screen.getByText('Welcome back, Kushang!')).toBeInTheDocument();
  });

  it('shows a login prompt when the user is not logged in', () => {
    render(<Greeting name="Kushang" isLoggedIn={false} />);

    expect(screen.getByText('Please log in to continue.')).toBeInTheDocument();
  });

  it('does not show the welcome message when logged out', () => {
    render(<Greeting name="Kushang" isLoggedIn={false} />);

    expect(screen.queryByText(/Welcome back/)).not.toBeInTheDocument();
  });
});

Notice the pattern every test follows — Arrange, Act, Assert:

Arrange: render the component
Act: interact with it (if needed)
Assert: check what's visible

Testing a Button Click

// components/Counter.tsx
import { useState } from 'react';

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

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>Increment</button>
      <button onClick={() => setCount(0)}>Reset</button>
    </div>
  );
}

// components/Counter.test.tsx
import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import Counter from './Counter';

describe('Counter', () => {
  it('starts at zero', () => {
    render(<Counter />);
    expect(screen.getByText('Count: 0')).toBeInTheDocument();
  });

  it('increments the count when the button is clicked', async () => {
    const user = userEvent.setup();
    render(<Counter />);

    await user.click(screen.getByRole('button', { name: 'Increment' }));
    expect(screen.getByText('Count: 1')).toBeInTheDocument();

    await user.click(screen.getByRole('button', { name: 'Increment' }));
    expect(screen.getByText('Count: 2')).toBeInTheDocument();
  });

  it('resets the count to zero', async () => {
    const user = userEvent.setup();
    render(<Counter />);

    await user.click(screen.getByRole('button', { name: 'Increment' }));
    await user.click(screen.getByRole('button', { name: 'Increment' }));
    await user.click(screen.getByRole('button', { name: 'Reset' }));

    expect(screen.getByText('Count: 0')).toBeInTheDocument();
  });
});

userEvent simulates real user interactions — clicking, typing, tabbing. It's more realistic than fireEvent and the recommended choice today.

🔗 Integration Testing: Real User Flows

Integration tests are where the real confidence comes from. Instead of testing one component, you test a complete flow — like filling out and submitting a form.

Testing a Login Form

// components/LoginForm.tsx
import { useState } from 'react';

interface Props {
  onSubmit: (email: string, password: string) => void;
}

export default function LoginForm({ onSubmit }: Props) {
  const [email, setEmail]       = useState('');
  const [password, setPassword] = useState('');
  const [error, setError]       = useState('');

  const handleSubmit = (e: React.FormEvent) => {
    e.preventDefault();

    if (!email || !password) {
      setError('Both fields are required.');
      return;
    }

    onSubmit(email, password);
  };

  return (
    <form onSubmit={handleSubmit}>
      <label htmlFor="email">Email</label>
      <input
        id="email"
        type="email"
        value={email}
        onChange={(e) => setEmail(e.target.value)}
      />

      <label htmlFor="password">Password</label>
      <input
        id="password"
        type="password"
        value={password}
        onChange={(e) => setPassword(e.target.value)}
      />

      {error && <p role="alert">{error}</p>}

      <button type="submit">Log In</button>
    </form>
  );
}

// components/LoginForm.test.tsx
import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import LoginForm from './LoginForm';

describe('LoginForm', () => {
  it('calls onSubmit with email and password when the form is valid', async () => {
    const user      = userEvent.setup();
    const onSubmit  = jest.fn(); // Mock function — tracks calls
    render(<LoginForm onSubmit={onSubmit} />);

    await user.type(screen.getByLabelText('Email'), 'hello@example.com');
    await user.type(screen.getByLabelText('Password'), 'secret123');
    await user.click(screen.getByRole('button', { name: 'Log In' }));

    expect(onSubmit).toHaveBeenCalledWith('hello@example.com', 'secret123');
    expect(onSubmit).toHaveBeenCalledTimes(1);
  });

  it('shows an error message when fields are empty', async () => {
    const user = userEvent.setup();
    render(<LoginForm onSubmit={jest.fn()} />);

    await user.click(screen.getByRole('button', { name: 'Log In' }));

    expect(screen.getByRole('alert')).toHaveTextContent('Both fields are required.');
  });

  it('does not call onSubmit when fields are empty', async () => {
    const user     = userEvent.setup();
    const onSubmit = jest.fn();
    render(<LoginForm onSubmit={onSubmit} />);

    await user.click(screen.getByRole('button', { name: 'Log In' }));

    expect(onSubmit).not.toHaveBeenCalled();
  });
});

These three tests cover the happy path, the validation error, and the guard against bad calls. That's most of what this form can do — and they take under a minute to run.

⏳ Testing Async Behaviour

Most real components talk to an API. Here's how to test those flows without making actual network requests.

Mocking an API Call

// components/UserProfile.tsx
import { useEffect, useState } from 'react';

interface User {
  id: number;
  name: string;
  email: string;
}

export default function UserProfile({ userId }: { userId: number }) {
  const [user, setUser]       = useState<User | null>(null);
  const [loading, setLoading] = useState(true);
  const [error, setError]     = useState('');

  useEffect(() => {
    fetch(`/api/users/${userId}`)
      .then((r) => {
        if (!r.ok) throw new Error('Failed to load user.');
        return r.json();
      })
      .then((data) => { setUser(data); setLoading(false); })
      .catch((err) => { setError(err.message); setLoading(false); });
  }, [userId]);

  if (loading) return <p>Loading profile...</p>;
  if (error)   return <p role="alert">{error}</p>;

  return (
    <div>
      <h2>{user?.name}</h2>
      <p>{user?.email}</p>
    </div>
  );
}

// components/UserProfile.test.tsx
import { render, screen, waitFor } from '@testing-library/react';
import UserProfile from './UserProfile';

// Mock the global fetch API
global.fetch = jest.fn();

const mockUser = { id: 1, name: 'Kushang Tailor', email: 'kushang@example.com' };

describe('UserProfile', () => {
  afterEach(() => jest.clearAllMocks()); // Clean up between tests

  it('shows a loading state first', () => {
    (fetch as jest.Mock).mockResolvedValueOnce({
      ok: true,
      json: async () => mockUser,
    });

    render(<UserProfile userId={1} />);
    expect(screen.getByText('Loading profile...')).toBeInTheDocument();
  });

  it('shows the user name and email after loading', async () => {
    (fetch as jest.Mock).mockResolvedValueOnce({
      ok: true,
      json: async () => mockUser,
    });

    render(<UserProfile userId={1} />);

    await waitFor(() => {
      expect(screen.getByText('Kushang Tailor')).toBeInTheDocument();
      expect(screen.getByText('kushang@example.com')).toBeInTheDocument();
    });
  });

  it('shows an error message when the API fails', async () => {
    (fetch as jest.Mock).mockResolvedValueOnce({ ok: false });

    render(<UserProfile userId={1} />);

    await waitFor(() => {
      expect(screen.getByRole('alert')).toHaveTextContent('Failed to load user.');
    });
  });
});

waitFor keeps polling the assertion until it passes (or times out). It's how you deal with async state updates in tests.

🪝 Testing Custom Hooks

Custom hooks need their own tests because they hold logic that multiple components share. Use renderHook from React Testing Library:

// hooks/useCounter.ts
import { useState } from 'react';

export function useCounter(initial = 0) {
  const [count, setCount] = useState(initial);

  return {
    count,
    increment: () => setCount((c) => c + 1),
    decrement: () => setCount((c) => c - 1),
    reset:     () => setCount(initial),
  };
}

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

describe('useCounter', () => {
  it('starts with the initial value', () => {
    const { result } = renderHook(() => useCounter(10));
    expect(result.current.count).toBe(10);
  });

  it('increments the count', () => {
    const { result } = renderHook(() => useCounter());

    act(() => result.current.increment());

    expect(result.current.count).toBe(1);
  });

  it('decrements the count', () => {
    const { result } = renderHook(() => useCounter(5));

    act(() => result.current.decrement());

    expect(result.current.count).toBe(4);
  });

  it('resets to the initial value', () => {
    const { result } = renderHook(() => useCounter(3));

    act(() => result.current.increment());
    act(() => result.current.increment());
    act(() => result.current.reset());

    expect(result.current.count).toBe(3);
  });
});

act wraps anything that causes state updates. It makes sure React processes all the state changes before your assertion runs.

🔥 Debugging: React DevTools Deep Dive

Testing catches bugs before they reach users. Debugging finds the ones that sneak through anyway.

Components Tab

Open DevTools → React tab → Components. Here's what you can do:

Select any component in the tree → see:
├─ Props (current values)
├─ State (useState values)
├─ Hooks (all hook values in order)
└─ Rendered by (parent chain)

You can also edit props and state live in the panel — no code change needed. Incredibly useful for testing edge cases.

Profiler Tab (Performance Debugging)

Already covered in Part 3, but worth repeating the workflow:

1. Open React DevTools → Profiler tab
2. Click ● Record
3. Interact with the slow part of your app
4. Click ■ Stop
5. Look for wide bars (slow renders) and grey bars (unnecessary renders)

Grey bars mean a component re-rendered but produced identical output — a prime candidate for React.memo.

Highlight Updates

In React DevTools settings, enable "Highlight updates when components render". Every re-render flashes a coloured outline on the component. If things are flashing that shouldn't be, you've found your problem.

🚨 Error Boundaries: Catching Crashes in Production

Here's something try/catch cannot do: catch errors thrown during rendering. Error Boundaries handle exactly that — they're React's safety net for when a component tree crashes.

// components/ErrorBoundary.tsx
import { Component, ReactNode } from 'react';

interface Props {
  children: ReactNode;
  fallback?: ReactNode;
}

interface State {
  hasError: boolean;
  error: Error | null;
}

export class ErrorBoundary extends Component<Props, State> {
  constructor(props: Props) {
    super(props);
    this.state = { hasError: false, error: null };
  }

  static getDerivedStateFromError(error: Error): State {
    return { hasError: true, error };
  }

  componentDidCatch(error: Error, info: React.ErrorInfo) {
    // Send to your error tracking service (Sentry, Datadog, etc.)
    console.error('Caught by ErrorBoundary:', error, info.componentStack);
  }

  render() {
    if (this.state.hasError) {
      return (
        this.props.fallback ?? (
          <div className="error-state">
            <h2>Something went wrong.</h2>
            <p>We're looking into it — try refreshing the page.</p>
            <button onClick={() => this.setState({ hasError: false, error: null })}>
              Try Again
            </button>
          </div>
        )
      );
    }

    return this.props.children;
  }
}

Wrap it around sections that could fail independently:

// app/dashboard/page.tsx
import { ErrorBoundary } from '@/components/ErrorBoundary';
import { SalesChart } from '@/components/SalesChart';
import { RecentOrders } from '@/components/RecentOrders';

export default function DashboardPage() {
  return (
    <div className="dashboard">
      {/* If SalesChart crashes, only this section shows an error */}
      <ErrorBoundary fallback={<p>Chart unavailable — try again later.</p>}>
        <SalesChart />
      </ErrorBoundary>

      {/* RecentOrders is unaffected by SalesChart crashing */}
      <ErrorBoundary fallback={<p>Orders unavailable — try again later.</p>}>
        <RecentOrders />
      </ErrorBoundary>
    </div>
  );
}

The result: one section crashing doesn't take down the entire page. Your users see a graceful fallback instead of a blank white screen.

🧪 Common Testing Queries — Which One to Use

React Testing Library gives you several ways to query the DOM. Here's when to use each:

// Priority 1: Accessible roles (best — mirrors what screen readers see)
screen.getByRole('button', { name: 'Submit' })
screen.getByRole('heading', { name: 'Welcome' })
screen.getByRole('textbox', { name: 'Email' })

// Priority 2: Labels (great for form fields)
screen.getByLabelText('Email Address')

// Priority 3: Placeholder (acceptable for inputs)
screen.getByPlaceholderText('Search...')

// Priority 4: Text content (good for readable text)
screen.getByText('Loading...')

// Priority 5: Test IDs (last resort — add data-testid only if nothing else works)
screen.getByTestId('product-card')

The philosophy: if you're querying by class name or component name, you're testing implementation, not behaviour. A CSS refactor will break your tests for no good reason.

📊 What a Healthy Test Suite Looks Like

Here's a realistic coverage target for a production React app:

Type	Target Coverage	Run Time
Utility functions	90–100%	< 1s
Custom hooks	80–90%	< 5s
Components (unit)	70–80%	< 30s
User flows (integration)	Key flows covered	< 2 min
E2E	Login, checkout, critical paths	< 10 min

100% coverage is a myth worth ignoring. A well-tested login flow, cart checkout, and search filter give you far more confidence than 100% coverage on a heading component.

💡 Debugging Checklist (When Things Go Wrong)

Before spending an hour on a bug, run through this:

□ Check the browser console — is there an error message?
□ Check the Network tab — did the API call succeed? What did it return?
□ Add a console.log right before the broken code
□ Open React DevTools → Components → check the props and state
□ Is the component re-rendering when it shouldn't? (Highlight updates)
□ Is it an async timing issue? (Add a debugger statement in the useEffect)
□ Are you mutating state directly? (Should always use setState)
□ Is a dependency array in useEffect missing something?
□ Did a prop change shape or become undefined?
□ Is the issue only in production? (Check .env variables)

Nine times out of ten, the bug is in the console, the network tab, or a missing dependency array.

🔗 Quick Resources

React Testing Library: testing-library.com/react
Jest Docs: jestjs.io
React DevTools: Chrome Web Store → "React Developer Tools"
Vitest (fast alternative to Jest): vitest.dev
Cypress (E2E): cypress.io
Playwright (E2E): playwright.dev

💬 What's Your Testing Philosophy?

Do you write tests before the code (TDD), after, or only when something breaks? No judgement either way — I'm genuinely curious what workflow actually sticks for people in the real world. Drop it in the comments!

Coming in Part 6:

Authentication flows (JWT, session, OAuth)
Real-world deployment patterns
Error monitoring with Sentry
CI/CD with GitHub Actions
Lessons from production React apps at scale

Happy testing! 🧪

Full-Stack with Next.js — From React Dev to Full-Stack Engineer

Kushang Tailor — Wed, 10 Jun 2026 06:29:33 +0000

Read Time: ~15 minutes | The bridge from React UI library to production full-stack framework

Prerequisites: React fundamentals, hooks, state management (Parts 1–3)

📌 What You'll Learn

By the end of this guide, you'll be able to:

✅ Understand what Next.js adds on top of React (and why it matters)
✅ Navigate the App Router with file-based routing
✅ Know when to use Server Components vs Client Components
✅ Fetch data on the server without a separate backend
✅ Build API routes that replace a Node/Express server
✅ Optimize images and fonts automatically
✅ Build and deploy a real blog platform to Vercel in under 10 minutes

🤔 What Is Next.js (And Why Does It Exist)?

React is a UI library—it renders components beautifully, but it has no opinion about routing, data fetching, server-side rendering, or deployment. You assemble all of that yourself.

Next.js is the full-stack framework built on React that makes those decisions for you. It's like React + routing + data fetching + a server + a build pipeline, all in one cohesive package.

React alone:
UI rendering ✅ | Routing ❌ | Data fetching ❌ | SSR ❌ | API ❌

Next.js (React + framework):
UI rendering ✅ | Routing ✅ | Data fetching ✅ | SSR ✅ | API ✅

Why the Industry Adopted Next.js So Fast

By 2025, Next.js is used by Vercel, Netflix, TikTok, Twitch, Notion, and GitHub among thousands of production applications. The reasons are practical:

SEO out of the box — pages are server-rendered, so search engines see real content
No Express server needed — API routes live inside the same codebase
Automatic optimizations — images, fonts, and scripts are optimized for free
Deployment in seconds — Vercel hosting knows Next.js deeply

⚖️ Next.js vs The Alternatives

Criteria	Create React App	Vite	Next.js	Remix
Routing	Manual (React Router)	Manual	Built-in	Built-in
SSR / SSG	❌	❌	✅	✅
API Routes	❌	❌	✅	✅
SEO	Poor (CSR only)	Poor (CSR only)	Excellent	Excellent
Image Optimization	Manual	Manual	Automatic	Manual
Learning Curve	Low	Low	Medium	Medium
Bundle Splitting	Manual	Auto	Auto	Auto
Best For	Prototypes	SPAs, tools	Full-stack apps	Form-heavy apps
Vercel Deploy	Manual	Manual	One click	One click

The takeaway: Use Next.js whenever your app needs SEO, a backend, or server-side data. Use Vite for internal dashboards or SPAs where SEO doesn't matter.

🚀 Setup & Project Structure

Create a Next.js App

# Create project (accept all defaults)
npx create-next-app@latest my-blog
cd my-blog
npm run dev

You'll be asked a few questions—say Yes to TypeScript (optional), Yes to Tailwind (optional), and Yes to the App Router (essential for 2025).

Project Structure (App Router)

my-blog/
├── app/                    # ← Heart of your app (App Router)
│   ├── layout.tsx          # Root layout (wraps every page)
│   ├── page.tsx            # Home page → renders at /
│   ├── globals.css         # Global styles
│   ├── about/
│   │   └── page.tsx        # About page → renders at /about
│   └── blog/
│       ├── page.tsx        # Blog list → renders at /blog
│       └── [slug]/
│           └── page.tsx    # Single post → renders at /blog/my-post
├── public/                 # Static assets (images, fonts, etc.)
├── components/             # Shared UI components
├── lib/                    # Utility functions, DB connections
├── next.config.js          # Next.js configuration
└── package.json

The magic: file path = URL path. No router config, no <Route> components. Just create a file and the route exists.

📁 File-Based Routing (App Router)

Page Files

Every page.tsx inside app/ becomes a route:

// app/page.tsx → renders at /
export default function HomePage() {
  return <h1>Welcome Home</h1>;
}

// app/about/page.tsx → renders at /about
export default function AboutPage() {
  return <h1>About Us</h1>;
}

// app/blog/page.tsx → renders at /blog
export default function BlogListPage() {
  return <h1>All Posts</h1>;
}

Dynamic Routes (Parameters in URLs)

// app/blog/[slug]/page.tsx → renders at /blog/any-post-title
interface Props {
  params: { slug: string };
}

export default function PostPage({ params }: Props) {
  return <h1>Post: {params.slug}</h1>;
  // /blog/hello-world → params.slug = "hello-world"
  // /blog/my-react-guide → params.slug = "my-react-guide"
}

Layout Files (Shared UI Across Routes)

// app/layout.tsx → wraps EVERY page in your app
export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <html lang="en">
      <body>
        <nav>
          <a href="/">Home</a>
          <a href="/blog">Blog</a>
          <a href="/about">About</a>
        </nav>
        <main>{children}</main>
        <footer>© 2025 My Blog</footer>
      </body>
    </html>
  );
}

// app/blog/layout.tsx → wraps only /blog/* routes
export default function BlogLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <div className="blog-container">
      <aside>
        <h3>Categories</h3>
        {/* Sidebar here */}
      </aside>
      <article>{children}</article>
    </div>
  );
}

Why layouts are powerful: Your nav and footer render once and persist across page navigations—no re-mounting, no flicker.

Special Files at a Glance

Filename	Purpose
`page.tsx`	The visible UI for a route
`layout.tsx`	Wrapper shared across child routes
`loading.tsx`	Auto-shown while page data loads
`error.tsx`	Error boundary for a route
`not-found.tsx`	Custom 404 page
`route.ts`	API endpoint (replaces Express route)

⚡ Server Components vs Client Components

This is the concept that trips up most React developers moving to Next.js.

Server Components (Default in App Router)

In Next.js App Router, every component is a Server Component by default. They run on the server, never in the browser.

// app/blog/page.tsx
// ✅ Server Component (no "use client" directive)
// Runs on the server — can access databases, env vars, file system

async function getBlogPosts() {
  const response = await fetch('https://api.example.com/posts', {
    next: { revalidate: 3600 } // Re-fetch every hour
  });
  return response.json();
}

export default async function BlogPage() {
  const posts = await getBlogPosts(); // Direct async/await — no useEffect!

  return (
    <div>
      <h1>Blog Posts</h1>
      {posts.map((post: Post) => (
        <article key={post.id}>
          <h2>{post.title}</h2>
          <p>{post.excerpt}</p>
          <a href={`/blog/${post.slug}`}>Read more →</a>
        </article>
      ))}
    </div>
  );
}

What Server Components can do:

✅ async/await directly (no useEffect + useState loading dance)
✅ Access databases and file system directly
✅ Use secret env variables safely
✅ Import heavy libraries without bloating the client bundle
❌ No useState, useEffect, event handlers
❌ No browser APIs (window, document)

Client Components (`"use client"` directive)

Add "use client" at the top when you need interactivity:

"use client"; // ← This one line switches to a Client Component

import { useState } from 'react';

export default function SearchBar({ onSearch }: { onSearch: (q: string) => void }) {
  const [query, setQuery] = useState('');

  return (
    <input
      value={query}
      onChange={(e) => {
        setQuery(e.target.value);
        onSearch(e.target.value);
      }}
      placeholder="Search posts..."
    />
  );
}

Client Components are for:

✅ useState, useEffect, custom hooks
✅ Event handlers (onClick, onChange)
✅ Browser APIs
✅ Third-party libraries needing the DOM
❌ Direct database/file system access
❌ Secret environment variables

The Golden Pattern: Server Shell + Client Islands

// app/blog/page.tsx — Server Component (default)
import SearchBar from '@/components/SearchBar'; // Client Component
import PostList from '@/components/PostList';   // Server Component

async function getPosts() {
  // Runs on server — safe to use secrets, DB, etc.
  const posts = await db.posts.findMany();
  return posts;
}

export default async function BlogPage() {
  const posts = await getPosts(); // Direct DB call — no API needed

  return (
    <div>
      {/* Client island — handles user input */}
      <SearchBar onSearch={(q) => console.log(q)} />

      {/* Server component — rendered on server */}
      <PostList posts={posts} />
    </div>
  );
}

Mental model: Server Components are the shell (fast, SEO-friendly, secure). Client Components are interactive islands inside that shell. Use the minimum number of Client Components necessary.

🌐 Data Fetching in Next.js

Three Patterns You'll Use

1. Static Data (SSG) — Build time, cached forever

// app/about/page.tsx
// Data fetched once at build time — ultra fast

export default async function AboutPage() {
  const team = await fetch('https://api.example.com/team').then(r => r.json());
  // This fetch runs ONCE when you build — result is cached as static HTML

  return (
    <div>
      {team.map((member: Member) => (
        <div key={member.id}>{member.name}</div>
      ))}
    </div>
  );
}

2. Revalidated Data (ISR) — Refreshes every N seconds

// app/blog/page.tsx
// Re-fetches every 60 seconds — fresh but still cached

async function getPosts() {
  const res = await fetch('https://api.example.com/posts', {
    next: { revalidate: 60 } // Refresh every 60 seconds
  });
  return res.json();
}

3. Dynamic Data (SSR) — Every request, always fresh

// app/dashboard/page.tsx
// Runs on every request — real-time data

async function getUserData(userId: string) {
  const res = await fetch(`https://api.example.com/users/${userId}`, {
    cache: 'no-store' // Never cache — always fresh
  });
  return res.json();
}

Fetching Strategy Decision

Is data the same for everyone?
├─ Yes, never changes → Static (no revalidate)
├─ Yes, but updates sometimes → ISR (revalidate: N seconds)
└─ No, user-specific or real-time → Dynamic (cache: 'no-store')

🔌 API Routes: Your Backend Lives Here

Next.js route.ts files replace Express, Fastify, or any separate Node server.

Basic CRUD API

// app/api/posts/route.ts → handles GET /api/posts & POST /api/posts
import { NextRequest, NextResponse } from 'next/server';

// In-memory store (use a real DB in production)
const posts = [
  { id: 1, title: 'Hello Next.js', slug: 'hello-nextjs' },
  { id: 2, title: 'Server Components', slug: 'server-components' },
];

// GET /api/posts
export async function GET() {
  return NextResponse.json(posts);
}

// POST /api/posts
export async function POST(request: NextRequest) {
  const body = await request.json();

  if (!body.title) {
    return NextResponse.json(
      { error: 'Title is required' },
      { status: 400 }
    );
  }

  const newPost = {
    id: posts.length + 1,
    title: body.title,
    slug: body.title.toLowerCase().replace(/\s+/g, '-'),
  };

  posts.push(newPost);
  return NextResponse.json(newPost, { status: 201 });
}

Dynamic API Routes

// app/api/posts/[id]/route.ts → handles /api/posts/1, /api/posts/42, etc.
import { NextRequest, NextResponse } from 'next/server';

interface Params {
  params: { id: string };
}

// GET /api/posts/1
export async function GET(_req: NextRequest, { params }: Params) {
  const post = await db.posts.findUnique({
    where: { id: parseInt(params.id) },
  });

  if (!post) {
    return NextResponse.json({ error: 'Post not found' }, { status: 404 });
  }

  return NextResponse.json(post);
}

// PATCH /api/posts/1
export async function PATCH(request: NextRequest, { params }: Params) {
  const body = await request.json();

  const updated = await db.posts.update({
    where: { id: parseInt(params.id) },
    data: { title: body.title },
  });

  return NextResponse.json(updated);
}

// DELETE /api/posts/1
export async function DELETE(_req: NextRequest, { params }: Params) {
  await db.posts.delete({ where: { id: parseInt(params.id) } });
  return NextResponse.json({ success: true });
}

The result: a full REST API, no separate server, no CORS headaches—everything in one codebase.

🖼️ Image & Font Optimization (Free Performance Wins)

The `<Image>` Component

Never use a plain <img> in Next.js—use next/image instead:

import Image from 'next/image';

// ❌ Plain HTML img — unoptimized
<img src="/hero.jpg" alt="Hero" width={1200} height={600} />

// ✅ Next.js Image — automatic WebP, lazy loading, no layout shift
<Image
  src="/hero.jpg"
  alt="Hero"
  width={1200}
  height={600}
  priority     // Load this image eagerly (above the fold)
/>

// ✅ Fill mode for responsive containers
<div style={{ position: 'relative', height: '300px' }}>
  <Image
    src="/cover.jpg"
    alt="Post cover"
    fill
    style={{ objectFit: 'cover' }}
    sizes="(max-width: 768px) 100vw, 50vw"
  />
</div>

What next/image gives you for free:

Converts to WebP/AVIF automatically (30-50% smaller)
Lazy loads by default (only loads when in viewport)
Prevents Cumulative Layout Shift (CLS)
Generates multiple sizes for different screen widths

Font Optimization

// app/layout.tsx
import { Inter, Fira_Code } from 'next/font/google';

// Fonts are downloaded at build time — no runtime network request
const inter = Inter({
  subsets: ['latin'],
  display: 'swap',      // Show fallback font until loaded
  variable: '--font-inter',
});

const firaCode = Fira_Code({
  subsets: ['latin'],
  display: 'swap',
  variable: '--font-fira-code',
});

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en" className={`${inter.variable} ${firaCode.variable}`}>
      <body style={{ fontFamily: 'var(--font-inter)' }}>
        {children}
      </body>
    </html>
  );
}

Why this matters: Google Fonts loaded the old way block rendering and cause layout shift. Next.js downloads fonts at build time—zero runtime latency, zero layout shift.

🏗️ Real-World: Building a Blog Platform

Let's put everything together and build a real blog with posts and an API.

Step 1: Project Setup

npx create-next-app@latest nextjs-blog
cd nextjs-blog
npm install gray-matter    # Parse markdown frontmatter
npm install next-mdx-remote # Render MDX content
npm run dev

Step 2: Post Data (Markdown Files)

<!-- posts/hello-nextjs.md -->
---
title: "Hello Next.js"
date: "2025-06-01"
excerpt: "A quick intro to why Next.js changes everything."
author: "Your Name"
---

# Hello Next.js

This is my first post rendered from markdown...

Step 3: Library to Read Posts

// lib/posts.ts
import fs from 'fs';
import path from 'path';
import matter from 'gray-matter';

const postsDir = path.join(process.cwd(), 'posts');

export function getAllPosts() {
  const slugs = fs.readdirSync(postsDir);

  return slugs
    .map((filename) => {
      const slug = filename.replace(/\.md$/, '');
      const fullPath = path.join(postsDir, filename);
      const fileContents = fs.readFileSync(fullPath, 'utf8');
      const { data } = matter(fileContents);

      return {
        slug,
        title: data.title as string,
        date: data.date as string,
        excerpt: data.excerpt as string,
        author: data.author as string,
      };
    })
    .sort((a, b) => (a.date > b.date ? -1 : 1));
}

export function getPostBySlug(slug: string) {
  const fullPath = path.join(postsDir, `${slug}.md`);
  const fileContents = fs.readFileSync(fullPath, 'utf8');
  const { data, content } = matter(fileContents);

  return {
    slug,
    content,
    title: data.title as string,
    date: data.date as string,
    author: data.author as string,
  };
}

Step 4: Blog List Page (Server Component)

// app/blog/page.tsx
import { getAllPosts } from '@/lib/posts';
import Link from 'next/link';

export const metadata = {
  title: 'Blog | My Next.js Blog',
  description: 'Thoughts on React, Next.js, and web development.',
};

export default function BlogPage() {
  // Direct file system access — no API call, no useEffect
  const posts = getAllPosts();

  return (
    <main>
      <h1>Blog</h1>
      <p>{posts.length} posts published</p>

      <div className="post-grid">
        {posts.map((post) => (
          <article key={post.slug}>
            <time>{new Date(post.date).toLocaleDateString()}</time>
            <h2>
              <Link href={`/blog/${post.slug}`}>{post.title}</Link>
            </h2>
            <p>{post.excerpt}</p>
            <span>{post.author}</span>
          </article>
        ))}
      </div>
    </main>
  );
}

Step 5: Single Post Page (Dynamic Route)

// app/blog/[slug]/page.tsx
import { getPostBySlug, getAllPosts } from '@/lib/posts';
import { notFound } from 'next/navigation';

// Pre-generate all post pages at build time
export async function generateStaticParams() {
  const posts = getAllPosts();
  return posts.map((post) => ({ slug: post.slug }));
}

// Generate dynamic metadata per post
export async function generateMetadata({ params }: { params: { slug: string } }) {
  const post = getPostBySlug(params.slug);
  return {
    title: `${post.title} | My Blog`,
    description: post.title,
  };
}

export default function PostPage({ params }: { params: { slug: string } }) {
  const post = getPostBySlug(params.slug);

  if (!post) notFound(); // Shows app/not-found.tsx automatically

  return (
    <article>
      <header>
        <h1>{post.title}</h1>
        <time>{new Date(post.date).toLocaleDateString()}</time>
        <span>By {post.author}</span>
      </header>

      {/* Render markdown as HTML */}
      <div dangerouslySetInnerHTML={{ __html: post.content }} />
    </article>
  );
}

Step 6: API Route for Posts

// app/api/posts/route.ts
import { getAllPosts } from '@/lib/posts';
import { NextResponse } from 'next/server';

// GET /api/posts — returns all posts as JSON
export async function GET() {
  const posts = getAllPosts();
  return NextResponse.json(posts);
}

Step 7: Loading & Error States

// app/blog/loading.tsx — Shows while blog page loads
export default function BlogLoading() {
  return (
    <div>
      {[1, 2, 3].map((i) => (
        <div key={i} className="post-skeleton">
          <div className="skeleton-title" />
          <div className="skeleton-text" />
        </div>
      ))}
    </div>
  );
}

// app/blog/error.tsx — Shows if blog page throws
'use client';

export default function BlogError({ error, reset }: {
  error: Error;
  reset: () => void;
}) {
  return (
    <div>
      <h2>Something went wrong loading the blog</h2>
      <p>{error.message}</p>
      <button onClick={reset}>Try again</button>
    </div>
  );
}

🚀 Deploying to Vercel in Under 10 Minutes

Vercel is the company behind Next.js. Their platform knows Next.js deeply—deployment is as simple as pushing code.

Step 1: Push to GitHub

git init
git add .
git commit -m "Initial blog setup"
git branch -M main
git remote add origin https://github.com/yourusername/my-blog.git
git push -u origin main

Step 2: Connect to Vercel

Go to vercel.com and sign up with GitHub
Click "New Project" → Import your repo
Vercel detects Next.js automatically—click Deploy That's it. Your app is live.

What Vercel Provides Automatically

✅ HTTPS certificate (SSL)
✅ Global CDN (fast worldwide)
✅ Automatic deploys on every git push
✅ Preview URLs for every pull request
✅ Environment variable management
✅ Edge Network for API routes
✅ Analytics dashboard
✅ Serverless functions (your API routes)

Environment Variables

# .env.local (never commit this file)
DATABASE_URL=postgresql://user:pass@host/db
NEXT_PUBLIC_API_URL=https://api.example.com  # NEXT_PUBLIC_ = visible in browser
SECRET_API_KEY=abc123  # No prefix = server-only (secure)

// Accessing env vars
const dbUrl = process.env.DATABASE_URL;           // Server only ✅
const apiUrl = process.env.NEXT_PUBLIC_API_URL;   // Both client + server ✅

Add the same variables in Vercel's dashboard under Project → Settings → Environment Variables.

📊 Performance Wins You Get for Free

When you deploy to Vercel with Next.js:

Optimization	Technique	Gain
Static pages	Pre-rendered HTML	Near-instant load
Dynamic pages	Edge SSR	<100ms TTFB globally
Images	WebP + lazy load	30-50% smaller
Fonts	Build-time download	0ms font latency
JavaScript	Auto code-splitting	Smallest possible bundles
API Routes	Serverless functions	Scales to zero, instant cold start

💡 Final Thoughts: Next.js as a Career Investment

The jump from React developer to Next.js full-stack engineer is one of the highest-ROI moves you can make in 2025.

What changes:

You go from "I build UIs" to "I build and ship entire applications"
You stop needing a separate backend team for simple APIs
Your apps get SEO, performance, and scalability built in The learning order that makes sense:

React Fundamentals (Part 1)
        ↓
Advanced Hooks & State (Part 2)
        ↓
Performance Optimization (Part 3)
        ↓
Next.js Full-Stack ← YOU ARE HERE
        ↓
Testing (Part 5)
        ↓
Production-Grade React (Part 6)

You're not adding a new tool—you're graduating to a platform.

🔗 Quick Resources

Next.js Docs: nextjs.org/docs — The best framework docs in the ecosystem
Next.js Learn: nextjs.org/learn — Official interactive tutorial
Vercel: vercel.com — Deploy Next.js in one click
Prisma: prisma.io — Best ORM for Next.js + database
shadcn/ui: ui.shadcn.com — Component library built for Next.js

💬 What's Your Next.js Story?

Have you made the jump from React to Next.js? Are you still on the fence? What's holding you back? Drop your experience in the comments—especially if you've hit any gotchas with Server Components. That's usually where people get stuck first!

Covered in Part 5:

Unit testing with Jest & React Testing Library
Testing Server Components and API routes
Debugging with React DevTools and browser tools
Error boundaries in production
CI/CD pipeline basics

Happy shipping! 🚀

🗄️ WordPress Database Tables: The Complete Developer's Guide

Kushang Tailor — Tue, 09 Jun 2026 13:13:26 +0000

📌 What You'll Learn

What WordPress actually is under the hood (beyond the marketing pitch)
How WordPress structures its database — and why it's built that way
What database engine WordPress runs on
Every core table explained with real-world examples
Which admin panel settings map to which tables (side-by-side)
Performance and security teaser for the next article

🌐 What is WordPress?

Let's be real — most developers have a short answer ready: "It's a blogging platform." But that undersells it massively.

WordPress is an open-source Content Management System (CMS) built with PHP and backed by a MySQL-compatible database. It powers roughly 43% of all websites on the internet as of 2024. That's not a CMS anymore — that's infrastructure.

At its core, WordPress is a framework for managing content, users, settings, and relationships between all of them. When you install WordPress, it doesn't just unzip some files — it creates an entire relational database schema with 12 default tables that handle everything from your blog post drafts to your plugin options.

Here's what makes WordPress interesting from a developer's perspective:

It separates content from presentation — posts, pages, and custom post types live in the DB; themes only control how they look
It's hook-driven — the database structure is designed to be extended without modification
It stores almost everything as key-value metadata — giving it tremendous flexibility at the cost of query complexity > 💡 Developer Insight: WordPress uses the Entity-Attribute-Value (EAV) pattern for metadata (postmeta, usermeta, options). This makes it incredibly extensible but also means you'll often see wide tables replaced by tall ones.

🧱 Database Fundamentals of WordPress

Before we jump into tables, let's set the stage with some foundational concepts.

The WordPress Database Prefix

Every WordPress table has a configurable prefix — by default, wp_. This is defined in wp-config.php:

$table_prefix = 'wp_';

Why does this matter?

Security: Changing the prefix from wp_ makes SQL injection attacks targeting default table names harder
Multisite: WordPress Multisite creates additional tables for each site (e.g., wp_2_posts, wp_3_posts)
Multiple Installs: You can run multiple WordPress installs in the same database using different prefixes ### WPDB — The WordPress Database Abstraction Layer

WordPress doesn't let you write raw SQL queries directly (well, you can, but you shouldn't). It provides the global $wpdb object — an instance of the wpdb class that abstracts all database interactions:

global $wpdb;

// Safe query with placeholder
$results = $wpdb->get_results(
    $wpdb->prepare(
        "SELECT * FROM {$wpdb->posts} WHERE post_status = %s LIMIT %d",
        'publish',
        10
    )
);

The $wpdb object also gives you named table properties so you never hardcode table names:

Property	Resolves To
`$wpdb->posts`	`wp_posts`
`$wpdb->postmeta`	`wp_postmeta`
`$wpdb->users`	`wp_users`
`$wpdb->options`	`wp_options`

🐬 What Database Does WordPress Use?

WordPress officially uses MySQL or its compatible forks:

Engine	Compatibility	Notes
MySQL	✅ Full	The default and most tested
MariaDB	✅ Full	Drop-in replacement, used by most hosts
Percona Server	✅ Full	MySQL fork with performance enhancements
SQLite	⚠️ Experimental	Supported via plugin (since WP 6.1 experimental)
PostgreSQL	❌ Not Official	Possible via third-party plugins only

Minimum Requirements (as of WordPress 6.x)

MySQL: 5.7.0 or higher
MariaDB: 10.3 or higher
PHP: 7.4+ (8.0+ recommended) ### Storage Engine: InnoDB vs MyISAM

Modern WordPress installations use InnoDB as the default storage engine — and for good reason:

Feature	InnoDB	MyISAM
Foreign keys	✅	❌
Transactions	✅	❌
Row-level locking	✅	❌ (table-level)
Full-text search	✅ (MySQL 5.6+)	✅
Crash recovery	✅	⚠️ Limited

Why this matters: If you're running a high-traffic site or using WooCommerce, InnoDB's row-level locking is critical. MyISAM locks the entire table on writes — a problem when multiple users are checking out simultaneously.

📋 All WordPress Core Tables — Explained with Examples

Here's a complete walkthrough of every default table WordPress creates.

1. `wp_posts` — The Heart of WordPress

This is the most important table in the entire WordPress ecosystem. Almost everything in WordPress is a post.

Schema overview:

CREATE TABLE wp_posts (
    ID               BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
    post_author      BIGINT(20) UNSIGNED NOT NULL DEFAULT 0,
    post_date        DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
    post_date_gmt    DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
    post_content     LONGTEXT NOT NULL,
    post_title       TEXT NOT NULL,
    post_excerpt     TEXT NOT NULL,
    post_status      VARCHAR(20) NOT NULL DEFAULT 'publish',
    comment_status   VARCHAR(20) NOT NULL DEFAULT 'open',
    ping_status      VARCHAR(20) NOT NULL DEFAULT 'open',
    post_name        VARCHAR(200) NOT NULL DEFAULT '',
    post_modified    DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
    post_type        VARCHAR(20) NOT NULL DEFAULT 'post',
    PRIMARY KEY (ID)
);

What post_type stores:

`post_type` Value	What It Represents
`post`	Blog posts
`page`	Static pages
`attachment`	Media uploads
`revision`	Auto-saved revisions
`nav_menu_item`	Navigation menu items
`custom_css`	Customizer CSS
`product`	WooCommerce products
`any_cpt`	Your custom post types

Real-world example:

global $wpdb;

// Get all published posts with their authors
$posts = $wpdb->get_results(
    $wpdb->prepare(
        "SELECT ID, post_title, post_status, post_type
         FROM {$wpdb->posts}
         WHERE post_type = %s
         AND post_status = %s
         ORDER BY post_date DESC
         LIMIT %d",
        'post',
        'publish',
        5
    )
);

2. `wp_postmeta` — The Post's Extra Drawers

If wp_posts is the filing cabinet, wp_postmeta is all the sticky notes attached to each folder. Every piece of additional data tied to a post lives here.

CREATE TABLE wp_postmeta (
    meta_id    BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
    post_id    BIGINT(20) UNSIGNED NOT NULL DEFAULT 0,
    meta_key   VARCHAR(255) DEFAULT NULL,
    meta_value LONGTEXT,
    PRIMARY KEY (meta_id),
    KEY post_id (post_id),
    KEY meta_key (meta_key(191))
);

What lives in wp_postmeta:

`meta_key`	Example Value	Set By
`_thumbnail_id`	`42`	WordPress core (featured image)
`_edit_lock`	`1712345678:1`	Block editor
`_wp_page_template`	`page-full-width.php`	Theme
`_price`	`29.99`	WooCommerce
`_yoast_wpseo_title`	`My Custom SEO Title`	Yoast SEO

Real-world example:

// Get all posts that have a featured image set
$posts_with_thumbnail = $wpdb->get_col(
    "SELECT DISTINCT post_id
     FROM {$wpdb->postmeta}
     WHERE meta_key = '_thumbnail_id'"
);

⚠️ Performance Note: The meta_key index is only 191 characters long (not 255). This is a UTF-8 MB4 limitation. Long meta keys won't be indexed fully — keep your custom meta keys short and consistent.

3. `wp_users` — The User Registry

This table stores the core identity of every user on your WordPress site.

CREATE TABLE wp_users (
    ID                  BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
    user_login          VARCHAR(60) NOT NULL DEFAULT '',
    user_pass           VARCHAR(255) NOT NULL DEFAULT '',
    user_nicename       VARCHAR(50) NOT NULL DEFAULT '',
    user_email          VARCHAR(100) NOT NULL DEFAULT '',
    user_url            VARCHAR(100) NOT NULL DEFAULT '',
    user_registered     DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
    user_activation_key VARCHAR(255) NOT NULL DEFAULT '',
    user_status         INT(11) NOT NULL DEFAULT 0,
    display_name        VARCHAR(250) NOT NULL DEFAULT '',
    PRIMARY KEY (ID),
    KEY user_login_key (user_login),
    KEY user_nicename (user_nicename),
    KEY user_email (user_email)
);

🔐 Security Note: user_pass stores a hashed password using WordPress's wp_hash_password() function (based on phpass). Never store or compare plain text passwords — always use wp_check_password().

Real-world example:

// Get users registered in the last 30 days
$new_users = $wpdb->get_results(
    $wpdb->prepare(
        "SELECT ID, user_login, user_email, user_registered
         FROM {$wpdb->users}
         WHERE user_registered >= DATE_SUB(NOW(), INTERVAL %d DAY)
         ORDER BY user_registered DESC",
        30
    )
);

4. `wp_usermeta` — User Preferences and Roles

Just like wp_postmeta extends posts, wp_usermeta extends users.

CREATE TABLE wp_usermeta (
    umeta_id   BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
    user_id    BIGINT(20) UNSIGNED NOT NULL DEFAULT 0,
    meta_key   VARCHAR(255) DEFAULT NULL,
    meta_value LONGTEXT,
    PRIMARY KEY (umeta_id),
    KEY user_id (user_id),
    KEY meta_key (meta_key(191))
);

Key rows stored here:

`meta_key`	Example `meta_value`	Meaning
`wp_capabilities`	`a:1:{s:13:"administrator";b:1;}`	User role
`wp_user_level`	`10`	Legacy user level
`session_tokens`	(serialized array)	Active login sessions
`dismissed_wp_pointers`	`wp111_privacy`	Admin UI tips dismissed
`show_admin_bar_front`	`true`	Admin bar visibility

💡 Interesting Fact: User roles are stored as serialized PHP arrays in wp_usermeta. The key is {prefix}capabilities. This is why switching table prefixes can break user roles — the key name changes!

5. `wp_options` — The Site's Brain

This is arguably the most queried table in WordPress on every single page load. Every WordPress setting, every plugin configuration, every theme mod — it all ends up here.

CREATE TABLE wp_options (
    option_id    BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
    option_name  VARCHAR(191) NOT NULL DEFAULT '',
    option_value LONGTEXT NOT NULL,
    autoload     VARCHAR(20) NOT NULL DEFAULT 'yes',
    PRIMARY KEY (option_id),
    UNIQUE KEY option_name (option_name),
    KEY autoload (autoload)
);

The autoload column is critical. If set to yes, WordPress loads this option on every single page request via a single SELECT query. Too many autoloaded options = slow site.

Key options and what they control:

`option_name`	Example Value	Controls
`siteurl`	`https://example.com`	Site URL
`blogname`	`My Awesome Site`	Site title
`blogdescription`	`Just another site`	Tagline
`admin_email`	`admin@example.com`	Admin email
`active_plugins`	(serialized array)	Active plugins list
`template`	`twentytwentyfour`	Active theme
`permalink_structure`	`/%postname%/`	URL structure
`uploads_use_yearmonth_folders`	`1`	Media organization
`wp_user_roles`	(serialized array)	All defined roles

Real-world example:

// Check autoloaded options bloat
$autoloaded = $wpdb->get_results(
    "SELECT option_name, LENGTH(option_value) as option_size
     FROM {$wpdb->options}
     WHERE autoload = 'yes'
     ORDER BY option_size DESC
     LIMIT 20"
);

foreach ( $autoloaded as $option ) {
    echo esc_html( $option->option_name ) . ': ' . esc_html( size_format( $option->option_size ) ) . '<br>';
}

6. `wp_terms` — The Taxonomy Vocabulary

Terms are the individual labels — like a category named "Technology" or a tag called "JavaScript".

CREATE TABLE wp_terms (
    term_id    BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
    name       VARCHAR(200) NOT NULL DEFAULT '',
    slug       VARCHAR(200) NOT NULL DEFAULT '',
    term_group BIGINT(10) NOT NULL DEFAULT 0,
    PRIMARY KEY (term_id),
    KEY slug (slug(191)),
    KEY name (name(191))
);

7. `wp_term_taxonomy` — What Kind of Term Is It?

A term alone doesn't know if it's a category, tag, or custom taxonomy. That's wp_term_taxonomy's job.

CREATE TABLE wp_term_taxonomy (
    term_taxonomy_id BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
    term_id          BIGINT(20) UNSIGNED NOT NULL DEFAULT 0,
    taxonomy         VARCHAR(32) NOT NULL DEFAULT '',
    description      LONGTEXT NOT NULL,
    parent           BIGINT(20) UNSIGNED NOT NULL DEFAULT 0,
    count            BIGINT(20) NOT NULL DEFAULT 0,
    PRIMARY KEY (term_taxonomy_id),
    UNIQUE KEY term_id_taxonomy (term_id, taxonomy),
    KEY taxonomy (taxonomy)
);

taxonomy column values:

Value	Represents
`category`	Post categories
`post_tag`	Post tags
`nav_menu`	Navigation menus
`link_category`	Blogroll categories
`wp_theme`	Theme-related terms
`product_cat`	WooCommerce categories

8. `wp_term_relationships` — The Many-to-Many Bridge

This table connects posts to their terms. A post can have many categories; a category can have many posts. Classic many-to-many.

CREATE TABLE wp_term_relationships (
    object_id        BIGINT(20) UNSIGNED NOT NULL DEFAULT 0,
    term_taxonomy_id BIGINT(20) UNSIGNED NOT NULL DEFAULT 0,
    term_order       INT(11) NOT NULL DEFAULT 0,
    PRIMARY KEY (object_id, term_taxonomy_id),
    KEY term_taxonomy_id (term_taxonomy_id)
);

Real-world example:

// Get all posts in the "News" category (term_id = 5)
$news_posts = $wpdb->get_results(
    $wpdb->prepare(
        "SELECT p.ID, p.post_title
         FROM {$wpdb->posts} p
         INNER JOIN {$wpdb->term_relationships} tr ON p.ID = tr.object_id
         INNER JOIN {$wpdb->term_taxonomy} tt ON tr.term_taxonomy_id = tt.term_taxonomy_id
         WHERE tt.term_id = %d
         AND tt.taxonomy = %s
         AND p.post_status = %s",
        5,
        'category',
        'publish'
    )
);

9. `wp_termmeta` — Metadata for Terms

Added in WordPress 4.4, this table works the same as wp_postmeta and wp_usermeta but for taxonomy terms.

CREATE TABLE wp_termmeta (
    meta_id    BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
    term_id    BIGINT(20) UNSIGNED NOT NULL DEFAULT 0,
    meta_key   VARCHAR(255) DEFAULT NULL,
    meta_value LONGTEXT,
    PRIMARY KEY (meta_id),
    KEY term_id (term_id),
    KEY meta_key (meta_key(191))
);

Common use cases:

Storing a category's banner image ID
WooCommerce product category thumbnails
Custom taxonomy term colors or icons

10. `wp_comments` — Every Comment Ever Made

CREATE TABLE wp_comments (
    comment_ID           BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
    comment_post_ID      BIGINT(20) UNSIGNED NOT NULL DEFAULT 0,
    comment_author       TINYTEXT NOT NULL,
    comment_author_email VARCHAR(100) NOT NULL DEFAULT '',
    comment_author_url   VARCHAR(200) NOT NULL DEFAULT '',
    comment_author_IP    VARCHAR(100) NOT NULL DEFAULT '',
    comment_date         DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
    comment_date_gmt     DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
    comment_content      TEXT NOT NULL,
    comment_karma        INT(11) NOT NULL DEFAULT 0,
    comment_approved     VARCHAR(20) NOT NULL DEFAULT '1',
    comment_agent        VARCHAR(255) NOT NULL DEFAULT '',
    comment_type         VARCHAR(20) NOT NULL DEFAULT 'comment',
    comment_parent       BIGINT(20) UNSIGNED NOT NULL DEFAULT 0,
    user_id              BIGINT(20) UNSIGNED NOT NULL DEFAULT 0,
    PRIMARY KEY (comment_ID)
);

comment_approved values:

Value	Meaning
`1`	Approved (visible)
`0`	Pending moderation
`spam`	Marked as spam
`trash`	Soft deleted

11. `wp_commentmeta` — Comment Metadata

Same EAV pattern — extended data for comments. Akismet stores its spam detection data here.

CREATE TABLE wp_commentmeta (
    meta_id    BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
    comment_id BIGINT(20) UNSIGNED NOT NULL DEFAULT 0,
    meta_key   VARCHAR(255) DEFAULT NULL,
    meta_value LONGTEXT,
    PRIMARY KEY (meta_id),
    KEY comment_id (comment_id),
    KEY meta_key (meta_key(191))
);

12. `wp_links` — The Legacy Blogroll

CREATE TABLE wp_links (
    link_id          BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
    link_url         VARCHAR(255) NOT NULL DEFAULT '',
    link_name        VARCHAR(255) NOT NULL DEFAULT '',
    link_image       VARCHAR(255) NOT NULL DEFAULT '',
    link_target      VARCHAR(25) NOT NULL DEFAULT '',
    link_description VARCHAR(255) NOT NULL DEFAULT '',
    link_visible     VARCHAR(20) NOT NULL DEFAULT 'Y',
    link_owner       BIGINT(20) UNSIGNED NOT NULL DEFAULT 1,
    link_rating      INT(11) NOT NULL DEFAULT 0,
    link_updated     DATETIME NOT NULL DEFAULT '0000-00-00 00:00-00',
    link_rel         VARCHAR(255) NOT NULL DEFAULT '',
    link_notes       MEDIUMTEXT NOT NULL,
    link_rss         VARCHAR(255) NOT NULL DEFAULT '',
    PRIMARY KEY (link_id),
    KEY link_visible (link_visible)
);

📌 Worth Knowing: wp_links is a relic from the blogroll era (pre-WordPress 3.5). The Links Manager was hidden in WordPress 3.5 and is no longer shown by default. You'll still find it in the database, and some legacy plugins still use it — but for new projects, it's effectively retired.

🗺️ Admin Settings ↔ Database Table Mapping

Here's where it all comes together. This is the cheat sheet you'll want to bookmark.

Settings → General

Admin Setting	Table	`option_name` / Column
Site Title	`wp_options`	`blogname`
Tagline	`wp_options`	`blogdescription`
WordPress Address (URL)	`wp_options`	`siteurl`
Site Address (URL)	`wp_options`	`home`
Admin Email	`wp_options`	`admin_email`
Membership (Anyone can register)	`wp_options`	`users_can_register`
New User Default Role	`wp_options`	`default_role`
Site Language	`wp_options`	`WPLANG`
Timezone	`wp_options`	`timezone_string`
Date Format	`wp_options`	`date_format`
Time Format	`wp_options`	`time_format`

Settings → Reading

Admin Setting	Table	`option_name`
Your homepage displays	`wp_options`	`show_on_front` (`posts`/`page`)
Homepage (static page)	`wp_options`	`page_on_front` (stores Post ID)
Posts page	`wp_options`	`page_for_posts` (stores Post ID)
Blog pages show at most	`wp_options`	`posts_per_page`
Syndication feeds show	`wp_options`	`posts_per_rss`
Search engine visibility	`wp_options`	`blog_public`

Settings → Discussion

Admin Setting	Table	`option_name`
Allow comments on new posts	`wp_options`	`default_comment_status`
Comment must be approved	`wp_options`	`comment_moderation`
Hold comment for moderation	`wp_options`	`comment_max_links`
Comment author must have approved comment	`wp_options`	`comment_previously_approved`
Before a comment appears	`wp_options`	`require_name_email`
Notify by email (new comment)	`wp_options`	`comments_notify`

Settings → Permalinks

Admin Setting	Table	`option_name`
Permalink structure	`wp_options`	`permalink_structure`
Category base	`wp_options`	`category_base`
Tag base	`wp_options`	`tag_base`

Posts & Pages (Content)

Admin Section	Table Affected	Key Column
New Post / Draft / Publish	`wp_posts`	`post_status`, `post_date`
Post Categories	`wp_terms`, `wp_term_taxonomy`, `wp_term_relationships`	`taxonomy = 'category'`
Post Tags	`wp_terms`, `wp_term_taxonomy`, `wp_term_relationships`	`taxonomy = 'post_tag'`
Featured Image	`wp_postmeta`	`meta_key = '_thumbnail_id'`
Custom Fields	`wp_postmeta`	Any custom `meta_key`
Page Template	`wp_postmeta`	`meta_key = '_wp_page_template'`
Revisions	`wp_posts`	`post_type = 'revision'`
Media Uploads	`wp_posts`, `wp_postmeta`	`post_type = 'attachment'`

Users & Profiles

Admin Section	Table Affected	Key Column
Add New User	`wp_users`	`user_login`, `user_email`
User Role	`wp_usermeta`	`meta_key = 'wp_capabilities'`
Profile bio, URL	`wp_usermeta`	`meta_key = 'description'`, `'url'`
Application Passwords	`wp_usermeta`	`meta_key = '_application_passwords'`
Sessions	`wp_usermeta`	`meta_key = 'session_tokens'`

Appearance → Menus

Admin Section	Table Affected	Notes
Menu structure	`wp_posts`	Each item = a row with `post_type = 'nav_menu_item'`
Menu assignment	`wp_term_taxonomy`	`taxonomy = 'nav_menu'`
Menu items order	`wp_postmeta`	`meta_key = '_menu_item_menu_item_parent'`

Comments

Admin Section	Table Affected	Key Column
Approved comments	`wp_comments`	`comment_approved = '1'`
Pending comments	`wp_comments`	`comment_approved = '0'`
Spam	`wp_comments`	`comment_approved = 'spam'`
Trash	`wp_comments`	`comment_approved = 'trash'`
Akismet spam data	`wp_commentmeta`	`meta_key = 'akismet_*'`

🔍 Bonus: How WordPress Uses Its Tables Together (A Query Walkthrough)

Let's trace what happens when WordPress loads a single blog post page (/?p=42):

-- Step 1: Get the post
SELECT * FROM wp_posts WHERE ID = 42 AND post_status = 'publish';

-- Step 2: Get all post meta (custom fields, featured image, SEO data)
SELECT meta_key, meta_value FROM wp_postmeta WHERE post_id = 42;

-- Step 3: Get post categories and tags
SELECT t.name, t.slug, tt.taxonomy
FROM wp_terms t
INNER JOIN wp_term_taxonomy tt ON t.term_id = tt.term_id
INNER JOIN wp_term_relationships tr ON tt.term_taxonomy_id = tr.term_taxonomy_id
WHERE tr.object_id = 42;

-- Step 4: Get approved comments
SELECT * FROM wp_comments WHERE comment_post_ID = 42 AND comment_approved = '1';

-- Step 5: Get site options (runs on every request via autoload)
SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes';

That's a minimum of 5 queries for a single page load — and that's before any plugin adds its own. This is why query caching and object caching are so important in WordPress performance tuning (which we'll cover in the next article).

💡 Multisite: How Tables Scale

When WordPress Multisite is enabled, each subsite gets its own set of prefixed tables:

wp_posts          ← Site 1 (main)
wp_2_posts        ← Site 2
wp_3_posts        ← Site 3
wp_options        ← Site 1 (main)
wp_2_options      ← Site 2
wp_3_options      ← Site 3

But some tables are shared across the network:

Shared Table	Purpose
`wp_users`	All users across all sites
`wp_usermeta`	All user metadata (capabilities per site stored here)
`wp_blogs`	Registry of all sites in the network
`wp_site`	Network-level site data
`wp_sitemeta`	Network-level settings
`wp_blog_versions`	DB version tracking per site
`wp_registration_log`	User registration log
`wp_signups`	Pending user/blog signups

🧹 Common Database Health Issues (And Which Tables to Check)

Problem	Table to Inspect	What to Look For
Site slowing down	`wp_options`	Bloated autoloaded options
Revisions eating storage	`wp_posts`	Rows with `post_type = 'revision'`
Orphaned metadata	`wp_postmeta`	`meta_key = '_edit_lock'` with no matching post
Spam comments	`wp_comments`	`comment_approved = 'spam'` piling up
Transient clutter	`wp_options`	`option_name LIKE '_transient_%'`
User role issues	`wp_usermeta`	Corrupted `wp_capabilities` serialized data

🎯 Final Thoughts

WordPress's database schema is deceptively simple on the surface — just 12 tables. But once you understand what each table does, how they relate to each other, and how the admin panel maps directly to rows and columns, you start to see WordPress not as a blogging tool, but as a well-engineered content framework that's been refined over 20 years.

Key takeaways from this article:

wp_posts is the universal content container — not just posts, but pages, menus, attachments, and custom post types
The EAV pattern (postmeta, usermeta, options) makes WordPress extensible but requires careful query design
wp_options with autoload = 'yes' runs on every request — keep it lean
The prefix system enables multisite scalability and adds a basic security layer
Every admin UI action maps directly to a database operation you can inspect and optimize Understanding this foundation isn't just academic — it directly affects how fast your queries run, how you architect custom plugins, and how you protect your data.

🔜 Next Up: DB Performance & Security in WordPress

Now that you know what the tables are, the next article dives into how to protect and optimize them:

Indexing strategies for high-traffic WordPress sites
Transient API — the right way to cache DB queries
Query Monitor — profiling slow queries in real time
Hardening — changing table prefixes, restricting DB permissions, and preventing SQL injection
Backup strategies and point-in-time recovery
WP_Query vs $wpdb — when to use each > 📌 Save this article and follow along — the next one is where the real performance gains are.

Did this article help you understand WordPress's database structure better? Drop a comment below — especially if you've run into a tricky table-related bug in the wild. Those make the best war stories. 🛠️

Performance Optimization & Advanced Patterns in React

Kushang Tailor — Thu, 04 Jun 2026 04:27:55 +0000

Read Time: ~13 minutes | Real techniques to make your React apps genuinely fast

Prerequisites: Custom hooks, useReducer, Context API (Parts 1 & 2)

📌 What You'll Learn

By the end of this guide, you'll be able to:

✅ Understand exactly how and when React re-renders
✅ Use React.memo to stop unnecessary re-renders
✅ Apply useMemo and useCallback correctly (not blindly)
✅ Split code and lazy-load components with React.lazy + Suspense
✅ Profile and diagnose bottlenecks with React DevTools
✅ Optimize a real 1,000-item product dashboard
✅ Measure real before/after performance gains

⚡ Why Performance Actually Matters

Before jumping into code, let's anchor this in reality.

A 1-second delay in page response → 7% drop in conversions
A 100ms improvement in load time  → 1% increase in revenue (Amazon)
53% of mobile users leave          → if page takes > 3s to load

React apps can get slow in very specific ways—usually not because React itself is slow, but because we accidentally make it do more work than necessary.

The golden rule of React performance:

"Don't re-render what hasn't changed."

🔄 How React Rendering Works (The Foundation)

Before you optimize anything, you need to understand why React re-renders.

The 3 Triggers for a Re-render

1. State changes       → setState or useState setter called
2. Props change        → Parent passed new values
3. Context changes     → A Provider's value changed

The Ripple Effect (The Real Problem)

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

  return (
    <div>
      <button onClick={() => setCount(count + 1)}>Click: {count}</button>
      <Child />        {/* Re-renders every time! Even if nothing changed */}
      <AnotherChild /> {/* Re-renders too! */}
    </div>
  );
}

When Parent re-renders, every child re-renders by default—even if their props didn't change. With 50 components, this becomes a problem fast.

🛡️ React.memo: Stop Unnecessary Re-renders

React.memo is a higher-order component that memoizes your component. It only re-renders if its props actually changed.

Without React.memo (Expensive)

// ❌ ProductCard re-renders on every parent update
function ProductCard({ product }) {
  console.log(`Rendering: ${product.name}`);
  return (
    <div>
      <h3>{product.name}</h3>
      <p>${product.price}</p>
    </div>
  );
}

// In a list of 1000 products = 1000 unnecessary re-renders

With React.memo (Efficient)

// ✅ Only re-renders when product prop actually changes
const ProductCard = React.memo(function ProductCard({ product }) {
  console.log(`Rendering: ${product.name}`);
  return (
    <div>
      <h3>{product.name}</h3>
      <p>${product.price}</p>
    </div>
  );
});

Custom Comparison for React.memo

// React.memo does shallow comparison by default
// For complex objects, provide a custom comparator:

const ProductCard = React.memo(
  function ProductCard({ product, onBuyClick }) {
    return (
      <div>
        <h3>{product.name}</h3>
        <button onClick={() => onBuyClick(product.id)}>Buy</button>
      </div>
    );
  },
  // Custom comparator: only re-render if these specific fields changed
  (prevProps, nextProps) =>
    prevProps.product.id === nextProps.product.id &&
    prevProps.product.price === nextProps.product.price
);

When to use React.memo:

✅ Components that render frequently with the same props
✅ Large lists (50+ items)
✅ Components with expensive calculations in render
❌ Simple components (overhead isn't worth it)

🧠 useMemo: Cache Expensive Calculations

useMemo memoizes the result of a function. React skips recalculating it unless dependencies change.

Without useMemo (Recalculates Every Render)

function ProductDashboard({ products, filters }) {
  // ❌ This runs on EVERY render—even if products/filters didn't change
  const filteredProducts = products
    .filter(p => p.price >= filters.minPrice && p.price <= filters.maxPrice)
    .filter(p => filters.category === 'all' || p.category === filters.category)
    .sort((a, b) => b.rating - a.rating)
    .slice(0, 100);

  return <ProductList items={filteredProducts} />;
}

With useMemo (Only Recalculates When Dependencies Change)

import { useMemo } from 'react';

function ProductDashboard({ products, filters }) {
  // ✅ Only recalculates when products or filters actually change
  const filteredProducts = useMemo(() => {
    return products
      .filter(p => p.price >= filters.minPrice && p.price <= filters.maxPrice)
      .filter(p => filters.category === 'all' || p.category === filters.category)
      .sort((a, b) => b.rating - a.rating)
      .slice(0, 100);
  }, [products, filters]);

  return <ProductList items={filteredProducts} />;
}

useMemo for Derived Statistics

function SalesDashboard({ orders }) {
  // Expensive aggregation—only recalculate when orders change
  const stats = useMemo(() => ({
    totalRevenue: orders.reduce((sum, o) => sum + o.total, 0),
    averageOrder: orders.reduce((sum, o) => sum + o.total, 0) / orders.length,
    topProduct: orders
      .flatMap(o => o.items)
      .reduce((acc, item) => {
        acc[item.name] = (acc[item.name] || 0) + item.quantity;
        return acc;
      }, {}),
    conversionRate: (orders.filter(o => o.completed).length / orders.length) * 100
  }), [orders]);

  return (
    <div>
      <StatCard label="Revenue" value={`$${stats.totalRevenue}`} />
      <StatCard label="Avg Order" value={`$${stats.averageOrder.toFixed(2)}`} />
      <StatCard label="Conversion" value={`${stats.conversionRate.toFixed(1)}%`} />
    </div>
  );
}

⚠️ The useMemo Mistake Most Developers Make

// ❌ DON'T memoize cheap calculations—overhead cost > savings
const doubled = useMemo(() => count * 2, [count]);

// ✅ DO memoize genuinely expensive calculations
const processedData = useMemo(() => heavyDataTransformation(dataset), [dataset]);

Rule of thumb: Use useMemo when the calculation takes noticeable time (>1ms) or when the result is passed to a memoized child component.

📞 useCallback: Stable Function References

useCallback memoizes a function itself. This matters because new function instances on every render break React.memo.

The Problem (Why We Need useCallback)

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

  // ❌ New function reference on every render!
  // React.memo on Child won't help—it sees a "new" prop every time
  const handleClick = (id) => {
    console.log(`Clicked: ${id}`);
  };

  return (
    <>
      <button onClick={() => setCount(c => c + 1)}>Update: {count}</button>
      <MemoizedChild onItemClick={handleClick} />
    </>
  );
}

The Solution (useCallback + React.memo Pair)

import { useCallback } from 'react';

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

  // ✅ Same function reference—only changes when cart changes
  const handleAddToCart = useCallback((product) => {
    setCart(prev => [...prev, product]);
  }, []); // Empty deps—setCart is stable, no need to include

  // ✅ Same function reference—only changes when cart changes
  const handleRemoveFromCart = useCallback((productId) => {
    setCart(prev => prev.filter(p => p.id !== productId));
  }, []);

  return (
    <>
      <button onClick={() => setCount(c => c + 1)}>Update: {count}</button>
      <MemoizedProductList
        onAdd={handleAddToCart}
        onRemove={handleRemoveFromCart}
      />
    </>
  );
}

// React.memo now works correctly—stable function references
const MemoizedProductList = React.memo(function ProductList({ onAdd, onRemove }) {
  return <div>...products...</div>;
});

React.memo + useCallback = Real Gains

Without optimization: 1000 items × parent update = 1000 re-renders
With React.memo only: 1000 items × new function ref = 1000 re-renders (same!)
With React.memo + useCallback: 1000 items × same function ref = 0 re-renders ✅

✂️ Code Splitting: Load Only What You Need

A React app bundled as one giant file makes users download everything—even pages they never visit. Code splitting fixes this.

Without Code Splitting (Heavy Initial Load)

// ❌ Every page loads at startup—even ones user never visits
import Dashboard from './pages/Dashboard';
import Analytics from './pages/Analytics'; // Heavy charts library
import AdminPanel from './pages/AdminPanel'; // Rarely visited
import Reports from './pages/Reports';

function App() {
  return (
    <Routes>
      <Route path="/dashboard" element={<Dashboard />} />
      <Route path="/analytics" element={<Analytics />} />
      <Route path="/admin" element={<AdminPanel />} />
      <Route path="/reports" element={<Reports />} />
    </Routes>
  );
}

With React.lazy + Suspense (Smart Loading)

import { lazy, Suspense } from 'react';

// ✅ Each page only loads when the user navigates to it
const Dashboard  = lazy(() => import('./pages/Dashboard'));
const Analytics  = lazy(() => import('./pages/Analytics'));
const AdminPanel = lazy(() => import('./pages/AdminPanel'));
const Reports    = lazy(() => import('./pages/Reports'));

function App() {
  return (
    <Suspense fallback={<LoadingSpinner />}>
      <Routes>
        <Route path="/dashboard" element={<Dashboard />} />
        <Route path="/analytics" element={<Analytics />} />
        <Route path="/admin" element={<AdminPanel />} />
        <Route path="/reports" element={<Reports />} />
      </Routes>
    </Suspense>
  );
}

function LoadingSpinner() {
  return (
    <div style={{ display: 'flex', justifyContent: 'center', padding: '2rem' }}>
      <div className="spinner">Loading...</div>
    </div>
  );
}

Real impact: Splitting a 2 MB bundle into 6 route-based chunks means the home page loads a 300 KB chunk instead of 2 MB. That's a 6× improvement in initial load.

Component-Level Splitting (Heavy Components)

// Lazy load a heavy chart component (D3, chart.js etc.)
const HeavyChart = lazy(() => import('./components/HeavyChart'));
const RichTextEditor = lazy(() => import('./components/RichTextEditor'));

function ProductPage({ product }) {
  const [showChart, setShowChart] = useState(false);

  return (
    <div>
      <h1>{product.name}</h1>
      <button onClick={() => setShowChart(true)}>View Price History</button>

      {showChart && (
        <Suspense fallback={<p>Loading chart...</p>}>
          <HeavyChart data={product.priceHistory} />
        </Suspense>
      )}
    </div>
  );
}

🔬 React DevTools Profiler: Find Real Bottlenecks

Never guess at performance problems. The React DevTools Profiler shows you exactly what's slow.

Setup

1. Install React DevTools browser extension (Chrome/Firefox)
2. Open DevTools → "Profiler" tab
3. Click the record (●) button
4. Interact with your app
5. Stop recording
6. Analyze the flame graph

Reading the Flame Graph

Flame Graph (wider = longer render time):
┌────────────────────── App (2.1ms) ───────────────────────────────┐
│  ┌─── Header (0.1ms) ─┐  ┌────── ProductList (1.9ms) ──────────┐ │
│  └────────────────────┘  │  ┌── ProductCard (0.8ms) ───────┐   │ │
│                           │  └──────────────────────────────┘   │ │
│                           │  ┌── ProductCard (0.7ms) ───────┐   │ │
│                           │  └──────────────────────────────┘   │ │
│                           └─────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────┘

💡 ProductList is the bottleneck → optimize here first

What to Look For

🔴 Components re-rendering unnecessarily    → Use React.memo
🔴 Long render times (>16ms)               → Use useMemo
🔴 Cascading re-renders                    → Check Context usage
🔴 Functions recreating on each render     → Use useCallback
🟡 Components rendering >10ms             → Investigate closer
🟢 Components rendering <1ms              → Leave them alone

🏗️ Real-World Optimization: Product Dashboard (Before vs After)

Let's optimize a real slow component—a product dashboard with 1,000+ items.

The Slow Version (Before)

// ❌ Before optimization - renders slowly with large datasets
function ProductDashboard({ products, user }) {
  const [searchTerm, setSearchTerm] = useState('');
  const [sortBy, setSortBy] = useState('name');
  const [category, setCategory] = useState('all');

  // Recalculates on EVERY render (even typing a letter!)
  const filteredProducts = products
    .filter(p => p.name.toLowerCase().includes(searchTerm.toLowerCase()))
    .filter(p => category === 'all' || p.category === category)
    .sort((a, b) => a[sortBy] > b[sortBy] ? 1 : -1);

  // New function on every render—breaks memoization downstream
  const handleAddToWishlist = (id) => {
    api.addToWishlist(user.id, id);
  };

  return (
    <div>
      <SearchBar value={searchTerm} onChange={e => setSearchTerm(e.target.value)} />
      <FilterBar onSort={setSortBy} onCategory={setCategory} />
      <div className="product-grid">
        {filteredProducts.map(product => (
          // Re-renders ALL cards on every keystroke
          <ProductCard
            key={product.id}
            product={product}
            onWishlist={handleAddToWishlist}
          />
        ))}
      </div>
    </div>
  );
}

Performance Profile (Before):

Typing one character in search:
→ filteredProducts recalculates: 1000 items × filter × sort = ~18ms
→ All 1000 ProductCards re-render: ~45ms
→ Total: ~63ms per keystroke = janky, visible lag

The Optimized Version (After)

import { useState, useMemo, useCallback } from 'react';

// ✅ After optimization - smooth at any scale

// Memoize ProductCard so it only re-renders when its own data changes
const ProductCard = React.memo(function ProductCard({ product, onWishlist }) {
  return (
    <div className="product-card">
      <img src={product.image} alt={product.name} loading="lazy" />
      <h3>{product.name}</h3>
      <p>${product.price}</p>
      <span className="badge">{product.category}</span>
      <button onClick={() => onWishlist(product.id)}>♡ Wishlist</button>
    </div>
  );
});

function ProductDashboard({ products, user }) {
  const [searchTerm, setSearchTerm] = useState('');
  const [sortBy, setSortBy] = useState('name');
  const [category, setCategory] = useState('all');

  // ✅ Only recalculates when its dependencies change
  const filteredProducts = useMemo(() => {
    const lower = searchTerm.toLowerCase();
    return products
      .filter(p => p.name.toLowerCase().includes(lower))
      .filter(p => category === 'all' || p.category === category)
      .sort((a, b) => a[sortBy] > b[sortBy] ? 1 : -1);
  }, [products, searchTerm, category, sortBy]);

  // ✅ Same function reference—memoized children stay stable
  const handleAddToWishlist = useCallback((id) => {
    api.addToWishlist(user.id, id);
  }, [user.id]);

  return (
    <div>
      <SearchBar value={searchTerm} onChange={e => setSearchTerm(e.target.value)} />
      <FilterBar onSort={setSortBy} onCategory={setCategory} />
      <div className="product-grid">
        {filteredProducts.map(product => (
          <ProductCard
            key={product.id}
            product={product}
            onWishlist={handleAddToWishlist}
          />
        ))}
      </div>
    </div>
  );
}

Performance Profile (After):

Typing one character in search:
→ filteredProducts recalculates: still ~8ms (filtering is inherent work)
→ Only changed ProductCards re-render: ~2ms (most skip!)
→ Total: ~10ms per keystroke = smooth, no visible lag

Improvement: 63ms → 10ms = 6.3× faster 🚀

📜 Virtualization: The Nuclear Option for Long Lists

When you have 10,000+ items, even memoized renders are too slow. Virtualization renders only what's visible on screen.

import { FixedSizeList } from 'react-window'; // npm install react-window

function VirtualizedProductList({ products }) {
  const Row = ({ index, style }) => (
    <div style={style}>
      <ProductCard product={products[index]} />
    </div>
  );

  return (
    <FixedSizeList
      height={600}      // Visible container height
      itemCount={products.length}
      itemSize={120}    // Each row height in px
      width="100%"
    >
      {Row}
    </FixedSizeList>
  );
}

Without virtualization: 10,000 DOM nodes = browser struggles
With virtualization:    ~10 DOM nodes visible = butter smooth 🧈

DOM nodes rendered: 10,000 → ~10 (99.9% reduction)

📊 Performance Benchmarks: Real Numbers

Here's what these optimizations actually deliver at different scales:

Dataset Size	Before (ms)	After (ms)	Improvement
100 items	8ms	3ms	2.7× faster
500 items	28ms	6ms	4.7× faster
1,000 items	63ms	10ms	6.3× faster
5,000 items	290ms	15ms	19× faster
10,000 items	600ms+	18ms (virtual)	33× faster

Techniques Used by Dataset Size

Size	Use
1–50 items	Nothing needed
50–500 items	React.memo + useCallback
500–5,000 items	+ useMemo for filtering
5,000+ items	+ react-window virtualization

⚙️ Additional Quick Wins

1. Lazy Load Images

// ✅ Images only load when in viewport
<img src={product.image} alt={product.name} loading="lazy" />

2. Debounce Search Input

import { useMemo } from 'react';
import { debounce } from 'lodash';

function SearchBar({ onSearch }) {
  // Debounce: only fires after user stops typing for 300ms
  const debouncedSearch = useMemo(
    () => debounce(onSearch, 300),
    [onSearch]
  );

  return <input onChange={e => debouncedSearch(e.target.value)} />;
}

3. Avoid Object/Array Literals in JSX

// ❌ New object created every render
<Component style={{ color: 'red', margin: 16 }} />

// ✅ Stable reference
const STYLE = { color: 'red', margin: 16 };
<Component style={STYLE} />

4. Key Prop Best Practices

// ❌ Using index as key breaks memoization when list reorders
{items.map((item, index) => <Item key={index} item={item} />)}

// ✅ Use stable, unique ID
{items.map(item => <Item key={item.id} item={item} />)}

🎯 Performance Optimization Checklist

Before shipping any React app, run through these:

Render Efficiency
□ No unnecessary re-renders (check with Profiler)
□ React.memo on frequently-rendered components
□ useCallback for functions passed as props
□ useMemo for expensive calculations
□ Stable keys in all lists (not index)
□ Avoid new objects/arrays in JSX props

Bundle Size
□ Route-based code splitting with React.lazy
□ Heavy components split and lazy-loaded
□ Tree-shaking verified (check bundle analyzer)
□ Dependencies audited (remove unused ones)

Load Performance
□ Images have loading="lazy"
□ Search inputs debounced
□ API calls appropriately cached
□ Virtualization for lists > 1000 items

💡 The Optimization Mindset

Here's something most articles won't tell you: premature optimization is a mistake.

Don't add useMemo and useCallback everywhere by default. Every memoization adds:

Memory overhead (storing the cached value)
Complexity (developers must understand the dependency array)
Potential bugs (stale closures from wrong dependencies)

The right workflow is:

1. Build it first       → Write clean, readable code
2. Measure it           → Profile with React DevTools
3. Find the bottleneck  → Identify the actual slow part
4. Optimize that part   → Apply the right technique
5. Measure again        → Confirm improvement

"Measure, don't guess."

🔗 Quick Resources

React DevTools: Chrome Web Store → Search "React DevTools"
react-window: github.com/bvaughn/react-window — Virtualized lists
Bundle Analyzer: webpack-bundle-analyzer — Visualize your bundle
Why Did You Render: github.com/welldone-software/why-did-you-render — Track unnecessary renders
React Profiler API: react.dev/reference/react/Profiler

🚀 Final Thoughts: Fast React is Intentional React

Performance isn't luck. The patterns in this article—memoization, code splitting, virtualization, and profiling—are deliberate decisions you make at the right moment.

The hierarchy:

Step 1: Write correct, clean code first
Step 2: Profile to identify slow components
Step 3: Apply React.memo to stop re-renders
Step 4: Apply useCallback to stabilize function props
Step 5: Apply useMemo to skip expensive calculations
Step 6: Code split heavy routes and components
Step 7: Virtualize lists beyond 1000 items
Step 8: Profile again to confirm wins

You don't need all eight steps for every app—just the ones your profiler tells you to.

💬 What's Your Performance Story?

Have you ever shipped a slow React app and had to go back and optimize it? What was the bottleneck—re-renders, bundle size, or something else entirely? Drop your story in the comments!

Covered in Part 4:

Next.js file-based routing
Server vs Client Components
API routes that replace a backend
getStaticProps vs getServerSideProps
Deploying to Vercel in under 10 minutes

Happy optimizing! 🚀

Google I/O 2026: Welcome to the Agentic Gemini Era 🚀

Kushang Tailor — Tue, 02 Jun 2026 11:05:18 +0000

Ten years after going "AI-first," Google didn't just show up at I/O 2026 — it showed up with receipts.

Held on May 19–20 at the Shoreline Amphitheatre in Mountain View, California, Google I/O 2026 was less of a developer conference and more of a statement. CEO Sundar Pichai took the stage with a clear message: AI shouldn't just answer your questions — it should work for you, around the clock, across every screen you own. Here's everything that dropped, broken down cleanly.

🧠 The Star of the Show: Gemini Gets a Full Glow-Up

If there's one thread running through every single I/O 2026 announcement, it's Gemini. Google didn't just update its AI — it rebuilt the entire experience around it.

Gemini 3.5 Flash

Google launched Gemini 3.5 Flash, a faster, more efficient multimodal model built for real-world performance across devices. It's not just about raw power — it's about making AI feel instant rather than impressive.

Gemini Omni

This is the headline model. Gemini Omni can take text, images, audio, video clips — basically anything — and transform them into entirely new outputs. During the keynote demo, users changed video backgrounds, applied cinematic effects, and created selfie-based avatar videos just by describing what they wanted. All Omni-generated content is automatically watermarked via SynthID, so you'll always know what was AI-made.

Gemini Spark — Your 24/7 AI Agent

Think of Gemini Spark as the AI that never clocks out. It's a personal AI agent that proactively manages your tasks, sends you relevant updates, and keeps working in the background — even when you've moved on. It's launching first in the U.S. as part of the AI Ultra plan ($100/month) and rolls out globally soon after.

New Gemini App Design

The Gemini app got a complete redesign with a smarter search box that accepts text, images, files, videos, and even Chrome tabs as inputs. Regional dialects are now supported too, making the experience feel far more personal.

🔍 Search Just Got Its Biggest Upgrade in Decades

Google Search didn't get a tweak — it got a full rethink.

AI Mode and AI Overviews are now deeply embedded in Search, offering personalized, real-time answers that go beyond a list of links. But the real shift is that Search is now agentic — meaning it can take action, not just answer.

A new intelligent Search box accepts multi-modal inputs (text, images, video, files). And with Gemini Spark integrated, search results can evolve over time — you ask a question once, and Gemini keeps tracking it for you, delivering updates as things change.

Google also introduced "preview of perspectives" — pulling in real discussions from social media and online communities to give Search a more human dimension.

🛒 Shopping Gets Seriously Smart: Universal Cart

One of the most practical announcements? The Universal Cart — and it's genuinely clever.

Add items to your cart from anywhere in Google's ecosystem: while browsing Search, chatting with Gemini, watching YouTube, or even reading Gmail. Once items are in your cart, AI gets to work automatically — hunting for deals, tracking price history, alerting you when something's back in stock, and even flagging incompatible product combinations (live demo showed it catching a mismatched CPU and motherboard mid-build).

It integrates with Google Wallet for loyalty perks and payment optimization, and Gemini Spark can complete the checkout entirely on your behalf. Universal Cart rolls out in the U.S. this summer, with YouTube and Gmail support following shortly after.

👓 Hardware: The Glasses Are (Almost) Here

The most buzz-worthy hardware reveal? Android XR intelligent eyewear — co-developed with Samsung, with designs from Warby Parker and Gentle Monster.

Audio Glasses (arriving Fall 2026) let you listen to music, take calls, make coffee orders, take photos, and access Gemini — all hands-free. Think Ray-Ban Meta glasses, but running on Google's full AI stack.

Display Glasses are still in development, promising in-lens information overlays and live language translation, coming at a later date.

🎬 Creative Tools: Google Flow, Stitch & More

Google expanded its creative suite in a big way:

Google Flow now covers video editing, music production, and creative workflows — all powered by Gemini Omni inside for multi-action jumps across audio and video.
Google Flow Music debuts as a standalone creative tool.
Flow Tools let you customize AI generation agents to match your creative style.
Stitch and Google Pics get new updates empowering designers and marketers to streamline content production with less back-and-forth.

🧑‍💻 Developer Tools: Antigravity 2.0 & AI Studio

Developers weren't left out — not by a long shot.

Antigravity 2.0, Google's answer to GitHub Copilot and Claude Code, launches as a full agent-first desktop IDE powered by Gemini 3.5 Flash. It runs 12x faster on token usage compared to the previous version, supports multi-agent orchestration, and integrates directly with Google Workspace APIs. It's available globally, for free.

Google AI Studio also got major upgrades — native Kotlin support for building Android apps, Workspace integration, and one-click deployment to Cloud Run. There's also a new Migration Agent in Android Studio that converts React Native, iOS, or web-based apps into native Kotlin Android apps — turning weeks of work into just hours.

WebMCP, a proposed open web standard, lets developers expose browser-based tools to AI agents for faster, more precise execution — with an experimental origin trial starting in Chrome 149.

🔬 Gemini for Science: AI That Could Change the World

Perhaps the most quietly significant announcement was Gemini for Science — a collection of AI research tools paired with a Co-Scientist collaborative AI partner designed to help researchers accelerate discoveries. Google demonstrated Gemini running full-scale weather and meteorological simulations, and even modeling cellular behavior to help identify new disease treatments. This isn't just cool tech — it's AI working on genuinely hard problems.

🔒 AI Safety & Transparency: SynthID + CodeMender

Google doubled down on responsible AI development. SynthID — Google's digital watermarking tech — has now embedded imperceptible signals into over 100 billion images, videos, and audio content totalling 60,000 years of material.

The new C2PA content credentials are coming to Gemini and Chrome, letting you right-click any image in Chrome and ask Gemini whether it was AI-generated or camera-captured — and whether it was edited with AI afterward.

For developers, the CodeMender API helps identify and resolve software vulnerabilities automatically, making security less of an afterthought.

⚡ The Engine Behind It All: TPU 8th Gen

Behind every fast AI experience is infrastructure, and Google's is formidable. The 8th-generation TPUs take a dual-chip approach — TPU 8t for large-scale pretraining (nearly 3x the raw computing power of the previous gen) and TPU 8i for inference. Training can now be distributed across more than 1 million TPUs globally, making Google's the largest training cluster in the world.

The Big Picture

Google I/O 2026 wasn't about one killer feature — it was about one clear direction. Gemini is no longer a chatbot. It's becoming the invisible layer running underneath Search, Gmail, YouTube, shopping, your glasses, and your daily workflow. Whether that excites or unnerves you might depend on your comfort with AI doing more of your thinking for you.

But one thing is clear: Google is moving fast, and this year's I/O was less of a preview and more of a promise.

Did a specific announcement catch your eye? Drop a comment — we'd love to know what you're most excited (or worried) about.

Advanced Hooks & State Management Patterns in React

Kushang Tailor — Fri, 29 May 2026 12:51:09 +0000

Read Time: ~14 minutes | Building on React fundamentals to master state management at scale

Prerequisites: Familiarity with React basics, useState, useEffect (Part 1)

📌 What You'll Learn

By the end of this guide, you'll understand:

✅ Creating powerful custom hooks
✅ When and how to use useReducer
✅ Managing state globally with Context API
✅ Redux fundamentals and when to use it
✅ Modern alternatives: Zustand and Jotai
✅ Choosing the right pattern for your project
✅ Real-world shopping cart implementation

🎣 Custom Hooks: Reusing Logic Across Components

Custom hooks are regular JavaScript functions that let you extract component logic into reusable functions. They're one of the most powerful React patterns.

Rule #1: Custom Hooks Must Start with "use"

// ✅ Correct - starts with "use"
function useFormInput(initialValue) {
  const [value, setValue] = useState(initialValue);

  return {
    value,
    bind: {
      value,
      onChange: e => setValue(e.target.value)
    },
    reset: () => setValue(initialValue)
  };
}

// ❌ Wrong - doesn't start with "use"
function formInput(initialValue) { ... }

Example #1: useFormInput Hook

import { useState } from 'react';

function useFormInput(initialValue = '') {
  const [value, setValue] = useState(initialValue);

  return {
    value,
    setValue,
    bind: {
      value,
      onChange: e => setValue(e.target.value)
    },
    reset: () => setValue(initialValue)
  };
}

// Using the custom hook
function LoginForm() {
  const email = useFormInput('');
  const password = useFormInput('');

  const handleSubmit = (e) => {
    e.preventDefault();
    console.log(email.value, password.value);
    email.reset();
    password.reset();
  };

  return (
    <form onSubmit={handleSubmit}>
      <input {...email.bind} placeholder="Email" type="email" />
      <input {...password.bind} placeholder="Password" type="password" />
      <button type="submit">Login</button>
    </form>
  );
}

Why it's powerful: Logic is extracted once, reused everywhere. Need form input validation? Add it once to the hook.

Example #2: useFetch Hook - Data Loading Pattern

This is one of the most practical custom hooks for real projects:

import { useState, useEffect } from 'react';

function useFetch(url, options = {}) {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    let isMounted = true; // Prevent memory leaks

    const fetchData = async () => {
      try {
        setLoading(true);
        const response = await fetch(url, options);
        if (!response.ok) throw new Error(`Error: ${response.status}`);

        const json = await response.json();
        if (isMounted) setData(json);
      } catch (err) {
        if (isMounted) setError(err.message);
      } finally {
        if (isMounted) setLoading(false);
      }
    };

    fetchData();
    return () => { isMounted = false; }; // Cleanup
  }, [url, options]);

  return { data, loading, error };
}

// Using it
function ProductList() {
  const { data: products, loading, error } = useFetch('/api/products');

  if (loading) return <p>Loading products...</p>;
  if (error) return <p>Error: {error}</p>;

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

Key insight: The component doesn't need to know about fetch logic—it just uses the hook.

Example #3: useLocalStorage Hook - Persistence Pattern

function useLocalStorage(key, initialValue) {
  const [storedValue, setStoredValue] = useState(() => {
    try {
      const item = window.localStorage.getItem(key);
      return item ? JSON.parse(item) : initialValue;
    } catch (error) {
      console.error(error);
      return initialValue;
    }
  });

  const setValue = (value) => {
    try {
      const valueToStore = value instanceof Function ? value(storedValue) : value;
      setStoredValue(valueToStore);
      window.localStorage.setItem(key, JSON.stringify(valueToStore));
    } catch (error) {
      console.error(error);
    }
  };

  return [storedValue, setValue];
}

// Using it - Dark mode preference persists across page reloads
function App() {
  const [isDarkMode, setIsDarkMode] = useLocalStorage('darkMode', false);

  return (
    <div className={isDarkMode ? 'dark' : 'light'}>
      <button onClick={() => setIsDarkMode(!isDarkMode)}>
        Toggle Dark Mode
      </button>
    </div>
  );
}

🔄 useReducer: Complex State Logic

When you have multiple state variables that depend on each other, useReducer is cleaner than useState.

useReducer vs useState

Scenario	Best Choice
Single simple value (count, toggle)	useState
Multiple related values	useReducer
State depends on previous state	useReducer
Complex state transitions	useReducer
Need to pass dispatch to children	useReducer

Complete useReducer Example: Todo App

import { useReducer } from 'react';

// Reducer function - pure, testable
function todoReducer(state, action) {
  switch(action.type) {
    case 'ADD_TODO':
      return {
        ...state,
        todos: [...state.todos, {
          id: Date.now(),
          text: action.payload,
          completed: false
        }]
      };

    case 'TOGGLE_TODO':
      return {
        ...state,
        todos: state.todos.map(todo =>
          todo.id === action.payload
            ? { ...todo, completed: !todo.completed }
            : todo
        )
      };

    case 'DELETE_TODO':
      return {
        ...state,
        todos: state.todos.filter(todo => todo.id !== action.payload)
      };

    case 'SET_FILTER':
      return { ...state, filter: action.payload };

    default:
      return state;
  }
}

function TodoApp() {
  const initialState = {
    todos: [],
    filter: 'all' // all, active, completed
  };

  const [state, dispatch] = useReducer(todoReducer, initialState);

  const filteredTodos = state.todos.filter(todo => {
    if (state.filter === 'active') return !todo.completed;
    if (state.filter === 'completed') return todo.completed;
    return true;
  });

  return (
    <div>
      <input
        onKeyPress={(e) => {
          if (e.key === 'Enter') {
            dispatch({ type: 'ADD_TODO', payload: e.target.value });
            e.target.value = '';
          }
        }}
        placeholder="Add a todo..."
      />

      <ul>
        {filteredTodos.map(todo => (
          <li key={todo.id}>
            <input
              type="checkbox"
              checked={todo.completed}
              onChange={() => dispatch({ 
                type: 'TOGGLE_TODO', 
                payload: todo.id 
              })}
            />
            <span style={{
              textDecoration: todo.completed ? 'line-through' : 'none'
            }}>
              {todo.text}
            </span>
            <button onClick={() => dispatch({ 
              type: 'DELETE_TODO', 
              payload: todo.id 
            })}>
              Delete
            </button>
          </li>
        ))}
      </ul>

      <div>
        {['all', 'active', 'completed'].map(f => (
          <button
            key={f}
            onClick={() => dispatch({ type: 'SET_FILTER', payload: f })}
            style={{
              fontWeight: state.filter === f ? 'bold' : 'normal'
            }}
          >
            {f.charAt(0).toUpperCase() + f.slice(1)}
          </button>
        ))}
      </div>
    </div>
  );
}

Why useReducer wins here:

All state changes go through dispatch—easy to debug and test
Reducer is a pure function—predictable and testable
Complex state logic stays organized in one place

🌍 Context API: Global State Without Libraries

Context API lets you share state across components without prop drilling.

Problem: Prop Drilling

// ❌ Passing props through 5 levels is messy
<App theme={theme} />
  <Header theme={theme} />
    <Nav theme={theme} />
      <Button theme={theme} />

Solution: Context API

import { createContext, useContext, useState } from 'react';

// Step 1: Create context
const ThemeContext = createContext();

// Step 2: Create provider component
export function ThemeProvider({ children }) {
  const [isDark, setIsDark] = useState(false);

  const value = {
    isDark,
    toggleTheme: () => setIsDark(prev => !prev),
    colors: isDark
      ? { bg: '#1a1a1a', text: '#ffffff' }
      : { bg: '#ffffff', text: '#000000' }
  };

  return (
    <ThemeContext.Provider value={value}>
      {children}
    </ThemeContext.Provider>
  );
}

// Step 3: Create custom hook to use context
export function useTheme() {
  const context = useContext(ThemeContext);
  if (!context) {
    throw new Error('useTheme must be used within ThemeProvider');
  }
  return context;
}

// Step 4: Wrap your app
function App() {
  return (
    <ThemeProvider>
      <Header />
      <MainContent />
      <Footer />
    </ThemeProvider>
  );
}

// Step 5: Use anywhere
function Button() {
  const { isDark, toggleTheme, colors } = useTheme();

  return (
    <button
      onClick={toggleTheme}
      style={{ background: colors.bg, color: colors.text }}
    >
      {isDark ? '☀️ Light' : '🌙 Dark'}
    </button>
  );
}

When to use Context API:

✅ Theme settings (light/dark mode)
✅ User authentication state
✅ Language/locale preferences
❌ Frequently changing data (performance issues)

📦 Redux: Enterprise-Grade State Management

Redux is a predictable state container. It's overkill for small apps but essential for large ones.

Redux Flow

Action → Reducer → Store → Components Update

Complete Redux Example: Shopping Cart

import { createStore } from 'redux';

// Step 1: Define initial state
const initialState = {
  items: [],
  total: 0,
  loading: false
};

// Step 2: Create reducer
function cartReducer(state = initialState, action) {
  switch(action.type) {
    case 'ADD_ITEM':
      const existingItem = state.items.find(
        item => item.id === action.payload.id
      );

      if (existingItem) {
        return {
          ...state,
          items: state.items.map(item =>
            item.id === action.payload.id
              ? { ...item, quantity: item.quantity + 1 }
              : item
          ),
          total: state.total + action.payload.price
        };
      }

      return {
        ...state,
        items: [...state.items, { ...action.payload, quantity: 1 }],
        total: state.total + action.payload.price
      };

    case 'REMOVE_ITEM':
      const removedItem = state.items.find(
        item => item.id === action.payload
      );
      return {
        ...state,
        items: state.items.filter(item => item.id !== action.payload),
        total: state.total - (removedItem.price * removedItem.quantity)
      };

    case 'CLEAR_CART':
      return initialState;

    default:
      return state;
  }
}

// Step 3: Create store
const store = createStore(cartReducer);

// Step 4: Dispatch actions
store.dispatch({
  type: 'ADD_ITEM',
  payload: { id: 1, name: 'Laptop', price: 1200 }
});

console.log(store.getState());
// { items: [{id: 1, name: 'Laptop', price: 1200, quantity: 1}], total: 1200 }

Redux Pros & Cons:

✅ Predictable state changes
✅ Time-travel debugging (Redux DevTools)
✅ Great for large, complex apps
❌ Boilerplate code (actions, reducers, selectors)
❌ Steep learning curve

⚡ Zustand: Lightweight Alternative to Redux

Zustand is simpler than Redux with minimal boilerplate.

import { create } from 'zustand';

// Create store in one place
const useCartStore = create((set) => ({
  items: [],
  total: 0,

  // Actions
  addItem: (item) => set((state) => ({
    items: [...state.items, item],
    total: state.total + item.price
  })),

  removeItem: (id) => set((state) => {
    const removedItem = state.items.find(item => item.id === id);
    return {
      items: state.items.filter(item => item.id !== id),
      total: state.total - removedItem.price
    };
  }),

  clearCart: () => set({
    items: [],
    total: 0
  })
}));

// Use anywhere - no Provider needed!
function ShoppingCart() {
  const { items, total, removeItem } = useCartStore();

  return (
    <div>
      <h2>Cart: ${total}</h2>
      {items.map(item => (
        <div key={item.id}>
          {item.name} - ${item.price}
          <button onClick={() => removeItem(item.id)}>Remove</button>
        </div>
      ))}
    </div>
  );
}

Why Zustand is Awesome:

✅ No Provider wrapper needed
✅ Minimal boilerplate
✅ Great performance
✅ TypeScript friendly
✅ Smaller bundle size

🎯 Jotai: Atom-Based State Management

Jotai takes a different approach—primitive atoms instead of a single store.

import { atom, useAtom } from 'jotai';

// Create atoms (primitive pieces of state)
const cartItemsAtom = atom([]);
const cartTotalAtom = atom(0);

// Derived atom (computed from other atoms)
const cartCountAtom = atom(
  (get) => get(cartItemsAtom).length
);

// Use atoms in components
function ShoppingCart() {
  const [items, setItems] = useAtom(cartItemsAtom);
  const [total, setTotal] = useAtom(cartTotalAtom);
  const [count] = useAtom(cartCountAtom);

  const addItem = (item) => {
    setItems([...items, item]);
    setTotal(total + item.price);
  };

  return (
    <div>
      <h2>Cart ({count} items): ${total}</h2>
      <button onClick={() => addItem({ name: 'Laptop', price: 1200 })}>
        Add Laptop
      </button>
    </div>
  );
}

Jotai Benefits:

✅ Fine-grained reactivity
✅ Only components using changed atoms re-render
✅ Great for complex interdependent state
✅ No Provider overhead

🛒 Real-World Example: Shopping Cart with Multiple Patterns

Let's build a shopping cart using Context API + useReducer (the practical combination):

import { createContext, useContext, useReducer } from 'react';

// 1. Create context
const CartContext = createContext();

// 2. Reducer
function cartReducer(state, action) {
  switch(action.type) {
    case 'ADD_TO_CART': {
      const existingItem = state.items.find(
        item => item.id === action.payload.id
      );

      if (existingItem) {
        return {
          ...state,
          items: state.items.map(item =>
            item.id === action.payload.id
              ? { ...item, quantity: item.quantity + 1 }
              : item
          )
        };
      }

      return {
        ...state,
        items: [...state.items, { ...action.payload, quantity: 1 }]
      };
    }

    case 'REMOVE_FROM_CART':
      return {
        ...state,
        items: state.items.filter(item => item.id !== action.payload)
      };

    case 'UPDATE_QUANTITY':
      return {
        ...state,
        items: state.items.map(item =>
          item.id === action.payload.id
            ? { ...item, quantity: action.payload.quantity }
            : item
        ).filter(item => item.quantity > 0)
      };

    case 'CLEAR_CART':
      return { ...state, items: [] };

    default:
      return state;
  }
}

// 3. Provider component
export function CartProvider({ children }) {
  const [state, dispatch] = useReducer(cartReducer, { items: [] });

  const total = state.items.reduce(
    (sum, item) => sum + (item.price * item.quantity),
    0
  );

  const value = {
    items: state.items,
    total,
    addToCart: (product) => dispatch({ type: 'ADD_TO_CART', payload: product }),
    removeFromCart: (id) => dispatch({ type: 'REMOVE_FROM_CART', payload: id }),
    updateQuantity: (id, quantity) => dispatch({
      type: 'UPDATE_QUANTITY',
      payload: { id, quantity }
    }),
    clearCart: () => dispatch({ type: 'CLEAR_CART' })
  };

  return (
    <CartContext.Provider value={value}>
      {children}
    </CartContext.Provider>
  );
}

// 4. Custom hook
export function useCart() {
  const context = useContext(CartContext);
  if (!context) {
    throw new Error('useCart must be used within CartProvider');
  }
  return context;
}

// 5. Usage
function ProductCard({ product }) {
  const { addToCart } = useCart();

  return (
    <div>
      <h3>{product.name}</h3>
      <p>${product.price}</p>
      <button onClick={() => addToCart(product)}>
        Add to Cart
      </button>
    </div>
  );
}

function Cart() {
  const { items, total, removeFromCart, updateQuantity } = useCart();

  return (
    <div>
      <h2>Shopping Cart</h2>
      {items.length === 0 ? (
        <p>Your cart is empty</p>
      ) : (
        <>
          {items.map(item => (
            <div key={item.id}>
              <h4>{item.name}</h4>
              <input
                type="number"
                value={item.quantity}
                onChange={(e) => updateQuantity(item.id, parseInt(e.target.value))}
              />
              <p>${item.price * item.quantity}</p>
              <button onClick={() => removeFromCart(item.id)}>Remove</button>
            </div>
          ))}
          <h3>Total: ${total.toFixed(2)}</h3>
        </>
      )}
    </div>
  );
}

// 6. App structure
function App() {
  return (
    <CartProvider>
      <ProductCard product={{ id: 1, name: 'Laptop', price: 1200 }} />
      <Cart />
    </CartProvider>
  );
}

🎯 Choosing Your State Management Tool

Decision Tree

Is your app small (< 5 components)?
├─ Yes → Use useState directly
└─ No → Continue

Do you need to share state between many components?
├─ Yes → Continue
└─ No → Use useState + prop drilling

Is the state changing frequently (> 10 times/sec)?
├─ Yes → Use Jotai or Zustand
└─ No → Continue

Is your team familiar with Redux?
├─ Yes → Consider Redux
└─ No → Consider Zustand

Do you need middleware (logging, analytics)?
├─ Yes → Use Redux
└─ No → Use Zustand or Context API

Quick Comparison

Tool	Best For	Learning Curve	Bundle Size
useState	Simple state	Easiest	0 KB
useReducer	Complex state	Easy	0 KB
Context API	Theme, auth	Easy	0 KB
Redux	Large apps	Hard	10 KB
Zustand	Medium apps	Easy	2 KB
Jotai	Granular updates	Medium	5 KB

🎓 Performance Considerations

Context API Performance Pitfall

// ❌ BAD - Entire app re-renders on state change
function ThemeProvider({ children }) {
  const [isDark, setIsDark] = useState(false);

  return (
    <ThemeContext.Provider value={{ isDark, setIsDark }}>
      {children}
    </ThemeContext.Provider>
  );
}

// ✅ GOOD - Memoize context value
function ThemeProvider({ children }) {
  const [isDark, setIsDark] = useState(false);

  const value = useMemo(() => ({ isDark, setIsDark }), [isDark]);

  return (
    <ThemeContext.Provider value={value}>
      {children}
    </ThemeContext.Provider>
  );
}

Key insight: Zustand and Jotai automatically optimize this. Redux requires careful selector use.

🚀 Advanced Pattern: Combining Approaches

Real projects often use multiple state management tools:

// Global app state → Redux/Zustand
// Theme & Auth → Context API
// UI state (modals, dropdowns) → useState
// Form data → Custom useForm hook

This is normal and healthy—don't over-engineer.

💡 Final Thoughts: State Management Maturity

Beginner Phase

Use useState everywhere
Props for simple sharing
useReducer when state gets complex

Intermediate Phase

Context API for theme, auth, user
useReducer for complex components
Custom hooks for reusable logic

Advanced Phase

Zustand for app state
Context for cross-cutting concerns
Jotai for highly granular updates
Redux only if you have 50+ components

📚 Key Takeaways

Custom hooks are the foundation—master these first
useReducer scales better than useState for complex state
Context API is perfect for theme/auth, not data caches
Zustand is the modern, simple alternative to Redux
Jotai excels at fine-grained reactivity
Choose based on app size, not hype

🔗 Quick Resources

Redux Docs: redux.js.org
Zustand: github.com/pmndrs/zustand
Jotai: jotai.org
React Query (for server state): tanstack.com/query
Context API Docs: react.dev/reference/react/useContext

💬 What's Your State Management Journey?

Have you struggled with prop drilling? Built a custom hook? Migrated from Redux? Share your experience in the comments—I'd love to hear what state management patterns your team uses!

Covered in Part 3:

useMemo & useCallback deep dive
Code splitting and lazy loading
Suspense and React.lazy()
Performance profiling with DevTools
Real optimization case studies

Happy state managing! 🚀

⚡ WordPress Performance: The Real Truth They Don't Tell You

Kushang Tailor — Sat, 23 May 2026 11:07:01 +0000

Security myths, speed secrets & a practical step-by-step guide

Let's be honest for a second. Somewhere on the internet, there's a developer passionately arguing that WordPress is "garbage," and a dozen others defending it to their last breath. The reality? It's somewhere in the middle — and that's what we're going to dig into today.

WordPress powers 43%+ of the entire web as of 2026. That's not a typo. Almost half of every website you've visited today probably runs on it. But with great popularity comes great responsibility — and unfortunately, also great misunderstanding, especially around performance and security.

So grab your coffee ☕, because we're going to bust some myths, look at some real-world security news, and then give you a proper no-nonsense roadmap to making your WordPress site scream fast.

📖 Table of Contents

The "Fragile CMS" Myth & Real Truth About WordPress Security
What Is Performance in WordPress?
Why Performance Actually Matters
Global News: WordPress Security in 2024–2025
Step-by-Step: How to Improve WordPress Performance
Bonus Performance Points Worth Knowing

1. 🔓 The "Fragile CMS" Myth & Real Truth About WordPress Security

"WordPress is insecure." If you've been in web development for more than five minutes, you've heard this. And while there's some truth buried in there, the full picture is way more nuanced.

Is WordPress inherently insecure?

No. WordPress core itself is well-maintained by a large dedicated security team and gets rapid patches. The real culprits? Plugins, themes, and user behavior.

Stat	Figure
WP hacks via vulnerable plugins or themes	97%
Share of entire web running on WordPress (2026)	43%
Plugins in the official repository	59,000+
Average time WordPress patches a critical CVE	~14 days

⚠️ Real Talk: Using an outdated plugin with a known vulnerability on 40% of the web is a massive attack surface. That's not WordPress being fragile — that's the plugin ecosystem carrying risks at scale.

What actually makes WordPress "fragile"?

✅ Abandoned plugins — Installed years ago, never updated, now a liability.
✅ Nulled themes — "Free premium" themes from shady sources often contain backdoors.
✅ Weak credentials — Admin username still "admin"? Password "123456"? That's an open door.
✅ No SSL / HTTPS — Transmitting data in plain text in 2026 is unacceptable.
✅ Shared hosting environments — One compromised site on a shared server can bleed into others.
✅ No WAF (Web Application Firewall) — Letting all traffic directly hit your app server.

✅ The Truth: WordPress is as secure as you make it. The CMS itself is solid. The responsibility lies with developers and site owners. A well-configured WordPress site with updated software, proper roles, and a WAF is genuinely hard to crack.

2. 🚀 What Is Performance in WordPress?

When developers talk about "WordPress performance," they usually mean a mix of several things — not just one magic number. Think of it as a health score for your website, measured from multiple angles.

Metric	What It Measures	Target
LCP (Largest Contentful Paint)	How fast the biggest element loads	< 2.5s
FID (First Input Delay)	How fast the page responds to first interaction	< 100ms
CLS (Cumulative Layout Shift)	Visual stability — do things jump around?	< 0.1
TTFB (Time to First Byte)	Server response speed	< 600ms
INP (Interaction to Next Paint)	Overall responsiveness of the page	< 200ms

These are Google's Core Web Vitals — and they directly affect your Google Search ranking. Slow WordPress site? Lower SEO. It's that simple and that brutal.

💡 Did You Know? Google officially uses Core Web Vitals as a ranking signal since 2021. A 1-second improvement in page load time can increase conversions by up to 7%. That's not a nerd stat — that's real money.

3. 💰 Why Performance Actually Matters

You might think performance is a "nice to have" thing — something you tackle after your site is already live and humming. But performance is foundational to everything: user experience, revenue, and even security.

The Business Case 📊

Stat	Impact
53%	of users abandon a page that takes longer than 3 seconds
7%	conversion drop for every 1-second delay
2×	faster sites get 2x more organic traffic on average
#1	factor in user satisfaction per Google UX research

The Security Connection 🔒

Here's something most tutorials miss: Performance and security are deeply connected. A slow WordPress site is often a symptom of bloated, outdated, or poorly coded plugins — the exact same things that create security holes. When you optimize performance, you almost always improve security too.

Removing unused plugins = fewer attack vectors
Enabling caching = less DB load = less attack surface
Using a CDN = DDoS mitigation + speed
Optimizing images = faster loads + cleaner codebase

4. 📰 Global News: WordPress Security in 2024–2025

Let's look at some real incidents — because nothing drives home the importance of performance + security like actual events.

🗞️ October 2024 — WPScan / Wordfence

LiteSpeed Cache Plugin — 6M+ Sites Affected

A critical privilege escalation vulnerability was found in the LiteSpeed Cache plugin, which has over 6 million active installs. The flaw allowed unauthenticated users to gain admin-level access. It was patched quickly, but millions of sites running unpatched versions remained exposed for weeks.

🗞️ January 2025 — Patchstack

WordPress Supply Chain Attack via Nulled Plugin Repositories

Attackers embedded malicious code into cracked/nulled versions of popular WordPress plugins distributed on unofficial sites. Sites using these plugins were silently backdoored, with data being siphoned to external servers for months before detection.

🗞️ March 2025 — WordPress.org

The WP Engine Controversy & Plugin Access Dispute

A high-profile legal and operational dispute between Automattic and WP Engine raised questions about plugin repository access control, with some plugins being temporarily pulled — highlighting the fragility of relying on third-party hosting ecosystems for critical site infrastructure.

🔑 Takeaway: The common thread across all these incidents? Plugins + outdated software + lack of monitoring. A fast, well-maintained WordPress site is almost always a more secure one too.

5. 🛠️ Step-by-Step: How to Improve WordPress Performance

Here's a practical, step-by-step playbook. Each step includes a short example so you can actually do something today — not just read and feel good about it.

Step 1 — Choose the Right Hosting 🏗️

Your hosting is your performance foundation. No amount of optimization can fix bad hosting. Go with a host that offers PHP 8.2+, server-side caching (OPcache), and NVMe SSD storage.

💡 Quick Pick: Managed WordPress: Kinsta, WP Engine, or Cloudways. VPS: DigitalOcean + ServerPilot or Nginx + PHP-FPM.

Step 2 — Enable PHP OPcache & Upgrade to PHP 8.2+ 🐘

PHP 8.2 is significantly faster than PHP 7.x. Combined with OPcache (which caches compiled PHP bytecode), you can cut server-side execution time by 30–50%.

; Enable OPcache in php.ini
opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.revalidate_freq=0
opcache.fast_shutdown=1

Step 3 — Implement Full-Page Caching 🗄️

Caching is the single biggest performance win for most WordPress sites. Instead of generating every page dynamically, caching serves pre-built HTML files to visitors.

// Add to wp-config.php
define( 'WP_CACHE', true );

// Use with a caching plugin like WP Rocket, W3 Total Cache,
// or LiteSpeed Cache (after patching!)

⭐ Recommended Plugins: WP Rocket (paid, best DX), LiteSpeed Cache (free, great on LiteSpeed servers), W3 Total Cache (free, powerful but complex).

Step 4 — Optimize Your Database 🗃️

WordPress databases accumulate garbage over time: post revisions, spam comments, transient options, orphaned metadata. Clean them regularly.

// Limit post revisions to 3 (default is unlimited!)
define( 'WP_POST_REVISIONS', 3 );

// Or disable revisions entirely for heavy content sites
define( 'WP_POST_REVISIONS', false );

-- Remove all auto-drafts
DELETE FROM wp_posts WHERE post_status = 'auto-draft';

-- Clean expired transients
DELETE FROM wp_options
WHERE option_name LIKE '_transient_%'
AND option_value < UNIX_TIMESTAMP();

Step 5 — Optimize Images 🖼️

Images are typically 60–80% of a page's total weight. This is the easiest win on any WordPress site.

A. Convert to WebP format
WebP is 25–35% smaller than JPEG at comparable quality. Use Imagify, ShortPixel, or the built-in WordPress WebP support (6.1+).

B. Add lazy loading
WordPress 5.5+ adds loading="lazy" to images by default. Make sure it's not disabled in your theme.

C. Use proper image dimensions
Don't upload a 4000×3000px image and let CSS scale it down. Always resize to the largest display size you actually need.

// Allow WebP uploads (WordPress 5.8+ handles this natively)
add_filter(
    'upload_mimes',
    function( $mimes ) {
        $mimes['webp'] = 'image/webp';
        return $mimes;
    }
);

Step 6 — Minify & Dequeue Unused CSS/JS Assets ⚙️

Every unminified JavaScript or CSS file is extra kilobytes and an extra HTTP request. Minification strips comments and whitespace; removing unused scripts cuts load entirely.

// Dequeue scripts you don't actually need
add_action( 'wp_enqueue_scripts', function() {
    // Remove comment-reply JS from non-singular pages
    if ( ! is_singular() || ! comments_open() ) {
        wp_dequeue_script( 'comment-reply' );
    }

    // Remove block library CSS if not using Gutenberg blocks
    wp_dequeue_style( 'wp-block-library' );
    wp_dequeue_style( 'wp-block-library-theme' );
}, 100 );

Step 7 — Use a CDN (Content Delivery Network) 🌐

A CDN caches your static assets (images, CSS, JS) across global servers and serves them from the closest node to your visitor. A user in Tokyo shouldn't be fetching your CSS from a server in New York.

✅ CDN Options: Cloudflare (free tier is excellent, includes WAF), BunnyCDN (affordable, fast), KeyCDN. Most caching plugins integrate directly with these.

Step 8 — Optimize WP_Query & Reduce Database Queries 🔍

Every time WordPress loads a page, it runs multiple database queries. Bad custom queries can balloon this from 20 to 200+. Keep your queries lean.

// ❌ Bad — fetches all post data unnecessarily
$bad_query = new WP_Query([
    'post_type'      => 'post',
    'posts_per_page' => 10,
]);

// ✅ Good — optimized, no unnecessary data
$good_query = new WP_Query([
    'post_type'               => 'post',
    'posts_per_page'          => 10,
    'no_found_rows'           => true,  // Skip count query
    'update_post_meta_cache'  => false, // Skip meta cache
    'update_post_term_cache'  => false, // Skip term cache
    'fields'                  => 'ids', // Only get IDs
]);

Step 9 — Enable GZIP / Brotli Compression 📦

Text-based assets (HTML, CSS, JS) compress extremely well. Brotli can reduce file sizes 20–26% more than GZIP. Enable it at the server level.

# .htaccess — Enable GZIP (Apache)
<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html
  AddOutputFilterByType DEFLATE text/css
  AddOutputFilterByType DEFLATE application/javascript
  AddOutputFilterByType DEFLATE application/json
  AddOutputFilterByType DEFLATE image/svg+xml
</IfModule>

Step 10 — Use Object Caching with Redis or Memcached 🚀

Object caching stores the results of expensive database queries in fast in-memory storage. Without it, every page load recalculates the same queries from scratch.

// wp-config.php — Redis Object Cache (with Redis Object Cache plugin)
define( 'WP_REDIS_HOST',         '127.0.0.1' );
define( 'WP_REDIS_PORT',         6379 );
define( 'WP_REDIS_TIMEOUT',      1 );
define( 'WP_REDIS_READ_TIMEOUT', 1 );
define( 'WP_REDIS_DATABASE',     0 );

6. 🎯 Bonus Performance Points Worth Knowing

These extra points don't need a whole section each, but they're absolutely worth knowing — and many developers miss them entirely.

🔌 Audit Your Plugins Ruthlessly
Every active plugin adds load time. If you have 30+ plugins, audit them hard. Does each one really need to run on every page? Use Query Monitor to identify plugin-level bottlenecks.

🌍 Preconnect & Preload Critical Resources
Tell the browser in advance what it'll need. Add <link rel="preconnect"> for Google Fonts or third-party APIs, and rel="preload" for critical fonts and CSS.

📱 Don't Forget Mobile Performance
Google uses mobile-first indexing. Test your performance on a throttled mobile device — not just desktop. Tools: Lighthouse, WebPageTest with the "Moto G4" profile.

🔐 Enable HTTP/2 or HTTP/3
HTTP/2 allows multiplexed requests (multiple assets in one connection). HTTP/3 (QUIC) is even faster. Most modern hosts support HTTP/2; Cloudflare auto-enables HTTP/3.

📊 Monitor Continuously with Real User Monitoring (RUM)
One-off audits aren't enough. Use Google Search Console's Core Web Vitals report or tools like SpeedCurve / New Relic to catch regressions before your users do.

🛡️ Keep the Security ↔ Performance Loop Tight
Run a security audit (Wordfence, Patchstack) alongside every performance audit. The same bloated plugin hurting your score is probably the same one creating a CVE risk.

🏁 Wrapping Up

WordPress isn't going anywhere. It's the most widely-used CMS on the planet, and when configured correctly, it can be both blazing fast and genuinely secure.

The "fragile CMS" narrative is mostly a story about neglect — outdated plugins, zero caching, poor hosting, and zero monitoring. You now have the tools to change that story for your sites.

✅ Your Quick-Win Checklist

[ ] Move to PHP 8.2+ with OPcache enabled
[ ] Enable full-page caching (WP Rocket or LiteSpeed Cache)
[ ] Audit and remove unnecessary plugins
[ ] Optimize images — convert to WebP, enable lazy load
[ ] Set up a CDN (Cloudflare free tier is a great start)
[ ] Clean your database and limit post revisions
[ ] Add Redis object caching
[ ] Enable GZIP / Brotli compression
[ ] Monitor Core Web Vitals monthly

Start with just two or three of these today. You'll see a difference. And then come back for the rest 💪

Got a performance tip that's saved your site? Drop it in the comments — let's build a killer thread! 👇

WordPress 7.0 "Armstrong" Is Live — Post-Release Deep Dive 🎺

Kushang Tailor — Thu, 21 May 2026 12:45:50 +0000

It's out. After a delayed launch, a last-minute feature removal, and weeks of "will it / won't it" energy from the community — WordPress 7.0 "Armstrong" officially went live on May 20, 2026.

I covered the pre-release picture in detail earlier in this article — WordPress 7.0 — Let's Dive!. Now that the build is actually in people's hands, this is the post-release breakdown — what shipped, what it feels like in practice, what broke, and what you should do before touching the update button on a production site.

🎺 Why "Armstrong"?

Every WordPress major release gets named after a jazz musician. This time it's Louis "Satchmo" Armstrong — a fitting pick for a release built around giving individual builders more expressive power and their own set of tools to work with.

Armstrong didn't just play jazz — he rewired how the whole genre thought about itself. He took something collaborative and orchestral and made space for individual voice and improvisation to lead. There's a parallel to what WordPress 7.0 is trying to do architecturally: instead of AI being a monolithic, vendor-locked thing bolted on, it becomes a platform where you bring your own model, your own workflow, your own expression.

Also worth flagging: this is the 30th major WordPress release since 1.0 "Miles" shipped in January 2004. More than 900 contributors were involved, with close to 280 of them contributing to a WordPress release for the first time. That's a meaningful number.

🤖 AI in Core — The Real Headline

Let me frame this honestly before we get into the details: WordPress 7.0 doesn't make your site "do AI" automatically. If you update to 7.0 and don't configure anything, your site will feel identical to 6.9. No AI widget, no content generator, nothing.

What 7.0 does is lay down the infrastructure layer — the wiring — so that AI becomes a consistent, stable, vendor-neutral part of how WordPress works going forward. Think back to when the REST API landed. The power wasn't in day one; it was in what the ecosystem built on top of it over the next few years. This is that moment for AI.

Here's the architecture:

WP AI Client

A new communication layer built into Core that any plugin or theme can call to send prompts to an external AI model. The calling code doesn't need to know which model is on the other end — it just talks to the Client, and the Client routes it. This eliminates the pattern of every AI plugin bundling its own SDK and managing its own API keys.

Abilities API (PHP)

A contract system for AI-powered capabilities. A plugin registers what it can do — summarise content, generate an alt text suggestion, rewrite a paragraph — in a way that both humans navigating the UI and machine agents can discover and invoke. This is the piece that makes 7.0 feel agentic rather than just AI-adjacent.

Client-Side Abilities (JavaScript)

The same Abilities concept, now accessible in the browser. There's a built-in UI component and a command palette hook, meaning abilities surface in the editor itself — not buried in settings pages. Developers building editor-integrated AI features will appreciate this a lot.

The AI Plugin (Separate & Optional)

The AI Client on its own generates nothing. To get actual output — image generation, title suggestions, excerpt drafts, alt text — you install the separately distributed AI plugin. It sits on top of the Client and Abilities API and activates the generation features. Purely opt-in.

AI Abilities API surfaced inside the editor — tools appear where you're actually working.

🔌 Connectors — Quick Overview

The Settings → Connectors screen is the user-facing piece of the AI infrastructure, and it solves a genuinely frustrating problem: credential sprawl.

Before 7.0, if you ran multiple AI-powered plugins, you were probably entering the same API keys multiple times across multiple settings panels. Different plugins, same credentials, no coordination. It was messy. 7.0 fixes this at the platform level.

You enter your API key once per provider on the Connectors screen. Any plugin that speaks the AI Client API inherits that connection automatically — no extra configuration, no duplicate keys. Three providers ship ready to connect out of the box: OpenAI, Anthropic (Claude), and Google (Gemini). You're not locked into any of them, and the architecture supports custom providers too.

Settings → Connectors — one screen, one set of credentials, everything that speaks AI Client just works.

The vendor neutrality angle matters here. There's no partnership deal pushing you toward one model. Your API keys stay yours. If the AI landscape shifts in two years (it will), you swap a provider connection — you don't rebuild your plugin stack.

📌 Deeper dive incoming: Connectors is a topic that deserves its own full article — including a video walkthrough of setting up each provider, how to configure multi-provider setups, and which plugins are already building on top of this. Coming soon. Follow along so you don't miss it.

🖥️ The Dashboard Refresh — Long Overdue

Spending a day in the new wp-admin and then opening 6.9 in another tab felt like time travel. The gap is more noticeable than I expected.

New visual foundation

Tighter spacing, a cleaner colour palette, smoother view transitions between screens. Nothing revolutionary in isolation, but together they make the admin feel like a product that was designed rather than accumulated. If you spend hours a day in the dashboard, this compounds.

`⌘K` / `Ctrl+K` — Command Palette

This is my personal favourite addition in the entire release. Hit the shortcut from anywhere in wp-admin and a fuzzy-search overlay opens. Type a post title, a settings screen name, a command — you're there instantly. No sidebar, no menu hierarchy, no clicking through three levels. Once it's in your muscle memory you'll miss it in every other CMS you touch.

Hit ⌘K from anywhere in the dashboard — fuzzy search, instant navigation, zero clicking.

Font Library — All themes, one place

Managing fonts previously meant something different depending on whether you were in a block theme, a hybrid theme, or a classic theme. There was no single consistent answer. 7.0 gives you a dedicated Fonts page that works across all three — install a font, upload one, or remove ones you don't need. All in one place, for the first time.

One fonts page. Doesn't care what kind of theme you're running.

Visual Revisions — Actually Usable Now

Revisions in previous WordPress versions showed you a text-based diff. Red lines, green lines. Trying to figure out whether the layout had changed — not just the words — was nearly impossible. The new revisions interface shows visual markers along a scrubber. You can see what the page actually looked like at each save point and restore from there.

Revision history you can actually navigate — scroll, see, restore.

🧱 Four New Blocks

Breadcrumbs

Genuinely surprising this took until 7.0, but here we are. A native Breadcrumbs block with theme.json support and compatibility across all block themes. Goodbye Yoast breadcrumb shortcodes and custom template functions for this specific use case.

Icons

A block that pulls from the @wordpress/icons library and lets you drop UI icons inline — inside callouts, feature lists, service grids. Saves you the "embed an SVG manually or install another plugin" decision on every new site.

Gallery — Lightbox Mode

The Gallery block now has a built-in lightbox and slideshow that activates on click. This was one of the most commonly plugin-dependent features in the editor. It's native now.

Heading — Refined

Less visible, but if you build themes you'll notice: cleaner markup output and more granular per-heading-level style control. Fewer overrides needed in your stylesheets.

🎨 Editor & Design Tools

Per-Block Custom CSS

You can now write CSS for a single block instance right inside the Advanced panel of the block sidebar. Not a global style, not a child theme rule — CSS scoped to that specific block on that specific page. It's one of those features where the moment you use it you'll wonder how it wasn't there before.

Responsive Visibility Controls

Show or hide any block based on device size — mobile, tablet, desktop. Customise where the breakpoints sit. This has been handled by page builders and premium plugins for years; it's now part of Core.

Block-Based Menu Overlay

The mobile nav overlay is a block canvas now. Add whatever you want — multiple columns, a branded header, custom close button, anything your design calls for. The days of the plain sliding menu being un-editable without custom code are done.

Patterns as Single Units

Patterns in the editor now behave as cohesive single objects rather than a loose collection of blocks that could accidentally get broken apart. You can still detach and edit individual elements, but the default is clean, predictable, and much less frustrating on complex layouts.

🛠️ Developer Changes Worth Your Attention

PHP-Only Block Registration

This is my favourite developer addition in the release. You can register a block entirely in PHP — no npm, no webpack, no block.json build step. The Block API picks it up automatically. The barrier for shipping a simple block just dropped significantly for PHP-first developers and plugin authors who've been avoiding the block editor because of the toolchain overhead.

Site Editor as an Extensible Platform

The Site Editor now has proper routing and route validation, plus a new wordpress/boot package that lets plugins register their own custom pages inside the Site Editor shell. It's no longer a closed set of screens — plugins can build native-feeling experiences inside it. This is going to reshape how complex plugins approach their UX over the next year or two.

Interactivity API — `watch()` and `data-wp-watch`

Two additions that make reactive block development meaningfully cleaner. watch() lets you subscribe to state signal changes; data-wp-watch is the DOM directive counterpart. If you've built interactive blocks and ended up writing convoluted workarounds to respond to state without a full re-render, these exist specifically for that problem.

Block Bindings — More Control

The new block_bindings_supported_attributes filter lets you explicitly declare which attributes on your custom blocks are eligible for Pattern override. Cleaner, more intentional than the previous behaviour.

Scripts Can Declare Module Dependencies

The script loading system now lets traditional wp_register_script() scripts declare dependencies on ESM modules. It's a small but important step in the ongoing migration toward native browser modules without breaking backward compatibility.

WP-CLI 3.0 Ships Alongside 7.0

Two new command groups: wp block for read-only block entity access, and wp ability for interacting with the AI Abilities API from the command line. If you're building automations or running site audits, these are going to be useful early.

OPCache in Site Health

Tools → Site Health → Info → Server now shows your PHP OPCache status. One less reason to go digging through cPanel or hosting dashboards when diagnosing a performance issue.

Iframed Editor Auto-Detection

When every block on a page declares Block API v3, the editor automatically switches to iframed rendering. This resolves a persistent class of CSS bleed issues between admin styles and editor styles that developers have been working around for years. Old blocks on old API versions? No change — backward compatibility is maintained.

⚠️ Things That Will Break — Check Before You Update

What	Action Required
PHP 7.2 / 7.3	Upgrade PHP before updating WordPress
`add_theme_support( 'html5', array( 'script' ) )`	Remove this — script loader handles it natively now
Author link `title` attributes	Gone by default; use new `$use_title_attr` param where needed
Patterns in fully editable mode	Default is now `contentOnly` — mark content attributes with `"role": "content"`
backbone.js, Requests, PHPMailer, CodeMirror	All updated — verify any direct integrations

❌ The RTC Situation

If you read the pre-release article, you already know this — but for anyone coming in fresh:

Real-time collaborative editing did not make it into 7.0.

It was removed twelve days before launch. The reasons were technical and legitimate: concurrent editing sessions were causing race conditions in the sync layer, memory pressure wasn't where it needed to be, and fuzz testing kept surfacing bugs that didn't have clean fixes. Shipping it anyway would have been a mistake the scale of WordPress's user base tends to punish harshly.

The collaborative foundation is still there — block-level Notes, the commenting system, the presence infrastructure. The multi-user simultaneous editing part moves to a feature plugin for extended community testing before attempting another Core merge. WordPress 7.1 (August 2026) is the next candidate window, but no firm commitment has been made yet.

I wrote about the full RTC removal in the pre-release update if you want the longer version.

🚀 How to Update Safely

For existing production sites: hold for one to two weeks. The plugin ecosystem needs time to release compatibility updates, and the combination of your specific theme, plugins, and hosting setup is never quite what the testing matrix covered.

For new sites you're spinning up right now: skip 6.9 entirely. Start on 7.0.

Checklist before you touch anything:

Take a full backup — files and database. Actually verify it downloaded.
Confirm your PHP version — 7.4 minimum, 8.2 or 8.3 strongly recommended
Update plugins and themes on a staging copy before touching Core
Run the WordPress 7.0 update on staging and test your critical flows
Push to production once staging is clean From the terminal:

# Update Core
wp core update --version=7.0

# Run the DB upgrade (important after major releases)
wp core update-db

# Flush rewrite rules
wp rewrite flush

💬 Where Does 7.0 Actually Land?

Stepping back from the feature list — what is WordPress 7.0 as a release?

It's a foundations release. The AI layer, the Connectors architecture, the extensible Site Editor, PHP-only blocks — none of these are flashy "look what you can do today" features. They're decisions about how WordPress should work for the next few years. And most of those decisions look right to me.

The AI infrastructure in particular is the kind of thing that will age well. Provider-agnostic, opt-in, built on a proper API surface. The kind of foundation that gets quietly more valuable as the ecosystem builds on top of it.

Losing RTC as the headline took the wind out of the launch narrative somewhat. But honestly, a rushed collaboration feature on 43% of the web would have been far more damaging than a delay. The core team made a hard call and made the right one.

The Command Palette is the thing you'll feel every single day. The visual revisions scrubber is the thing your clients will finally understand. The AI Connectors screen is the thing that will matter most in twelve months.

Welcome to the Armstrong era. 🎺

📡 What's Coming Next

This post opens a series of dedicated 7.0 deep-dives:

🔌 Connectors Deep Dive + Video Walkthrough — setting up OpenAI, Claude, and Gemini; multi-provider patterns; real plugin integrations (coming very soon)
🧱 PHP-Only Block Registration — Hands-On — building a real block without writing a line of JavaScript
⚡ 7.0 Performance in the Real World — benchmarks across major hosting environments
🔮 WordPress 7.1 Preview — what RTC might actually look like when it ships in August 🔔 Follow me on dev.to to catch each one as it drops.

Research sources: WordPress.org Official Release, Make WordPress Core, WordPress Developer News, Make WordPress CLI

React: A Complete Guide from Zero to Production

Kushang Tailor — Thu, 21 May 2026 04:25:59 +0000

Read Time: ~15 minutes | Perfect for developers transitioning to React or deepening their framework knowledge.

📌 What is React?

React is a JavaScript library for building user interfaces with reusable components and efficient rendering. Developed and maintained by Meta (Facebook), React simplifies how we create dynamic, interactive web applications.

Why React Stands Out

Instead of manually updating the DOM (Document Object Model), React uses a declarative approach:

You describe what the UI should look like
React handles how to make it happen efficiently

// The React way: Describe what you want
function Greeting({ name }) {
  return <h1>Hello, {name}!</h1>;
}

// React renders it automatically

Key Philosophy: React makes building UIs predictable, testable, and maintainable by breaking interfaces into small, reusable components.

🌍 React's Global Adoption & Market Share

React dominates the frontend ecosystem with remarkable growth and adoption.

Usage Statistics (2025)

React Market Position:
├─ 40.5% of professional developers use React
├─ 23.3M+ weekly npm downloads
├─ 42% of companies prefer React in hiring
└─ 215K+ stars on GitHub

React in the Wild: Industries & Companies

Sector	Notable Companies	Usage
Tech Giants	Meta, Netflix, Uber, Airbnb	Core platform infrastructure
E-commerce	Shopify, Stripe, Amazon Prime	Dynamic product interfaces
Social Media	Instagram, WhatsApp, Messenger	Real-time updates, messaging
Streaming	Netflix, Discord, Spotify	Complex media players, UIs
Fintech	Square, Robinhood, Coinbase	Trading dashboards, analytics

React Ecosystem Growth Chart

Annual Developer Growth (Estimated)
2019: 15%  ████
2020: 22%  ███████
2021: 28%  █████████
2022: 35%  ███████████
2023: 39%  █████████████
2024: 40%  ██████████████
2025: 42%  ██████████████

⚖️ React vs. Other Frontend Frameworks

Detailed Comparison Table

Criteria	React	Vue.js	Angular	Svelte	Next.js
Learning Curve	Moderate	Easy	Steep	Easy	Moderate
Bundle Size	42 KB	34 KB	144 KB	4 KB	90 KB
Performance	Excellent	Very Good	Good	Excellent	Excellent*
Community Size	Massive	Large	Large	Growing	Growing Rapidly
Job Market	Highest	Moderate	Moderate	Emerging	Very High
TypeScript Support	Native	Good	Native	Excellent	Native
State Management	Redux/Zustand	Vuex/Pinia	NgRx	Simple (stores)	Built-in
Mobile Ready	React Native	NativeScript	NativeScript	N/A	React Native
SEO Out-of-Box	❌ Needs SSR	⚠️ Nuxt needed	✅ Yes	✅ Yes	✅ Yes
Setup Complexity	Moderate	Low	High	Low	Moderate
Ideal For	SPAs, PWAs	Small-Medium	Enterprise	Performance-critical	Full-stack apps

Performance Benchmarks

Render Speed (lower is better, ms):
React:        ████████ 8ms
Vue:          ██████ 6ms
Angular:      ██████████ 12ms
Svelte:       ███ 2ms
Next.js:      █████ 4ms (with optimization)

Why Choose React?

✅ Largest Job Market - 40% of frontend positions require React

✅ Ecosystem Maturity - 1000+ libraries, tools, and solutions

✅ Corporate Backing - Meta's continued investment and support

✅ Flexibility - Works for SPAs, mobile (React Native), and static sites

✅ Developer Experience - Hot reloading, excellent dev tools

🚀 React Setup & Installation

For Mac Users

Step 1: Prerequisites

# Check Node.js installation
node --version  # Should be v18 or higher
npm --version

If not installed, download from nodejs.org

Step 2: Create Your First React App

# Using Create React App (Easiest for beginners)
npx create-react-app my-react-app

# Navigate to project
cd my-react-app

# Start development server
npm start

Browser opens automatically at http://localhost:3000

Step 3: Verify Installation

You should see the React welcome page
Edit src/App.js and save - changes appear instantly (hot reload)

For Windows Users

Step 1: Install Node.js

Download from nodejs.org (Windows Installer)
Run installer, follow the setup wizard
Restart your computer

Step 2: Open PowerShell/CMD & Create App

# Create React app
npx create-react-app my-react-app

# Navigate to project
cd my-react-app

# Start development server
npm start

Step 3: Verify Setup

Windows Defender may ask to allow Node.js - click "Allow"
Browser opens at http://localhost:3000

Alternative: Vite (Faster & Modern)

For experienced developers or faster setup:

# Create Vite project
npm create vite@latest my-react-app -- --template react
cd my-react-app
npm install
npm run dev

📁 Project Structure & File Explanations

After running npx create-react-app my-react-app, your folder looks like:

my-react-app/
├── node_modules/          # All dependencies (ignore this)
├── public/
│   ├── index.html         # Entry HTML file (main DOM node)
│   └── favicon.ico        # Website icon
├── src/
│   ├── App.js             # Main React component
│   ├── App.css            # Styling for App component
│   ├── index.js           # React app startup point
│   ├── index.css          # Global styles
│   └── App.test.js        # Testing file
├── package.json           # Project metadata & dependencies
├── package-lock.json      # Locked dependency versions
└── .gitignore            # Git ignore rules

Key Files Explained

public/index.html

<!-- This is what the browser loads -->
<div id="root"></div>
<!-- React renders everything here -->

src/index.js

// Starts the React app
import React from 'react';
import ReactDOM from 'react-dom/client';
import App from './App';

const root = ReactDOM.createRoot(document.getElementById('root'));
root.render(<App />);  // Renders App component into <div id="root">

src/App.js

// Your main component - everything builds from here
function App() {
  return (
    <div className="App">
      <h1>Hello, React!</h1>
    </div>
  );
}
export default App;

package.json

{
  "name": "my-react-app",
  "version": "0.1.0",
  "dependencies": {
    "react": "^18.2.0",
    "react-dom": "^18.2.0"
  },
  "scripts": {
    "start": "react-scripts start",    // npm start
    "build": "react-scripts build",    // npm run build
    "test": "react-scripts test"       // npm test
  }
}

⚡ Essential React Functions & Hooks

1. useState - Manage Component State

import { useState } from 'react';

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

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>
        Increment
      </button>
    </div>
  );
}

Use: Whenever you need data that changes (user input, API data, etc.)

2. useEffect - Side Effects & Lifecycle

import { useEffect, useState } from 'react';

function UserProfile() {
  const [user, setUser] = useState(null);

  useEffect(() => {
    // Runs once on component mount
    fetch('/api/user')
      .then(res => res.json())
      .then(data => setUser(data));
  }, []);  // Empty dependency array = run once

  return <h1>Welcome, {user?.name}</h1>;
}

Use: Fetching data, setting up subscriptions, manual DOM updates

3. useContext - Share Data Globally

import { createContext, useContext } from 'react';

// Create theme context
const ThemeContext = createContext();

export function ThemeProvider({ children }) {
  const [isDark, setIsDark] = useState(false);

  return (
    <ThemeContext.Provider value={{ isDark, setIsDark }}>
      {children}
    </ThemeContext.Provider>
  );
}

// Use in any component
function Header() {
  const { isDark } = useContext(ThemeContext);
  return <header style={{ background: isDark ? '#000' : '#fff' }} />;
}

Use: Avoiding prop drilling, sharing theme/user data across components

4. useReducer - Complex State Logic

import { useReducer } from 'react';

const initialState = { count: 0 };

function reducer(state, action) {
  switch(action.type) {
    case 'INCREMENT': return { count: state.count + 1 };
    case 'DECREMENT': return { count: state.count - 1 };
    default: return state;
  }
}

function Counter() {
  const [state, dispatch] = useReducer(reducer, initialState);

  return (
    <>
      <p>Count: {state.count}</p>
      <button onClick={() => dispatch({ type: 'INCREMENT' })}>+</button>
      <button onClick={() => dispatch({ type: 'DECREMENT' })}>-</button>
    </>
  );
}

Use: Managing multiple related state values, complex state transitions

5. useMemo - Performance Optimization

import { useMemo } from 'react';

function ExpensiveComponent({ data }) {
  // Only recalculates when 'data' changes
  const expensiveResult = useMemo(() => {
    return data.map(item => item * 2).reduce((a, b) => a + b, 0);
  }, [data]);

  return <p>Result: {expensiveResult}</p>;
}

Use: Prevent unnecessary recalculations of expensive operations

6. useCallback - Memoize Functions

import { useCallback } from 'react';

function Parent() {
  const handleClick = useCallback(() => {
    console.log('Button clicked');
  }, []);  // Function never changes

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

Use: Optimizing performance when passing functions to child components

7. Fragment - Group Elements Without Extra DOM

// ❌ Extra <div>
function List() {
  return (
    <div>
      <h1>Title</h1>
      <ul><li>Item 1</li></ul>
    </div>
  );
}

// ✅ Clean with Fragment
function List() {
  return (
    <>
      <h1>Title</h1>
      <ul><li>Item 1</li></ul>
    </>
  );
}

Use: Returning multiple elements without adding unnecessary DOM nodes

8. map() - Render Lists

function TodoList({ todos }) {
  return (
    <ul>
      {todos.map((todo) => (
        <li key={todo.id}>{todo.text}</li>
      ))}
    </ul>
  );
}

Use: Rendering dynamic lists - always use a unique key prop

🎯 Real-World Use Case #1: E-commerce Product Filter

Scenario: Building a product listing page with filters (price, category, rating)

import { useState, useEffect } from 'react';

function ProductStore() {
  const [products, setProducts] = useState([]);
  const [filters, setFilters] = useState({ 
    minPrice: 0, 
    maxPrice: 1000,
    category: 'all'
  });

  useEffect(() => {
    // Fetch products from API
    fetchProducts(filters).then(setProducts);
  }, [filters]);

  const handleFilterChange = (newFilters) => {
    setFilters(prev => ({ ...prev, ...newFilters }));
  };

  return (
    <div className="store">
      <Sidebar onFilterChange={handleFilterChange} />
      <ProductGrid products={products} />
    </div>
  );
}

Why React Excels Here:

State management (filter values, products) automatically updates UI
Component reusability (ProductCard used 100+ times)
Virtual DOM optimizes rendering only changed products
Real-time filter application without page reloads

🎯 Real-World Use Case #2: Real-Time Notification System

Scenario: Building a notification center with real-time updates

import { useState, useEffect, useContext } from 'react';

function NotificationCenter() {
  const [notifications, setNotifications] = useState([]);
  const { userId } = useContext(UserContext);

  useEffect(() => {
    // WebSocket connection for real-time updates
    const ws = new WebSocket('wss://api.example.com/notifications');

    ws.onmessage = (event) => {
      const newNotification = JSON.parse(event.data);
      setNotifications(prev => [newNotification, ...prev]);
    };

    return () => ws.close(); // Cleanup on unmount
  }, [userId]);

  const removeNotification = (id) => {
    setNotifications(prev => prev.filter(n => n.id !== id));
  };

  return (
    <div className="notifications">
      {notifications.map(notif => (
        <NotificationItem
          key={notif.id}
          notification={notif}
          onDismiss={() => removeNotification(notif.id)}
        />
      ))}
    </div>
  );
}

Why React Excels Here:

Real-time state updates with setNotifications
Automatic re-render when new notifications arrive
useEffect cleanup prevents memory leaks
Component isolation means notifications don't affect other features

💡 Final Thoughts: Why React in 2026?

React Remains Essential Because:

Job Market Reality - 40-42% of frontend positions require React skills
Enterprise Standard - 70% of Fortune 500 companies use React
Ecosystem Maturity - Next.js, React Native, Remix enable full-stack development
Developer Happiness - Tools like React DevTools, Hot Reload make development enjoyable

The React-to-Meta Pipeline:

React (UI Library)
    ↓
Next.js (Full-stack Framework)
    ↓
React Native (Mobile)
    ↓
Expo (Deployment Platform)

What's Next After React?

Once comfortable with React fundamentals:

State Management: Learn Redux, Zustand, or Jotai
Full-Stack: Explore Next.js for backend integration
Mobile: React Native for iOS/Android
Advanced: Server Components, Concurrent Features, Suspense

Key Takeaway

React isn't just a library—it's a way of thinking about UI. The component-based, declarative approach translates across frameworks. Learning React deeply makes you a better developer regardless of what you build next.

🎓 Quick Resources

Official Docs: react.dev (New official React documentation)
Next.js: nextjs.org - Full-stack React framework
Create React App: create-react-app.dev
React DevTools: Browser extension for debugging
Community: Dev.to React Tag | React Discord

💬 Share Your React Journey

Have you started with React? Are you migrating from Vue or Angular? Drop your thoughts in the comments—I'd love to hear about your projects and challenges!

Happy coding! 🚀

WordPress Coding Standards: Complete Setup Guide for Mac & Windows

Kushang Tailor — Wed, 20 May 2026 11:22:44 +0000

🚀 Introduction: Why WordPress Coding Standards Matter

If you're building WordPress plugins or themes, you've probably heard about WordPress coding standards. But what exactly are they, and why should you care?

Think of coding standards as the style guide for code—similar to how newspapers follow AP style to ensure consistency. WordPress coding standards help ensure that:

Code is readable across your entire project
Multiple developers can collaborate without conflicts
Your code is secure and follows best practices
WordPress reviewers can approve your code faster

💡 Pro Tip: Whether you're a seasoned developer or just starting out, implementing coding standards from day one saves hours of refactoring later.

What Are WordPress Coding Standards?

WordPress coding standards consist of five main pillars:

Standard	Description
📝 PHP Standards	Code formatting, naming conventions, and structure
🎨 CSS Standards	Styling conventions and organization
⚙️ JavaScript Standards	Script formatting and best practices
🛡️ Security Standards	Escaping, sanitizing, and validating
✓ Best Practices	Overall code quality and maintainability

The most important? PHP Standards—this is what we'll focus on today, along with the security practices that make WordPress code production-ready.

Step 1: Install Composer (For Both Mac & Windows)

Before we can use WordPress coding standards tools, we need Composer—PHP's dependency manager. It's essential for managing the PHP CodeSniffer and WordPress-specific linting tools.

🍎 macOS Setup

Option 1: Using Homebrew (Recommended)

If you don't have Homebrew installed, first run:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Then install Composer:

brew install composer

Verify installation:

composer --version

Option 2: Manual Installation

Open Terminal and run:

curl -sS https://getcomposer.org/installer | php
mv composer.phar /usr/local/bin/composer
chmod +x /usr/local/bin/composer

Then verify:

composer --version

✅ Success! You should see the composer version number. Now move to Step 2.

Windows Setup

Option 1: Using Chocolatey (Recommended)

If you have Chocolatey installed, simply run in PowerShell (as Administrator):

choco install composer

Verify installation:

composer --version

Option 2: Using Windows Installer

Download the Windows Installer from getcomposer.org
Run the .exe file
Follow the installation wizard—it will auto-detect PHP installation
Open Command Prompt and verify: composer --version

Option 3: Manual Setup

Download composer.phar from getcomposer.org
Place it in a directory (e.g., C:\composer)
Add this directory to your system PATH
Restart Command Prompt and verify installation > ⚠️ Note: Windows users should use PowerShell instead of CMD for best results. Right-click and select "Run as Administrator."

Step 2: Set Up WordPress Coding Standards (PHPCS + WPCS)

Now we'll install the tools that actually check your code against WordPress standards.

What We're Installing:

PHP CodeSniffer (PHPCS) — The core tool that analyzes code
WordPress Coding Standards (WPCS) — WordPress-specific rules for PHPCS
PHP Compatibility Checker — Ensures your code works across PHP versions ### 🍎 macOS Setup

Step 1: Create a Project Directory

mkdir -p ~/wordpress-project
cd ~/wordpress-project

Step 2: Initialize Composer

composer init

Answer the prompts or press Enter to accept defaults.

Step 3: Install PHPCS and WPCS

composer require --dev squizlabs/php_codesniffer:* wp-coding-standards/wpcs:* phpcompatibility/php-compatibility:*

Step 4: Register WordPress Standards

./vendor/bin/phpcs --config-set installed_paths vendor/wp-coding-standards/wpcs,vendor/phpcompatibility/php-compatibility

Step 5: Verify Installation

./vendor/bin/phpcs -i

You should see a list of installed standards including "WordPress", "WordPress-Core", etc.

✅ Perfect! Your macOS development environment is ready. You can now scan files for WordPress coding standard violations.

Windows Setup

Step 1: Create a Project Directory

Open PowerShell (as Administrator):

mkdir C:\wordpress-project
cd C:\wordpress-project

Step 2: Initialize Composer

composer init

Answer the prompts or press Enter to accept defaults.

Step 3: Install PHPCS and WPCS

composer require --dev squizlabs/php_codesniffer:* wp-coding-standards/wpcs:* phpcompatibility/php-compatibility:*

Step 4: Register WordPress Standards

.\vendor\bin\phpcs.bat --config-set installed_paths vendor/wp-coding-standards/wpcs,vendor/phpcompatibility/php-compatibility

Step 5: Verify Installation

.\vendor\bin\phpcs.bat -i

You should see a list of installed standards.

✅ Excellent! Windows setup is complete. You're ready to scan WordPress code.

Step 3: Create Your First Configuration File

PHPCS is now installed, but we need to tell it which standards to use and which files to scan. We do this with a phpcs.xml file.

Create phpcs.xml in your project root:

<?xml version="1.0"?>
<ruleset name="WordPress Project">
    <!-- Check all PHP files in src/ -->
    <file>src</file>
    <file>includes</file>

    <!-- Exclude these directories -->
    <exclude-pattern>node_modules</exclude-pattern>
    <exclude-pattern>vendor</exclude-pattern>
    <exclude-pattern>tests</exclude-pattern>

    <!-- Use WordPress coding standard -->
    <rule ref="WordPress">
        <!-- Adjust this rule if you prefer different spacing -->
        <exclude name="WordPress.Arrays.ArrayKeySpaced.SpacedAssociativeArray" />
    </rule>

    <!-- Add PHP 7.2+ compatibility check -->
    <rule ref="PHPCompatibility">
        <config name="testVersion" value="7.2-" />
    </rule>
</ruleset>

💡 Tip: You can customize which rules to enforce. This configuration checks WordPress standards while excluding certain non-critical rules that might be too strict for your project.

Step 4: Running Your First Code Scan

Now for the exciting part—let's scan some actual code!

🍎 macOS Commands

Basic scan:

./vendor/bin/phpcs

Scan specific file:

./vendor/bin/phpcs /path/to/file.php

Generate detailed report:

./vendor/bin/phpcs --report=full --report-file=report.txt

Auto-fix issues (when possible):

./vendor/bin/phpcbf

Windows Commands

Basic scan:

.\vendor\bin\phpcs.bat

Scan specific file:

.\vendor\bin\phpcs.bat C:\path\to\file.php

Generate detailed report:

.\vendor\bin\phpcs.bat --report=full --report-file=report.txt

Auto-fix issues:

.\vendor\bin\phpcbf.bat

🎯 Example Output

When you run phpcs, you'll see output like:

FILE: /path/to/plugin.php
 3 | ERROR   | Missing file header comment

This tells you exactly where problems are and what to fix!

Step 5: Integrating with Code Editors

Scanning manually is helpful, but catching errors while you code is even better.

VS Code Integration (Recommended)

Install the "PHPCS for WordPress" extension by Shama
Open VS Code settings (⌘, on Mac or Ctrl+, on Windows)
Search for "phpcs" and configure:

"phpcs.enable": true,
"phpcs.standard": "WordPress",
"phpcs.executablePath": "./vendor/bin/phpcs"

Save and reload. Now you'll see errors highlighted in red as you type!

⚠️ Important: Update the phpcs.executablePath to match your setup. Windows users should use .\vendor\bin\phpcs.bat.

Understanding Common WordPress Code Standards Violations

Let's decode some common errors you'll encounter:

1. Missing Nonces (Security)

❌ WRONG - No security verification

if ( isset( $_POST['save'] ) ) {
    update_option( 'my_option', $_POST['value'] );
}

✅ CORRECT - Verified nonce

if ( isset( $_POST['save'], $_POST['nonce'] ) && 
     wp_verify_nonce( sanitize_text_field( wp_unslash( $_POST['nonce'] ) ), 'my_action' ) ) {
    update_option( 'my_option', sanitize_text_field( wp_unslash( $_POST['value'] ) ) );
}

2. Improper Sanitization (Security)

❌ WRONG - No sanitization

$value = $_GET['search'];
echo $value;

✅ CORRECT - Properly sanitized and escaped

$search = isset( $_GET['search'] ) ? sanitize_text_field( wp_unslash( $_GET['search'] ) ) : '';
echo esc_html( $search );

3. Function Prefixes (Namespace)

❌ WRONG - Generic function name

function save_settings() {
    // ...
}

✅ CORRECT - Unique prefix to avoid conflicts

function my_plugin_save_settings() {
    // ...
}

Creating a Plugin Template Following Standards

Let's build a proper WordPress plugin structure from scratch:

my-awesome-plugin/
├── my-awesome-plugin.php          # Main plugin file
├── includes/
│   ├── class-plugin.php            # Main plugin class
│   └── class-settings.php          # Settings handler
├── assets/
│   ├── css/
│   │   └── style.css
│   └── js/
│       └── script.js
├── languages/
│   └── my-awesome-plugin.pot       # Translations
├── vendor/                         # Composer dependencies
├── composer.json
├── phpcs.xml
└── README.md

Main plugin file (my-awesome-plugin.php):

<?php
/**
 * Plugin Name: My Awesome Plugin
 * Plugin URI: https://example.com
 * Description: An awesome plugin following WordPress standards
 * Version: 1.0.0
 * Author: Your Name
 * License: GPL-2.0-or-later
 * Text Domain: my-awesome-plugin
 * Domain Path: /languages
 *
 * @package MyAwesomePlugin
 */

// Prevent direct access.
if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

// Include autoloader.
require_once plugin_dir_path( __FILE__ ) . 'vendor/autoload.php';

/**
 * Initialize the plugin.
 *
 * @return void
 */
function my_awesome_plugin_init() {
    do_action( 'my_awesome_plugin_init' );
}
add_action( 'plugins_loaded', 'my_awesome_plugin_init' );

Best Practices Checklist

Practice	Description
✓ Always validate input	Use `sanitize_` and `validate_` functions for all user input
✓ Escape output	Use `esc_html`, `esc_attr`, `esc_url` before outputting data
✓ Use nonces	Protect form submissions with WordPress nonce verification
✓ Name spacing	Prefix all functions, hooks, and classes uniquely
✓ Document code	Use PHPDoc comments on all functions and classes
✓ Use proper hooks	Leverage WordPress actions and filters for extensibility

Troubleshooting Common Issues

Q: PHPCS says "could not find any installable packages"?

A: Make sure you have PHP and Composer installed. Run php --version to verify. Also ensure Composer is in your system PATH. On Windows, restart Command Prompt or PowerShell after installing Composer.

Q: Auto-fix (phpcbf) isn't working?

A: Some violations can't be auto-fixed. Check the error message for details. Complex issues like security concerns (nonces, sanitization) require manual fixing. Run phpcbf with the --standard=WordPress flag to apply only WordPress rules.

Q: How do I exclude specific files?

A: Edit phpcs.xml and add <exclude-pattern> tags. Example:

<exclude-pattern>node_modules</exclude-pattern>
<exclude-pattern>vendor</exclude-pattern>
<exclude-pattern>*/tests/*</exclude-pattern>

Q: I'm getting "WordPress standard could not be found" error?

A: This means WordPress Coding Standards (WPCS) isn't registered. Run this command to fix it:

For macOS:

./vendor/bin/phpcs --config-set installed_paths vendor/wp-coding-standards/wpcs,vendor/phpcompatibility/php-compatibility

For Windows:

.\vendor\bin\phpcs.bat --config-set installed_paths vendor/wp-coding-standards/wpcs,vendor/phpcompatibility/php-compatibility

Then verify: phpcs -i or phpcs.bat -i

Q: Why is PHPCS taking so long to scan my project?

A: Scanning large projects can take time. To speed it up:

Exclude unnecessary directories in phpcs.xml (node_modules, vendor, etc.)
Run phpcs on specific files instead of the whole project
Use the -j flag for parallel processing (if available) macOS example:

./vendor/bin/phpcs --ignore=node_modules,vendor src/

Q: How do I ignore a specific line that I know violates standards?

A: Use the PHPCS annotation comment before the problematic line:

// phpcs:ignore WordPress.Security.NonceVerification.Missing
$unsafe_value = $_POST['value'];

Or ignore an entire block:

// phpcs:disable WordPress.Security.NonceVerification.Missing
// Your code here
// phpcs:enable WordPress.Security.NonceVerification.Missing

Q: I'm getting different results than a team member. Why?

A: Version mismatches! Make sure both of you are using the same versions of PHPCS and WPCS. Commit your composer.lock file to version control:

git add composer.lock
git commit -m "Lock composer dependencies"

Q: How do I run PHPCS on only modified files (useful for Git)?

A: Get list of changed files and scan them:

macOS/Linux:

git diff --name-only HEAD | grep '\.php$' | xargs ./vendor/bin/phpcs

Or scan staged files:

git diff --cached --name-only | grep '\.php$' | xargs ./vendor/bin/phpcs

Q: PHPCS extension isn't showing errors in VS Code even though phpcs command finds them?

A: Try these solutions:

Reload VS Code window (Command Palette → Reload Window)
Check VS Code settings: Ensure phpcs.enable is true and path is correct
Open terminal in VS Code and verify: ./vendor/bin/phpcs --version
Reinstall the PHPCS extension
Check VS Code output panel (View → Output) for error messages

Q: Can I create custom coding standards for my project?

A: Yes! Create a custom ruleset in phpcs.xml that extends WordPress standard:

<?xml version="1.0"?>
<ruleset name="My Custom Standard">
    <description>Custom standards based on WordPress</description>

    <!-- Inherit WordPress standard -->
    <rule ref="WordPress" />

    <!-- Override or add custom rules -->
    <rule ref="WordPress.NamingConventions.PrefixAllGlobals">
        <properties>
            <property name="prefixes" type="array">
                <element value="my_plugin" />
                <element value="my_custom" />
            </property>
        </properties>
    </rule>
</ruleset>

Q: My plugin passed phpcs but failed WordPress.org submission. What's wrong?

A: PHPCS catches most issues, but not everything. WordPress reviewers also check:

Security: Proper use of nonces, escaping, sanitization
Documentation: Clear comments and proper PHPDoc
Functionality: Plugin works correctly and doesn't conflict
Performance: No unnecessary database queries or API calls
Best practices: Proper use of WordPress hooks and functions Review WordPress.org plugin handbook before submission. Consider having someone else review your code first.

Q: How often should I update PHPCS and WPCS?

A: Update when new versions are released (especially for security fixes). Update your composer packages:

composer update squizlabs/php_codesniffer wp-coding-standards/wpcs

Always test your code after updating to catch any new violations introduced by rule changes.

Next Steps: Advanced Setup

🔗 Git Hooks: Auto-run phpcs on commit with husky
📊 CI/CD: Add phpcs checks to GitHub Actions
🎯 Custom Rules: Create project-specific coding rules
📚 Team Standards: Share phpcs.xml with your team

🎓 Learn More: Visit developer.wordpress.org for the complete WordPress coding standards documentation.

Conclusion

You now have a complete WordPress development environment set up with coding standards checking! Whether you're building plugins, themes, or contributing to WordPress itself, these tools will help you write cleaner, more secure code.

The key takeaway? Consistency matters. By following these standards from day one, you'll save time on code reviews, reduce bugs, and make your WordPress projects more maintainable.

Happy coding! 🎉

Share This Guide

Found this helpful? Share it with your developer friends and don't forget to drop a comment if you have questions or want to discuss WordPress coding standards further!

Most Used PHP and WordPress Functions: A Developer's Complete Guide

Kushang Tailor — Wed, 20 May 2026 08:20:37 +0000

📖 12 min read | 💻 PHP/WordPress | 🚀 Advanced

Whether you're building WordPress plugins, themes, or custom applications, understanding the most used PHP and WordPress functions is crucial. These functions form the backbone of modern web development and can significantly improve your code quality, performance, and maintainability.

In this guide, we'll explore the functions you'll use every day, with practical examples and explanations following WordPress and WordPress VIP coding standards.

Core PHP Functions Every Developer Should Know

`isset()` / `empty()` / `is_null()`

Check variable existence and emptiness with precision.

// isset() - Check if variable exists and is not NULL
$username = 'john_doe';

if ( isset( $username ) ) {
    echo 'Username is set';
}

// empty() - Returns TRUE if variable is empty
$email = '';

if ( empty( $email ) ) {
    echo 'Email field is required';
}

// is_null() - Check specifically for NULL
$value = null;

if ( is_null( $value ) ) {
    echo 'Value is explicitly NULL';
}

When to use: isset() checks existence, empty() checks if value is falsy, is_null() checks explicitly for NULL.

`array_map()` / `array_filter()`

Transform and filter arrays functionally.

// array_map() - Apply callback to each array element
$numbers = array( 1, 2, 3, 4, 5 );

$squared = array_map(
    function( $num ) {
        return $num * $num;
    },
    $numbers
);
// Result: [1, 4, 9, 16, 25]

// array_filter() - Filter array by callback condition
$posts = get_posts( array( 'numberposts' => -1 ) );

$published_posts = array_filter(
    $posts,
    function( $post ) {
        return 'publish' === $post->post_status;
    }
);

Use case: Process collections of data without loops. Keep code clean and functional.

`implode()` / `explode()`

Convert between strings and arrays.

// explode() - Split string into array
$tags_string = 'php,wordpress,coding';
$tags_array = explode( ',', $tags_string );
// Result: ['php', 'wordpress', 'coding']

// implode() - Join array into string
$tags = array( 'php', 'wordpress', 'coding' );
$tags_string = implode( ', ', $tags );
// Result: 'php, wordpress, coding'

// Sanitize and escape array elements
$sanitized_tags = array_map( 'sanitize_text_field', $tags_array );
$safe_output = implode( ', ', $sanitized_tags );
echo wp_kses_post( $safe_output );

Important: Always sanitize input data before processing and escape output.

`in_array()` / `array_key_exists()`

Search for values and keys in arrays.

// in_array() - Check if value exists
$allowed_roles = array( 'admin', 'editor', 'author' );
$user_role = 'editor';

if ( in_array( $user_role, $allowed_roles, true ) ) {
    // Third parameter 'true' enables strict comparison
    echo 'User has valid role';
}

// array_key_exists() - Check if key exists
$user_data = array(
    'name'  => 'John',
    'email' => 'john@example.com',
);

if ( array_key_exists( 'name', $user_data ) ) {
    echo $user_data['name'];
}

Pro tip: Use strict comparison (third parameter = true) in in_array() to avoid type juggling issues.

`sprintf()` / `printf()`

Format strings safely and consistently.

// sprintf() - Return formatted string
$post_title = 'WordPress Development';
$post_count = 42;

$message = sprintf(
    'We have %d articles about %s',
    $post_count,
    $post_title
);
// Result: 'We have 42 articles about WordPress Development'

// Use with internationalization
$translated = sprintf(
    __( 'We have %d articles about %s', 'textdomain' ),
    $post_count,
    $post_title
);

// printf() - Output directly
printf( 'Welcome %s!', 'Developer' ); 
// Outputs: Welcome Developer!

Advantage: Better for internationalization and prevents concatenation issues.

Essential WordPress Functions

`get_option()` / `update_option()`

Manage WordPress site options safely.

// get_option() - Retrieve option value
$site_name = get_option( 'blogname' );
$custom_setting = get_option( 'my_plugin_setting', 'default_value' );

// update_option() - Update option value
update_option( 'my_plugin_setting', 'new_value' );

// Best practice: Sanitize and validate
class Plugin_Settings {
    private $option_name = 'my_plugin_settings';

    public function get_settings() {
        $settings = get_option( $this->option_name, array() );
        return $this->validate_settings( $settings );
    }

    public function save_settings( $new_settings ) {
        $sanitized = $this->sanitize_settings( $new_settings );
        update_option( $this->option_name, $sanitized );
    }

    private function sanitize_settings( $settings ) {
        return array(
            'api_key' => sanitize_text_field( $settings['api_key'] ?? '' ),
            'timeout' => absint( $settings['timeout'] ?? 30 ),
        );
    }
}

Important: Always sanitize and validate option values before saving.

`get_posts()` / `get_post()`

Retrieve post data from database.

// get_posts() - Retrieve multiple posts
$args = array(
    'post_type'      => 'post',
    'posts_per_page' => 10,
    'orderby'        => 'date',
    'order'          => 'DESC',
    's'              => sanitize_text_field( $_GET['search'] ?? '' ),
);

$posts = get_posts( $args );

foreach ( $posts as $post ) {
    setup_postdata( $post );
    echo wp_kses_post( $post->post_title );
}
wp_reset_postdata();

// get_post() - Retrieve single post by ID
$post = get_post( 123 );

if ( $post ) {
    echo wp_kses_post( $post->post_content );
}

Remember: Always use wp_reset_postdata() after custom loop and escape all output.

`get_post_meta()` / `update_post_meta()`

Handle custom post metadata.

// get_post_meta() - Retrieve post meta
$post_id = get_the_ID();
$author_name = get_post_meta( $post_id, 'author_name', true );

// With default value
$featured_image = get_post_meta( 
    $post_id, 
    'featured_image', 
    true 
) ?? 'default-image.jpg';

// Get all meta for a post
$all_meta = get_post_meta( $post_id );

// update_post_meta() - Update or create meta
$author = sanitize_text_field( $_POST['author'] ?? '' );
$post_id = absint( $_POST['post_id'] ?? 0 );

if ( $post_id ) {
    update_post_meta( 
        $post_id, 
        'author_name', 
        $author 
    );
}

Best practice: Always sanitize and validate metadata before saving.

`wp_kses_post()` / `sanitize_text_field()`

Secure input and output handling.

// Escape output - wp_kses_post() allows safe HTML
$user_content = get_post_meta( get_the_ID(), 'content', true );
echo wp_kses_post( $user_content );

// Sanitize input - Remove dangerous HTML
$title = sanitize_text_field( $_POST['title'] ?? '' );
$description = wp_kses_post( $_POST['description'] ?? '' );

// Class-based approach following OOP
class Secure_Handler {

    /**
     * Sanitize user input
     * 
     * @param string $input Raw user input.
     * @return string Sanitized input.
     */
    public static function sanitize_input( $input ) {
        return sanitize_text_field( stripslashes( $input ) );
    }

    /**
     * Escape output safely
     * 
     * @param string $output Content to escape.
     * @return string Escaped output.
     */
    public static function escape_output( $output ) {
        return wp_kses_post( $output );
    }
}

⚠️ Critical: Never skip sanitization and escaping. These functions prevent XSS attacks.

`do_action()` / `apply_filters()`

Implement the WordPress hook system.

// do_action() - Execute action hooks
do_action( 'my_plugin_init' );

// With parameters
do_action( 'my_plugin_process_data', $user_id, $data );

// apply_filters() - Filter data through hooks
$title = apply_filters( 'my_plugin_title', 'Default Title' );

class Plugin_Core {

    /**
     * Initialize plugin hooks
     */
    public function __construct() {
        add_action( 'init', array( $this, 'register_post_types' ) );
        add_filter( 'the_content', array( $this, 'modify_content' ) );
    }

    public function register_post_types() {
        do_action( 'my_plugin_before_register' );
        // Register custom post type
    }

    public function modify_content( $content ) {
        return apply_filters( 
            'my_plugin_modify_content', 
            $content 
        );
    }
}

Philosophy: Hooks make plugins extensible and follow WordPress best practices.

`wp_enqueue_script()` / `wp_enqueue_style()`

Load assets properly in WordPress.

// Register and enqueue script
add_action( 'wp_enqueue_scripts', function() {

    // Enqueue with dependencies and version
    wp_enqueue_script(
        'my-plugin-script',
        plugins_url( 'assets/script.js', __FILE__ ),
        array( 'jquery' ), // Dependencies
        '1.0.0',           // Version
        true               // Load in footer
    );

    // Localize script (pass PHP data to JS)
    wp_localize_script(
        'my-plugin-script',
        'myPluginData',
        array(
            'ajax_url' => admin_url( 'admin-ajax.php' ),
            'nonce'    => wp_create_nonce( 'my_plugin_nonce' ),
        )
    );
} );

// Enqueue stylesheet
add_action( 'wp_enqueue_scripts', function() {
    wp_enqueue_style(
        'my-plugin-style',
        plugins_url( 'assets/style.css', __FILE__ ),
        array(),
        '1.0.0'
    );
} );

Tip: Always use proper dependencies, versioning, and localization for maintainability.

Best Practices & Advanced Patterns

1. Error Handling and Validation

Always validate and handle errors gracefully:

class Data_Processor {

    /**
     * Process user data with validation
     * 
     * @param array $data User data to process.
     * @return array|WP_Error Processed data or error.
     */
    public function process( $data ) {
        // Validate input
        if ( ! is_array( $data ) || empty( $data ) ) {
            return new WP_Error( 
                'invalid_data', 
                __( 'Invalid data provided', 'textdomain' ) 
            );
        }

        // Sanitize
        $sanitized = $this->sanitize_data( $data );

        // Process with error handling
        try {
            $result = $this->execute_process( $sanitized );
            return $result;
        } catch ( Exception $e ) {
            return new WP_Error( 
                'process_error', 
                $e->getMessage() 
            );
        }
    }

    private function sanitize_data( $data ) {
        return array_map( 
            'sanitize_text_field', 
            $data 
        );
    }
}

2. Caching for Performance

Use WordPress caching to improve performance:

class Data_Retriever {

    private $cache_key = 'my_plugin_data_cache';
    private $cache_duration = 24 * HOUR_IN_SECONDS;

    /**
     * Get data with caching
     * 
     * @param int $id Data ID.
     * @return mixed Cached or fresh data.
     */
    public function get_cached_data( $id ) {
        $cache = wp_cache_get( 
            $this->cache_key . '_' . $id 
        );

        if ( false !== $cache ) {
            return $cache;
        }

        // Data not cached, fetch it
        $data = $this->fetch_data( $id );

        // Cache the data
        wp_cache_set( 
            $this->cache_key . '_' . $id, 
            $data, 
            '', 
            $this->cache_duration 
        );

        return $data;
    }

    /**
     * Invalidate cache
     */
    public function invalidate_cache( $id ) {
        wp_cache_delete( $this->cache_key . '_' . $id );
    }
}

3. Following PHPCS Standards

✅ Correct:

// Proper spacing and naming
$post_id = absint( $_GET['post_id'] ?? 0 );
$title = sanitize_text_field( $_POST['title'] ?? '' );

// Use tabs for indentation in WordPress
if ( isset( $post_id ) ) {
    update_post_meta( $post_id, 'key', $title );
}

❌ Incorrect:

// Poor spacing and variable naming
$pid=$_GET['pid'];
$t=$_POST['t'];

if($pid){
update_post_meta($pid,'k',$t);
}

Quick Reference Table

Function	Purpose	Return Type
`isset()`	Check if variable exists	bool
`empty()`	Check if variable is empty	bool
`get_option()`	Retrieve option value	mixed
`wp_kses_post()`	Safely escape HTML	string
`apply_filters()`	Apply filter hooks	mixed
`wp_cache_get()`	Retrieve cached data	mixed\|bool
`sanitize_text_field()`	Remove dangerous characters	string
`wp_enqueue_script()`	Load JavaScript safely	void

Key Takeaways

✅ Always sanitize input - Use sanitize_text_field(), absint(), floatval()

✅ Always escape output - Use wp_kses_post(), esc_html(), esc_url()

✅ Follow WordPress coding standards - Use tabs, proper spacing, and meaningful names

✅ Leverage hooks - do_action() and apply_filters() make code extensible

✅ Use OOP patterns - Organize code into classes for better maintainability

✅ Implement caching - Use wp_cache_* functions for performance optimization

✅ Handle errors gracefully - Return WP_Error objects and validate inputs

Conclusion

Mastering these PHP and WordPress functions is essential for writing secure, maintainable, and performant code. By following WordPress coding standards, implementing proper sanitization and escaping, and leveraging hooks and OOP patterns, you'll create professional-grade WordPress solutions.

Practice these functions in your projects, and you'll build better WordPress applications that stand the test of time.

Have questions? Share your thoughts in the comments below. Happy coding! 🚀

DEV Community: Kushang Tailor

React in Production — Ship It, Monitor It, Sleep at Night

Part 6: The Finale 🎉

📌 What You'll Learn

🏁 You Made It Here — Now What?

🔐 Authentication: JWT vs Session Cookies

The Two Main Approaches

Building JWT Auth in Next.js

🌐 OAuth: Google & GitHub Login in Minutes

🔄 CI/CD with GitHub Actions

What the Pipeline Does

Full GitHub Actions Workflow

🚨 Error Monitoring with Sentry

Setup

Capturing Errors Manually

Setting User Context

🗂️ Production Environment Variables

🧱 Production-Ready Checklist

Security

Reliability

Performance

Observability

💣 Production Mistakes Worth Learning From

🎓 The Full Journey — What You've Built Over This Series

🔗 Quick Resources

💬 You've Reached the End — What's Next for You?

Testing & Debugging React Apps — Write Code You Can Actually Trust

📌 What You'll Learn

🤔 Why Testing Feels Painful (And Why It Doesn't Have To)

🏗️ The Three Layers of Testing

⚙️ Setup: Jest + React Testing Library

For Next.js

✅ Unit Testing: Components

Testing a Simple Component

Testing a Button Click

🔗 Integration Testing: Real User Flows

Testing a Login Form

⏳ Testing Async Behaviour

Mocking an API Call

🪝 Testing Custom Hooks

🔥 Debugging: React DevTools Deep Dive

Components Tab

Profiler Tab (Performance Debugging)

Highlight Updates

🚨 Error Boundaries: Catching Crashes in Production

🧪 Common Testing Queries — Which One to Use

📊 What a Healthy Test Suite Looks Like

💡 Debugging Checklist (When Things Go Wrong)

🔗 Quick Resources

💬 What's Your Testing Philosophy?

Full-Stack with Next.js — From React Dev to Full-Stack Engineer

📌 What You'll Learn

🤔 What Is Next.js (And Why Does It Exist)?

Why the Industry Adopted Next.js So Fast

⚖️ Next.js vs The Alternatives

🚀 Setup & Project Structure

Create a Next.js App

Project Structure (App Router)

📁 File-Based Routing (App Router)

Page Files

Dynamic Routes (Parameters in URLs)

Layout Files (Shared UI Across Routes)

Special Files at a Glance

⚡ Server Components vs Client Components

Server Components (Default in App Router)

Client Components ("use client" directive)

The Golden Pattern: Server Shell + Client Islands

🌐 Data Fetching in Next.js

Three Patterns You'll Use

Fetching Strategy Decision

🔌 API Routes: Your Backend Lives Here

Basic CRUD API

Dynamic API Routes

🖼️ Image & Font Optimization (Free Performance Wins)

The <Image> Component

Font Optimization

🏗️ Real-World: Building a Blog Platform

Step 1: Project Setup

Step 2: Post Data (Markdown Files)

Step 3: Library to Read Posts

Client Components (`"use client"` directive)

The `<Image>` Component

1. `wp_posts` — The Heart of WordPress

2. `wp_postmeta` — The Post's Extra Drawers

3. `wp_users` — The User Registry

4. `wp_usermeta` — User Preferences and Roles

5. `wp_options` — The Site's Brain

6. `wp_terms` — The Taxonomy Vocabulary

7. `wp_term_taxonomy` — What Kind of Term Is It?

8. `wp_term_relationships` — The Many-to-Many Bridge

9. `wp_termmeta` — Metadata for Terms

10. `wp_comments` — Every Comment Ever Made

11. `wp_commentmeta` — Comment Metadata

12. `wp_links` — The Legacy Blogroll