Forem: Tihomir Ivanov

How I built a Database-Free eCommerce for my Online Store and hosted it for $0

Tihomir Ivanov — Sun, 22 Feb 2026 00:29:03 +0000

Selling digital products like WordPress themes and plugins shouldn't require a $30/month Shopify subscription or a complex backend with a heavy database.

As a developer, I wanted something minimalist, fast, and, most importantly, cost-effective. That’s why I built TishCommerce.

The Problem: Overhead is the Enemy

When you only have a few sales a month, paying for a managed database (RDS, MongoDB Atlas) or a SaaS platform eats your entire margin. I wanted a store that:

Has zero monthly software fees.
Requires no database maintenance.
Can be hosted for free on platforms like Netlify or Vercel.

The Solution: TishCommerce

I built TishCommerce using Next.js 16 (App Router) and React 19.

No Database? No Problem.

Instead of a traditional DB, I used a JSON-based architecture for product storage. For a store with up to 200 products (like my plugin shop at tishonator.com), this is incredibly efficient. It makes the site blazing fast and eliminates the need for database connections.

Hosting for $0

By keeping the architecture serverless-friendly and database-free, I’m able to host the entire storefront on Netlify for free. No hosting bills, no hidden costs.

The Tech Stack

Framework: Next.js 16 & TypeScript

Styling: TailwindCSS

Payments: Integrated Stripe and PayPal (Standard + Express)

Email: Automated order details via Gmail SMTP (no expensive email providers needed)

Marketing: Mailchimp integration & reCAPTCHA v3

You can check out the full source code here:

👉 GitHub: https://github.com/tishonator/TishCommerce/

And see it in action here:

👉 Live Demo: https://tishcommerce.vercel.app/

Final Thoughts

If you're looking for a "set it and forget it" eCommerce solution for your side projects, give TishCommerce a try. It’s built by a dev, for devs.

I’d love to hear your thoughts on the database-free approach! Is it the future for small-scale eCommerce?

Referential Equality & Memoization: Why `{} !== {}` Breaks React Performance

Tihomir Ivanov — Fri, 16 Jan 2026 23:54:41 +0000

You've probably seen code like this in React:

<ChildComponent config={{ theme: 'dark' }} />

And wondered why ChildComponent re-renders on every parent render, even when wrapped in React.memo.

Or you've used useEffect and seen it run repeatedly:

useEffect(() => {
  fetchData();
}, [config]); // 'config' is recreated every render!

The culprit? Referential equality — JavaScript's way of comparing objects and arrays by reference, not by value.

Understanding this is critical for writing performant React applications.

The Golden Rule

In JavaScript, objects and arrays are compared by reference (memory address), not by value. Two objects with identical contents are NOT equal if they're different instances. This means {} !== {} and [] !== []. React uses referential equality to determine when to re-render components, so creating new objects/arrays on every render can cause unnecessary re-renders.

In simpler terms: JavaScript doesn't care if two objects look the same — it only cares if they're the SAME object in memory.

Let's understand why this matters and how memoization solves it.

Part 1: Referential Equality Explained

Primitives vs Objects

Primitives (numbers, strings, booleans, null, undefined) are compared by value:

const a = 5;
const b = 5;
console.log(a === b); // true

const str1 = 'hello';
const str2 = 'hello';
console.log(str1 === str2); // true

Objects (including arrays, functions) are compared by reference:

const obj1 = { name: 'Alice' };
const obj2 = { name: 'Alice' };
console.log(obj1 === obj2); // false (different references!)

const arr1 = [1, 2, 3];
const arr2 = [1, 2, 3];
console.log(arr1 === arr2); // false

Why? obj1 and obj2 are stored at different memory addresses, even though they have identical contents.

What About Same Reference?

const obj1 = { name: 'Alice' };
const obj2 = obj1; // Same reference

console.log(obj1 === obj2); // true (same memory address)

obj2.name = 'Bob';
console.log(obj1.name); // "Bob" (mutation affects both!)

Key Point: When you assign an object to another variable, you're copying the reference, not the object itself. (See the "Pass by Value" article for more on this!)

Part 2: How This Affects React

React uses referential equality to determine if props have changed:

Example: `React.memo` Doesn't Work

function Child({ config }) {
  console.log('Child rendered');
  return <div>{config.theme}</div>;
}

const MemoizedChild = React.memo(Child);

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

  const config = { theme: 'dark' }; // New object every render!

  return (
    <div>
      <button onClick={() => setCount(count + 1)}>Count: {count}</button>
      <MemoizedChild config={config} />
    </div>
  );
}

Result: Every time you click the button, MemoizedChild re-renders, even though React.memo is supposed to prevent that.

Why?

Clicking the button triggers Parent to re-render
const config = { theme: 'dark' } creates a new object
React compares the old and new config props: oldConfig === newConfig → false
React thinks the props changed, so it re-renders MemoizedChild

The Same Problem with Arrays

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

  const items = [1, 2, 3]; // New array every render!

  return (
    <div>
      <button onClick={() => setCount(count + 1)}>Count: {count}</button>
      <MemoizedList items={items} />
    </div>
  );
}

Same issue: items is a new array on every render, so MemoizedList always re-renders.

And Functions Too!

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

  const handleClick = () => { // New function every render!
    console.log('Clicked');
  };

  return (
    <div>
      <button onClick={() => setCount(count + 1)}>Count: {count}</button>
      <MemoizedButton onClick={handleClick} />
    </div>
  );
}

Same issue: handleClick is a new function on every render.

Part 3: Memoization to the Rescue

Memoization is the technique of caching values/computations so they're only recalculated when dependencies change.

React provides three hooks for memoization:

useMemo — Memoize values (objects, arrays, expensive computations)
useCallback — Memoize functions (special case of useMemo)
React.memo — Memoize entire components

1. `useMemo` for Objects and Arrays

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

  const config = useMemo(() => ({ theme: 'dark' }), []); // Same object every render!

  return (
    <div>
      <button onClick={() => setCount(count + 1)}>Count: {count}</button>
      <MemoizedChild config={config} />
    </div>
  );
}

How it works:

useMemo returns the same object ({ theme: 'dark' }) on every render
The object is only recreated if dependencies change (empty array [] = never)
Now oldConfig === newConfig → true, so MemoizedChild doesn't re-render

With Dependencies

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

  const config = useMemo(() => ({ theme }), [theme]); // Recreate only when 'theme' changes

  return (
    <div>
      <button onClick={() => setCount(count + 1)}>Count: {count}</button>
      <MemoizedChild config={config} />
    </div>
  );
}

Now:

When count changes, config stays the same (no re-render)
When theme changes, config is recreated (re-render happens, as expected)

2. `useCallback` for Functions

useCallback is shorthand for memoizing functions:

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

  const handleClick = useCallback(() => { // Same function every render!
    console.log('Clicked');
  }, []); // No dependencies = function never changes

  return (
    <div>
      <button onClick={() => setCount(count + 1)}>Count: {count}</button>
      <MemoizedButton onClick={handleClick} />
    </div>
  );
}

Equivalent useMemo version:

const handleClick = useMemo(() => {
  return () => console.log('Clicked');
}, []);

But useCallback is cleaner for functions.

With Dependencies

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

  const handleClick = useCallback(() => {
    console.log(`Clicked for user ${userId}`);
  }, [userId]); // Recreate when 'userId' changes

  return (
    <div>
      <button onClick={() => setCount(count + 1)}>Count: {count}</button>
      <MemoizedButton onClick={handleClick} />
    </div>
  );
}

3. `React.memo` for Components

React.memo is a Higher-Order Component that memoizes the entire component:

const Child = React.memo(function Child({ config }) {
  console.log('Child rendered');
  return <div>{config.theme}</div>;
});

How it works:

React shallowly compares old and new props
If all props are referentially equal, skip re-render
If any prop changes (by reference), re-render

Important: React.memo uses shallow comparison:

// Shallow comparison (default)
oldProps.config === newProps.config // Checks reference only

// Deep comparison (custom)
React.memo(Child, (prevProps, nextProps) => {
  return prevProps.config.theme === nextProps.config.theme; // Custom logic
});

Part 4: When to Use Memoization

Use Memoization When:

Passing objects/arrays to memoized child components

const config = useMemo(() => ({ theme: 'dark' }), []);
<MemoizedChild config={config} />

Passing functions to memoized child components

const handleClick = useCallback(() => {}, []);
<MemoizedButton onClick={handleClick} />

Expensive computations

const sortedData = useMemo(() => {
  return data.sort((a, b) => a.value - b.value); // Expensive!
}, [data]);

Dependencies in useEffect or other hooks

const config = useMemo(() => ({ theme: 'dark' }), []);

useEffect(() => {
  fetchData(config); // Won't re-run unnecessarily
}, [config]);

Don't Use Memoization When:

Primitives (already compared by value)

// Unnecessary
const count = useMemo(() => 5, []);

// Just use the value
const count = 5;

Child doesn't re-render expensively

// Overkill if rendering <div>{text}</div> is cheap
const text = useMemo(() => someString, []);

Component always re-renders anyway

// No benefit if Child isn't memoized
const config = useMemo(() => ({ theme: 'dark' }), []);
<Child config={config} /> // Not wrapped in React.memo

Premature optimization

Don't memoize everything! Only optimize when you have a performance problem.

Part 5: Common Memoization Pitfalls

Pitfall 1: Missing Dependencies

