DEV Community: Maks

JavaScript Proxy: One more way to use it I wish I’d known 3 years ago

Maks — Sun, 07 Jun 2026 19:29:52 +0000

In our everyday work, we do a lot of data shuffling.

We work with heavily loaded data grids. We have built our own RevoGrid for this matter hence market didn't offer all options we need back than. Some of our clients want to pull 400k rows and 5k columns into the UI and look at them on huge monitors.

Don’t ask me what they see there. We deliver.

For a very long time, our approach was to rely on different event management systems. Based on the event type, we would incrementally update data sources outside of the grid.

And this works.

But the problem with this approach is that you slowly end up with a lot of different events:

cell edit
range fill
autofill
copy/paste
row grouping
grouping migration
column mapping
source refresh
external updates

Trust me, a lot.

So we were growing together with these events. One more feature, one more event. One more edge case, one more handler.

But we live in the age of reactivity, so why not take one step further and make the source itself reactive?

Instead of only reacting to grid events, we can feed the grid a source wrapped with Proxy.

The idea is simple:

The grid reads from the row through the get trap.

And when the grid tries to write something back into the data source, we catch that write through the set trap.

So the grid still works with normal-looking row objects:

row.price
row.quantity
row.status

But under the hood, we now control how reads and writes actually happen.

A very simplified version looks like this:

function createRowProxy<T extends object>(
  row: T,
  onWrite: (row: T, prop: keyof T, value: unknown) => void,
): T {
  return new Proxy(row, {
    get(target, prop, receiver) {
      return Reflect.get(target, prop, receiver);
    },

    set(target, prop, value, receiver) {
      const result = Reflect.set(target, prop, value, receiver);

      onWrite(target, prop as keyof T, value);

      return result;
    },
  });
}

Then we can pass proxied rows into the grid:

const source = rawRows.map(row =>
  createRowProxy(row, (row, prop, value) => {
    console.log('changed:', row.id, prop, value);

    // mark field as dirty
    // update external store
    // queue backend sync
    // trigger validation
    // update derived state
  }),
);

grid.source = source;

Now the interesting part:

The grid/component does not need to know anything about your real store architecture.

It does not care if your data lives in:

a plain array
a Map
a normalized store
a remote cache
a local-first database
a custom reactive state layer

From the grid perspective, it just reads and writes object properties.

But from your application perspective, you now have a controlled bridge between the grid and your real data model.

For example, the grid can read:

row.quantity

But internally this can be resolved from something like:

rowsById.get(row.id).quantity

Same for writes.

The grid can do:

row.quantity = 10

And your proxy can decide what should happen next:

set(target, prop, value) {
  updateStore(target.id, prop, value);
  markDirty(target.id, prop);
  queueSave(target.id);
  return true;
}

This is where the pattern becomes useful.

You stop treating every grid event as the main data pipeline.

Instead, the row object becomes an adapter.

Events are still useful. I would not remove them completely.

You still want events for things like:

validation cancellation
editor lifecycle
analytics
permissions
before/after hooks
custom UX behavior

But for data synchronization itself, proxy-based source handling can be much cleaner.

Especially when you have many ways to change data:

direct cell editing
paste
autofill
range updates
programmatic updates
grouping changes
external source changes

Instead of writing separate synchronization logic for every path, you can centralize a big part of it at the data access level.

Of course, there are rules.

Do not create proxies inside render loops
Keep proxy identity stable
Avoid mixing too much logic in both edit events and proxy setters, otherwise you will double-handle the same update
Think carefully about performance if you are working with very large datasets.

But as a pattern, it is surprisingly practical.

For me, this changed how I think about data flow - component does not always need to own the data flow.

Sometimes it is better to give it an object that looks simple from the outside, but is smart enough inside to route reads and writes into your actual application state.

I wrote this while working on editable data-grid internals. We use this pattern in RevoGrid’s proxy source approach, but the idea itself works with any editable table/grid where you want your app state to stay in control.

Happy coding!

React Data Tables Made Simple: A Friendly Guide into Data Grids

Maks — Tue, 21 Jan 2025 21:08:28 +0000

