But one thing it doesn’t provide out of the box - Infinite scrolling!

The Problem

When you’re dealing with thousands of rows, the usual approaches are:

• Pagination: Works, but breaks the smooth “scrolling through data” experience.

• Load All Data: Possible for small datasets, but if you try with 1,000+ rows… the table will lag, the DOM will bloat, and your browser will cry.

What we really need is a way to:

1. Only render what’s visible (virtualization)

2. Fetch more rows as the user scrolls (infinite loading)

Unfortunately, Ant Design only supports virtualization and doesn’t support infinite scrolling out of the box.

The Solution

I built a lightweight useVirtualInfiniteScroll hook that makes it super easy to add infinite scroll to scrollable list with virtual scrollbars.

Example Code (with Ant Design Table)

import React, { useState, useEffect } from "react";
import { Table } from "antd";
import { fetchData } from "../helpers/fetchData";
import { COLUMNS } from "../helpers/constants";
import useVirtualInfiniteScroll from "react-virtual-infinite-scroll-hook";

const AntdTableVirtualWithInfiniteScroll: React.FC = () => {
  const [data, setData] = useState<any[]>([]);
  const [page, setPage] = useState(1);
  const [loading, setLoading] = useState(false);
  const [hasMore, setHasMore] = useState(true);

  const loadMore = async () => {
    if (loading || !hasMore) return;
    setLoading(true);
    const newData = await fetchData(page, 10);
    setData((prev) => [...prev, ...newData]);
    setHasMore(newData.length > 0);
    setPage((p) => p + 1);
    setLoading(false);
  };

  // https://www.npmjs.com/package/react-virtual-infinite-scroll-hook
  // Just import & call the hook anywhere passing the required props
  useVirtualInfiniteScroll({
    onLoadMore: loadMore,
    hasMore,
    loading,
    scrollbarSelector: ".ant-table-tbody-virtual-scrollbar-vertical",
    enabled: true,
  });

  useEffect(() => {
    loadMore();
  }, []);

  return (
    <div style={{ maxWidth: 700 }}>
      <Table
        bordered
        columns={COLUMNS}
        loading={loading}
        dataSource={data}
        pagination={false} //👈 disable pagination
        virtual={true} // 👈 enable virtual table
        scroll={{ y: 450 }} // 👈 Virtual table container height
      />
    </div>
  );
};

export default AntdTableVirtualWithInfiniteScroll;

Why This Works

• The hook only passes the visible slice of data to the table.

• As you scroll near the bottom, it automatically asks for more rows.

• The DOM never gets overloaded, so scrolling stays smooth even with huge datasets.

Let’s check out useVirtualInfiniteScroll hook in action

Final Thoughts

Ant Design Tables are fantastic for enterprise apps, but when it comes to scroll-heavy datasets, we need to go beyond pagination and use infinite scrolling with virtualization.

With useVirtualInfiniteScroll hook, you can supercharge your Ant Design Table with infinite scrolling and virtualization in just a few lines of code. The hook is available as a npm package - https://www.npmjs.com/package/react-virtual-infinite-scroll-hook

Give it a try in your next project and let me know how it works for you! 🚀

An event travels or propagates through the DOM tree, this is called Event propagation.

This can happen in 2 ways -

• From top to bottom
• From bottom to top

Let's understand using an example

• Take 3 divs, a grandparent div, inside that we have a parent div and inside that, we have our target div.

<div id="grand-parent">
    <div id="parent">
        <div id="target">
        </div>
    </div>
</div>

• Attach onClick handlers to all divs console logging the name of the divs.

grandParent.addEventListener("click",() => console.log("Grand Parent"))
parent.addEventListener("click",() => console.log("Parent"))
target.addEventListener("click",() => console.log("Target"))

-Now click on the target div (smallest one)

Default order of onClick event

• We get Target => Parent => Grandparent logged in the console.
• This is an example of the bottom to top event propagation or Event Bubbling.
• So, without doing anything we got to see the event bubbling, so it is safe to say the onClick event by default bubbles up. (Not all events bubble up by default)

Remember event bubbling as bubbles coming up to the top surface of a water

Reversing the order of events

Now, we want to reverse the order of events. But how do we do that? There's a third parameter taken by the addEventListner which accepts a boolean value, which is false by default. This attribute tells the handler if the event is to be captured or not.

If the third parameter is set to true the event capturing mode is enabled.

grandParent.addEventListener("click",()=>console.log("Grand Parent"),true)
parent.addEventListener("click",()=>console.log("Parent"),true)
target.addEventListener("click",()=>console.log("Target"),true)