function Component({ userId }) {
  const handleClick = useCallback(() => {
    console.log(`User: ${userId}`); // Uses 'userId'
  }, []); // Missing dependency!

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

Problem: handleClick closes over the initial userId and never updates.

Fix:

const handleClick = useCallback(() => {
  console.log(`User: ${userId}`);
}, [userId]); // Include 'userId'

Pitfall 2: Memoizing Without Memoized Child

function Parent() {
  const config = useMemo(() => ({ theme: 'dark' }), []); // Useless!

  return <Child config={config} />; // Child isn't memoized
}

function Child({ config }) {
  return <div>{config.theme}</div>;
}

Problem: Child re-renders on every Parent render anyway (not wrapped in React.memo).

Fix:

const MemoizedChild = React.memo(Child); // Now useMemo helps

function Parent() {
  const config = useMemo(() => ({ theme: 'dark' }), []);
  return <MemoizedChild config={config} />;
}

Pitfall 3: Creating Objects Inside JSX

function Parent() {
  return <Child config={{ theme: 'dark' }} />; // New object every render!
}

Fix:

function Parent() {
  const config = useMemo(() => ({ theme: 'dark' }), []);
  return <Child config={config} />; // Stable reference
}

Pitfall 4: Memoizing Everything (Over-Optimization)

// Too much memoization
function Component() {
  const a = useMemo(() => 1, []);
  const b = useMemo(() => 2, []);
  const sum = useMemo(() => a + b, [a, b]);

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

Problem: useMemo has overhead. For simple computations, it's slower than just recalculating.

Better:

function Component() {
  const a = 1;
  const b = 2;
  const sum = a + b; // Fast enough without memoization

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

Part 6: Memoization Patterns in React

Pattern 1: Memoizing Context Values

function ThemeProvider({ children }) {
  const [theme, setTheme] = useState('light');

  // New object every render → all consumers re-render!
  // const value = { theme, setTheme };

  // Stable reference
  const value = useMemo(() => ({ theme, setTheme }), [theme]);

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

Pattern 2: Memoizing Expensive Filters

function UserList({ users, filter }) {
  const filteredUsers = useMemo(() => {
    return users.filter(user => {
      // Expensive filtering logic
      return user.name.toLowerCase().includes(filter.toLowerCase());
    });
  }, [users, filter]); // Only recompute when 'users' or 'filter' changes

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

Pattern 3: Memoizing Event Handlers with Parameters

function ItemList({ items, onDelete }) {
  return (
    <ul>
      {items.map(item => (
        <Item key={item.id} item={item} onDelete={onDelete} />
      ))}
    </ul>
  );
}

const Item = React.memo(function Item({ item, onDelete }) {
  // New function every render
  // const handleDelete = () => onDelete(item.id);

  // Memoized
  const handleDelete = useCallback(() => {
    onDelete(item.id);
  }, [item.id, onDelete]);

  return (
    <li>
      {item.name}
      <button onClick={handleDelete}>Delete</button>
    </li>
  );
});

Pattern 4: Using Refs for Stable References

Sometimes you need a value that doesn't trigger re-renders:

function Component() {
  const configRef = useRef({ theme: 'dark' });

  useEffect(() => {
    // Always uses the same object reference
    fetchData(configRef.current);
  }, []); // No dependencies needed

  return <div>Content</div>;
}

Use case: When you need a stable reference but don't want to trigger re-renders when it changes.

Part 7: Debugging Referential Equality

Tool 1: `Object.is()` (React's Comparison)

React uses Object.is() for comparison (similar to === but handles NaN correctly):

const obj1 = { theme: 'dark' };
const obj2 = { theme: 'dark' };

console.log(Object.is(obj1, obj2)); // false (different references)

const obj3 = obj1;
console.log(Object.is(obj1, obj3)); // true (same reference)

Tool 2: React DevTools Profiler

Use the React DevTools Profiler to see why components re-render:

Open React DevTools
Go to Profiler tab
Start recording
Interact with your app
Look at "Why did this render?" section

Tool 3: `useWhyDidYouUpdate` Hook (Custom)

function useWhyDidYouUpdate(name, props) {
  const previousProps = useRef();

  useEffect(() => {
    if (previousProps.current) {
      const allKeys = Object.keys({ ...previousProps.current, ...props });
      const changedProps = {};

      allKeys.forEach(key => {
        if (previousProps.current[key] !== props[key]) {
          changedProps[key] = {
            from: previousProps.current[key],
            to: props[key]
          };
        }
      });

      if (Object.keys(changedProps).length) {
        console.log('[why-did-you-update]', name, changedProps);
      }
    }

    previousProps.current = props;
  });
}

function MyComponent(props) {
  useWhyDidYouUpdate('MyComponent', props);
  return <div>Content</div>;
}

Quick Reference Cheat Sheet

Hook	Purpose	Example
`useMemo`	Memoize values (objects, arrays, computations)	`useMemo(() => ({ theme }), [theme])`
`useCallback`	Memoize functions	`useCallback(() => {}, [deps])`
`React.memo`	Memoize components	`React.memo(Component)`
`useRef`	Stable mutable reference (doesn't cause re-renders)	`useRef({ theme: 'dark' })`

Key Takeaways

Objects and arrays are compared by reference, not by value: {} !== {}
Creating objects/arrays/functions on every render causes unnecessary re-renders in memoized components
useMemo stabilizes object/array references across renders
useCallback stabilizes function references (shorthand for useMemo with functions)
React.memo prevents component re-renders when props don't change (by reference)
Always include dependencies in useMemo and useCallback
Don't memoize primitives — they're already compared by value
Memoize context values to prevent unnecessary consumer re-renders
Don't over-optimize — memoization has overhead, only use it when needed

Interview Tip

When asked about referential equality and memoization:

"In JavaScript, objects are compared by reference, not value, so {} !== {} even though they look identical"
React's impact: "React uses referential equality to check if props changed. If you create a new object on every render, React thinks the props changed, causing re-renders"
Solution: "useMemo and useCallback stabilize references across renders, preventing unnecessary re-renders in memoized components"
Example: "If you pass config={{ theme: 'dark' }} to a memoized child, it re-renders every time. Using useMemo(() => ({ theme: 'dark' }), []) fixes it"
Best practice: "Only memoize when you have a performance problem — measure first, optimize second"

Now go forth and never wonder why your memoized component keeps re-rendering again!h

Composition vs Inheritance: Why React Chose the "Has-A" Over "Is-A" Relationship

Tihomir Ivanov — Fri, 16 Jan 2026 23:53:02 +0000

If you've learned object-oriented programming in languages like Java or C++, you've been taught that inheritance is the way to reuse code. Create a base class, extend it, override methods — it's the OOP way.

But React's official documentation says something surprising: "At Facebook, we use React in thousands of components, and we haven't found any use cases where we would recommend creating component inheritance hierarchies."

Why? Because composition is more flexible, more explicit, and easier to maintain than inheritance.

The Golden Rule

In JavaScript and React, prefer composition ("has-a" relationships) over inheritance ("is-a" relationships). Build complex components by combining simpler ones, not by creating deep class hierarchies.

In simpler terms: Instead of saying "Button is-a Component," say "Button has-a label and has-a onClick handler."

Let's understand why this matters and how to apply it.

Part 1: Inheritance vs Composition in JavaScript

Inheritance: The "Is-A" Relationship

Inheritance models an "is-a" relationship using class hierarchies.

class Animal {
  constructor(name) {
    this.name = name;
  }

  eat() {
    console.log(`${this.name} is eating`);
  }

  sleep() {
    console.log(`${this.name} is sleeping`);
  }
}

class Dog extends Animal {
  bark() {
    console.log(`${this.name} barks`);
  }
}

class Cat extends Animal {
  meow() {
    console.log(`${this.name} meows`);
  }
}

const dog = new Dog('Buddy');
dog.eat();   // "Buddy is eating"
dog.bark();  // "Buddy barks"

The relationship: Dog is-a Animal, Cat is-a Animal.

Looks good so far, right? Now let's add more behavior...

The Problem with Deep Inheritance

What if we want:

A Robot that can walk() but doesn't need eat() or sleep()
A FlyingDog that can bark() and fly()
A SwimmingRobot that can walk() and swim()

Inheritance solution (becomes messy):

class Animal {
  eat() {}
  sleep() {}
}

class WalkingAnimal extends Animal {
  walk() {}
}

class FlyingAnimal extends Animal {
  fly() {}
}

// Problem: Dog needs both walking AND barking
class Dog extends WalkingAnimal {
  bark() {}
}

// Problem: FlyingDog can't extend both Dog and FlyingAnimal!
// JavaScript doesn't support multiple inheritance
class FlyingDog extends ??? {
  // Stuck!
}

The issue: You're forced into a rigid hierarchy. You can't mix and match behaviors.

Composition: The "Has-A" Relationship

Composition models a "has-a" relationship by combining smaller objects.

// Behavior objects (composable)
const canEat = (state) => ({
  eat: () => console.log(`${state.name} is eating`)
});

const canSleep = (state) => ({
  sleep: () => console.log(`${state.name} is sleeping`)
});

const canBark = (state) => ({
  bark: () => console.log(`${state.name} barks`)
});

const canFly = (state) => ({
  fly: () => console.log(`${state.name} flies`)
});

// Compose behaviors
const createDog = (name) => {
  const state = { name };
  return {
    ...canEat(state),
    ...canSleep(state),
    ...canBark(state)
  };
};

const createFlyingDog = (name) => {
  const state = { name };
  return {
    ...canEat(state),
    ...canSleep(state),
    ...canBark(state),
    ...canFly(state) // Easy to add!
  };
};

const dog = createDog('Buddy');
dog.eat();   // "Buddy is eating"
dog.bark();  // "Buddy barks"

const flyingDog = createFlyingDog('Super Buddy');
flyingDog.bark(); // "Super Buddy barks"
flyingDog.fly();  // "Super Buddy flies"

The relationship: Dog has the ability to eat, sleep, and bark. FlyingDog has those abilities plus flying.

Key Advantage: You can mix and match behaviors freely without rigid hierarchies.

Part 2: Why React Prefers Composition

React's component model is built around composition, not inheritance.

Inheritance in React (The Old Way)

In early React, you might see:

class BaseButton extends React.Component {
  handleClick = () => {
    console.log('Base button clicked');
  }

  render() {
    return <button onClick={this.handleClick}>Base</button>;
  }
}

class PrimaryButton extends BaseButton {
  handleClick = () => {
    console.log('Primary button clicked');
  }

  render() {
    return (
      <button className="primary" onClick={this.handleClick}>
        Primary
      </button>
    );
  }
}

Problems:

Tight coupling — PrimaryButton is tightly bound to BaseButton's implementation
Hard to modify — Changing BaseButton might break PrimaryButton
Limited reuse — Can't easily combine behaviors from multiple base classes
Not composable — Can't use a PrimaryButton inside a BaseButton

Composition in React (The Modern Way)

Instead of extending, compose:

function Button({ className, onClick, children }) {
  return (
    <button className={className} onClick={onClick}>
      {children}
    </button>
  );
}

function PrimaryButton({ onClick, children }) {
  return (
    <Button className="primary" onClick={onClick}>
      {children}
    </Button>
  );
}

function DangerButton({ onClick, children }) {
  return (
    <Button className="danger" onClick={onClick}>
      {children}
    </Button>
  );
}

Advantages:

Flexible — Easy to compose buttons with different styles
Reusable — Button is a simple, focused component
Testable — Each component can be tested independently
Explicit — Clear what props each component accepts

Part 3: Composition Patterns in React

Pattern 1: `children` Prop (Containment)

The most basic composition pattern is using the children prop:

function Card({ children }) {
  return <div className="card">{children}</div>;
}

function App() {
  return (
    <Card>
      <h1>Title</h1>
      <p>Description</p>
    </Card>
  );
}

Key Point: Card doesn't know what its children are — it just renders them. This makes it maximally reusable.

Pattern 2: Named Slots (Multiple Composition Points)

For more complex layouts, use named props instead of just children:

function Dialog({ title, content, actions }) {
  return (
    <div className="dialog">
      <div className="dialog-title">{title}</div>
      <div className="dialog-content">{content}</div>
      <div className="dialog-actions">{actions}</div>
    </div>
  );
}

function App() {
  return (
    <Dialog
      title={<h1>Confirm Delete</h1>}
      content={<p>Are you sure?</p>}
      actions={
        <>
          <button>Cancel</button>
          <button>Delete</button>
        </>
      }
    />
  );
}

Advantages:

Clear structure (title, content, actions)
Each slot can contain any React element
More controlled than a single children prop

Pattern 3: Specialization (Specific Cases of Generic Components)

Create specific versions of generic components:

function Dialog({ title, children }) {
  return (
    <div className="dialog">
      <h1>{title}</h1>
      <div>{children}</div>
    </div>
  );
}

function WelcomeDialog() {
  return (
    <Dialog title="Welcome">
      <p>Thank you for visiting our spacecraft!</p>
    </Dialog>
  );
}

function ConfirmDialog() {
  return (
    <Dialog title="Confirm">
      <p>Are you sure?</p>
      <button>Yes</button>
      <button>No</button>
    </Dialog>
  );
}

Key Point: WelcomeDialog and ConfirmDialog are specialized versions of the generic Dialog component.

Pattern 4: Higher-Order Components (HOCs)

HOCs are functions that take a component and return a new component with additional props or behavior:

// HOC that adds loading state
function withLoading(Component) {
  return function WithLoadingComponent({ isLoading, ...props }) {
    if (isLoading) {
      return <div>Loading...</div>;
    }
    return <Component {...props} />;
  };
}

function UserList({ users }) {
  return (
    <ul>
      {users.map(user => (
        <li key={user.id}>{user.name}</li>
      ))}
    </ul>
  );
}

const UserListWithLoading = withLoading(UserList);

function App() {
  const [users, setUsers] = useState([]);
  const [isLoading, setIsLoading] = useState(true);

  return <UserListWithLoading isLoading={isLoading} users={users} />;
}

Use case: Adding cross-cutting concerns (loading, error handling, authentication) to multiple components.

Pattern 5: Render Props

A component with a render prop takes a function as a child:

function MouseTracker({ render }) {
  const [position, setPosition] = useState({ x: 0, y: 0 });

  useEffect(() => {
    const handleMouseMove = (e) => {
      setPosition({ x: e.clientX, y: e.clientY });
    };

    window.addEventListener('mousemove', handleMouseMove);
    return () => window.removeEventListener('mousemove', handleMouseMove);
  }, []);

  return render(position);
}

function App() {
  return (
    <MouseTracker
      render={({ x, y }) => (
        <div>
          Mouse position: {x}, {y}
        </div>
      )}
    />
  );
}

Use case: Sharing stateful logic between components without HOCs.

Modern alternative: Custom hooks (see below).

Pattern 6: Custom Hooks (Modern Composition)

Custom hooks are the modern way to compose logic:

function useMousePosition() {
  const [position, setPosition] = useState({ x: 0, y: 0 });

  useEffect(() => {
    const handleMouseMove = (e) => {
      setPosition({ x: e.clientX, y: e.clientY });
    };

    window.addEventListener('mousemove', handleMouseMove);
    return () => window.removeEventListener('mousemove', handleMouseMove);
  }, []);

  return position;
}

function App() {
  const { x, y } = useMousePosition();

  return (
    <div>
      Mouse position: {x}, {y}
    </div>
  );
}

Advantages over HOCs and Render Props:

Simpler syntax
No wrapper components
Easy to compose multiple hooks
Clear dependencies

This is why React recommends hooks over HOCs and render props.

Part 4: Composing Hooks

Custom hooks can be composed just like components:

function useAuth() {
  const [user, setUser] = useState(null);

  useEffect(() => {
    // Fetch user from API
    const fetchUser = async () => {
      const userData = await api.getUser();
      setUser(userData);
    };
    fetchUser();
  }, []);

  return { user, isAuthenticated: !!user };
}

function usePermissions(user) {
  const [permissions, setPermissions] = useState([]);

  useEffect(() => {
    if (user) {
      const fetchPermissions = async () => {
        const perms = await api.getPermissions(user.id);
        setPermissions(perms);
      };
      fetchPermissions();
    }
  }, [user]);

  return permissions;
}

function useDashboard() {
  const { user, isAuthenticated } = useAuth(); // Compose hooks!
  const permissions = usePermissions(user);

  return { user, isAuthenticated, permissions };
}

function Dashboard() {
  const { user, isAuthenticated, permissions } = useDashboard();

  if (!isAuthenticated) {
    return <div>Please log in</div>;
  }

  return (
    <div>
      <h1>Welcome, {user.name}!</h1>
      <p>Permissions: {permissions.join(', ')}</p>
    </div>
  );
}

Key Point: Hooks compose horizontally (call multiple hooks), while inheritance composes vertically (extend classes).

Part 5: When Inheritance Might Make Sense (Rarely)

There are a few cases where inheritance is acceptable in JavaScript/React:

1. Extending Built-in Classes

class MyArray extends Array {
  first() {
    return this[0];
  }

  last() {
    return this[this.length - 1];
  }
}

const arr = new MyArray(1, 2, 3);
console.log(arr.first()); // 1
console.log(arr.last());  // 3

Use case: Adding utility methods to built-in types.

2. Third-Party Library Requirements

Some libraries require extending their classes:

import { Component } from 'some-library';

class MyComponent extends Component {
  // Library requires extending Component
}

But: In React, you rarely need to extend React.Component anymore — use functional components instead.

Part 6: Composition Anti-Patterns

Anti-Pattern 1: Prop Drilling

Passing props through many levels:

function App() {
  const user = { name: 'Alice' };
  return <Layout user={user} />;
}

function Layout({ user }) {
  return <Sidebar user={user} />;
}

function Sidebar({ user }) {
  return <UserMenu user={user} />;
}

function UserMenu({ user }) {
  return <div>{user.name}</div>;
}

Problem: Every component needs to pass user down, even if it doesn't use it.

Solution: Use Context API or state management:

const UserContext = React.createContext();

function App() {
  const user = { name: 'Alice' };
  return (
    <UserContext.Provider value={user}>
      <Layout />
    </UserContext.Provider>
  );
}

function UserMenu() {
  const user = useContext(UserContext); // No prop drilling!
  return <div>{user.name}</div>;
}

Anti-Pattern 2: Over-Abstraction

Creating too many generic components:

function GenericContainer({ type, className, style, children, ...props }) {
  const Component = type || 'div';
  return (
    <Component className={className} style={style} {...props}>
      {children}
    </Component>
  );
}

// Usage becomes confusing
<GenericContainer type="section" className="container" style={{ padding: 10 }}>
  Content
</GenericContainer>

Problem: Too generic — harder to understand than just using <section>.

Solution: Create specific, purposeful components:

function Section({ children }) {
  return <section className="container">{children}</section>;
}

Quick Reference Cheat Sheet

Pattern	Use Case	Example
`children` prop	Containment, generic wrappers	`<Card>{content}</Card>`
Named props	Multiple composition points	`<Dialog title={...} content={...} />`
Specialization	Specific versions of generic components	`<PrimaryButton>` from `<Button>`
HOCs	Adding behavior to multiple components	`withLoading(Component)`
Render Props	Sharing stateful logic	`<Tracker render={data => ...} />`
Custom Hooks	Modern logic composition	`useAuth()`, `useMousePosition()`

Key Takeaways

Composition is more flexible than inheritance — you can mix and match behaviors
React prefers composition — use children props, HOCs, render props, and hooks
Inheritance creates tight coupling — hard to change and reuse
Custom hooks are the modern way to compose logic — simpler than HOCs and render props
Use the children prop for containment — makes components maximally reusable
Avoid deep component hierarchies — prefer flat composition
Context API solves prop drilling — no need to pass props through every level

Interview Tip

When asked about composition vs inheritance:

"Composition means building complex components by combining simpler ones, while inheritance means creating hierarchies of classes"
Explain the problem: "Inheritance creates rigid hierarchies that are hard to change. If you need to mix behaviors from multiple base classes, you're stuck."
React's approach: "React uses composition patterns like children props, HOCs, render props, and now custom hooks to share logic"
Best practice: "Use custom hooks to compose logic and the children prop to compose UI"
Example: "Instead of extending a BaseButton class, create a Button component that accepts props, then create PrimaryButton that renders Button with specific props"

Now go forth and compose fearlessly!

Reconciliation & The Virtual DOM: How React Decides What to Update

Tihomir Ivanov — Fri, 16 Jan 2026 23:51:23 +0000

You've probably heard that React is "fast because of the Virtual DOM." But what does that actually mean? And more importantly, why do you need to add a key prop to list items?

The answer lies in React's reconciliation algorithm — the intelligent system that decides which parts of the DOM need updating when your component state changes.

Understanding this isn't just academic — it's critical for writing performant React applications.

The Golden Rule

React uses a Virtual DOM (a lightweight JavaScript representation of the real DOM) and a reconciliation algorithm to efficiently determine the minimum set of changes needed to update the UI. The key prop helps React identify which items have changed, been added, or removed in lists.

In simpler terms: React compares the old and new Virtual DOM trees, calculates the differences (diffing), and applies only those changes to the real DOM.

Let's understand how and why this works.

Part 1: The Problem with Direct DOM Manipulation

Why Updating the DOM is Slow

The DOM (Document Object Model) is a tree structure that browsers use to represent HTML. Updating it directly is expensive because:

Layout recalculation — Browser must recalculate positions and sizes
Repaint — Browser must redraw pixels on screen
Reflow — Changes can trigger cascading updates to other elements

Example of inefficient DOM updates:

// Bad: Direct DOM manipulation
for (let i = 0; i < 1000; i++) {
  const div = document.createElement('div');
  div.textContent = `Item ${i}`;
  document.body.appendChild(div); // Triggers reflow 1000 times!
}

Each appendChild causes a reflow, making this extremely slow.

React's Solution: Batch Updates

React batches changes in memory (Virtual DOM) and applies them all at once:

// Good: React batches updates
function ItemList({ items }) {
  return (
    <div>
      {items.map((item, i) => (
        <div key={i}>Item {i}</div>
      ))}
    </div>
  );
}

Result: React creates a Virtual DOM tree, diffs it with the previous version, and applies all changes in one batch to the real DOM.

Part 2: What is the Virtual DOM?

The Virtual DOM is a lightweight JavaScript object that represents the structure of your UI.

Real DOM vs Virtual DOM

Real DOM:

<div id="root">
  <h1>Hello</h1>
  <p>World</p>
</div>

Virtual DOM (simplified representation):

{
  type: 'div',
  props: { id: 'root' },
  children: [
    {
      type: 'h1',
      props: {},
      children: ['Hello']
    },
    {
      type: 'p',
      props: {},
      children: ['World']
    }
  ]
}

Key Point: The Virtual DOM is just a JavaScript object — it's fast to create, compare, and manipulate.

React Elements

When you write JSX:

const element = <h1 className="greeting">Hello, world!</h1>;

React transforms it into:

const element = React.createElement(
  'h1',
  { className: 'greeting' },
  'Hello, world!'
);

Which creates a Virtual DOM object:

{
  type: 'h1',
  props: {
    className: 'greeting',
    children: 'Hello, world!'
  }
}

Part 3: The Reconciliation Process

When a component's state or props change, React:

Renders the component to create a new Virtual DOM tree
Diffs (compares) the new tree with the previous one
Commits the changes to the real DOM

This three-step process is called reconciliation.

Step 1: Render Phase

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

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

When you click the button:

setCount triggers a re-render
React calls Counter() again
A new Virtual DOM tree is created with the updated count

Step 2: Diffing Algorithm

React compares the new Virtual DOM with the previous one using a smart diffing algorithm.

Assumption 1: Different Types = Completely Rebuild

// Old tree
<div>
  <Counter />
</div>

// New tree
<span>
  <Counter />
</span>

Result: React destroys the <div> and its children completely, then creates a new <span> tree from scratch.

Why? Elements of different types (div vs span) are unlikely to produce similar trees, so React doesn't waste time comparing their children.

Assumption 2: Same Type = Update Props

// Old
<div className="before" />

// New
<div className="after" />

Result: React keeps the same DOM node and only updates the className attribute.

Step 3: Commit Phase

React applies the calculated changes to the real DOM in a single batch:

// React's internal operations (pseudocode)
domNode.className = 'after'; // Update attribute
textNode.textContent = 'New text'; // Update text
parentNode.appendChild(newNode); // Add new node

Key Optimization: React applies only the necessary changes, not a full re-render of the entire DOM.

Part 4: The Importance of `key` in Lists

The key prop is React's way of tracking which items have changed in a list.

Without `key` (or with index as `key`)

function TodoList({ todos }) {
  return (
    <ul>
      {todos.map((todo, index) => (
        <li key={index}>{todo.text}</li>
      ))}
    </ul>
  );
}

Problem: If you add/remove/reorder items, React can't efficiently determine what changed.

Example:

// Before
['Buy milk', 'Walk dog', 'Read book']

// After (removed 'Walk dog')
['Buy milk', 'Read book']

Without unique keys, React sees:

Index 0: 'Buy milk' → 'Buy milk' (no change)
Index 1: 'Walk dog' → 'Read book' (update text)
Index 2: 'Read book' → deleted

Result: React updates index 1 instead of just removing index 1 — inefficient!

With Unique `key`

function TodoList({ todos }) {
  return (
    <ul>
      {todos.map((todo) => (
        <li key={todo.id}>{todo.text}</li>
      ))}
    </ul>
  );
}

Now React sees:

Key 'milk': 'Buy milk' → 'Buy milk' (no change)
Key 'dog': deleted
Key 'book': 'Read book' → 'Read book' (no change)

Result: React efficiently removes the correct item without updating the others.

Why Index as `key` is Dangerous

Using array index as key breaks when items are reordered:

// Before
const items = [
  { id: 'a', name: 'Alice' },
  { id: 'b', name: 'Bob' }
];

// After (reversed)
const items = [
  { id: 'b', name: 'Bob' },
  { id: 'a', name: 'Alice' }
];

With key={index}:

Index 0: Alice → Bob (React updates text)
Index 1: Bob → Alice (React updates text)

With key={item.id}:

Key 'a': Alice stays Alice (React reorders DOM node)
Key 'b': Bob stays Bob (React reorders DOM node)

The second approach is much more efficient and preserves component state.

Example: Input State Lost

function ItemList({ items }) {
  return (
    <div>
      {items.map((item, index) => (
        <div key={index}>
          <input defaultValue={item.name} />
        </div>
      ))}
    </div>
  );
}

Problem: If you add an item to the beginning of the list:

React thinks index 0 is the same element
The input keeps its old value (doesn't reset)
But the defaultValue prop changes (confusing state)

Fix: Use a unique key:

<div key={item.id}>
  <input defaultValue={item.name} />
</div>

Part 5: Optimizing Reconciliation

1. Avoid Changing Component Types

Bad:

function App({ isLoggedIn }) {
  return isLoggedIn ? <UserDashboard /> : <LoginForm />;
}

Why it's bad: Switching between completely different components causes full unmount/remount.

Better (if components share logic):

function App({ isLoggedIn }) {
  return <Dashboard isLoggedIn={isLoggedIn} />;
}

function Dashboard({ isLoggedIn }) {
  return isLoggedIn ? <UserView /> : <LoginView />;
}

But: If they're truly different, the first approach is fine! The point is to avoid unnecessary type changes.

2. Stable Component Structure

Bad:

function App() {
  const [showHeader, setShowHeader] = useState(true);

  return (
    <div>
      {showHeader && <Header />}
      <Content />
      <Footer />
    </div>
  );
}

Issue: When showHeader toggles, React has to diff the entire tree differently.

Better:

function App() {
  const [showHeader, setShowHeader] = useState(true);

  return (
    <div>
      <Header visible={showHeader} />
      <Content />
      <Footer />
    </div>
  );
}

function Header({ visible }) {
  if (!visible) return null;
  return <header>Header</header>;
}

Result: Component tree structure remains stable, making diffing faster.

3. Memoization with `React.memo`

Prevent unnecessary re-renders of child components:

const ExpensiveComponent = React.memo(function ExpensiveComponent({ data }) {
  // Complex rendering logic
  return <div>{data}</div>;
});

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

  return (
    <div>
      <button onClick={() => setCount(count + 1)}>Count: {count}</button>
      <ExpensiveComponent data={data} />
    </div>
  );
}

Result: ExpensiveComponent doesn't re-render when count changes because its props (data) haven't changed.

4. Use Keys Correctly in Dynamic Lists

Rules:

Use unique, stable IDs (key={item.id})
Don't use array index when items can be reordered/added/removed
Don't use random values (key={Math.random()}) — causes remount every render!
Use index only if the list is static and never reordered

Part 6: Reconciliation in React 18+ (Concurrent Rendering)

React 18 introduced concurrent rendering, which changes how reconciliation works.

Time-Slicing

React can now pause reconciliation work to handle urgent updates (like user input):

import { useTransition } from 'react';

function SearchComponent() {
  const [query, setQuery] = useState('');
  const [results, setResults] = useState([]);
  const [isPending, startTransition] = useTransition();

  const handleChange = (e) => {
    setQuery(e.target.value); // High priority (input value)

    startTransition(() => {
      // Low priority (expensive search)
      setResults(performExpensiveSearch(e.target.value));
    });
  };

  return (
    <div>
      <input value={query} onChange={handleChange} />
      {isPending && <div>Loading...</div>}
      <ResultsList results={results} />
    </div>
  );
}

How it works:

React renders the input update immediately
React pauses the expensive search rendering to keep the UI responsive
If another high-priority update comes in (more typing), React abandons the incomplete work and starts fresh

This is only possible because reconciliation is now interruptible.

Automatic Batching

React 18 batches all state updates, even in async code:

function handleClick() {
  setCount(c => c + 1);
  setFlag(f => !f);
  // Before React 18: 2 renders (async callback)
  // React 18+: 1 render (automatic batching)
}

setTimeout(() => {
  setCount(c => c + 1);
  setFlag(f => !f);
  // React 18+: Still 1 render!
}, 1000);

Result: Fewer reconciliation cycles = better performance.

Part 7: Common Reconciliation Pitfalls

Pitfall 1: Creating Components Inside Render

Bad:

function Parent() {
  const Child = () => <div>Child</div>; // New component every render!

  return <Child />;
}

Why it's bad: React sees a new component type every render, causing full unmount/remount.

Fix:

const Child = () => <div>Child</div>; // Defined outside

function Parent() {
  return <Child />;
}

Pitfall 2: Spreading Props Without Memoization

Bad:

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

  const config = { theme: 'dark', lang: 'en' }; // New object every render!

  return <Child config={config} />;
}

const Child = React.memo(({ config }) => {
  // Re-renders every time Parent renders (even with React.memo!)
  return <div>{config.theme}</div>;
});

Fix:

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

  const config = useMemo(() => ({ theme: 'dark', lang: 'en' }), []); // Stable reference

  return <Child config={config} />;
}

Pitfall 3: Conditional Rendering with Different Keys

Bad:

function App({ isEditMode }) {
  return isEditMode ? <Form key="edit" /> : <Form key="view" />;
}

Result: React sees different keys, so it unmounts and remounts the component (losing state).

Fix: Only change key when you want to reset state.

Quick Reference Cheat Sheet

Concept	Explanation	Best Practice
Virtual DOM	Lightweight JS representation of DOM	React handles it automatically
Reconciliation	Process of comparing Virtual DOM trees	Keep component structure stable
Diffing	Algorithm to find differences	Avoid changing component types
`key` prop	Helps React identify list items	Use unique IDs, not array index
`React.memo`	Prevents re-renders if props unchanged	Use for expensive components
`useMemo`	Memoizes values to stabilize references	Use for objects/arrays passed as props

Key Takeaways

React uses the Virtual DOM to batch DOM updates efficiently
Reconciliation compares old and new Virtual DOM trees to determine what changed
The diffing algorithm assumes different element types produce different trees (destroys and rebuilds)
key prop is essential for efficient list reconciliation — use unique IDs, not array index
Using index as key can cause bugs when items are added/removed/reordered
React.memo prevents unnecessary re-renders of child components
React 18+ supports concurrent rendering, making reconciliation interruptible
Keep component structure stable to make diffing more efficient

Interview Tip

When asked about the Virtual DOM and reconciliation:

"The Virtual DOM is a JavaScript representation of the UI that React uses to minimize expensive DOM updates"
Explain the process: "React compares the old and new Virtual DOM (diffing), calculates the minimum changes needed, and applies them to the real DOM in a batch"
Explain key: "The key prop helps React identify which items in a list have changed, been added, or removed, making reconciliation more efficient"
Common mistake: "Using array index as key can cause bugs when items are reordered because React can't track which item is which"
Optimization: "Use React.memo to prevent unnecessary child re-renders and useMemo to stabilize object references passed as props"

Now go forth and never forget to add unique keys to your lists again!

Hoisting & The Temporal Dead Zone: Why `let` and `const` Behave Differently Than `var`

Tihomir Ivanov — Fri, 16 Jan 2026 23:44:29 +0000

You've probably seen this error before:

ReferenceError: Cannot access 'myVariable' before initialization

Or wondered why this works:

console.log(x); // undefined (not an error!)
var x = 5;

But this doesn't:

console.log(y); // ReferenceError!
let y = 5;

The answer lies in hoisting and the Temporal Dead Zone (TDZ) — two of JavaScript's most misunderstood features.

The Golden Rule

All declarations (var, let, const, function, class) are hoisted to the top of their scope during the compilation phase, but only var and function declarations are initialized. let and const remain in the Temporal Dead Zone until their declaration is executed.

In simpler terms: JavaScript knows about your variables before you declare them, but let and const can't be accessed until the exact line where they're declared.

Let's break this down step by step.

Part 1: What is Hoisting?

JavaScript runs in two phases:

Compilation Phase — Code is parsed, variables are registered, scope is determined
Execution Phase — Code runs line by line

Hoisting is what happens during the compilation phase: JavaScript moves declarations to the top of their scope (conceptually — it doesn't literally move code).

Function Hoisting

greet(); // "Hello!" (works!)

function greet() {
  console.log('Hello!');
}

Why this works:

The entire function is hoisted (both declaration and body)
You can call it before the line where it's defined

What JavaScript "sees":

function greet() { // Hoisted to top
  console.log('Hello!');
}

greet(); // Now it makes sense

Function Expressions Are NOT Hoisted

greet(); // TypeError: greet is not a function

var greet = function() {
  console.log('Hello!');
};

Why this fails:

var greet is hoisted (as undefined)
But the function assignment happens later
You're trying to call undefined(), which is an error

What JavaScript "sees":

var greet; // Hoisted, initialized to undefined
greet();   // Calling undefined()

greet = function() {
  console.log('Hello!');
};

Part 2: `var` Hoisting

Variables Declared with `var`

console.log(x); // undefined (not an error!)
var x = 5;
console.log(x); // 5

What JavaScript "sees":

var x; // Hoisted and initialized to undefined
console.log(x); // undefined
x = 5; // Assignment happens here
console.log(x); // 5

Key Points:

var declarations are hoisted to the top of their function scope (or global scope)
They're initialized to undefined
The assignment stays where it is

`var` is Function-Scoped, Not Block-Scoped

function example() {
  if (true) {
    var x = 5;
  }
  console.log(x); // 5 (accessible outside the block!)
}

example();

What JavaScript "sees":

function example() {
  var x; // Hoisted to function scope
  if (true) {
    x = 5;
  }
  console.log(x); // 5
}

Problem: var ignores block scope (if, for, while), which leads to unexpected behavior:

for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 100);
}
// Logs: 3, 3, 3 (all callbacks see the same 'i')

Part 3: `let` and `const` Hoisting

Here's the twist: let and const are hoisted, but they're not initialized.

The Temporal Dead Zone (TDZ)

console.log(x); // ReferenceError: Cannot access 'x' before initialization
let x = 5;

What's happening:

let x is hoisted to the top of the block scope
But it's not initialized (no default value)
The time between the start of the block and the let x declaration is the Temporal Dead Zone
Accessing x in the TDZ throws a ReferenceError

Visualizing the TDZ

{
  // TDZ starts here for 'x'
  console.log(x); // ReferenceError
  // TDZ continues...
  // TDZ ends here
  let x = 5; // 'x' is now initialized
  console.log(x); // 5
}

The TDZ is temporal (time-based), not spatial (location-based):

{
  const func = () => console.log(x); // Defined before 'x'
  let x = 5;
  func(); // Works! (called after 'x' is initialized)
}

`const` Has the Same Behavior

console.log(y); // ReferenceError
const y = 10;

Additional const rule: Must be initialized at declaration:

const z; // SyntaxError: Missing initializer in const declaration

Part 4: `var` vs `let` vs `const`

Comparison Table

Feature	`var`	`let`	`const`
Scope	Function-scoped	Block-scoped	Block-scoped
Hoisting	Yes (initialized to `undefined`)	Yes (but uninitialized)	Yes (but uninitialized)
TDZ	No	Yes	Yes
Re-declaration	Allowed	Not allowed	Not allowed
Reassignment	Allowed	Allowed	Not allowed
Initialization Required	No	No	Yes

Re-declaration Examples

var allows re-declaration:

var x = 1;
var x = 2; // No error
console.log(x); // 2

let doesn't:

let y = 1;
let y = 2; // SyntaxError: Identifier 'y' has already been declared

const doesn't:

const z = 1;
const z = 2; // SyntaxError: Identifier 'z' has already been declared

Reassignment Examples

let x = 1;
x = 2; // Allowed

const y = 1;
y = 2; // TypeError: Assignment to constant variable

Important: const prevents reassignment, not mutation:

const obj = { name: 'Alice' };
obj.name = 'Bob'; // Mutation allowed
obj = {};         // Reassignment forbidden

Part 5: Block Scoping in Practice

`let` in Loops

for (let i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 100);
}
// Logs: 0, 1, 2 (each callback has its own 'i')

Why this works: let creates a new binding for each iteration.

Compare to var:

for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 100);
}
// Logs: 3, 3, 3 (all callbacks share the same 'i')

`let` in `if` Blocks

if (true) {
  let blockScoped = 'Inside';
  console.log(blockScoped); // "Inside"
}

console.log(blockScoped); // ReferenceError: blockScoped is not defined

With var:

if (true) {
  var functionScoped = 'Inside';
  console.log(functionScoped); // "Inside"
}

console.log(functionScoped); // "Inside" (leaked out of block!)

Part 6: Hoisting in React

While modern React doesn't rely heavily on hoisting quirks, understanding it helps avoid bugs.

1. Component Definition Order

Function declarations are hoisted:

function App() {
  return <Header />; // Works
}

function Header() {
  return <h1>Hello</h1>;
}

Function expressions are not:

function App() {
  return <Header />; // ReferenceError (or undefined)
}

const Header = () => {
  return <h1>Hello</h1>;
};

Fix: Define components before using them, or use function declarations.

2. `useState` and Hoisting

function Counter() {
  console.log(count); // ReferenceError! (TDZ)

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

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

Why this fails: const is in the TDZ before its declaration.

This is fine:

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

  console.log(count); // 0

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

3. Closure Issues with `var` in React

Old pattern (before hooks):

class Counter extends React.Component {
  state = { count: 0 };

  componentDidMount() {
    for (var i = 0; i < 3; i++) {
      setTimeout(() => {
        console.log(i); // Logs: 3, 3, 3
      }, i * 1000);
    }
  }

  render() {
    return <div>{this.state.count}</div>;
  }
}

Fix with let:

for (let i = 0; i < 3; i++) {
  setTimeout(() => {
    console.log(i); // Logs: 0, 1, 2
  }, i * 1000);
}

4. Event Handlers and Block Scope

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

  const handleSubmit = (e) => {
    e.preventDefault();

    if (value) {
      const message = `Submitted: ${value}`; // Block-scoped
      alert(message);
    }

    // console.log(message); // ReferenceError (outside block)
  };

  return (
    <form onSubmit={handleSubmit}>
      <input value={value} onChange={(e) => setValue(e.target.value)} />
      <button>Submit</button>
    </form>
  );
}

Key Point: Block-scoped variables (let, const) are contained to their blocks, preventing accidental usage outside.

Part 7: Common Hoisting Gotchas

Gotcha 1: Function Declarations vs Expressions

// Function declaration (hoisted)
function sayHi() {
  console.log('Hi!');
}

// Function expression (not hoisted)
const sayBye = function() {
  console.log('Bye!');
};

// Arrow function (not hoisted)
const sayHello = () => {
  console.log('Hello!');
};

Only function declarations are fully hoisted.

Gotcha 2: Class Hoisting

Classes are hoisted but remain in the TDZ like let and const:

const instance = new MyClass(); // ReferenceError

class MyClass {
  constructor() {
    this.value = 42;
  }
}

Fix: Define classes before using them:

class MyClass {
  constructor() {
    this.value = 42;
  }
}

const instance = new MyClass(); // Works

Gotcha 3: TDZ in Parameter Defaults

function example(a = b, b = 2) {
  console.log(a, b);
}

example(); // ReferenceError: Cannot access 'b' before initialization

Why? When evaluating a = b, b is still in the TDZ (parameters are evaluated left-to-right).

Fix:

function example(b = 2, a = b) {
  console.log(a, b);
}

example(); // 2, 2

Gotcha 4: `typeof` and TDZ

With var:

console.log(typeof x); // "undefined" (no error)
var x = 5;

With let:

console.log(typeof y); // ReferenceError (TDZ!)
let y = 5;

Surprising, right? Even typeof can't save you from the TDZ.

Gotcha 5: Accessing Variables from Outer Scope

let x = 'outer';

{
  console.log(x); // ReferenceError
  let x = 'inner';
}

Why? The inner let x is hoisted to the top of the block, creating a TDZ. JavaScript doesn't look at the outer x.

Fix: Don't shadow variables if you need the outer value:

let x = 'outer';

{
  console.log(x); // "outer"
  let y = 'inner'; // Different name
}

Quick Reference Cheat Sheet

Scenario	`var`	`let`	`const`
Accessed before declaration	`undefined`	ReferenceError (TDZ)	ReferenceError (TDZ)
Scope	Function	Block	Block
Re-declare in same scope	Allowed	Not allowed	Not allowed
Reassign	Allowed	Allowed	Not allowed
Mutate object properties	N/A	N/A	Allowed

Key Takeaways

All declarations are hoisted, but only var and function declarations are initialized
let and const are in the TDZ from the start of the block until their declaration
Accessing a variable in the TDZ throws ReferenceError, not undefined
var is function-scoped; let and const are block-scoped
Use const by default, let when reassignment is needed, avoid var
const prevents reassignment, not mutation of objects/arrays
Classes are hoisted but remain in the TDZ like let and const

Interview Tip

When asked about hoisting, explain it clearly:

"Hoisting is when JavaScript moves declarations to the top of their scope during compilation"
Contrast var and let/const:
- var is initialized to undefined
- let and const remain uninitialized in the TDZ
Explain TDZ: "The Temporal Dead Zone is the period between entering a scope and the variable's declaration where accessing it throws a ReferenceError"
Best practice: "Use const by default, let when reassignment is needed, and avoid var to prevent scoping issues"
React connection: "In React, block scoping with let and const prevents common closure bugs, especially in loops and event handlers"

Now go forth and never be confused by ReferenceError: Cannot access before initialization again!

The `this` Keyword & Binding: JavaScript's Most Confusing Feature (Finally Explained)

Tihomir Ivanov — Fri, 16 Jan 2026 18:19:53 +0000

Ask 10 JavaScript developers what this means, and you'll get 10 different explanations. It's the source of countless bugs, especially for developers coming from other languages where this (or self) is straightforward.

Here's the uncomfortable truth: In JavaScript, this isn't determined by where a function is defined — it's determined by how the function is called.

This single fact explains 90% of the confusion.

The Golden Rule

The value of this is determined by the call site (how the function is invoked), not where the function is written. There are four binding rules, and arrow functions break all of them by lexically binding this to their surrounding scope.

Let's break down each rule systematically.

Part 1: The Four Binding Rules

Rule 1: Default Binding (Function Invocation)

When a function is called standalone (not as a method, not with new, not with call/apply/bind), this defaults to the global object (or undefined in strict mode).

function showThis() {
  console.log(this);
}

showThis(); // In browser: Window, in Node: global, in strict mode: undefined

In strict mode:

'use strict';

function showThis() {
  console.log(this);
}

showThis(); // undefined

Key Point: This is the "fallback" rule when no other rule applies.

Rule 2: Implicit Binding (Method Invocation)

When a function is called as a method of an object, this refers to the object before the dot.

const person = {
  name: 'Alice',
  greet: function() {
    console.log(`Hello, I'm ${this.name}`);
  }
};

person.greet(); // "Hello, I'm Alice"

The rule: Look at the call site. What's to the left of the dot? That's this.

Common Mistake: Losing Implicit Binding

const person = {
  name: 'Alice',
  greet: function() {
    console.log(`Hello, I'm ${this.name}`);
  }
};

const greet = person.greet; // Extract the function
greet(); // "Hello, I'm undefined" (or error in strict mode)

Why? When you call greet() (not person.greet()), there's no object before the dot, so default binding applies, not implicit binding.

This also happens with callbacks:

setTimeout(person.greet, 1000); // Loses 'this'

Fix:

setTimeout(() => person.greet(), 1000); // Call it as a method
// or
setTimeout(person.greet.bind(person), 1000); // Explicitly bind

Rule 3: Explicit Binding (call, apply, bind)

You can explicitly set this using call(), apply(), or bind().

`call()` and `apply()`

function greet(greeting, punctuation) {
  console.log(`${greeting}, I'm ${this.name}${punctuation}`);
}

const person = { name: 'Alice' };

greet.call(person, 'Hello', '!');  // "Hello, I'm Alice!"
greet.apply(person, ['Hi', '.']);  // "Hi, I'm Alice."

Difference:

call(thisArg, arg1, arg2, ...) — arguments passed individually
apply(thisArg, [arg1, arg2, ...]) — arguments passed as array

`bind()`

function greet() {
  console.log(`Hello, I'm ${this.name}`);
}

const person = { name: 'Alice' };

const boundGreet = greet.bind(person); // Returns NEW function with 'this' locked

boundGreet(); // "Hello, I'm Alice"

setTimeout(boundGreet, 1000); // 'this' is still 'person'

Key Point: bind() returns a new function with this permanently set. Useful for callbacks.

Rule 4: `new` Binding (Constructor Invocation)

When you call a function with new, JavaScript:

Creates a new empty object
Sets the object's [[Prototype]] to the function's prototype
Binds this to the new object
Returns the object (unless the function explicitly returns a different object)

function Person(name) {
  this.name = name; // 'this' refers to the new object
  console.log(this);
}

const alice = new Person('Alice');
// Logs: Person { name: 'Alice' }

console.log(alice.name); // "Alice"

What new does behind the scenes:

function Person(name) {
  // const this = Object.create(Person.prototype); (implicit)
  this.name = name;
  // return this; (implicit)
}

What if a constructor returns an object?

function Person(name) {
  this.name = name;
  return { different: true }; // Explicit return
}

const alice = new Person('Alice');
console.log(alice); // { different: true } (not Person instance!)

Rule: If a constructor returns an object, that object is returned instead of this. If it returns a primitive, this is returned.

Part 2: Arrow Functions (Breaking the Rules)

Arrow functions don't have their own this. Instead, they lexically inherit this from their surrounding scope.

const person = {
  name: 'Alice',
  greet: function() {
    const inner = () => {
      console.log(this.name); // 'this' is inherited from greet()
    };
    inner();
  }
};

person.greet(); // "Alice"

Key Point: The arrow function doesn't care how it's called — it captures this from where it's defined.

Arrow Functions vs Regular Functions

const person = {
  name: 'Alice',
  regularGreet: function() {
    console.log(this.name);
  },
  arrowGreet: () => {
    console.log(this.name); // 'this' is NOT 'person'!
  }
};

person.regularGreet(); // "Alice" (implicit binding)
person.arrowGreet();   // undefined (lexical binding to outer scope, probably global)

Why? The arrow function was defined in the global scope (outside any function), so its this is the global object (or undefined in modules).

When Arrow Functions are Perfect

Avoiding this confusion in callbacks:

const person = {
  name: 'Alice',
  hobbies: ['reading', 'coding'],
  showHobbies: function() {
    this.hobbies.forEach(hobby => {
      console.log(`${this.name} likes ${hobby}`); // 'this' is 'person'
    });
  }
};

person.showHobbies();
// "Alice likes reading"
// "Alice likes coding"

With a regular function (old way):

showHobbies: function() {
  const self = this; // Save reference
  this.hobbies.forEach(function(hobby) {
    console.log(`${self.name} likes ${hobby}`); // Use 'self'
  });
}

Arrow functions eliminate the need for self = this hacks.

Part 3: Binding Precedence

When multiple rules apply, what wins?

Precedence (highest to lowest):

Arrow functions (lexical this, ignores all other rules)
new binding (new always wins)
Explicit binding (call, apply, bind)
Implicit binding (method call)
Default binding (standalone function call)

Example: `new` vs `bind`

function Person(name) {
  this.name = name;
}

const boundPerson = Person.bind({ name: 'Bound' });

const instance = new boundPerson('Alice');
console.log(instance.name); // "Alice" (new wins over bind)

Example: Explicit vs Implicit

const person1 = { name: 'Alice' };
const person2 = { name: 'Bob' };

function greet() {
  console.log(this.name);
}

person1.greet = greet;
person1.greet.call(person2); // "Bob" (explicit wins over implicit)

Part 4: `this` in React

Understanding this is critical for React class components (and understanding legacy code).

1. Class Components and Method Binding

The problem:

class Button extends React.Component {
  constructor(props) {
    super(props);
    this.state = { clicked: false };
  }

  handleClick() {
    this.setState({ clicked: true }); // 'this' is undefined!
  }

  render() {
    return <button onClick={this.handleClick}>Click me</button>;
  }
}

Why does this fail?

When React calls the event handler, it's a standalone function call (default binding)
In strict mode (React uses strict mode), this is undefined

Solutions

Solution 1: Arrow function property (modern)

class Button extends React.Component {
  handleClick = () => { // Arrow function
    this.setState({ clicked: true });
  }

  render() {
    return <button onClick={this.handleClick}>Click me</button>;
  }
}

How it works: Arrow functions lexically bind this to the class instance.

Trade-off: Creates a new function per instance (not on prototype), slightly more memory.

Solution 2: Bind in constructor

class Button extends React.Component {
  constructor(props) {
    super(props);
    this.handleClick = this.handleClick.bind(this); // Bind once
  }

  handleClick() {
    this.setState({ clicked: true });
  }

  render() {
    return <button onClick={this.handleClick}>Click me</button>;
  }
}

How it works: bind() creates a new function with this locked to the instance.

Solution 3: Arrow function in JSX (not recommended)

class Button extends React.Component {
  handleClick() {
    this.setState({ clicked: true });
  }

  render() {
    return <button onClick={() => this.handleClick()}>Click me</button>;
  }
}

Why not recommended: Creates a new function on every render, which can cause unnecessary re-renders in child components.

2. Functional Components (No `this` Problems!)

Modern React with hooks eliminates this entirely:

function Button() {
  const [clicked, setClicked] = useState(false);

  const handleClick = () => {
    setClicked(true); // No 'this' needed!
  };

  return <button onClick={handleClick}>Click me</button>;
}

Why this is cleaner:

No this binding issues
No need for constructors
Closures handle state access (see Closures article!)

3. Passing `this` Context to Children

In class components:

class Parent extends React.Component {
  state = { count: 0 };

  increment = () => {
    this.setState({ count: this.state.count + 1 });
  }

  render() {
    return <Child onIncrement={this.increment} />;
  }
}

function Child({ onIncrement }) {
  return <button onClick={onIncrement}>Increment</button>;
}

The increment arrow function ensures this is always the Parent instance, even when called from Child.

4. Event Handlers and Synthetic Events

React's event system preserves this in interesting ways:

class Form extends React.Component {
  state = { value: '' };

  handleChange(event) { // Regular method
    this.setState({ value: event.target.value }); // 'this' works!
  }

  render() {
    return (
      <input
        value={this.state.value}
        onChange={this.handleChange.bind(this)} // Must bind!
      />
    );
  }
}

Why does this work differently than other callbacks?

It doesn't! You still need to bind
The difference is React automatically binds some lifecycle methods (render, constructor)

Part 5: Common `this` Gotchas

Gotcha 1: Nested Function Calls

const obj = {
  value: 42,
  getValue: function() {
    function inner() {
      return this.value; // 'this' is undefined (strict mode)
    }
    return inner();
  }
};

console.log(obj.getValue()); // undefined or error

Fix:

getValue: function() {
  const inner = () => this.value; // Arrow function
  return inner();
}

Gotcha 2: `this` in Object Literals

const obj = {
  value: 42,
  getValue: function() {
    return this.value; // Works
  },
  getValueArrow: () => {
    return this.value; // 'this' is NOT obj!
  }
};

console.log(obj.getValue());      // 42
console.log(obj.getValueArrow()); // undefined

Why? The arrow function is defined in the global scope, so its this is global (or undefined in modules).

Gotcha 3: `this` in Async Functions

const obj = {
  value: 42,
  async getValue() {
    return this.value; // 'this' is preserved
  }
};

obj.getValue().then(console.log); // 42

Good news: async/await doesn't change this behavior — it follows the same binding rules.

Gotcha 4: `this` in Classes with Callbacks

class Counter {
  constructor() {
    this.count = 0;
  }

  increment() {
    this.count++;
  }

  start() {
    setInterval(this.increment, 1000); // 'this' is lost!
  }
}

const counter = new Counter();
counter.start(); // Error: Cannot read 'count' of undefined

Fix:

start() {
  setInterval(() => this.increment(), 1000); // Arrow function
  // or
  setInterval(this.increment.bind(this), 1000); // Bind
}

Quick Reference Cheat Sheet

Binding Type	Call Site Example	`this` Value
Default	`func()`	`undefined` (strict mode) or global
Implicit	`obj.func()`	`obj`
Explicit	`func.call(obj)`	`obj`
`new`	`new Func()`	New instance
Arrow	`() => {}`	Lexical (outer scope)

Key Takeaways

this is determined by how a function is called, not where it's defined
Four binding rules: default, implicit, explicit, new (in order of precedence)
Arrow functions lexically bind this from their surrounding scope
Losing this in callbacks is the most common bug — use arrow functions or bind()
In React class components, bind methods in the constructor or use arrow functions
Functional components with hooks avoid this entirely (one reason they're preferred)
bind() creates a new function; call() and apply() invoke immediately

Interview Tip

When asked about this, explain it systematically:

"The value of this depends on how a function is called, not where it's defined"
Walk through the four rules: default, implicit, explicit, new
Mention arrow functions: "Arrow functions don't have their own this — they inherit it lexically"
React example: "In class components, event handlers need binding because they're called as standalone functions, losing the implicit binding to the class instance"
Functional components: "Modern React avoids this entirely with hooks and closures"

Now go forth and never lose this again!

Prototypes & Prototypal Inheritance: JavaScript's Secret Superpower (and Memory Saver)

Tihomir Ivanov — Fri, 16 Jan 2026 18:17:58 +0000

If you've learned object-oriented programming in languages like Java or C++, JavaScript's inheritance model will feel alien at first. There are no "real" classes in JavaScript (even with the class syntax introduced in ES6). Instead, JavaScript uses prototypes — a powerful and memory-efficient mechanism that's often misunderstood.

Here's the truth: Understanding prototypes is the key to understanding how JavaScript objects really work.

The Golden Rule

In JavaScript, objects inherit from other objects through a prototype chain. Every object has an internal [[Prototype]] reference that points to another object, and property lookups traverse this chain until the property is found or the chain ends.

In simpler terms: Objects link to other objects.

Let's demystify this from the ground up.

Part 1: What is a Prototype?

Every JavaScript object has a hidden internal property called [[Prototype]] (you can access it via __proto__ or Object.getPrototypeOf()).

When you try to access a property on an object, JavaScript:

Checks if the object has that property directly
If not, checks the object's prototype
If not, checks the prototype's prototype
Continues until it finds the property or reaches null

This chain is called the prototype chain.

Basic Example

const animal = {
  eats: true,
  walk() {
    console.log('Animal walks');
  }
};

const rabbit = {
  jumps: true
};

// Set rabbit's prototype to animal
Object.setPrototypeOf(rabbit, animal);

console.log(rabbit.jumps); // true (own property)
console.log(rabbit.eats);  // true (inherited from animal)
rabbit.walk();             // "Animal walks" (inherited method)

What happened?

rabbit doesn't have an eats property, so JavaScript looks at rabbit.__proto__ (which is animal)
It finds eats: true there
Same for the walk() method

Visualizing the Prototype Chain

rabbit = {
  jumps: true,
  __proto__: animal
}

animal = {
  eats: true,
  walk: function,
  __proto__: Object.prototype
}

Object.prototype = {
  toString: function,
  hasOwnProperty: function,
  ...
  __proto__: null
}

When you call rabbit.toString(), JavaScript:

Checks rabbit → not found
Checks animal → not found
Checks Object.prototype → found!

Part 2: Constructor Functions and `prototype`

Before ES6 classes, JavaScript used constructor functions to create objects with shared methods.

The Old Way: Constructor Functions

function Animal(name) {
  this.name = name; // Instance property
}

// Methods go on the prototype (shared by all instances)
Animal.prototype.walk = function() {
  console.log(`${this.name} walks`);
};

const dog = new Animal('Dog');
const cat = new Animal('Cat');

dog.walk(); // "Dog walks"
cat.walk(); // "Cat walks"

console.log(dog.walk === cat.walk); // true (same function!)

Key Points:

Animal.prototype is an object that becomes the [[Prototype]] of all instances created with new Animal()
Methods on prototype are shared across all instances (memory efficient!)
Properties set in the constructor (this.name) are unique to each instance

Why Put Methods on the Prototype?

Wrong way (memory inefficient):

function Animal(name) {
  this.name = name;
  this.walk = function() { // New function created for EVERY instance
    console.log(`${this.name} walks`);
  };
}

const dog = new Animal('Dog');
const cat = new Animal('Cat');

console.log(dog.walk === cat.walk); // false (different functions!)

Right way (memory efficient):

function Animal(name) {
  this.name = name;
}

Animal.prototype.walk = function() { // One function shared by all
  console.log(`${this.name} walks`);
};

const dog = new Animal('Dog');
const cat = new Animal('Cat');

console.log(dog.walk === cat.walk); // true (same function!)

Result: With 10,000 Animal instances, the prototype approach uses one walk function in memory, while the constructor approach creates 10,000 separate functions.

Part 3: `proto` vs `prototype`

This is where confusion arises:

prototype is a property on constructor functions (e.g., Animal.prototype)
__proto__ (or [[Prototype]]) is an internal property on objects that points to their prototype

function Animal(name) {
  this.name = name;
}

const dog = new Animal('Dog');

console.log(Animal.prototype);        // Object with constructor and methods
console.log(dog.__proto__);           // Same as Animal.prototype
console.log(dog.__proto__ === Animal.prototype); // true

Mental Model:

Animal (function)
  ├─ prototype (object)
       ├─ constructor: Animal
       └─ walk: function

dog (instance)
  ├─ name: 'Dog'
  └─ __proto__ → Animal.prototype

Part 4: ES6 Classes (Syntactic Sugar)

ES6 introduced the class syntax, but under the hood, it's still prototypes:

class Animal {
  constructor(name) {
    this.name = name; // Instance property
  }

  walk() { // Method on prototype
    console.log(`${this.name} walks`);
  }
}

const dog = new Animal('Dog');
dog.walk(); // "Dog walks"

console.log(typeof Animal); // "function" (it's still a constructor!)
console.log(dog.__proto__ === Animal.prototype); // true

What class does:

constructor() → same as the old constructor function
Methods inside the class → added to Animal.prototype
new Animal() → creates an instance with __proto__ pointing to Animal.prototype

Inheritance with Classes

class Animal {
  constructor(name) {
    this.name = name;
  }

  walk() {
    console.log(`${this.name} walks`);
  }
}

class Dog extends Animal {
  constructor(name, breed) {
    super(name); // Call parent constructor
    this.breed = breed;
  }

  bark() {
    console.log(`${this.name} barks`);
  }
}

const dog = new Dog('Buddy', 'Golden Retriever');

dog.walk(); // "Buddy walks" (inherited)
dog.bark(); // "Buddy barks" (own method)

console.log(dog.__proto__);                  // Dog.prototype
console.log(dog.__proto__.__proto__);        // Animal.prototype
console.log(dog.__proto__.__proto__.__proto__); // Object.prototype

Prototype chain:

dog
  └─ __proto__: Dog.prototype
       └─ __proto__: Animal.prototype
            └─ __proto__: Object.prototype
                 └─ __proto__: null

Part 5: Practical Prototype Patterns

Pattern 1: Checking Property Origin

const animal = { eats: true };
const rabbit = { jumps: true, __proto__: animal };

console.log('jumps' in rabbit); // true (own property)
console.log('eats' in rabbit);  // true (inherited)

console.log(rabbit.hasOwnProperty('jumps')); // true
console.log(rabbit.hasOwnProperty('eats'));  // false (not own)

Pattern 2: Iterating Over Own Properties

const animal = { eats: true };
const rabbit = { jumps: true, __proto__: animal };

for (let key in rabbit) {
  console.log(key); // "jumps", "eats" (includes inherited!)
}

// Only own properties:
for (let key in rabbit) {
  if (rabbit.hasOwnProperty(key)) {
    console.log(key); // "jumps"
  }
}

// Modern way:
console.log(Object.keys(rabbit)); // ["jumps"] (only own properties)

Pattern 3: Creating Objects Without Prototype

// Normal object has Object.prototype as prototype
const obj1 = {};
console.log(obj1.toString); // function (inherited from Object.prototype)

// Object without prototype (useful for dictionaries)
const obj2 = Object.create(null);
console.log(obj2.toString); // undefined (no prototype!)

Use case: Pure dictionaries where you don't want inherited properties:

const settings = Object.create(null);
settings.toString = 'Custom setting'; // No conflict with Object.prototype.toString

Part 6: Prototypes in React

While modern React doesn't heavily rely on prototypes (thanks to functional components and hooks), understanding prototypes helps when:

1. Working with Class Components (Legacy Code)

class Counter extends React.Component {
  constructor(props) {
    super(props);
    this.state = { count: 0 };
  }

  increment = () => { // Arrow function (own property, not on prototype)
    this.setState({ count: this.state.count + 1 });
  }

  render() { // Method (on prototype)
    return (
      <div>
        <p>Count: {this.state.count}</p>
        <button onClick={this.increment}>Increment</button>
      </div>
    );
  }
}

What's happening:

Counter.prototype has render (shared across all instances)
increment is an instance property (arrow function, not inherited)
React.Component.prototype has setState, forceUpdate, etc.

Prototype chain:

counterInstance
  └─ __proto__: Counter.prototype
       └─ __proto__: React.Component.prototype
            └─ __proto__: Object.prototype

2. Understanding Method Binding in Class Components

The problem:

class Button extends React.Component {
  handleClick() { // Regular method (on prototype)
    console.log(this); // undefined in strict mode!
  }

  render() {
    return <button onClick={this.handleClick}>Click</button>;
  }
}

Why this is undefined:

this.handleClick passes the function without binding
When React calls it, this is lost

Solutions:

// Solution 1: Arrow function (creates new instance property)
class Button extends React.Component {
  handleClick = () => {
    console.log(this); // Always correct
  }

  render() {
    return <button onClick={this.handleClick}>Click</button>;
  }
}

// Solution 2: Bind in constructor
class Button extends React.Component {
  constructor(props) {
    super(props);
    this.handleClick = this.handleClick.bind(this); // Create bound version
  }

  handleClick() {
    console.log(this);
  }

  render() {
    return <button onClick={this.handleClick}>Click</button>;
  }
}

// Solution 3: Arrow function in JSX (creates new function every render!)
class Button extends React.Component {
  handleClick() {
    console.log(this);
  }

  render() {
    return <button onClick={() => this.handleClick()}>Click</button>;
  }
}

3. Extending Component Libraries

Some libraries use prototypes for extensibility:

import { Component } from 'react';

// Adding a method to all React components (not recommended!)
Component.prototype.log = function(message) {
  console.log(`[${this.constructor.name}] ${message}`);
};

class MyComponent extends Component {
  componentDidMount() {
    this.log('Mounted'); // Uses inherited method
  }

  render() {
    return <div>Hello</div>;
  }
}

Warning: Modifying built-in prototypes is generally not recommended in production code.

4. Functional Components Don't Use Prototypes

Modern React with hooks avoids prototype chains entirely:

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

  const increment = () => { // Regular function, no prototype involved
    setCount(count + 1);
  };

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={increment}>Increment</button>
    </div>
  );
}