Data tables (or so called data grids) are at the core of many modern web applications, especially when dealing with large datasets or complex interactions. React's ecosystem offers several ways to implement a data grid, but today we'll compare two approaches:

A simple, custom-built React grid.
A robust and highly performant implementation using external libraries.

Let's dive in!

Creating a Simple React Grid

Before jumping into advanced solutions, let’s start with a basic implementation of a data grid in React using mock data. This example will give you a feel for how React components, hooks, and states can work together to create a functional grid.

Code Example

import React, { useState } from "react";

// Mock data generator
const generateMockData = (count: number) => {
  return Array.from({ length: count }, (_, index) => ({
    id: index + 1,
    name: `Name ${index + 1}`,
    age: Math.floor(Math.random() * 50) + 20,
  }));
};

const SimpleGrid = () => {
  const [data] = useState(generateMockData(50));

  return (
    <table>
      <thead>
        <tr>
          <th>ID</th>
          <th>Name</th>
          <th>Age</th>
        </tr>
      </thead>
      <tbody>
        {data.map((row) => (
          <tr key={row.id}>
            <td>{row.id}</td>
            <td>{row.name}</td>
            <td>{row.age}</td>
          </tr>
        ))}
      </tbody>
    </table>
  );
};

export default SimpleGrid;

Mock Data Generator: Creates sample rows with an id, name, and age for demonstration purposes.
State Management: Uses useState to manage and render the mock data.
HTML Table: Simple and styled to display the data as a grid.

So, you have an app that manages intensive datasets and you might think it’s straightforward enough to handle on your own. After all, implementing virtual scrolling might seem like all it takes.

But what happens when your needs grow?

Suppose you want to pin a row at the top or bottom. Add a column that also needs to be pinned. And then start grouping these elements. Soon, you might find yourself needing cell focus and range selections. This is where the complexity increases significantly.

In scenarios like this, maintaining performance while adding sophisticated grid functionalities can become difficult.
That’s where 3rd party components come in.

RevoGrid for Advanced Data Grids

We decided to use RevoGrid because we genuinely believe it’s the best data grid framework out there — and yes, we built it ourselves. With RevoGrid, you get React compatibility, unmatched performance, and the ability to handle massive datasets effortlessly. We’ve poured our expertise into creating a framework that’s feature-packed, highly customizable, and optimized to deliver a seamless experience. It’s the tool we’d choose for our own projects, and we’re confident you’ll love it too.

Installation

To get started with RevoGrid, first install the library via npm:

npm install @revolist/react-datagrid

Building a simple Example

Creating a data grid with RevoGrid in React is remarkably simple and efficient. All you have to do is define your data model, and voilà!
In the example below, we define a basic table with two columns — First and Second — and provide a static data source containing two rows.

Using useMemo, we ensure that the column definitions maintain a stable reference to avoid unnecessary re-renders. Similarly, the source data is stored in state with useState.

The component then renders the grid, automatically handling the layout and performance optimizations for the provided configuration.

// App.tsx
import { RevoGrid } from "@revolist/react-datagrid";
import { useState, useMemo } from "react";

function App() {
  // note: columns & source need a "stable" reference
  // in order to prevent infinite re-renders
  const columns = useMemo(
    () => [
      {
        prop: "name",
        name: "First",
      },
      {
        prop: "details",
        name: "Second",
      },
    ],
    []
  );
  const [source] = useState([
    {
      name: "1",
      details: "Item 1",
    },
    {
      name: "2",
      details: "Item 2",
    },
  ]);
  return (
    <>
      <RevoGrid columns={columns} source={source} />
    </>
  );
}

export default App;

Try it yourself!

Building an advanced RevoGrid Example

Below is an example implementation of RevoGrid in a React application. This example highlights row selection functionality and shows how to handle large datasets efficiently.

import React, { useState, useMemo, useCallback, useEffect } from "react";
import { ColumnRegular, RevoGrid } from "@revolist/react-datagrid";

