DEV Community: Favour Okpara

I penned my thoughts on react rendering behaviour down.

Favour Okpara — Mon, 09 Feb 2026 10:21:57 +0000

Understanding React's Rendering Behavior: What Actually Triggers a Re-render?

Favour Okpara ・ Feb 9

Understanding React's Rendering Behavior: What Actually Triggers a Re-render?

Favour Okpara — Mon, 09 Feb 2026 09:22:37 +0000

TL;DR

React components re-render for exactly four reasons: state changes (useState/useReducer), parent component re-renders, context value changes, and custom hook state changes. Props changing doesn't directly cause re-renders—the parent re-rendering does. Mutating regular variables or refs won't trigger re-renders. React is fast by default, so only optimize when you have a proven performance issue.

If you've ever wondered why your React component re-rendered when you didn't expect it to, or worse, why it didn't re-render when you needed it to, you're not alone. React's rendering behavior can feel magical at first, but understanding what's happening under the hood will make you a more confident developer.

Let's break down exactly what triggers re-renders in React, clear up common misconceptions, and build a mental model you can rely on.

What is a "Render" Anyway?

Before we dive into triggers, let's clarify what we mean by "render." In React, rendering is the process of calling your component function (or the render() method in class components) to determine what should be displayed.

function MyComponent() {
  console.log('Component is rendering!');
  return <div>Hello World</div>;
}

Every time you see that console.log fire, React is rendering your component. But rendering doesn't automatically mean the DOM updates. React first calculates what should change, then only updates the actual DOM if necessary. This is a crucial distinction.

The Four Fundamental Re-render Triggers

There are exactly four things that cause a React component to re-render:

1. State Changes

When you call a state setter function (from useState or useReducer), React schedules a re-render of that component.

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

  const increment = () => {
    setCount(count + 1); // Triggers a re-render
  };

  return <button onClick={increment}>{count}</button>;
}

Note: React uses Object.is() comparison to check if the state actually changed. If you set state to the same value it already has, React will bail out of the re-render.

const [count, setCount] = useState(5);
setCount(5); // No re-render! Value didn't change

2. Parent Component Re-renders

This is the source of many "Why did this re-render?" moments. When a parent component re-renders, all of its children re-render by default, regardless of whether their props changed.

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

  return (
    <div>
      <button onClick={() => setCount(count + 1)}>Click me</button>
      <Child /> {/* Re-renders every time Parent does */}
    </div>
  );
}

function Child() {
  console.log('Child rendered!');
  return <div>I'm a child</div>;
}

Even though Child receives no props and has no state, it re-renders whenever Parent does. This is React's default behavior. React assumes that a parent re-rendering might affect its children.

3. Context Changes

When a context value changes, every component that consumes that context (via useContext or Context.Consumer) will re-render.

const ThemeContext = createContext();

function App() {
  const [theme, setTheme] = useState('light');

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

function Toolbar() {
  // This component re-renders when theme changes
  const theme = useContext(ThemeContext);
  return <div className={theme}>Toolbar</div>;
}

Note: Even if a component sits between the Provider and the consumer, the consumer will still re-render when the context changes, even if the middle component doesn't.

4. Hook Changes

When a custom hook's internal state or subscribed values change, components using that hook will re-render.

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

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

  return width;
}

function MyComponent() {
  const width = useWindowWidth(); // Re-renders when window is resized
  return <div>Width: {width}</div>;
}

What DOESN'T Trigger Re-renders

Just as important as knowing what triggers re-renders is knowing what doesn't:

Props Changes Alone Don't Trigger Re-renders

This surprises people, but it's true. Props changing doesn't directly cause a re-render, the parent re-rendering does. Props changing is just a consequence of the parent re-rendering and passing new values down.

function Parent() {
  const [count, setCount] = useState(0);
  return <Child value={count} />; // Parent re-renders, Child re-renders
}

The Child doesn't re-render "because props changed." It re-renders because Parent re-rendered, which happens to result in new props being passed.

Regular Variable Changes

Mutating regular variables or object properties doesn't trigger re-renders. Only state changes do.

function Broken() {
  let count = 0; // NOT state

  const increment = () => {
    count++; // This won't trigger a re-render!
    console.log(count); // Will log incremented value
  };

  return <button onClick={increment}>{count}</button>; // UI won't update
}