Why this works without prototypes:

Functions are first-class citizens in JavaScript
No need for this binding
Closures handle state access (see Closures article!)

Part 7: Common Prototype Gotchas

Gotcha 1: Mutating Prototype Properties

function Animal() {}
Animal.prototype.friends = []; // Shared array!

const dog = new Animal();
const cat = new Animal();

dog.friends.push('Buddy');

console.log(cat.friends); // ["Buddy"] - Oops!

Why? The friends array is shared on the prototype. Mutating it affects all instances.

Fix: Initialize arrays/objects in the constructor:

function Animal() {
  this.friends = []; // Each instance gets its own array
}

Gotcha 2: Shadowing Prototype Properties

const animal = {
  eats: true
};

const rabbit = {
  __proto__: animal
};

console.log(rabbit.eats); // true (inherited)

rabbit.eats = false; // Creates OWN property, doesn't modify prototype

console.log(rabbit.eats);      // false (own property)
console.log(animal.eats);      // true (prototype unchanged)
console.log(rabbit.__proto__.eats); // true

Key Point: Assigning to a property creates an own property, it doesn't modify the prototype.

Gotcha 3: Losing `this` in Callbacks

class Logger {
  constructor(prefix) {
    this.prefix = prefix;
  }

  log(message) { // Method on prototype
    console.log(`${this.prefix}: ${message}`);
  }
}