// Mock data generator
const generateFakeDataRows = (rowsNumber: number) => {
  const result = [];
  for (let j = 0; j < rowsNumber; j++) {
    result[j] = {
      id: j,
      myRow: `Row ${j}`,
    };
  }
  return result;
};

// Make an App
const App = () => {
  const [rows] = useState(generateFakeDataRows(1000));

  // Selection state management
  const [selected, setSelected] = useState<Set<number>>(new Set());
  const [allSelectedStatus, setAllSelectedStatus] = useState<number>(0);

  const selectAll = useCallback(
    (checked: boolean) => {
      setSelected(new Set(checked ? rows.map((row) => row.id) : []));
    },
    [rows]
  );

  const selectSingle = useCallback((rowId: number, checked: boolean) => {
    setSelected((prevSelected) => {
      const updatedSelected = new Set(prevSelected);
      if (checked) {
        updatedSelected.add(rowId);
      } else {
        updatedSelected.delete(rowId);
      }
      return updatedSelected;
    });
  }, []);

  useEffect(() => {
    if (selected.size === 0) {
      setAllSelectedStatus(0);
    } else if (selected.size === rows.length) {
      setAllSelectedStatus(2);
    } else {
      setAllSelectedStatus(1);
    }
  }, [selected, rows.length]);

  const columns: ColumnRegular[] = useMemo(() => {
    const status = allSelectedStatus;
    return [
      {
        prop: "myRow",
        columnTemplate: (h, v) => {
          return [
            h("input", {
              type: "checkbox",
              indeterminate: status === 1,
              checked: status > 1 || undefined,
              onChange(e: InputEvent) {
                if (e.target instanceof HTMLInputElement) {
                  selectAll(e.target.checked);
                }
              },
            }),
            "Select All",
          ];
        },
        cellTemplate: (h, { model, value, rowIndex }) => {
          return h("label", undefined, [
            h("input", {
              type: "checkbox",
              key: rowIndex,
              checked: selected.has(model.id) || undefined,
              onChange(e: React.ChangeEvent<HTMLInputElement>) {
                if (e.target instanceof HTMLInputElement) {
                  selectSingle(model.id, e.target.checked);
                }
              },
            }),
            value,
          ]);
        },
        size: 400,
      },
    ];
  }, [allSelectedStatus, selected, selectAll, selectSingle]);

  return (
    <RevoGrid
      columns={columns}
      source={rows}
      readonly
      theme="compact"
    />
  );
};

Try it yourself!

For applications requiring high-performance grids, deep customization, and an excellent user experience, RevoGrid is the perfect choice. Start building smarter, faster grids today!

Battle of the Rows: The Limits of Data Performance

Maks — Tue, 19 Nov 2024 19:41:34 +0000

Hi there! 😊

Welcome to our recently conducted series of performance benchmarks. Data grids are becoming more popular and increasingly important as they play a vital role in managing and visualizing large datasets, especially in data-intensive applications. In this article we are going to evaluate one of the most famous data grids: AG Grid, Handsontable, and RevoGrid. Our goal was to provide you with some insight into this rapidly growing field.

Benchmark Methodology

We used the following metrics for our comparisons:

Memory Usage: Measures how efficiently each grid uses memory (What could be more important in a heavily loaded app?).
Scroll FPS: Evaluates the smoothness of scrolling, using frames per second (FPS). Typically, 60 FPS is considered the standard for smooth scrolling, but actual FPS may vary depending on browser capabilities, device performance, and other environmental factors. Variations between tests can occur due to these differences in hardware and software conditions.
Time Before First Cell Loaded: How quickly a grid can render and display the first cell (or viewport) after data is loaded.

Consider experimenting with the provided sample datasets. This hands-on approach will give you a practical understanding of grid performance.

We used four different datasets of increasing size: 1,000 rows, 100,000 rows, 200,000 rows, and 400,000 rows, each containing 100 columns. The data was generated using a web worker to avoid environmental dependencies.

We ran two types of tests:

Headless Mode: Using the Playwright framework for objective, script-driven tests.
Visual Mode: Testing manually in an actual browser environment.

