Framework Native Rendering Without Code Duplication?

Yes, today I want to talk to you about an experiment that we're running inside of Agigrid, 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 we're all going to be writing, especially for the products that we've got like Agigrid, 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 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 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 View, and any other framework that we want to support in the future.

So 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 via JavaScript. Do we need the state 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 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 that itself could be pulled out. And then we keep going, and we get down to this level where it's an 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 view. But if all of that view logic has collapsed away, 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 into 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, 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 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 table or a row or a cell within that row, 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, to say, well, this is the kind of element that you want, the div, the span, and what your 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 Agic Grid at the moment, because we want to see how far can we push this. If we go down this approach, instead of having handwritten implementations for the different frameworks, can we collapse that all into one thing so that we can move faster, ship faster? But we have to make sure that performance doesn't get hurt. You can still render your custom React components within the grid, 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 not these specific details. But it's this new idea of thinking that doing these iterations, doing these experiments, has become so much cheaper. 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 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 grunt work for us. So I would encourage you all, explore freely, ask what if it can do this, and then finally, keep curious. Thank you. Thank you. Thank you. Thank you. Thank you.