One Rendering Layer for React, Angular & Vue. No Duplication - AG Grid Case Study | Stephen Cooper

This talk covers an experiment at AG Grid focused on rendering across multiple frameworks such as React, Angular, and Vue without duplicating code. The speaker discusses the challenges of organizing complex logic that lies beyond individual components, emphasizing the importance of a scalable and clean codebase. They explore the Model-View-Controller (MVC) architecture, highlighting how to separate logic from the view to facilitate rendering with different frameworks. By removing unnecessary view logic and consolidating event logic within a JavaScript data engine, they propose a shared interface resembling the DOM. This approach aims to streamline development processes while maintaining performance, allowing for faster iterations and improvements in application design. The speaker also encourages the use of AI for experimentation in code optimization and encourages curiosity in software development.

Yes, so today I want to talk to you about an experiment that running that we're running inside of AG Grid. Thinking about how can we render to each of these frameworks, React, Angular, Vue, maybe we can add in a few more including JavaScript of course, without duplicating a lot of our code. So sometimes the logic that you're going to be writing and especially for the products that

we've got like AG Grid, charts and studio is too complex to live in a component itself. So once you get to that point, you need to start thinking in kind of bigger scale. How do we structure our code base to make sure that it scales and that we can actually write this code in a clean testable way. So one of the first things you might reach for

is that the MVC approach. So you've got your model for your data, you've got your controller which contains a lot of the logic. So like you know, which rows should be rendering when we're doing virtualized scrolling. That doesn't really live in a controller, sorry, a component in itself. It's more like the actual data engine behind the grid. And then you have your view. So we actually still

need to render this to the DOM and that's the part which actually then starts interacting with the frameworks that we support. But the question becomes, well, what actually needs to live in that view? Because if our views are complicated, that means that we're going to have to duplicate quite a lot of the work for supporting JavaScript, for Angular, for React and Vue and any other framework that

we want to support in the future. So the the experiment that we're doing is how far can we push this? So if we look at the view code, we might be thinking, well, okay, do we actually need event logic in the view itself? And the answer is, well, no, we don't. We can do this by JavaScript. Do we need the state in the in the components? Again,

no, not really. We can manage this within our own JavaScript data engine itself. So, we could remove those as well. And then we look at a React component we can see this nested tree of of components and you think that is defined in the component, but is it actually critical that this is in the view? We're all very familiar with tree structures. So, you know, that's itself

could be pulled out. And then we keep going and we get down to this this level where it's element with a value inside of it and it's like, well, actually, we can't go any further. This is as low as we can go and this does need to have to be the But if all of that view logic has collapsed away, it's been pulled out of the view,

and it's just the DOM content, it's more likely that we're actually just working with a DOM API here. And every framework is expert at rendering to the DOM. So, at this point we have pulled all of the logic out into our controllers and onto our JavaScript logic, and then we're actually just going to offload the rendering to each of the frameworks. So, this is where we can

kind of come up with this very precise interface, [clears throat] which looks a little bit like the DOM. And it's this thing of, well, have I got children? Are they changing or am I just trying to display something myself? And then you what you might get is something that looks like this. I'm not going to try and focus on the specific implementations because it's still evolving and

it's probably not, you know, code that we're all going to want to be writing. But the simple idea is that actually instead of defining all the different elements, say like a a table or a row or a cell within that we can just have this generic component which knows how to render itself and then recursively go through its children. And instead our components we can define in

this new kind of shared language um to say well this is the kind of tile the element that you want a div a span and what the your [snorts] children are. And once you've done that you can have a DOM renderer, you can have a React renderer and they can both work on these same components. And so the idea is the component doesn't know and shouldn't care

about what framework is actually rendering it. It just wants to be rendered to the DOM. So this is the experiment that we're running inside of AG Grid at the moment because we want to see how far can we push this. If we go down this approach instead of having hand-written implementations for the different frameworks you know, can we up collapse that all into one thing so that

we can move faster and ship faster, but we have to make sure that performance doesn't doesn't get hurt. You can still render your custom React components within the grid um but it's looking promising and we're excited about where this is going. But I think Oh yeah. There we go. So it's all about writing the logic once and rendering it natively. But maybe the better takeaway for everyone

here is is not these specific details but it's this new idea of thinking that during these iterations, during these experiments has become so much cheaper. Like that we've probably all had these ideas about well I think this area of my application or this part of my code could do with some improvements. But we don't have the time maybe to to fully experiment and to work through all

the side effects of that. So this is where I think we can really leverage AI. We can throw our ideas at it and let it do the you know the the groundwork for us. So, I would encourage you all explore freely, ask what if it can do this, and then finally keep curious. Thank you all. >> [applause]