const logger = new Logger('INFO');
logger.log('Test'); // "INFO: Test"

setTimeout(logger.log, 1000, 'Test'); // Error: Cannot read 'prefix' of undefined

Why? When you pass logger.log to setTimeout, it loses the this binding.

Fix:

setTimeout(() => logger.log('Test'), 1000); // Arrow function preserves context
// or
setTimeout(logger.log.bind(logger), 1000, 'Test'); // Bind explicitly

Quick Reference Cheat Sheet

Concept	Explanation	Example
`[[Prototype]]`	Internal property linking objects	`obj.__proto__`
`prototype`	Property on constructor functions	`Animal.prototype`
Prototype Chain	Series of `__proto__` links	`obj → proto1 → proto2 → null`
`hasOwnProperty()`	Check if property is own (not inherited)	`obj.hasOwnProperty('key')`
`Object.create()`	Create object with specific prototype	`Object.create(proto)`
`Object.getPrototypeOf()`	Get object's prototype (modern)	`Object.getPrototypeOf(obj)`
`instanceof`	Check if object is in constructor's chain	`dog instanceof Animal`

Key Takeaways

JavaScript uses prototypal inheritance, not classical inheritance
Methods on the prototype are shared across all instances (memory efficient)
Properties on the instance are unique to each object
__proto__ points to the object's prototype; prototype is on constructor functions
ES6 classes are syntactic sugar over constructor functions and prototypes
React class components use prototypes, but functional components don't
Never mutate shared arrays/objects on prototypes — initialize them in constructors
Arrow functions in class components create instance properties, not prototype methods