-Now click on the target div (smallest one)

• We get Grandparent => Parent => Target logged in the console.
• This is an example of top to bottom event propagation or Event Capturing/Trickling.

Remember event capturing/trickling as water trickling down the slope of a mountain

Order of event propagation

Consider the code below where only the parent event has capture set to true

grandParent.addEventListener("click",() => console.log("Grand Parent"))
parent.addEventListener("click",() => console.log("Parent"),true)
target.addEventListener("click",() => console.log("Target"))

What would be the logged on the console on clicking the target(smallest) div now?

on clicking the target div(smallest div) :

• We get Parent => Target => Grandparent logged in the console.
• To predict this output we need to remember one simple thing -

In an event propagation cycle, the capturing phase occurs first then followed by the target phase and bubbling phase.

Consider the image below -

• The event propagation happens down the mountain and then up the mountain.
• Events are placed on the vertical plane based on the hierarchy in the DOM. i.e. Grandparent contains the parent so the grandparent will be above the parent.
• Also, based on the true/false attribute of the capture flag events are placed on the capture line or bubble line
• Now we traverse as per the arrows shown and we get the expected output.

How to stop this propagation?

So far we saw an event propagating either up or down the DOM tree but what if we only want the event to happen on the target div and do not propagate, say we want to log on which div the user clicked, here we could use something as: e.stopPropagation()

grandParent.addEventListener("click",() => console.log("Grand Parent"))
parent.addEventListener("click",() => console.log("Parent"))
target.addEventListener(
  "click",
  (e) => {
    e.stopPropagation();
    console.log("Target");
  }
)

Try clicking on target(smallest) div :

Here, since the target has a stopPropagation so events from the target won't propagate. i.e. on clicking on target(smallest) div we will see only target in the console.

Try clicking on the parent div now- Since there is no such stopPropagation on the parent, clicking on the parent will still behave as it behaved before and consoled parent => grandparent

Event Delegation

Event delegation is a performance optimization technique. Say you have a shopping site where there are multiple categories, now if you attach onClick handlers to each category then when the page is fully loaded then it will have too many event listeners. Having too many event listeners can slow down the performance of a web app and hence event delegation comes to the rescue.

Implementation

Instead of attaching event listeners to all target elements, attach an event listener to the parent and with the help of the event-bubbling get what target has been clicked.

const parent = document.querySelector("#parent");
parent.addEventListener("click",(e) => console.log(e.target.innerText))

Click on the numbered divs it will console the number of the div clicked

TLDR

Event Bubbling - start from the target element and traverse up in the DOM tree Event Capturing - start from the top of the DOM tree and traverse down to the target Event Delegation - Instead of attaching multiple events listeners attach one event listener to the parent and with the help of event bubbling get on which element the event has occurred.

Javascript is a single-threaded interpreted language with a non-blocking event loop. What this means is that everything runs on a single main thread so it's important to use the thread only when required. Blocking this main thread means subsequent operations have to wait till the main thread is clear, this may result in performance issues.

In this blog, we will look at 2 simple examples to understand what are these issues & how to tackle them thereby optimizing performance. Let's say we have an expensive function, a function that makes an API call and performs some heavy computation and then some significant UI changes.

Example 1 :

Consider an input search field with this expensive function attached to its onChange handler. Say, I want to search for a "refrigerator" and I type this without making any wrong keystrokes. In this case, the expensive function will be called 12 times. You might argue that it is better to call the function as suggestions can be quicker. Now, Imagine 1 million users search something at the same time. Imagine the number of requests a server gets that too when someone doesn't make a mistake in typing. So, as the number increases, the number of requests also increases. But do we need to call this function on every change? We probably don't, we can optimize this by calling the function if the delay between two events(keystrokes) is more than let's say 400ms. In simple words, if the user pauses while typing call the function. This method of performance optimization is called debouncing.

Implementation :

• Create a function debounce that takes a function and a delay.
• It returns a function that clears the timeout if it already exists and then starts a new timer of the given delay.
• If another event occurs before the timer is over then this function is called again the old-timer gets cleared and the new timer starts.
• If another event does not occur before the timer gets over then the expensive function is called.

const debounce = (func, delay) => {
    let timer;
    return function () {
      clearTimeout(timer);
      timer = setTimeout(() => func(), delay);
    };
  };

Try searching with and without debounce and notice the number of API calls -

Example 2:

