Forem: Bernard Maina

A Comprehensive Guide to React Rendering Behavior

Bernard Maina — Sun, 04 May 2025 06:47:40 +0000

What is Rendering in React?

Rendering is the process of React asking your components to describe what they want their section of the UI to look like, now, based on the current combination of props and state.

Think of React components as chefs in a kitchen, preparing dishes based on specific recipes (props and state). React acts like a waiter, taking orders from customers and bringing them their meals. This process involves three key steps:

Triggering a render (taking the guest's order)
Rendering the component (preparing the order in the kitchen)
Committing to the DOM (serving the order to the table)

Step 1: Triggering a Render

There are two main reasons why a component would render:

Initial render - When your app first starts
State updates - When a component's state (or one of its ancestors' state) changes

Initial Render

When your app starts, you trigger the initial render by calling createRoot with the target DOM node, and then calling its render method with your component:

import { createRoot } from 'react-dom/client';
const root = createRoot(document.getElementById('root'));
root.render(<App />);

Re-renders from State Updates

After the initial render, you can trigger additional renders by updating component state with a setter function. Updating state automatically queues a render.

Here are the ways to queue a re-render:

Function components: Using state setters from useState or dispatches from useReducer
Class components: Calling this.setState() or this.forceUpdate()
Calling the ReactDOM render() method again (equivalent to forceUpdate() on the root component)

Step 2: React Renders Your Components

After a render is triggered, React calls your components to figure out what to display. "Rendering" is React calling your components.

During this phase:

For initial render, React starts with the root component
For subsequent renders, React starts with the component that had its state updated

The rendering process is recursive - React will render the component that triggered the update, then its children, then their children, and so on.

The Important Rule of React Rendering

React's default behavior is that when a parent component renders, React will recursively render all child components inside of it!

This means:

When a parent renders, all children automatically render too
React does not care whether "props changed" - children render unconditionally when parents render
Rendering itself is not bad - it's how React determines what needs to change

Component Trees and Rendering Example

Consider a component tree of A > B > C > D, where a user clicks a button in B that increments a counter:

We call setState() in B, which queues a re-render of B
React starts the render pass from the top of the tree
React sees A is not marked for update and moves past it
React sees B is marked for update and renders it
Since B rendered, React moves downwards and renders C too
Since C rendered, React moves downwards and renders D too

Render vs. DOM Update

A key part to understand is that "rendering" is not the same thing as "updating the DOM", and a component may be rendered without any visible changes happening as a result. When React renders a component:

The component might return the same render output as last time, so no changes are needed
In Concurrent Rendering, React might render a component multiple times, but throw away the render output if other updates invalidate the current work

Render Phase vs. Commit Phase

React divides rendering work into two phases:

Render Phase: Contains all the work of rendering components and calculating changes
Commit Phase: The process of applying those changes to the DOM

After the commit phase, React updates all refs to point to the DOM nodes and component instances, then synchronously runs lifecycle methods and useLayoutEffect hooks.

After a short timeout, React runs all useEffect hooks in what's known as the "Passive Effects" phase.

Rules of React Rendering

One of the primary rules of React rendering is that rendering must be "pure" and not have any side effects!

Render logic must NOT:

Mutate existing variables and objects
Create random values like Math.random() or Date.now()
Make network requests
Queue state updates

Render logic MAY:

Mutate objects that were newly created during rendering
Throw errors
"Lazy initialize" data that hasn't been created yet, such as a cached value

Performance Optimization Techniques

While renders are a normal part of React's workflow, sometimes we want to avoid unnecessary renders to improve performance.

Component Render Optimization APIs

React provides three main APIs to skip rendering components when appropriate:

React.memo(): A higher-order component that prevents re-renders when props haven't changed. Works for both function and class components.
shouldComponentUpdate: A class component lifecycle method that lets you control whether the component should re-render.
React.PureComponent: A base class that implements a shallow comparison of props and state to determine if re-rendering is necessary.

These approaches all use "shallow equality" comparison to check if props or state have changed between renders.

How to Use Memoization Effectively

For function components, React provides hooks to help reuse the same references:

useMemo: For memoizing calculated values or objects
useCallback: Specifically for memoizing callback functions

Example of effective memoization:

function OptimizedComponent() {
  const [counter1, setCounter1] = useState(0);
  const [counter2, setCounter2] = useState(0);

  // This element stays the same reference if counter2 changes,
  // preventing unnecessary re-renders of ExpensiveChild
  const memoizedElement = useMemo(() => {
    return <ExpensiveChildComponent data={counter1} />;
  }, [counter1]);

  return (
    <div>
      <button onClick={() => setCounter1(counter1 + 1)}>Counter 1</button>
      <button onClick={() => setCounter2(counter2 + 1)}>Counter 2</button>
      {memoizedElement}
    </div>
  );
}

Should You Memoize Everything?

The answer is no - memoization itself has a cost. You should only optimize components when:

The component renders often with the same props
The rendering logic is expensive
You've identified a performance problem through profiling

Render Batching and Timing

React applies an optimization called "render batching." This is when multiple state updates result in a single render pass being queued and executed.

In React 18+, all updates queued within a single event loop tick are automatically batched together, reducing the total number of renders.

State Updates, Closures, and the "Snapshot" Model

A common confusion point in React:

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

  const handleClick = () => {
    setCount(count + 1);
    console.log(count); // This will log the "old" value, not the updated one
  };

  return <button onClick={handleClick}>Increment</button>;
}

The reason this happens is that function components capture the state values in their closures. Each render has its own "snapshot" of state, and that snapshot can't see future updates.

Context and Rendering Behavior

React's Context API allows values to be passed down through the component tree without prop drilling.

Context is not a "state management" tool. You have to manage the values that are passed into context yourself, typically by keeping data in React component state.

How Context Updates Affect Rendering

When a context provider receives a new value:

React checks if the provider's value is a new reference
If it's a new reference, React knows the value has changed
All components that consume that context need to be updated, even if they only use part of the context value

Optimizing Context Performance

The React component right under your Context Provider should probably use React.memo.

This prevents state updates in the parent component from causing all components to re-render - only the sections where context is actually used will re-render.

Measuring and Improving Performance

To identify and fix performance issues:

Use the React DevTools Profiler to see which components are rendering and why
Look for components that render unnecessarily
Apply optimization techniques like React.memo(), useMemo(), and useCallback() appropriately
Always test performance in production builds, not development mode

Immutability and Rendering

State updates in React should always be done immutably. Mutating state can lead to components not rendering when expected and confusion about when data actually updated.

When updating objects or arrays in state:

// ❌ BAD - mutating state directly
const handleClick = () => {
  todos[3].completed = true;
  setTodos(todos); // This won't trigger a re-render!
};

// ✅ GOOD - creating a new reference
const handleClick = () => {
  const newTodos = [...todos];
  newTodos[3].completed = true;
  setTodos(newTodos);
};

Future React Improvements

The React team is working on several improvements that may change how we think about rendering:

React Forget: An experimental compiler designed to automatically add memoization to components, potentially eliminating many unnecessary renders throughout the component tree.
Context Selectors: A proposed API that would allow components to selectively subscribe to only parts of a context value, making Context more efficient for larger state.

Summary

React always renders components recursively by default
Rendering itself is not a problem - it's how React knows what to update
React only updates the DOM when necessary after comparing render outputs
Use memoization techniques like React.memo(), useMemo(), and useCallback() to optimize performance when needed
Keep state updates immutable to ensure proper rendering
Context is useful for passing values down the tree but requires careful optimization

Understanding React's rendering behavior helps you build more efficient applications and debug rendering issues more effectively.

🚀 The Power of `...`: Mastering JavaScript's Spread Syntax Like a Code Wizard

Bernard Maina — Thu, 10 Apr 2025 05:54:15 +0000

Have you ever felt like JavaScript was holding back on you? Like you’re writing decent code but not quite wielding its full cosmic power?

Well, buckle up.

Today, we’re diving into one of JavaScript’s most elegant, flexible, and misunderstood superpowers: the Spread Syntax (...). Often mistaken for its cousin, rest parameters, spread syntax flips the script — turning arrays (or other iterables) into individual elements with a single stroke of syntactic sorcery.

Let’s ignite this journey with a classic use case.

🧠 Problem: You Have an Array, But Need Arguments

console.log(Math.max(3, 5, 1)); // Easy

But what if you’re handed an array?

let arr = [3, 5, 1];
console.log(Math.max(arr)); // ❌ NaN