Ref Changes

Updating a ref (via useRef) doesn't trigger re-renders. That's actually the point of refs, they're for values that need to persist across renders without causing re-renders.

function Component() {
  const renderCount = useRef(0);

  renderCount.current++; // No re-render triggered

  return <div>Rendered {renderCount.current} times</div>;
}

Common Misconceptions

"React re-renders when props change"

As we discussed, this is backwards. React re-renders the component, which results in potentially different props being passed to children.

"Re-rendering is bad and should be avoided"

Re-rendering is how React works! It's not inherently bad. React is very fast at rendering, and most components render in microseconds. Only optimize re-renders if you have a proven performance problem.

"Setting state to the same value always causes a re-render"

React will bail out of re-renders if you set state to the same value (using Object.is() comparison). However, this bailout happens after React has started the re-render process, so the component function will be called once more, but children won't re-render.

Building Your Mental Model

Here's a simple mental model to internalize:

State changes are the root cause of all re-renders (including context and hook state)
Re-renders cascade down the component tree by default
React compares before committing to the DOM (rendering ≠ DOM updates)
Optimization tools exist when needed (React.memo, useMemo, useCallback)

When Should You Care About Re-renders?

Most of the time, you shouldn't. React is fast, and premature optimization wastes time. You should investigate re-renders when:

You notice visible lag or stuttering in your UI
You have components doing expensive calculations on every render
You're rendering large lists (hundreds or thousands of items)
Your profiler shows components taking significant time to render

Practical Example: Debugging Unexpected Re-renders

Let's say you have a component re-rendering too much. Here's how to debug it:

function MyComponent({ data }) {
  // Add this to see when and why component renders
  useEffect(() => {
    console.log('MyComponent rendered');
  });

  return <div>{data.value}</div>;
}

Then ask yourself:

Is the parent re-rendering? (Check parent's render logs)
Is state changing in this component? (Log state values)
Is context changing? (Log context values)
Are we getting new prop objects on every render? (Log data identity)

Conclusion

React's rendering behavior follows consistent, predictable rules. State changes trigger re-renders, which cascade to children by default. Understanding this helps you reason about your app's behavior and know when (and when not) to optimize.

The key insight: React re-renders are not triggered by props changes or variable assignments, they're triggered by state changes and then propagate down the component tree. Everything else follows from this fundamental truth.

Now when you see an unexpected re-render, you'll know exactly where to look: trace back to find which state changed, and you'll find your answer.

Have questions about React rendering? Found this helpful? Want me to dive deeper into when to use useMemo, useCallback, and React.memo for optimization? Let me know in the comments below!

Implementing Secure Authentication in Next.js with External APIs: A BFF Pattern Approach

Favour Okpara — Tue, 03 Feb 2026 07:16:34 +0000

TL;DR

Next.js middleware can't read httpOnly cookies from external APIs because they're cross origin. The solution: create Next.js API routes that proxy requests to your external backend, setting same origin cookies that middleware can access. This BFF (Backend for Frontend) pattern is secure but adds maintenance overhead. Use it when working with external APIs you don't control and security is critical.

A few weeks back, I was working on a project to build a website for a tutor in Next.js that required me to integrate login and register APIs for user authentication. Coming from a React background, it seemed easy and straightforward. All I had to do was ensure that my backend was sending the authorization token as cookies, then include it in my API calls by adding credentials—and that was that.

The React Authentication Pattern

Example of login in React below

const login = async (e) => {
  e.preventDefault();
  setError("");
  setLoading(true);

  try {
    const response = await fetch("https://external-api.com/login", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      credentials: "include",
      body: JSON.stringify({ email, password }),
    });

    if (!response.ok) {
      const data = await response.json();
      throw new Error(data.error || "Login failed");
    }

    const data = await response.json();

    router.push("/dashboard");
  } catch (err) {
    setError(err.message);
  } finally {
    setLoading(false);
  }
};

This works well in a traditional React SPA, but how do I prevent unauthenticated or unauthorized users from accessing protected routes in Next.js?

The Problem with Client-Side Authentication

The normal React way of protecting routes is to wrap protected routes in an AuthProvider connected to a global state management solution (Zustand, Redux, etc.) and conditionally render based on whether the user is authenticated or not. This is UI based authentication, and while it works, several critical issues concerned me:

No real security - A user can manipulate the client side state (localStorage, Redux store, etc.) to bypass the protection
API calls still need protection - Even if you hide a route, someone can still make API requests directly
Token exposure - If you store tokens in localStorage, they're accessible to JavaScript and vulnerable to XSS attacks

The Next.js Middleware Challenge

I was building in Next.js and I knew that Middleware (running at the edge) could be paired with my client-side API calls to provide better security. So I got to work, asking my middleware to check if the user is authorized by verifying cookies. But it was then I realized the core problem:

I can't access httpOnly cookies set by my external backend domain in my Next.js middleware because they're cross origin.

The middleware runs on my Next.js domain (e.g., myapp.com), but the cookies are set by my external API (e.g., external-api.com). Due to browser security policies, these cookies simply aren't available to my middleware. So the user would always appear unauthenticated because middleware doesn't have access to the particular httpOnly cookie I was looking for.

Why Common Workarounds Don't Work

I considered asking my backend developer to include the accessToken in the response body for a successful login, then set the cookie using document.cookie.

Example code below

const login = async (e) => {
  e.preventDefault();
  setError("");
  setLoading(true);

  try {
    const response = await fetch("https://external-api.com/login", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      credentials: "include",
      body: JSON.stringify({ email, password }),
    });

    if (!response.ok) {
      const data = await response.json();
      throw new Error(data.error || "Login failed");
    }

    const data = await response.json();

    // Store token in regular cookie (NOT httpOnly)
    document.cookie = `accessToken=${data.accessToken}; path=/; max-age=${24 * 60 * 60}; SameSite=Strict; Secure`;

    router.push("/dashboard");
  } catch (err) {
    setError(err.message);
  } finally {
    setLoading(false);
  }
};

This approach defeats the entire purpose of what I was trying to achieve because:

Token accessible to JavaScript (XSS risk) - Any malicious script can read document.cookie and steal the token
Cross Origin complications - When making authenticated requests to my external backend, I'd need to manually attach this token, potentially causing CORS issues

So I couldn't do without my middleware because I didn't want just UI based authentication, but when I involved my middleware, I was unnecessarily putting my entire project at risk by exposing the accessToken to JavaScript.

The Solution: Backend for Frontend (BFF) Pattern with Next.js API Routes

After research, I decided to implement what's essentially a Backend for Frontend (BFF) pattern using Next.js server routes. This approach bypasses the cross origin cookie problem entirely by creating a proxy layer between my client and the external API.

The flow is straightforward:

Client queries my Next.js API route (same domain)
Next.js API route queries the external backend
Next.js receives the token from the external API
Next.js sets httpOnly cookies on its own domain
Middleware can now read these same origin cookies
All subsequent requests go through the Next.js proxy

Step 1: Create the Login API Route

Under src/app, I created an api/login/route.ts file to act as a proxy to my external backend:

// app/api/login/route.ts
import { NextRequest, NextResponse } from 'next/server';

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

    // Validate input
    if (!email || !password) {
      return NextResponse.json(
        { error: 'Email and password are required' },
        { status: 400 }
      );
    }

    // Call external backend
    const response = await fetch(`${process.env.NEXT_PUBLIC_API_URL}/auth/login`, {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({ email, password }),
    });

    // Handle backend errors
    if (!response.ok) {
      const errorData = await response.json().catch(() => ({}));
      return NextResponse.json(
        { error: errorData.message || 'Login failed' },
        { status: response.status }
      );
    }

    // Get data from backend
    const data = await response.json();
    // Expected: { accessToken: "...", user: { id, email, name, ... } }

    // Create response with user data (NO TOKEN in response body)
    const res = NextResponse.json(
      { 
        user: data.user,
        message: 'Login successful' 
      },
      { status: 200 }
    );

    // Set httpOnly cookie with accessToken
    res.cookies.set('accessToken', data.accessToken, {
      httpOnly: true,
      secure: process.env.NODE_ENV === 'production',
      sameSite: 'strict',
      maxAge: 24 * 60 * 60, // 24 hours
      path: '/',
    });

    return res;
  } catch (error) {
    console.error('Login error:', error);
    return NextResponse.json(
      { error: 'An unexpected error occurred' },
      { status: 500 }
    );
  }
}