Interview Tip

When asked about prototypes, explain it in layers:

"Every object has an internal prototype link (__proto__)"
"When you access a property, JavaScript searches the prototype chain"
"Constructor functions have a prototype property that becomes the __proto__ of instances"
Give an example: "Methods on the prototype are shared for memory efficiency"
React connection: "Class components inherit from React.Component.prototype, which provides setState and other methods"

Now go forth and never confuse __proto__ and prototype again!

Closures & Lexical Scope: How JavaScript Functions "Remember" Where They Were Born

Tihomir Ivanov — Fri, 16 Jan 2026 18:15:59 +0000

Ask a junior developer to explain closures, and you'll likely get a nervous laugh. Ask a senior developer, and you might get a technically correct but confusing answer. Yet closures are everywhere in JavaScript — they're the invisible force behind React Hooks, event handlers, and countless design patterns.

The truth? Closures are simpler than you think, once you understand lexical scope.

The Golden Rule

A closure is a function that "remembers" variables from its outer (lexical) scope, even after that outer function has finished executing.

In other words: Functions carry their birthplace with them.

Let's build this understanding from the ground up.

Part 1: Understanding Lexical Scope First

Before closures, you need to understand lexical scope (also called static scope).

What is Lexical Scope?

Lexical scope means that variable accessibility is determined by where functions are defined in the code, not where they are called.