Math.max expects individual numbers, not a single array. Manually unpacking like arr[0], arr[1], arr[2] is ugly, brittle, and screams junior.

So what’s the elegant fix?

🌟 Spread Syntax: Unleash the Elements

console.log(Math.max(...arr)); // ✅ 5

By using ...arr, we’re saying: “Hey JavaScript, unpack this iterable and feed its items one by one.” Simple, stunning, and effective.

🤯 Spread Gets Wild — Combine, Extend, Inject

You’re not limited to just one array. Combine several:

let arr1 = [1, -2, 3, 4];
let arr2 = [8, 3, -8, 1];

console.log(Math.max(...arr1, ...arr2)); // 8

Or mix spread elements with raw values like a true JS chef:

console.log(Math.max(1, ...arr1, 2, ...arr2, 25)); // 25

Anywhere you’d manually unpack — spread can flex.

🔡 Strings? Yup. Spread Works There Too.

let str = "Hello";
console.log([...str]); // ['H', 'e', 'l', 'l', 'o']

Strings are iterable, so spreading them splits them into characters. Internally, it’s powered by the same mechanics as for...of.

Prefer something more explicit?

console.log(Array.from(str)); // ['H', 'e', 'l', 'l', 'o']

☝️ Small difference: Array.from() works on array-likes and iterables. Spread only works with iterables. That’s why Array.from() is more universal in edge cases.

📦 Copying Arrays & Objects — The Slick Way

Need a shallow copy of an array?

let original = [1, 2, 3];
let copy = [...original];

console.log(original === copy); // false
console.log(JSON.stringify(original) === JSON.stringify(copy)); // true

And just like that, you’ve cloned an array without Array.slice() or Object.assign().

Same magic for objects:

let obj = { a: 1, b: 2, c: 3 };
let clone = { ...obj };

obj.d = 4;

console.log(clone); // { a: 1, b: 2, c: 3 }

👑 Clean. Concise. Classy.

🧘‍♂️ Rest vs. Spread — Know the Difference Like a Pro

They look the same, but they’re polar opposites.

Syntax	Looks Like	Purpose
Rest	`function(...args)`	Collect parameters into an array
Spread	`func(...arr)`	Expand an iterable into parameters

Think of it this way:

🥄 Rest gathers.

💥 Spread explodes.

And they play beautifully together. For example:

function logAll(...args) {
  console.log(args);
}

logAll(...[1, 2, 3]); // [1, 2, 3]

💡 This pattern makes your functions endlessly flexible.

🔥 TL;DR — Spread Syntax

Use ...arr to expand arrays (or strings, or sets...) into individual elements.
Combine multiple iterables, inject values mid-array, or copy data structures with elegance.
Pair with rest parameters for total control over your function arguments.
Prefer Array.from() for weird objects that look like arrays but aren’t iterable.

🧪 Bonus Challenge for the Curious

Here’s a challenge to flex your new powers:

function mergeUnique(...arrays) {
  return [...new Set(arrays.flat())];
}

console.log(mergeUnique([1, 2], [2, 3], [4, 1])); // [1, 2, 3, 4]

Using spread, flat(), and Set to create a clean, deduplicated array — like a wizard casting a one-liner spell.

Unlocking the V8 Engine: Why Your JavaScript is Faster Than You Think

Bernard Maina — Mon, 07 Apr 2025 17:18:18 +0000

Ever wondered how JavaScript in Chrome or Node.js runs so fast? This deep dive into the V8 Engine reveals its inner workings — from parsing and bytecode to TurboFan optimizations and JIT magic.

Inside V8: The Hidden Architecture Powering JavaScript's Speed

JavaScript has come a long way from being “just a scripting language.” Thanks to V8, Google’s high-performance JavaScript engine, it's now powering everything from browsers (like Chrome) to backend runtimes (like Node.js). But what makes V8 so fast?

Let’s break down the internal architecture of V8 — from parsing to Just-In-Time (JIT) compilation — and uncover how it transforms human-readable JavaScript into blazing-fast machine code.

🧩 The Core Components of V8

At a high level, V8 is composed of four major parts:

1. 🧾 The Parser

Responsible for converting your JavaScript code into an Abstract Syntax Tree (AST) — the structured representation of code.

Scanner: Tokenizes the source code.
Pre-parser: Skims through functions that might not run immediately.
Full parser: Fully parses the code that’s about to be executed.

