Why AG Grid's React Rendering Matters
Tags: react
Published: 2022-02-23 14:44:20

---
title: Why AG Grid's React Rendering Matters
published: true
date: 2022-02-15 13:40:49 UTC
tags: React
canonical_url: https://blog.ag-grid.com/why-ag-grids-react-rendering-matters/
---

 ![Why AG Grid's React Rendering Matters](https://blog.ag-grid.com/content/images/2022/02/why-react-100-percent-blog.png)

7 years ago the first version of AG Grid was released, initially for AngularJS, but then following on to support Angular, React and Vue. The reason the AG Grid project was started was there was nothing out there with the breadth of features and depth of quality than what was needed for the new era of JavaScript applications getting created.

The latest version of AG Grid uses React for its Rendering (assuming that is you are using the React version of AG Grid). But it wasn't always this way. In the beginning there was a thin React wrapper around an otherwise Plain JavaScript AG Grid and this created concern among the React community, with the opinion "It's not really React". But before going into this, lets start at the start...

## Data Grid's are Complex

One thing the AG Grid team have learnt is that Data Grid's are incredibly difficult to write. I can honestly say that AG Grid is by far the most taxing project I have ever worked on - and everyone else who joins the AG Grid team ends up agreeing. The problem with Data Grid's is the sheer interconnected complexity. You cannot write one feature (eg Sorting) without considering how that feature impacts all the other features (Filtering, Editing, Grouping, Pivoting, Navigation, Theming, etc, etc). As you add features, the complexity grows exponentially.

You can see the problem this leads to with the many JavaScript Grid projects out there, especially in the open source community. Almost all follow the same project lifecycle. They start off solving a subset of the problem by creating a core set of features that work well together. But once breadth is added to the complexity (i.e. more features are added), then the projects begin to stumble on quality, as it's incredibly difficult to create a Data Grid that covers all the basic features and still maintains quality. That's why it's so hard to find a JavaScript Data Grid that delivers on both quality and features. So almost all of the Data Grids out there are either severely limited in capability, or are very questionable with regards their depth and quality.

## We Started By Wrapping React

Now getting back to React - historically AG Grid supported the different frameworks by wrapping a JavaScript core. So AG Grid React was a wrapper around a Vanilla JavaScript AG Grid. That is how the React version had all the features of the Vanilla JavaScript version - it was the Vanilla JavaScript version, just wrapped by React! This wrapping came with a price - because the grid wasn't really React, it didn't really behave like React. For example all the React goodies exposed by the React Developer Dev Tools (viewing component state, managing render cycles etc) did not work well with AG Grid.

A lot of people noticed this smell around AG Grid when using it with React, and as a result avoided using AG Grid inside React applications. This led to what I call "weed projects" - not very good (hence I call them weeds) React data grids appearing inside the React community claiming to be 100% React Data Grid solutions. Some of them even with websites and pricing mirroring that of AG Grid (you know you're doing something right, when wannabies try to copy what you are doing!). These grids were "React Grids" for "Real React Developers". The only problem is, they suffered from the same problem most grid projects suffer - they start out with some good ideas, but as the complexity grows, the breadth and / or quality drops, and they are simply poor quality projects.

## Going 100% React

Seeing the many React projects pop up is what led us to re-think our React solution - the React community wanted something different from AG Grid. About one year ago, we went full bananas on this, and imagined . . . what would it be like if we ported the rendering of AG Grid over to React? And so our internal project code-named "AG Grid React UI" began. One year later, and we are finished. The rendering engine of AG Grid was refactored out into a separate swappable layer, and then a brand new React rendering engine provided for when using AG Grid inside React. The result is a React JavaScript Data Grid that is rendered 100% in React. The Data Grid does exactly the same thing regardless of which rendering engine is used with respect to the DOM that gets created. So every feature in AG Grid works the same down to each DIV, SPAN and CSS style and class. That means that the breath of features, and quality of the underlying implementation of those features remains the same. The AG Grid React, with React Rendering, comes with the 7 years of quality built up inside AG Grid.

So why does this matter? There is no need for an alternative to AG Grid for React anymore. All the weed projects providing "A React alternative for AG Grid" can now be dug up and thrown out. AG Grid is now a full React Component, and as such Real React Developers can use AG Grid with full knowledge their grid is getting rendered in React. We are delighted (and proud may I add) of this approach and are looking forward to how the React Community responds to our new offering.

What do you think? Let's chat - Tweet and include my handle [@niallcrosby](https://twitter.com/niallcrosby), let's get some discussion going!

You can check out our website to see [AG Grid's React Rendering in action](https://www.ag-grid.com/react-data-grid/reactui/).