Step 2: Client-Side Login Component

Let the client query the login server route:

// app/login/page.tsx

'use client';

import { useState, FormEvent } from 'react';
import { useRouter } from 'next/navigation';

export default function LoginPage() {
  const [email, setEmail] = useState('');
  const [password, setPassword] = useState('');
  const [error, setError] = useState('');
  const [loading, setLoading] = useState(false);
  const router = useRouter();

  const handleLogin = async (e: FormEvent) => {
    e.preventDefault();
    setError('');
    setLoading(true);

    try {
      const response = await fetch('/api/login', {
        method: 'POST',
        headers: {
          'Content-Type': 'application/json',
        },
        credentials: 'include', // Important: allows cookies to be set
        body: JSON.stringify({ email, password }),
      });

      if (!response.ok) {
        const data = await response.json();
        throw new Error(data.error || 'Login failed');
      }

      const data = await response.json();
      console.log('Login successful:', data.message);

      // Redirect to dashboard
      router.push('/dashboard');
      router.refresh(); // Refresh to update server components
    } catch (err) {
      setError(err instanceof Error ? err.message : 'An error occurred');
    } finally {
      setLoading(false);
    }
  };

  return (
    <div className="flex min-h-screen items-center justify-center">
      <form onSubmit={handleLogin} className="w-full max-w-md space-y-4 p-8">
        <h1 className="text-2xl font-bold">Login</h1>

        {error && (
          <div className="bg-red-100 border border-red-400 text-red-700 px-4 py-3 rounded">
            {error}
          </div>
        )}

        <div>
          <label htmlFor="email" className="block text-sm font-medium mb-2">
            Email
          </label>
          <input
            id="email"
            type="email"
            value={email}
            onChange={(e) => setEmail(e.target.value)}
            required
            className="w-full px-3 py-2 border rounded-lg"
            placeholder="you@example.com"
          />
        </div>

        <div>
          <label htmlFor="password" className="block text-sm font-medium mb-2">
            Password
          </label>
          <input
            id="password"
            type="password"
            value={password}
            onChange={(e) => setPassword(e.target.value)}
            required
            className="w-full px-3 py-2 border rounded-lg"
            placeholder="••••••••"
          />
        </div>

        <button
          type="submit"
          disabled={loading}
          className="w-full bg-blue-600 text-white py-2 rounded-lg hover:bg-blue-700 disabled:opacity-50"
        >
          {loading ? 'Logging in...' : 'Login'}
        </button>
      </form>
    </div>
  );
}

Step 3: Middleware for Route Protection

Finally, create middleware to handle initial route protection. Because we've set cookies in our login server route (on the same domain), middleware has access to them and JavaScript never sees the actual token.

//middleware.ts (same level as app folder)

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

export function middleware(request: NextRequest) {
  // Check for authentication token
  const accessToken = request.cookies.get('accessToken');

  // If no auth cookie, redirect to login
  if (!accessToken) {
    return NextResponse.redirect(new URL('/login', request.url));
  }

  // Token exists, allow request to proceed
  // NOTE: This doesn't validate if token is valid/expired
  // That validation happens in your page components/layouts
  return NextResponse.next();
}

// Specify which routes to protect
export const config = {
  matcher: [
    '/dashboard/:path*',
    '/profile/:path*',
    '/settings/:path*',
    // Add more protected routes here
  ],
};

Step 4: Server-Side Token Validation

Middleware can only check if the cookie exists, not if it's valid or expired. You must validate the token on the server side in your protected pages or layouts.

// app/dashboard/layout.tsx

import { cookies } from 'next/headers';
import { redirect } from 'next/navigation';

async function validateToken(token: string) {
  try {
    // Call your backend to verify the token
    const response = await fetch(`${process.env.NEXT_PUBLIC_API_URL}/auth/verify`, {
      headers: {
        'Authorization': `Bearer ${token}`,
      },
    });

    if (!response.ok) {
      return null;
    }

    return await response.json();
  } catch (error) {
    return null;
  }
}