const global = 'I am global';

function outer() {
  const outerVar = 'I am outer';

  function inner() {
    const innerVar = 'I am inner';
    console.log(global);    // Accessible
    console.log(outerVar);  // Accessible
    console.log(innerVar);  // Accessible
  }

  inner();
}

outer();

Output:

I am global
I am outer
I am inner

Key Point: The inner() function can access:

Its own variables (innerVar)
Variables from outer() (outerVar)
Global variables (global)

This chain is called the scope chain. JavaScript searches for variables starting from the innermost scope and working outward.

Lexical Scope is Determined at "Write Time," Not "Run Time"

const name = 'Outer';

function showName() {
  console.log(name); // Looks for 'name' where showName was DEFINED
}

function wrapper() {
  const name = 'Inner';
  showName(); // Called here, but uses outer 'name'
}

wrapper();

Output:

Outer

Why? showName() was defined in the global scope, so it looks for name in the global scope — even though it's called from inside wrapper().

Part 2: What is a Closure?

A closure happens when a function retains access to its lexical scope even after the outer function has returned.

Classic Closure Example

function createCounter() {
  let count = 0; // Private variable

  return function increment() {
    count++;
    console.log(count);
  };
}

const counter = createCounter();

counter(); // 1
counter(); // 2
counter(); // 3

What just happened?

createCounter() ran and finished executing
Normally, count would be garbage-collected
But increment() still has a reference to count — this is a closure
Every time we call counter(), it accesses the same count variable

Key Insight: The increment function "closed over" the variable count.

Why This Matters: Data Privacy

In JavaScript, there are no true private variables (until ES2022's # syntax). Closures are the classic workaround:

function createBankAccount(initialBalance) {
  let balance = initialBalance; // Private!

  return {
    deposit(amount) {
      balance += amount;
      return balance;
    },
    withdraw(amount) {
      if (amount > balance) {
        throw new Error('Insufficient funds');
      }
      balance -= amount;
      return balance;
    },
    getBalance() {
      return balance;
    }
  };
}

const account = createBankAccount(100);

console.log(account.getBalance()); // 100
account.deposit(50);               // 150
account.withdraw(30);              // 120

// No way to directly access 'balance' from outside!
console.log(account.balance); // undefined

Result: The balance variable is encapsulated — only the returned methods can access it.

Part 3: Common Closure Patterns

Pattern 1: Function Factory

function createMultiplier(multiplier) {
  return function (number) {
    return number * multiplier;
  };
}

const double = createMultiplier(2);
const triple = createMultiplier(3);

console.log(double(5));  // 10
console.log(triple(5));  // 15

Each function remembers its own multiplier value.

Pattern 2: Event Handlers with Closures

function setupButtons() {
  for (let i = 1; i <= 3; i++) {
    const button = document.createElement('button');
    button.textContent = `Button ${i}`;

    button.addEventListener('click', function() {
      console.log(`Button ${i} clicked`); // Closure over 'i'
    });

    document.body.appendChild(button);
  }
}

setupButtons();

Result: Clicking each button logs the correct number (1, 2, or 3).

Why it works: let creates a new binding for each iteration, and the click handler closes over that specific i.

⚠️ Common Mistake: Using `var` Instead of `let`

function setupButtonsWrong() {
  for (var i = 1; i <= 3; i++) { // Using 'var'
    const button = document.createElement('button');
    button.textContent = `Button ${i}`;

    button.addEventListener('click', function() {
      console.log(`Button ${i} clicked`);
    });

    document.body.appendChild(button);
  }
}

setupButtonsWrong();

Result: All buttons log Button 4 clicked (the final value of i after the loop).

Why? var is function-scoped, not block-scoped. All click handlers share the same i variable.

Fix: Use let (block-scoped) or create a closure manually:

for (var i = 1; i <= 3; i++) {
  (function(j) { // IIFE creates new scope
    button.addEventListener('click', function() {
      console.log(`Button ${j} clicked`);
    });
  })(i);
}

Part 4: Closures in React

React Hooks are built on closures. Understanding this is critical for avoiding bugs.

1. `useState` and Closures

import { useState } from 'react';

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

  const handleClick = () => {
    setCount(count + 1); // 'count' is captured by closure
  };

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={handleClick}>Increment</button>
    </div>
  );
}

How it works:

Each render creates a new handleClick function
That function closes over the current value of count
When you click the button, it uses the count from that render

2. The Stale Closure Problem

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

  useEffect(() => {
    const id = setInterval(() => {
      console.log(`Count: ${count}`); // Always logs 0!
      setCount(count + 1);             // Always sets to 1!
    }, 1000);

    return () => clearInterval(id);
  }, []); // Empty deps = only runs once

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

Problem: The setInterval callback closes over the initial count value (0) because the effect only runs once.

Solution 1: Use functional updates

setCount(prevCount => prevCount + 1); // Uses current state

Solution 2: Add count to dependencies

useEffect(() => {
  const id = setInterval(() => {
    console.log(`Count: ${count}`); // Updates every time count changes
  }, 1000);

  return () => clearInterval(id);
}, [count]); // Re-run effect when count changes

Trade-off: Solution 2 restarts the interval every second (might not be desired). Solution 1 is usually better for this case.

3. Event Handlers and Closures

function UserList({ users }) {
  const handleClick = (userId) => {
    console.log(`Clicked user: ${userId}`);
  };

  return (
    <ul>
      {users.map(user => (
        <li key={user.id} onClick={() => handleClick(user.id)}>
          {user.name}
        </li>
      ))}
    </ul>
  );
}

What's happening:

Each onClick handler is a new function (created on every render)
Each closes over the specific user.id from that iteration

Performance note: If UserList re-renders frequently, you might memoize the handler:

const handleClick = useCallback((userId) => {
  console.log(`Clicked user: ${userId}`);
}, []); // Doesn't depend on any props/state

4. Custom Hooks and Closures

function useInterval(callback, delay) {
  const savedCallback = useRef();

  // Remember the latest callback
  useEffect(() => {
    savedCallback.current = callback;
  }, [callback]);

  // Set up the interval
  useEffect(() => {
    function tick() {
      savedCallback.current(); // Always calls the latest callback
    }

    if (delay !== null) {
      const id = setInterval(tick, delay);
      return () => clearInterval(id);
    }
  }, [delay]);
}

Why this pattern?

The setInterval callback closes over savedCallback.current
We update savedCallback.current every render
This ensures the interval always calls the latest callback, avoiding stale closures

Usage:

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

  useInterval(() => {
    setCount(count + 1); // 'count' is always current!
  }, 1000);

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

5. Closures in Context API

const ThemeContext = React.createContext();