Our goal was to create an unbiased, basic example of each grid, generating a large dataset and assessing how they handle this load under the same conditions.

Results Overview Summary

Handsontable

The oldest among the three. It operates based on a two-dimensional array structure and relies on traditional HTML elements like <table>, <tr>, and <td>. This makes it less flexible and contributes to performance issues.

Scrolling performance was subpar compared to the others; we noticed visible flickering when scrolling quickly, especially in dark mode. This may be due to Handsontable refreshing the entire viewport on each scroll event, which is common with traditional table structures.

100,000 Rows: 1297 MB of memory
200,000 Rows: 2498.63 MB of memory
Failed Beyond 300,000 Rows: Due to memory overhead and table duplication for column freezing, Handsontable struggled beyond 300,000 rows, often leading to crashes.

AG Grid

The most widely-used grids, backed by heavy marketing efforts. It provides a solid, user-friendly experience and features smooth, native-like scrolling. However, it also showed high memory consumption, similar to Handsontable, with its memory usage growing exponentially as we increased the dataset size.

100,000 Rows: 1297 MB of memory
200,000 Rows: 2660.75 MB of memory
Failed Beyond 300,000 Rows: Like Handsontable, AG Grid began to crash the browser tab when attempting to handle 400,000 rows.

RevoGrid

The youngest grid of the three, adopts a more modern approach. It uses virtual nodes backed by StencilJS, making it highly efficient for large datasets. RevoGrid includes advanced features that rival those of AG Grid, such as native smooth scrolling and customizable cells, while also being incredibly lightweight.

200,000 Rows: Only 368.12 MB of memory
Succeeded at 400,000 Rows: Handled 400,000 rows smoothly, using only 720 MB of RAM and retaining a smooth scroll experience.

Detailed Performance Metrics

Below are the performance metrics we collected during testing:

Testing 1,000 Rows

- AG Grid:
  - Used JS Heap Size: 40.15 MB
  - Scroll FPS: 60.23
  - Time to First Cell: 8.31 ms

- Handsontable:
  - Used JS Heap Size: 37.77 MB
  - Scroll FPS: 60.62
  - Time to First Cell: 6.67 ms

- RevoGrid:
  - Used JS Heap Size: 20.69 MB
  - Scroll FPS: 60.22
  - Time to First Cell: 6.07 ms

Testing 100,000 Rows

- **AG Grid**:
  - Used JS Heap Size: 1297.00 MB
  - Scroll FPS: 60.59
  - Time to First Cell: 10.95 ms

- Handsontable:
  - Used JS Heap Size: 1297.00 MB
  - Scroll FPS: 60.85
  - Time to First Cell: 16.71 ms

- RevoGrid:
  - Used JS Heap Size: 214.58 MB
  - Scroll FPS: 61.88
  - Time to First Cell: 6.09 ms

Testing 200,000 Rows

- AG Grid:
  - Used JS Heap Size: 2660.75 MB
  - Scroll FPS: 60.10
  - Time to First Cell: 7.42 ms

- Handsontable:
  - Used JS Heap Size: 2498.63 MB
  - Scroll FPS: 59.63
  - Time to First Cell: 13.10 ms

- RevoGrid:
  - Used JS Heap Size: 368.12 MB
  - Scroll FPS: 61.02
  - Time to First Cell: 6.14 ms

Visual Representations of Performance Metrics

To better illustrate the differences in performance between the three grids, we created bar charts for each key metric:

Memory Usage Comparison: This chart shows how much memory each grid uses for different dataset sizes.

Time Before First Cell Loaded: This chart highlights the time each grid takes to render and display the first cell.

Scroll FPS Comparison: This chart visualizes the smoothness of scrolling, using frames per second as a measure.

Final thoughts

The results of our testing clearly show that RevoGrid outperforms the other grids in terms of memory efficiency, scalability, and overall performance. It effectively handles larger datasets with significantly lower memory usage while maintaining smooth scrolling and rapid load times.

AG Grid provides a solid user experience, and Handsontable has some advantages in terms of familiarity and its traditional table semantics.