export default async function DashboardLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  const cookieStore = cookies();
  const accessToken = cookieStore.get('accessToken')?.value;

  if (!accessToken) {
    redirect('/login');
  }

  // CRITICAL: Validate the token with your backend
  const user = await validateToken(accessToken);

  if (!user) {
    // Token is invalid or expired
    redirect('/login');
  }

  return (
    <div>
      {/* Your dashboard layout */}
      {children}
    </div>
  );
}

What This Approach Achieves

With the steps above, I've created a secure authentication flow that addresses all my original concerns:

1. Maximum Security

HttpOnly cookies - Token can't be accessed by client side JavaScript (XSS protection)
Token never exposed - Client never sees the actual token in response body
Server-side validation - Backend validates every request through the proxy
No localStorage/sessionStorage - Eliminates common XSS attack vectors
Same-origin cookies - Middleware can enforce route protection before page loads

2. Better User Experience

Middleware protection - Unauthorized users are redirected BEFORE the page loads (no flash of protected content)
Seamless authentication - No loading states for auth checks on protected routes
Clean separation - Authentication logic is centralized in API routes

3. Leverages Next.js Native Features

Built-in middleware - No third party auth libraries needed for basic protection
Server components - Can read cookies on the server for SSR
Route protection - Declarative protection via middleware matcher
API routes - Natural place to handle authentication logic

4. Bypasses Cross Origin Issues

This approach doesn't solve CORS, it bypasses it entirely. By creating a same-origin proxy, you eliminate the cross-origin cookie problem. Your Next.js app becomes the single domain your frontend interacts with, while the external API remains completely separate.

The Trade-offs You Need to Consider

After discussing with colleagues and implementing this at scale, I have to acknowledge this approach comes with significant trade-offs:

1. Increased Complexity

More code to maintain - You need API routes for login, logout, refresh, and potentially every protected endpoint
Duplicate error handling - Must handle errors in both API routes and external backend
Cookie synchronization - Must keep Next.js cookies in sync with backend authentication state
Proxy maintenance - Every new backend endpoint needs a corresponding API route

2. Critical Middleware Limitations

This is the most important caveat: Middleware can only check if a cookie exists, not if it's valid or expired. This means:

Expired tokens will pass middleware checks
Invalid tokens will pass middleware checks
Revoked sessions will pass middleware checks

The actual validation still happens later either in your API routes when you proxy requests to the backend, or in server components when you validate the token. This creates a false sense of security if you're not aware of it.

Middleware provides a first line of defense (preventing completely unauthenticated access and avoiding UI flashes), but server-side validation in your components/layouts is mandatory for true security.

3. Performance Considerations

Extra network hop - Every request goes through your Next.js proxy before reaching the backend
Increased latency - Added overhead compared to direct backend calls
Server load - Your Next.js server now handles authentication proxy traffic

4. Scalability Concerns

Session management complexity - Token refresh, logout, and session invalidation all need proxy routes
State synchronization - Keeping authentication state consistent across your Next.js layer and backend
Deployment considerations - Your Next.js app now needs to be highly available since it's a critical proxy layer

When to Use This Pattern

This BFF (Backend-for-Frontend) pattern is appropriate when:

You're integrating with an external API you don't control that uses httpOnly cookies
You need server-side route protection with middleware
Security is a high priority and you want to eliminate XSS token exposure
You're willing to accept the maintenance overhead of a proxy layer
Your team has the resources to maintain parallel API routes

When NOT to Use This Pattern

Consider alternatives if:

You control both frontend and backend (use a monorepo or unified auth)
Your project is small/simple
You can use NextAuth.js or similar libraries (they handle this complexity for you)
Performance is critical and you can't afford the extra network hop
Your backend supports alternative auth methods (like token-based auth with short-lived tokens)

Conclusion

Implementing secure authentication in Next.js when working with external APIs requires understanding the limitations of cross origin cookies and the middleware execution model. The BFF pattern I've described solves real security problems but introduces architectural complexity.

The key insight is this: middleware provides route-level access control, but you still need server side token validation in your components. Think of middleware as a bouncer checking if you have a ticket, while your server components are the venue staff verifying the ticket is actually valid.

This approach has worked well for my tutor website project, but I wouldn't recommend it for every Next.js application. Evaluate your specific requirements, team capacity, and security needs before implementing this pattern. Sometimes a simpler solution with different trade-offs is the right choice, but for applications requiring this level of security with external APIs, it's a worthwhile investment.