function ThemeProvider({ children }) {
  const [theme, setTheme] = useState('light');

  const toggleTheme = () => { // Closure over 'theme' and 'setTheme'
    setTheme(prevTheme => prevTheme === 'light' ? 'dark' : 'light');
  };

  const value = { theme, toggleTheme }; // New object every render

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

Optimization: Create the value object with useMemo to prevent unnecessary re-renders:

const value = useMemo(() => ({ theme, toggleTheme }), [theme]);

Part 5: Advanced Closure Concepts

Memory Leaks with Closures

Closures can prevent garbage collection if you're not careful:

function createHugeArray() {
  const hugeArray = new Array(1000000).fill('data');

  return function() {
    console.log(hugeArray[0]); // Closure keeps entire array in memory!
  };
}

const fn = createHugeArray(); // 'hugeArray' can't be garbage-collected

Fix: Only close over what you need:

function createHugeArray() {
  const hugeArray = new Array(1000000).fill('data');
  const firstElement = hugeArray[0]; // Extract what you need

  return function() {
    console.log(firstElement); // Only keeps 'firstElement', not entire array
  };
}

Closures and `this` Keyword

const obj = {
  name: 'Object',
  regularFunction: function() {
    setTimeout(function() {
      console.log(this.name); // 'this' is undefined (or global object)
    }, 1000);
  },
  arrowFunction: function() {
    setTimeout(() => {
      console.log(this.name); // 'this' is lexically bound to obj
    }, 1000);
  }
};

obj.arrowFunction(); // Logs 'Object'

Why? Arrow functions don't have their own this — they close over the this value from their outer scope.

Quick Reference Cheat Sheet

Concept	Explanation	Example Use Case
Lexical Scope	Variable access determined by where functions are defined	Understanding scope chains
Closure	Function remembers its outer scope after outer function returns	Data privacy, callbacks
Stale Closure	Closure captures old variable values	Common bug in `useEffect`
Functional Updates	`setState(prev => ...)` to avoid stale closures	Counters, intervals
`useCallback`	Memoizes functions to prevent new closures every render	Performance optimization
`useRef`	Mutable container that doesn't cause re-renders	Storing latest callback

Key Takeaways

Lexical scope is determined at write time, not run time
Closures allow functions to access outer variables even after the outer function has returned
Use let in loops, not var, to create proper closures
React Hooks rely on closures — useState, useEffect, and custom hooks all use them
Stale closures are a common bug — fix with functional updates or proper dependencies
Closures can cause memory leaks if you close over large data structures unnecessarily
Arrow functions lexically bind this by closing over the outer this value

Interview Tip

When asked about closures, explain them in three steps:

"A closure is when a function remembers variables from its outer scope"
Give a simple example (like a counter)
Explain a practical use case (React Hooks, data privacy, or event handlers)

Then mention: "In React, understanding closures is critical because Hooks like useState and useEffect create closures over props and state. If you don't handle dependencies correctly, you can get stale closures."

Now go forth and never fear the closure question again!

The JavaScript Event Loop & Concurrency Model: Why setTimeout(fn, 0) Doesn't Run Immediately

Tihomir Ivanov — Wed, 14 Jan 2026 07:22:49 +0000

The JavaScript Event Loop & Concurrency Model: Why setTimeout(fn, 0) Doesn't Run Immediately

One of the most mind-bending aspects of JavaScript for new and experienced developers alike is understanding why asynchronous code behaves the way it does. You've probably heard that "JavaScript is single-threaded," but then how can it handle multiple operations simultaneously without blocking?

The answer lies in JavaScript's Event Loop and Concurrency Model — the engine that powers non-blocking I/O and makes JavaScript feel multithreaded even though it isn't.

The Golden Rule

JavaScript has a single call stack (single-threaded execution), but it achieves concurrency through the Event Loop, which coordinates between the Call Stack, Web APIs, and Task Queues.

Let's break this down step by step, from the fundamentals to how it impacts React applications.

Part 1: The Core Components

1. The Call Stack (Execution Context Stack)

The Call Stack is where JavaScript keeps track of function execution. It's a LIFO (Last In, First Out) data structure.

function first() {
  console.log('First');
  second();
}

function second() {
  console.log('Second');
}

first();

Execution flow:

first() gets pushed onto the stack
console.log('First') executes
second() gets pushed onto the stack
console.log('Second') executes
second() pops off the stack
first() pops off the stack

Key Point: JavaScript can only execute one function at a time. This is what "single-threaded" means.

2. Web APIs (Browser-provided functionality)

When you call functions like setTimeout, fetch, or addEventListener, these aren't actually part of the JavaScript engine — they're Web APIs provided by the browser (or Node.js runtime).

console.log('Start');

setTimeout(() => {
  console.log('Timeout');
}, 0);

console.log('End');

Output:

Start
End
Timeout

Why? Even though the timeout is 0ms, the callback gets handed off to the Web API, allowing the Call Stack to continue executing synchronous code.

3. The Task Queue (Callback Queue / Macrotask Queue)

When Web APIs complete their work (like a timer finishing), they push callbacks into the Task Queue. This queue holds tasks waiting to be executed.

Examples of Macrotasks:

setTimeout / setInterval callbacks
I/O operations
UI rendering events
requestAnimationFrame (in browsers)

4. The Microtask Queue (Job Queue)

There's a second, higher-priority queue called the Microtask Queue. This is where Promise callbacks live.

Examples of Microtasks:

.then() / .catch() / .finally() callbacks
async/await continuations
queueMicrotask()
MutationObserver callbacks

Critical Rule: The Event Loop always empties the entire Microtask Queue before processing the next Macrotask.

5. The Event Loop

The Event Loop is the orchestrator. Here's its simplified algorithm:

while (true) {
  // 1. Execute all synchronous code in the Call Stack

  // 2. When the Call Stack is empty:
  //    a. Process ALL microtasks (Promise callbacks)
  //    b. Render UI updates (if in a browser)
  //    c. Process ONE macrotask (setTimeout, I/O)

  // 3. Repeat
}

Part 2: The Classic setTimeout(fn, 0) Mystery

Let's examine why setTimeout(fn, 0) doesn't execute immediately:

console.log('A');

setTimeout(() => console.log('B'), 0);

Promise.resolve().then(() => console.log('C'));

console.log('D');

Output:

A
D
C
B

Step-by-step breakdown:

console.log('A') executes immediately → Output: A
setTimeout callback goes to the Web API, then to the Macrotask Queue
Promise.resolve().then() callback goes to the Microtask Queue
console.log('D') executes immediately → Output: D
Call Stack is now empty, so the Event Loop checks the Microtask Queue first → Output: C
Finally, the Event Loop processes the Macrotask → Output: B

Takeaway: Microtasks (Promises) always run before the next Macrotask (setTimeout), even if the setTimeout delay is 0.

Part 3: Practical Examples with Promises

Example 1: Nested Promises vs setTimeout

setTimeout(() => console.log('Timeout 1'), 0);

Promise.resolve()
  .then(() => console.log('Promise 1'))
  .then(() => console.log('Promise 2'))
  .then(() => console.log('Promise 3'));

setTimeout(() => console.log('Timeout 2'), 0);

Output:

Promise 1
Promise 2
Promise 3
Timeout 1
Timeout 2

Why? All chained .then() callbacks are microtasks and run before moving to the next macrotask.

Example 2: Mixing Async/Await

console.log('Start');

setTimeout(() => console.log('Timeout'), 0);

async function asyncFunc() {
  console.log('Async Start');
  await Promise.resolve();
  console.log('After Await');
}

asyncFunc();

console.log('End');

Output:

Start
Async Start
End
After Await
Timeout

Explanation:

await Promise.resolve() causes the rest of the function to be queued as a microtask
Synchronous code finishes first (End)
Then microtasks run (After Await)
Finally, the macrotask runs (Timeout)

Part 4: How This Impacts React

1. State Updates and Batching

In React 18+, state updates are automatically batched in event handlers:

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

  const handleClick = () => {
    setCount(count + 1); // Queued
    setCount(count + 1); // Queued
    setCount(count + 1); // Queued
    // React batches these into a single re-render
  };

  return <button onClick={handleClick}>Count: {count}</button>;
}

Result: Only one re-render happens, not three. This batching relies on React's event loop integration.

2. useEffect Timing

useEffect(() => {
  console.log('Effect runs');

  setTimeout(() => {
    console.log('Timeout in effect');
  }, 0);

  Promise.resolve().then(() => {
    console.log('Promise in effect');
  });
}, []);

console.log('Render complete');

Output:

Render complete
Effect runs
Promise in effect
Timeout in effect

Why?

useEffect callbacks run after the render is committed to the DOM (as a microtask)
The Promise inside the effect is a nested microtask (runs immediately after the effect)
The setTimeout is a macrotask (runs later)

3. React's Concurrent Rendering (React 18+)

React 18 introduced time-slicing, which breaks rendering work into chunks. This leverages the Event Loop to:

Pause rendering to handle urgent updates (user input)
Resume rendering during idle time
Prioritize interactive updates over background work

import { useTransition } from 'react';

function SearchComponent() {
  const [isPending, startTransition] = useTransition();
  const [query, setQuery] = useState('');

  const handleChange = (e) => {
    // High priority: Update input immediately
    setQuery(e.target.value);

    // Low priority: Update search results
    startTransition(() => {
      setSearchResults(performExpensiveSearch(e.target.value));
    });
  };

  return <input value={query} onChange={handleChange} />;
}

How it works: startTransition marks updates as "interruptible," allowing React to yield control back to the browser's Event Loop between chunks of work.

4. Common Pitfall: Stale Closures in Async Code

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

  useEffect(() => {
    const id = setInterval(() => {
      console.log(count); // Always logs 0!
      setCount(count + 1); // Wrong: captures stale 'count'
    }, 1000);

    return () => clearInterval(id);
  }, []); // Empty deps = closure captures initial 'count' value

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

Fix using functional updates:

setCount(prevCount => prevCount + 1); // Correct: uses current state

Why this happens: The setInterval callback is a macrotask that closes over the count value from when the effect ran. Since the effect only runs once ([] dependencies), it never gets the updated count.

Part 5: Visualizing the Event Loop

Here's a mental model:

┌─────────────────────────────────────────┐
│        JavaScript Call Stack            │  ← Executes synchronous code
└─────────────────────────────────────────┘
              ↓ (when empty)
┌─────────────────────────────────────────┐
│       Microtask Queue (Promises)        │  ← Process ALL microtasks
│  [Promise.then, async/await, ...]      │
└─────────────────────────────────────────┘
              ↓ (when empty)
┌─────────────────────────────────────────┐
│      Macrotask Queue (setTimeout)       │  ← Process ONE macrotask
│  [setTimeout, setInterval, I/O, ...]   │
└─────────────────────────────────────────┘
              ↓ (repeat)

Quick Reference Cheat Sheet

Feature	Queue Type	Priority	Examples
Synchronous Code	Call Stack	Highest	Regular function calls
Promises	Microtask Queue	High	`.then()`, `async/await`
setTimeout/setInterval	Macrotask Queue	Low	Timers, I/O
React State Updates	Batched (React 18+)	Varies	`setState` in event handlers

Key Takeaways

JavaScript is single-threaded but achieves concurrency through the Event Loop
Microtasks (Promises) always run before the next Macrotask (setTimeout)
setTimeout(fn, 0) doesn't run immediately — it waits for the Call Stack and Microtask Queue to clear
React state updates are batched to optimize re-renders
useEffect runs after rendering as a microtask, but callbacks inside can schedule macrotasks
Always use functional updates (setState(prev => prev + 1)) in async callbacks to avoid stale closures

Interview Tip

When asked about the Event Loop, explain it in layers:

"JavaScript has a single Call Stack" (synchronous execution)
"Web APIs handle async operations" (setTimeout, fetch)
"Callbacks go into queues" (Microtask vs Macrotask)
"The Event Loop coordinates execution" (empties microtasks first, then one macrotask)
"In React, this affects state batching and useEffect timing"

Now go forth and never wonder why your setTimeout runs "late" again!

Is JS pass-by-value or pass-by-reference? Let's clear the confusion once and for all, from memory basics to modern Immutability.

Tihomir Ivanov — Tue, 13 Jan 2026 02:59:45 +0000

JavaScript: Is it Pass-by-Value or Pass-by-Reference?

One of the most common questions in JavaScript interviews is: "How are variables passed in JS?". The answer often leads to confusion. Let's break it down simply and accurately.

The Golden Rule: Everything is Pass-by-Value

In JavaScript, everything is passed by value. However, the "value" depends on what type of data you are dealing with.

1. Primitives (Number, String, Boolean, Symbol, BigInt, null, undefined)

When you pass a primitive, JS makes a complete copy of the data. The original and the copy are totally independent.

let a = 10;
function change(x) {
  x = 20;
}
change(a);
console.log(a); // Result: 10 (Original stays the same)

Why? Primitives are stored directly in the variable. When you pass them, JavaScript copies the actual value.

let name = "Alice";
let copyName = name;
copyName = "Bob";

console.log(name);     // "Alice" - unchanged
console.log(copyName); // "Bob"

2. Objects and Arrays (The "Copy of a Reference")

Objects are also passed by value, but the value being copied is the reference (address) to where the object lives in memory. This is often called "Pass-by-sharing".

You aren't copying the whole object.
You are copying the "remote control" to that object.

let user = { name: "Neo" };

function rename(obj) {
  obj.name = "Smith"; // Both variables point to the same object
}

rename(user);
console.log(user.name); // Result: "Smith"

What Happens in Memory?

let obj1 = { value: 42 };
let obj2 = obj1; // Copying the reference, not the object

obj2.value = 100;

console.log(obj1.value); // 100 - They both point to the same object!
console.log(obj1 === obj2); // true - Same reference

Reassignment vs Mutation

Important distinction: Reassigning the variable does NOT affect the original, but mutating the object does.

let original = { count: 5 };

function reassign(obj) {
  obj = { count: 10 }; // Creates new object, breaks the link
}

function mutate(obj) {
  obj.count = 10; // Modifies the existing object
}

reassign(original);
console.log(original.count); // 5 - Reassignment didn't affect original

mutate(original);
console.log(original.count); // 10 - Mutation changed the original

Shallow Copy vs. Deep Copy

Because objects are shared, modifying a copy often accidentally modifies the original. This is where cloning comes in.

Shallow Copy

Copies only the first level. Nested objects are still shared.

How: { ...original } or Object.assign({}, original) or [...array]

Danger: Changing copy.address.city will change original.address.city.

const user = {
  name: "Alice",
  address: {
    city: "NYC"
  }
};

const shallowCopy = { ...user };
shallowCopy.name = "Bob";           // Safe: Creates new string
shallowCopy.address.city = "LA";    // Danger: Modifies shared object

console.log(user.name);             // "Alice" - unchanged
console.log(user.address.city);     // "LA" - changed! ⚠️

Array example:

const nested = [[1, 2], [3, 4]];
const copy = [...nested];

copy[0][0] = 99; // Modifies the original!

console.log(nested[0][0]); // 99 ⚠️

Deep Copy

Creates a completely independent clone of the entire tree.

Modern way: structuredClone(original) ✅

const user = {
  name: "Alice",
  address: { city: "NYC" },
  hobbies: ["reading"]
};

const deepCopy = structuredClone(user);
deepCopy.address.city = "LA";
deepCopy.hobbies.push("coding");

console.log(user.address.city);  // "NYC" - unchanged ✅
console.log(user.hobbies);       // ["reading"] - unchanged ✅

Legacy way: JSON.parse(JSON.stringify(original))

Limitations:

Loses functions
Loses undefined values
Loses Symbol keys
Can't handle circular references
Loses Date objects (converts to string)

const obj = {
  date: new Date(),
  fn: () => console.log("hi"),
  undef: undefined
};

const copy = JSON.parse(JSON.stringify(obj));

console.log(copy.date);   // String, not Date object
console.log(copy.fn);     // undefined - lost!
console.log(copy.undef);  // undefined - lost!

The Power of Immutability

In modern development (especially with React), we follow the principle of Immutability: Never change the original data. Instead, always return a new version.

Why?

Predictability: You always know what your data looks like.
Performance: Frameworks can check if data changed by simply comparing references (oldState === newState) instead of checking every property.
Time-travel debugging: Tools like Redux DevTools can track state changes.
Avoid bugs: No unexpected side effects from distant parts of your code.

How to Stay Immutable

Arrays

Mutation (Bad):

const todos = ["task1", "task2"];
todos.push("task3"); // Mutates original

Immutable (Good):

const todos = ["task1", "task2"];
const newTodos = [...todos, "task3"]; // Creates new array

Common immutable array operations:

const arr = [1, 2, 3, 4, 5];