Consider a shooting game where to fire a weapon we need to click and this expensive function is attached to its onClick handler. In an intense fighting situation where we want to kill the enemies, we would spam the clicks to fire as many rounds as possible. But, a weapon has its limits - Let's say between subsequent shots, there is a delay of 300ms. But, we won't think of all this we would spam the click. So we need to call the function only where there is a delay of 400ms from the last function call. This method of rate-limiting of the function call is called throttling.

Implementation :

• Create a function throttle that takes a function and a delay.
• It returns a function that runs the expensive function only if the flag is true, then set's the flag to false and starts a setTimeout to set the flag to true again after the specified limit.
• If other events occur before this setTimeout expires then the flag is false and the expensive function is not called.
• In this way the expensive function is only called when the flag is true, else it has to wait till the setTimeout expires and set's the flag to true

const throttle = (func, limit) => {
  let flag = true;
  return function () {
    if (flag) {
      func();
      flag = false;
      setTimeout(() => (flag = true), limit);
    }
  };
};

Try Spamming the two fire buttons and notice the number of shots fired -

TLDR

DEBOUNCING => call a function if the delay between events is more than d THROTTLING => call a function if the delay between function call is more than d

Note: When it comes to debouncing vs throttling, there is no clear winner, it depends on the situation.

One of the reasons React is so popular is that it's blazing fast. This speed is achieved by updating only part of the real DOM that has changed. But, updating the real DOM is a slow process. So, how does React achieve this? React achieves this using virtual DOM.

Virtual DOM is a lighter version of real DOM. But, it looks nowhere like the real DOM instead it's a tree of React(JS) objects that represent the UI at an instant.

Think of the real DOM as a building and virtual DOM as a blueprint of the building.

When a state changes or prop updates, it triggers a render.

When we hear the term "render" we think of it as painting a picture or printing a page. However, in React this is not what "render" means!

Render

This is a process of traversing through the virtual DOM and collecting the updated states or props and running the render() function for those components which use the updated state or prop and create the new virtual DOM.

Reconciliation

This process involves comparing the new virtual DOM with the old virtual DOM and finding the differences. This process is called reconciliation and it uses a diffing algorithm based on two assumptions:-

1. Two elements of different types will produce different trees.
2. The developer can hint at which child elements may be stable across different renders with a key prop.

Due to the 2nd assumption, you might have seen Warning: Each child in a list should have a unique "key" prop many times. Now you know why this happens.

We'll look into what the 1st assumption means in the example given later.

React

Once React finds the most efficient way to update the UI, the real DOM gets updated. This is called a React phase or Commit phase (not render phase).

Let's understand this better with an example:

Throughout this example, the UI will remain the same, only the code will change.

Part 1

• We have a simple counter with 2 buttons increment and decrement.
• We also have a div that changes style at the click of a button.
• CSB: https://codesandbox.io/embed/rrr-1-g58481

• on clicking increment/decrement the counter increases/decreases.
• then, if we click on Toggle Style the background changes.
• there is no effect on the counter on clicking Toggle Style.

Part 2

• Now, we change the code slightly for the style change div
• CSB: https://codesandbox.io/embed/rrr-2-9dv9jb

• We've changed the style change div to a single component and on the click of Toggle Theme we see the same output as before.

Part 3

• Now, we change the code slightly more for the style change div
• CSB: https://codesandbox.io/embed/rrr-3-ng6xrf

• instead of just the style of h1 being changed we see the whole h1 being changed and not just that we see the whole example-2-wrapper div and its children being changed.
• So, what happened here is on click of Toggle Style the whole component is being changed and is rendered accordingly. So, looking at the real DOM, it might look like not much needs to be changed but instead of looking at the real DOM, we need to look at the virtual dom and then we see the Comp1 being changed to Comp2 and vice versa and hence all of its children will render.

Part 4

• Now, we change the code slightly again
• CSB: https://codesandbox.io/embed/rrr-4-l016gq

• Now, we extracted the counter into a component keeping other things the same.
• As excepted, the output remains the same as before

Part 5

• Now, we make some more code changes
• CSB: https://codesandbox.io/embed/rrr-5-2t6t72

• On clicking Toggle Style we see the counter getting reset.

• So, what's happened here is, the same that happened in Part 3. On clicking Toggle Style a new component gets rendered and hence all of its children get rendered freshly.

• In case, we need to make the counter retain its state then we may use context

The way React sees while diffing:

• Node is same -> React goes inside
• Node is different -> Change fully

This was my understanding of Render Reconciliation React.