2. ⚙️ Ignition (Interpreter)

V8's interpreter turns the AST into bytecode and begins execution.

Produces compact bytecode.
Starts collecting type feedback during execution.
Marks functions as "hot" (frequently used) — a signal for deeper optimization.

3. 🏎️ TurboFan (Optimizing Compiler)

Once a function is deemed “hot,” it gets handed over to TurboFan.

Typer: Uses runtime data to specialize code.
Graph Builder: Builds an intermediate representation (IR).
Optimizer: Applies dozens of smart compiler techniques.
Code Generator: Outputs machine-level code.

4. ♻️ Garbage Collector

Manages memory allocation and cleanup to ensure performance without leaks.

Young Generation: Handles short-lived objects.
Old Generation: Keeps long-lived data.
Scavenger & Mark-and-Sweep: Clean memory incrementally or fully.
Compactor: Reduces fragmentation.

🔄 The Execution Pipeline: From Code to Machine

Let’s walk through the full execution flow:

JavaScript is parsed → AST is created.
Ignition compiles it into bytecode and starts running.
During execution, profiling data (types, frequency, etc.) is collected.
"Hot" code is passed to TurboFan for JIT optimization.
Optimized machine code replaces bytecode.
If assumptions fail, V8 deoptimizes back to bytecode.

🚀 Where Optimization Happens in the Pipeline

🔹 Parser-Level

Lazy Parsing: Only fully parses code that's needed now.
Pre-parsing: Syntax checks without full AST generation.
Parse Caching: Reuses previously parsed code across page loads.

🔹 Ignition-Level

Efficient Bytecode: Leaner execution instructions.
Type Feedback: Observes runtime types for future optimization.
Inline Caching: Accelerates property access patterns.
Hot Spot Detection: Identifies candidates for JIT compilation.

🔹 TurboFan-Level

Function Inlining: Removes call overhead.
Type Specialization: Produces faster, tailored machine code.
Loop Optimization: Unrolling, peeling, fusion for speed.
Dead Code Elimination: Strips out unused logic.
Escape Analysis: Allocates some objects on the stack, not heap.
Redundancy Removal: Eliminates duplicate computations.

🔹 GC-Level

Generational GC: Tailors cleanup for object lifespan.
Incremental/Concurrent GC: Runs in the background to reduce pauses.
Memory Compaction: Ensures better space utilization.

💡 JIT Compilation in Action

Just-In-Time (JIT) compilation is V8’s superpower. Here's how it works:

🧬 1. Tiered Compilation

Tier 1: Ignition interprets bytecode (fast startup).
Tier 2: TurboFan replaces hot code with optimized machine code.

🔮 2. Speculation & Assumptions

V8 speculates about types and behaviors.
Optimized code is based on these assumptions.
Assumption checks are embedded. If wrong → deoptimize.

📈 3. Profiling-Guided Optimization

V8 uses real runtime data to guide what code gets optimized.
Focuses resources on code that actually runs often.

🔄 4. On-Stack Replacement (OSR)

Mid-execution code (like loops) gets swapped with optimized versions.
No need to restart — it’s a live upgrade.

🎯 5. Optimization Triggers

High function call count.
Long-running loops.
Significant CPU time spent.

⏱️ Optimization & Deoptimization Cycle

graph TD
A[JavaScript Source Code] --> B[Parser → AST]
B --> C[Ignition: Bytecode + Type Profiling]
C --> D[TurboFan: Optimized Machine Code]
D --> E[Execution]
E -->|If assumptions break| C

📊 Real-World Performance Impact

Factor	Impact
Startup Time	Compact bytecode allows fast load and execution
Runtime Speed	JIT turns hot paths into native machine code for blazing performance
Memory Usage	Balances compactness (bytecode) vs speed (machine code)
Battery Life	Optimized code reduces CPU cycles, improving efficiency on devices

👀 What’s Next?

Curious about how Hidden Classes and Inline Caches make property access so fast in V8? Or want a visual walk-through of Escape Analysis?

Let me know in the comments and I’ll drop the next deep-dive article soon!

🙌 Wrap-up

Understanding V8 internals is a superpower. Whether you're debugging performance issues, building high-speed backend apps, or just curious about what happens under the hood — this knowledge will level you up as a JavaScript developer.

Let’s connect! If you liked this, drop a ❤️