If your project needs to manage vast amounts of data without sacrificing performance, RevoGrid is an excellent choice. Its lightweight, highly optimized approach ensures that you can scale without worrying about browser crashes or excessive memory use.

Interested in comparing other grids like Tanstack, MUI, Syncfusion, or ReactTable? Let us know, and we'll create a detailed review for you.

Code repo

How to get 2000+ Github stars in 2 days

Maks — Mon, 25 Jan 2021 03:08:21 +0000

Today our project https://github.com/revolist/revogrid received crossed 2700+ stars mark. And 2000 of them happened to us in the last 2 days.

I think each of us came to GitHub with some goal. Most of us bound to the idea of organic promotion. According to it a good project is enough to become famous itself. But there are too many of them and we have to live with it.

This is a very short instruction on how to get your first stars:

Solve my pain

Write a project which the world has necessary in. You can't make people love it if there is no solution to their pain;

Good a Readme.

This is the easiest part you can start with. You just have to learn from the best. I would start with https://github.com/matiassingers/awesome-readme, you can come with your own better sample;

Leave "cold stay zone"

Get your first stars. Find a channel you like: Friends, colleagues, or some channel you start with.

And here we go

The best way to launch your ship into space is to get visible by media.
Best way to get into GitHub trending. How to do that:

Timing is important. If you aiming to be visible you have to get a significant amount of start in a short period of time;
Describe your project for media: start with writing down a very simple and beautiful description. According to which even your granny can understand what it is. Follow it with a promo picture. Better have 2
Make sure you started your Twitter live and most of us like short news from each other;
Start your activity on Reddit if you aren't there yet;
Collect your channels in one place. You'll need them soon. I would suggest some, but discover your own too:
https://www.reddit.com/r/webdev
https://www.reddit.com/r/javascript
https://www.reddit.com/r/Frontend
https://www.reddit.com/r/opensource
http://www.echojs.com
https://dev.to/t/javascript
Methodically start posting to your collected channels. Also, keep answering comments. This is very important, doesn't matter how harsh they are.

There is no clear mark where your project gets trended, for us, it was 160+ stars. But there were a lot of projects with 100+ stars and a smaller amount. The good thing is you'll get a lot of feedback about your project by this moment and will see different perspectives around it.

I wish you luck and no matter what keep trying.

What are Protocol Buffers? Will they replace JSON?

Maks — Sat, 23 Jan 2021 23:42:35 +0000

https://www.codewall.co.uk/what-are-protocol-buffers-will-they-replace-json/?utm_source=CWTwitter&utm_medium=social#

Open source excel grid system with advanced performance for Vue, React, Ember, Angular, Svelte

Maks — Fri, 22 Jan 2021 04:39:14 +0000

On regular bases I’m working in development and consulting for project with complex frontend. Most of them require enormous data representation without problems for client, others require complex ui design systems.

In the end revo-grid system was born. I have created data grid system which combines best excel sheet qualities with high performance.

These are key features:

VNode based DOM almost without rerendering. I do recombination instead;
Full customization: custom cells, headers, properties, editors;
Advanced plugin system with most important plugins out of box such as sorting, filtering, exporting to excel, column based on context size;
Custom sizes for rows and columns;
Column/Row grouping;
Freezed columns/rows;
Integration with all popular frameworks: react, vue, angulat, ember, vanilla;
Multiple other useful features just to get it in use out of box.

Hope you will enjoy component. Looking for some feedback from you. Any suggestion are welcome. Thank you.

Data grid with excel like features in 2025

Maks — Thu, 01 Oct 2020 08:44:08 +0000

In our company we are facing problems with huge datasets on client side.

So far there wasn't any good solution with MIT license, we've decided to create our own (wish it would be that easy): https://rv-grid.com.

The biggest challenge was to create multiple viewport renderers which will work fast and extend easily.

Except of usual virtualization we are using VNode DOM, which updates only changed parts, but we went much farther: - We are monitoring nodes per scroll and move nodes from edges, not entire screen redraw. With this we achieved amazing performance. Now we are going to add more features and grow up.

Thank you for reading, hope to get some feedback from you guys.