// Add item
const added = [...arr, 6];

// Remove item by index
const removed = arr.filter((_, i) => i !== 2); // Removes index 2

// Update item by index
const updated = arr.map((item, i) => i === 2 ? 99 : item);

// Insert at specific position
const inserted = [...arr.slice(0, 2), 99, ...arr.slice(2)];

Objects

Mutation (Bad):

const user = { name: "Alice", age: 25 };
user.age = 26; // Mutates original

Immutable (Good):

const user = { name: "Alice", age: 25 };
const updatedUser = { ...user, age: 26 }; // Creates new object

Nested updates:

const state = {
  user: {
    name: "Alice",
    address: {
      city: "NYC"
    }
  }
};

// Update nested property immutably
const newState = {
  ...state,
  user: {
    ...state.user,
    address: {
      ...state.user.address,
      city: "LA"
    }
  }
};

React-Specific Patterns

React relies heavily on immutability for efficient rendering.

State Updates

Wrong way:

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

// This won't trigger re-render!
const updateAge = () => {
  user.age = 26;
  setUser(user); // Same reference, React ignores it
};

Correct way:

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

const updateAge = () => {
  setUser({ ...user, age: 26 }); // New reference, React re-renders
};

Array State Updates

const [items, setItems] = useState([1, 2, 3]);

// Add item
setItems([...items, 4]);

// Remove item
setItems(items.filter(item => item !== 2));

// Update item
setItems(items.map(item => item === 2 ? 99 : item));

Why React Cares About References

// React's simplified internal check
if (prevState === newState) {
  // Skip rendering, nothing changed
} else {
  // Re-render component
}

This is why mutating state directly breaks React:

const [todos, setTodos] = useState([]);

// Wrong
const addTodo = (text) => {
  todos.push(text);
  setTodos(todos); // Same reference! React won't re-render
};

// Correct
const addTodo = (text) => {
  setTodos([...todos, text]); // New reference, React re-renders
};

Common Pitfalls and Solutions

Pitfall 1: Accidental Mutation in Callbacks

const handleClick = () => {
  const items = [...currentItems];
  items.sort(); // sort() mutates the array!
  setItems(items);
};

// Better
const handleClick = () => {
  const items = [...currentItems];
  const sorted = items.sort(); // Still mutates, but we have a copy
  setItems(sorted);
};

// Best
const handleClick = () => {
  const sorted = [...currentItems].sort();
  setItems(sorted);
};

Pitfall 2: Forgetting About Nested Objects

// Shallow copy doesn't protect nested data
const newState = { ...state };
newState.user.name = "Bob"; // Mutates original state.user!

// Deep copy or nested spread
const newState = {
  ...state,
  user: {
    ...state.user,
    name: "Bob"
  }
};

Pitfall 3: Reference Equality in Dependencies

// Creates new object on every render
const MyComponent = () => {
  const config = { theme: "dark" }; // New reference each render

  useEffect(() => {
    applyConfig(config);
  }, [config]); // Runs on every render!
};

// Stable reference
const MyComponent = () => {
  const config = useMemo(() => ({ theme: "dark" }), []);

  useEffect(() => {
    applyConfig(config);
  }, [config]); // Only runs when needed
};

Performance Considerations

When to Use Each Approach

Scenario	Recommended Approach
Small objects	Shallow copy `{ ...obj }`
Nested structures	`structuredClone()` or nested spreads
Large objects updated frequently	Consider Immer library
Arrays with primitives	Spread `[...arr]`
Arrays with objects	`structuredClone()` or map with spreads

Using Libraries for Complex Immutability

For deeply nested state, consider Immer:

import produce from 'immer';

const newState = produce(state, draft => {
  // Mutate draft freely, Immer makes it immutable
  draft.user.address.city = "LA";
  draft.todos.push("New task");
});

Summary Table

Data Type	Passed by...	Result of Modification	Copy Method
Primitives	Value	Original is safe	Automatic
Objects	Value (Reference)	Original property changes	`{ ...obj }` (shallow) `structuredClone(obj)` (deep)
Arrays	Value (Reference)	Original item changes	`[...arr]` (shallow) `structuredClone(arr)` (deep)
Cloned Object	New Reference	Original is safe	Depends on copy type

Quick Reference Cheat Sheet

// ========== PRIMITIVES ==========
let a = 5;
let b = a; // Copy
b = 10;
// a is still 5

// ========== OBJECTS ==========
let obj1 = { x: 1 };
let obj2 = obj1; // Reference copy
obj2.x = 2;
// obj1.x is now 2!

// Shallow copy
let obj3 = { ...obj1 };

// Deep copy
let obj4 = structuredClone(obj1);

// ========== ARRAYS ==========
let arr1 = [1, 2, 3];
let arr2 = arr1; // Reference copy
arr2.push(4);
// arr1 is now [1, 2, 3, 4]!

// Shallow copy
let arr3 = [...arr1];

// Deep copy
let arr4 = structuredClone(arr1);

// ========== IMMUTABLE UPDATES ==========
// Object
const newObj = { ...oldObj, prop: newValue };

// Array - add
const newArr = [...oldArr, newItem];

// Array - remove
const filtered = oldArr.filter(item => item.id !== idToRemove);

// Array - update
const updated = oldArr.map(item =>
  item.id === targetId ? { ...item, prop: newValue } : item
);

Conclusion

Understanding that JavaScript passes a copy of the reference for objects is a "lightbulb moment" for many developers. By mastering Shallow vs. Deep copying and embracing Immutability, you will write cleaner, bug-free code—especially in modern frameworks like React.

Key Takeaways:

JS is always pass-by-value (but the value might be a reference)
Primitives are safe from external changes
Objects and arrays share references—be careful!
Use spread or structuredClone() to create copies
Embrace immutability for predictable, performant code
React relies on reference equality for optimization

Now go forth and never mutate state directly again! 🚀

How to Delete the Un-deletable "nul" File Created by Claude Console on Windows 11

Tihomir Ivanov — Mon, 29 Dec 2025 23:53:51 +0000

The Mystery of the Un-deletable "nul" File

If you’ve been using the Claude Console or Claude CLI tools on Windows 11, you might have encountered a frustrating little bug: a file named nul appearing in your directories that simply refuses to be deleted.

If you try to delete it via the UI, nothing happens. If you try del nul in the command line, you get an error. It’s like a ghost file haunting your project.

Why is this happening?

In the Windows world, NUL is a reserved system name. It’s not meant to be a file; it’s a virtual device used to discard data (the "black hole" of the OS).

Sometimes, when tools like the Claude Console try to redirect output to "null" but the syntax doesn't perfectly align with Windows' expectations, the system accidentally creates a physical file named nul. Because the OS sees "NUL" as a protected device name, the standard del command can't target it.

The Fix: Using the UNC Path

To delete it, you have to bypass the standard Windows naming checks using the Universal Naming Convention (UNC). This tells Windows: "Treat this path literally, don't look for reserved names."

Option 1: Command Prompt (Recommended)

Open CMD and run this command (replace D:\ with your actual drive letter and path):

del "\\?\D:\path\to\your\folder\nul"

Option 2: PowerShell

If you prefer PowerShell, you must use the -LiteralPath argument:

PowerShell

Remove-Item -LiteralPath "\\?\D:\path\to\your\folder\nul"

Summary

The \?\ prefix is the "magic key" for managing files with reserved names like NUL, CON, or PRN.

If you are a developer working on Windows 11, keep this trick handy. CLI tools—especially those primarily built for Unix-like environments—will occasionally drop these "reserved" files into your folders by mistake.

How to Customize Any WordPress Theme with AI

Tihomir Ivanov — Tue, 26 Aug 2025 13:47:13 +0000

Customizing WordPress themes has always been a balancing act between flexibility and complexity. Beginners often rely on the built-in Customizer or block editor, while advanced developers dive into CSS, PHP, or child themes to get full control. But what if customizing a theme could be as simple as describing what you want in plain English?

This is where AI-powered customization comes into play. With the latest advances in large language models like GPT-5, artificial intelligence can understand the structure of a WordPress theme — its elements, layout, and styling — and help you make changes without having to write a single line of code (unless you want to).

Why AI is a Game-Changer for WordPress Theme Customization

Traditionally, customizing a WordPress theme requires some combination of:

Element targeting: Finding the right CSS selector for the header, footer, or widget area.
Styling knowledge: Writing CSS rules (and sometimes JavaScript) to adjust colors, spacing, typography, or responsiveness.
Previewing & testing: Checking how the changes look across devices before deploying them.

AI changes the equation by understanding both natural language and code. For example:

“Make the blog post titles bold, increase the font size to 28px, and center them on mobile devices.”

An AI model like GPT-5 can parse that request, identify the relevant CSS selectors, and generate the exact code snippet needed. Even better, it can show a live preview so you can approve before applying.

How It Works in Practice

At its core, AI customization for WordPress themes works like this:

Element Identification: AI can act like an element picker, letting you highlight the part of the page you want to change.
Code Generation: GPT-5 generates clean, minimal CSS (or JS if needed) that matches your request.
Preview & Approval: Before committing, you can preview the changes in real time.
Safe Customization: The code is applied in a non-destructive way, so your original theme files remain untouched.

This means you don’t need to spend hours digging into the inspector panel or worrying about overwriting theme updates.

Free and Paid Options for Getting Started

If you’d like to try AI-driven theme customization today, here are two options you can explore:

Tish Theme AI Customizer Lite (Free on WordPress.org)

A lightweight version that brings AI-powered customization into the WordPress dashboard. It’s a great way to experiment with natural-language-driven theme tweaks.
Tish WordPress Theme AI Customizer (Premium)

A more advanced version with additional features like full AI CSS management and extended customization capabilities. Ideal for freelancers, agencies, or power users who want deeper control.

The Bigger Picture: What AI Means for WordPress

AI isn’t here to replace developers or designers. Instead, it lowers the entry barrier for non-technical users while speeding up workflows for professionals. Imagine:

Site owners making quick design tweaks without hiring a developer.
Agencies scaling theme customization across dozens of client sites faster.
Developers spending less time on repetitive CSS adjustments and more on building unique features.

As GPT-5 and future models continue to improve, we’re heading toward a world where AI becomes a co-designer, bridging the gap between ideas and execution.

Final Thoughts

Customizing WordPress themes no longer has to be intimidating. With AI’s ability to understand both your intentions and the underlying code, anyone can shape their website’s look and feel in minutes.

If you’re curious, try out the free plugin to see what AI-powered customization feels like, and if you need more advanced capabilities, explore the premium version. Either way, it’s an exciting step forward for the WordPress ecosystem.

Get the free plugin here

Check out the premium version here

Forem: Tihomir Ivanov

How I built a Database-Free eCommerce for my Online Store and hosted it for $0

The Problem: Overhead is the Enemy

The Solution: TishCommerce

No Database? No Problem.

Hosting for $0

The Tech Stack

Final Thoughts

Referential Equality & Memoization: Why `{} !== {}` Breaks React Performance

The Golden Rule

Part 1: Referential Equality Explained

Primitives vs Objects

What About Same Reference?

Part 2: How This Affects React

Example: React.memo Doesn't Work

The Same Problem with Arrays

And Functions Too!

Part 3: Memoization to the Rescue

1. useMemo for Objects and Arrays

With Dependencies

2. useCallback for Functions

With Dependencies

3. React.memo for Components

Part 4: When to Use Memoization

Use Memoization When:

Don't Use Memoization When:

Part 5: Common Memoization Pitfalls

Pitfall 1: Missing Dependencies

Pitfall 2: Memoizing Without Memoized Child

Pitfall 3: Creating Objects Inside JSX

Pitfall 4: Memoizing Everything (Over-Optimization)

Part 6: Memoization Patterns in React

Pattern 1: Memoizing Context Values

Pattern 2: Memoizing Expensive Filters

Pattern 3: Memoizing Event Handlers with Parameters

Pattern 4: Using Refs for Stable References

Part 7: Debugging Referential Equality

Tool 1: Object.is() (React's Comparison)

Tool 2: React DevTools Profiler

Tool 3: useWhyDidYouUpdate Hook (Custom)

Quick Reference Cheat Sheet

Key Takeaways

Interview Tip

Composition vs Inheritance: Why React Chose the "Has-A" Over "Is-A" Relationship

The Golden Rule

Part 1: Inheritance vs Composition in JavaScript

Inheritance: The "Is-A" Relationship

The Problem with Deep Inheritance

Composition: The "Has-A" Relationship

Part 2: Why React Prefers Composition

Inheritance in React (The Old Way)

Composition in React (The Modern Way)

Part 3: Composition Patterns in React

Pattern 1: children Prop (Containment)

Pattern 2: Named Slots (Multiple Composition Points)

Pattern 3: Specialization (Specific Cases of Generic Components)

Pattern 4: Higher-Order Components (HOCs)

Pattern 5: Render Props

Pattern 6: Custom Hooks (Modern Composition)

Part 4: Composing Hooks

Part 5: When Inheritance Might Make Sense (Rarely)

1. Extending Built-in Classes

2. Third-Party Library Requirements

Part 6: Composition Anti-Patterns

Anti-Pattern 1: Prop Drilling

Anti-Pattern 2: Over-Abstraction

Quick Reference Cheat Sheet

Key Takeaways

Interview Tip

Reconciliation & The Virtual DOM: How React Decides What to Update

The Golden Rule

Part 1: The Problem with Direct DOM Manipulation

Why Updating the DOM is Slow

React's Solution: Batch Updates

Part 2: What is the Virtual DOM?

Real DOM vs Virtual DOM

React Elements

Part 3: The Reconciliation Process

Step 1: Render Phase

Step 2: Diffing Algorithm

Example: `React.memo` Doesn't Work

1. `useMemo` for Objects and Arrays

2. `useCallback` for Functions

3. `React.memo` for Components

Tool 1: `Object.is()` (React's Comparison)

Tool 3: `useWhyDidYouUpdate` Hook (Custom)

Pattern 1: `children` Prop (Containment)

Part 4: The Importance of `key` in Lists

Without `key` (or with index as `key`)

With Unique `key`

Why Index as `key` is Dangerous

3. Memoization with `React.memo`

Part 2: `var` Hoisting

Variables Declared with `var`

`var` is Function-Scoped, Not Block-Scoped

Part 3: `let` and `const` Hoisting

`const` Has the Same Behavior

Part 4: `var` vs `let` vs `const`

`let` in Loops

`let` in `if` Blocks

2. `useState` and Hoisting

3. Closure Issues with `var` in React

Gotcha 4: `typeof` and TDZ

`call()` and `apply()`

`bind()`

Rule 4: `new` Binding (Constructor Invocation)