What Refs Can Do for You

Today, I want to talk to you about what refs can do for you. As you've had some spoilers and here's some more information about, you know, me. So there's 10 years in the financial industry and now three years with Agigrid. And I had to add this to my slide, you know, pictures of the pets, seeing as you're all going to find out about them. So it's Toby, Rufus, and Coco. So yeah, life is busy at home. But that's my personal life.

In a professional setting, I work at Agigrid. So you've all heard the adverts today, we've got Agigrid and the AgiCharts. So you can drop these components into your application, start using them and have all these great features. But don't worry, that's not what I'm going to focus on today. I'm going to share some of the things that I've learned while profiling Agigrid. And these are things that I think as we go on this journey together, walk through the problems, we should hopefully all learn something about these different parts of React, or that's my aim at least.

So let's start here. So while we were developing Agigrid, we were running these different use cases. And one of them was, well, a user comes to us and says, I've got this custom component that I'm going to put into one of these columns. So in this case, it's like a ticker with a picture and image of the company. And they're going to resize it. And what we noticed in these testing is that, well, actually, the resizing was really jumpy. And they're like, this is a terrible user experience. So it's like, OK, what are we going to do about it? Let's investigate.

So before we jump into the complicated case of this situation, let's take a step back and see, can we actually reproduce this in a simpler case and see if there's any performance issues there? So we opened up React DevTools. I took away all the custom cell renderers. So here we're just rendering plain text cells, moved the column around, and recorded the profile. And this is what we saw. So we're not seeing any perceived performance issues in this situation. But what you can see is that we've got 254 renders for just doing a few of these resizes. But they're fast renders. So we haven't actually automatically got a problem here because we got a lot of renders. But it's something that we maybe need to consider.

And while we're looking at the profile, these are two settings which I think are very, very important. So recording the component Y is actually re-rendered. So this is telling you, well, it's the cell component, and it was hook 30 that changed. And then there's another setting under the components panel where it can parse the hook names. So instead of having this undefined false, false, false, it actually gives you the names that you used in your code. So these are just a small thing which can make debugging these issues so much easier.

Like I said, we didn't really see this performance issue in the simple case. So now we put in a custom cell component, and we make it artificially slow. So we'll put some slow logic in there, maybe like a for loop, which does a lot of work, before it renders things. So these are just an idea of simulating what a user might provide to us. Because we're not in control of what the user is going to give us. But we need to make sure the grid still works well in those situations.

So when we did this, put it into the grid, we could see we had this slow behavior again. And this time in the profile, it looks quite different. We've only actually managed to render it 10 times. So this is why instead of having lots and lots and lots of different renders, and you get that smooth resizing, we've instead got this, you know, the browser gets stuck, it re-renders. The browser gets stuck, it re-renders. So you can see this with the much taller bars and the time that they were taking. And we can also quite clearly see that it's this ticker cell that we've provided, which is the bottleneck, and which is blocking the browser.

So if we quickly look at this and say, okay, well, why is this component rendering so much? Now, in our cell component, we were setting the style via the state property, say we've got left here. So our cell controller, which is what controls where all these columns are, it was saying, well, the left position is changing. And that's what you would expect. And we would simply update the state. But because we're updating the state, React is re-rendering this whole component. And because the state is being updated on that div, the custom cell is a child of that. And so if there's no memorization or any kind of catches there, that is also being re-rendered. So the first step is, well, we can wrap it and use memo, or memo. And then also this is something that the React compiler will take care of us. So I'm not going to spend much time talking about that. That helps us improve the performance.

And that might be good enough. But can we actually do better than memo, or the compiler? And I think the answer is yes. But to demonstrate this, we need to now take a look at the actual performance panel itself. And we'll record a profile while we're doing this in Chrome DevTools here. And what you see is something like this. Lots and lots of these very long lines, where lots of functions deeply nested have been run. But if we zoom in to one of these single tracks, and then we start looking at the code that's being run, we see we've got this section from Agigrid, which is the logic working out where is this column going. And then we've got a second bit from React. So this is in React dev mode, so which is why you can see the function names. So even though in production that would be smaller and shorter, there's still this notion of there's Agigrid code working out what needs to change and then React is responding and making those changes for you. And so in this, you can see the cell component is being rendered lots of times. Or we had lots of cell components on the page that have been rendered. So as I said, what if we don't rerender at all? Now to think about this, if we look at the component again that we had, the only thing that we were changing when we were moving the columns around is actually a style position. It's just this left position. So can we actually update this manually? So if we had a reference to the dev element, we could actually set the left property ourselves. Because under the hood, that's all React is going to end up doing. Because that's the only thing that we have changed between those renders. So what if we do it ourselves? But then the question is, well, how do we get a reference to that div? And this is where we can use ref. So we create a ref, cell ref equals use ref. And then within our template, we can set that to our ref property. And then we set up our cell controller and update the style manually. But can anyone see what might be the problem here? Well, the cell ref is possibly undefined. So on the initial render, this on left change method, that might actually run this logic. And it might run the callback to try and set this left property. But at that point in time, the cell ref hasn't been assigned yet. So it's going to blow up. So then we think, oh, OK, well, then what if I wrap this in a news effect? Because I know that the ref is going to be defined once when the effect is called. So we can make this change. But then we need to be careful, because we've actually made a massive bug here. So now on the initial render, all of the columns are lined up on the first one.

So what you can see is all those initial left properties aren't being set in time. So the browser is actually rendering before we managed to set them. And now this makes sense in the way that use effect is run. Because use effect is run asynchronously after the browser is paint. So the columns are rendered with no left position, then we set the style, and the columns jump into position. And this is completely by design. Use effect is not meant to block the browser from painting. So it's not actually the right thing for our use case.

So we might have two different ideas. So you say, well, or maybe I can provide an initial left value to the template via state, then I'll start updating it. Or maybe I just need to find a way of forcing the browser to run synchronously. So if we look at this approach, so maybe here we'll add an optional chaining to handle the fact that it's undefined. And we'll set the style with an initial left property. But I would say don't do this at all. So React does not know about the direct style changes that you're making. So then in a future render, it might come back and say, well, okay, I've got this initial left property, I'm going to re-render, and I'm going to set the style to that. So you do not want to mix and match these versions, because then you're not working with React, you're actually fighting against it, and you could get in some really bad, messy situations.

So, isn't this talk about refs? Well, yes, it is. So we are used to seeing refs defined in this way. So we say, useRef, it gives us this ref object, and then we pass this to the ref prop on our development, and that will be assigned asynchronously.

And now there is a big pitfall that is called out on the docs in terms of performance, and it's because you're doing all that kind of work before the browser is painting, so you are blocking it. So code which you should be running in useEffect shouldn't necessarily be moved to a useLayoutEffect. But we can make this change. So we'll swap it in for useEffect, it will run synchronously, and that initial left value actually gets applied before the browser gets painted. So now we have effectively fixed our problem, and that works. But there are some downsides, and there are some things that make this maybe not the optimal solution. But we'll come back to them later on in the talk.

So, isn't this talk about refs? Well, yes, it is. So we are used to seeing refs defined in this way. So we say, useRef, it gives us this ref object, and then we pass this to the ref prop on our development, and that will be assigned asynchronously. But if we inspect the type of the ref property, as well as the ref object, which we can pass it, there's also a ref callback. And so what this means is you can actually define a function. And this function, when passed to the ref property, is going to behave in this way. So when a dev element is, or whatever element you apply it to, is mounted by React, this callback will be called with a reference to that HTML element. And then when, for whatever reason, that element is maybe removed from the DOM, this callback will again be called but with none. Well, this is the way it works in React 18, at least. And it's very important, if you follow this approach, that you wrap this with useCallback. Or maybe when you start using Compiler, that might not be required anymore. Because any time, if you didn't use useCallback, it would be a new function, it would force a render, and then you get into this, you could get into a bit of a loop. So you remember the useCallback for this approach. So as I said, it's called when it's mounted, it's called again with null when it's unmounted, and this runs synchronously before paint. And also in version 18, it's not impacted by strict mode. So this is how we could update our code to use a ref callback. So when the ref is given to us and it is defined, we can set up our listening so that we can adjust the left position. And because it's running synchronously, that initial one, we're able to set the position before it's rendered. And then another nice thing about this approach is that we've now got rid of those renders completely. So all of the renders that we did have, where we were updating the state or having things, have gone. But the end result is we've still got this really nice, smooth browser operating, because the only code that is now running is our code from AG Grid, to work out where it needs to be, and then to set that browser style. So we've basically chopped off all the React code, which was just duplicating what we knew how to do already. Now, with React 19, nearly here, these are some changes that are actually affecting the ref callback approach.

So in version 18, you need that use callback, and also it will give you a null when the element is unmounted. But from version 19, you can actually write this in a nicer way. So if you return a cleanup function, then React won't call it with a null value. Instead, it will just run the cleanup function, so it's much closer to how we define useEffect and useLayoutEffect. So it's a really nice DX improvement. And also, it's going to be called twice in strict mode now. So it's becoming much more closer to how you would define your effects.

Now, yes, we've got time. So this is a, if we come back to useLayoutEffect and why it might be the downside to using it. It's because you have this potential issue if you're doing conditional rendering. So if an element is conditionally rendered, useLayoutEffect will still run because it's tied to the lifespan of that component. So if, in the initial rendering of this component, if the cell visible flag is set to false, that div is not going to be mounted. But our useLayoutEffect, that's still going to be run. So if at some point we then say, well, this cell should now be visible, we have to make sure that we have our dependency array matching the conditional output because we need to make sure we rerun this layout effect to be able to then access that div and do whatever code we want to do. But the complexity could come in to the fact that you might not know or be in control of the exact state variables that change the conditional rendering of this element. So this is something where useLayoutEffect isn't as easy. And if we look at our ref callback approach here, so we'll define our setRef, and notice that we don't have to worry about the dependencies of what makes that cell visible because whenever React ends up mounting this div element, it will run that setRef callback, and we can set up the code that we need to. So instead of the, I guess, the synchronization and the lifecycle being tied to the component, these ref callbacks are really nicely attached to the div element that you're actually wanting to work with. So it removes that complexity from the equation. This is something which you can read a bit more in the Dominic's blog post about avoiding useEffect with callback refs. So he's got some other examples as well of where this works nicely.

So React is fast, and especially with the compiler coming out and with Memo, that might be good enough for you. But if you want to take direct control, there are performance gains to be made. And this is something that we have done at AgGrid. And we are seeing how a ref prop can take a callback function to be giving you all the advantage that we've just outlined. But remember, with great power comes great responsibility. So make sure you only reach for these tools when you need them. Don't start sprinkling them everywhere in your code base when actually running some code in the useEffect is good enough. So use this if you need it, but don't try and be too clever.

So use this if you need it, but don't try and be too clever. And that's what refs can do for you.

Thank you. First question. What was the tool you used to monitor the number of re-renders and identifying why a re-render happened? How did you get that? So that's the React DevTools. So that's an extension that you can install from, I guess, Chrome or Firefox or other browsers are supported. But yeah, so once you've installed that extension in your DevTools, is it DevTools, console, what's the, hit F12, that's what I do. Or right-click and say Inspect. And then you'll see React in your panel and you can click the record button in there and start interacting with your app. And then when you stop the recording, the React DevTools profiler will show you all the renders that have happened.

Sounds really useful. Yeah, there's other talks, you know, that dive into that and how you can use the profiler to spot these things. Awesome. Ooh, we've got some deep technical questions. This will be fun. Did you consider using CSS variables instead of setting the style directly from JavaScript? If so, why did you go for setting the style from JS? I would be interested to find out how you would manage the difference. So, you know, how do you respond to the user doing an action and then having that applied to the cells as well? So I think there's always going to need to be some kind of JavaScript involved to update those things. And there's lots of different use cases about why you might need columns to move. It's not always just about, you know, the user doing it. We might have features where it's, like, you want to auto-size your columns. So when you start auto-sizing columns based on their contents, then you need to move other columns. So there's quite a lot of complex logic when you're adding all these different features. Let's say, like, my pinner column, everything else needs to move over. So that's why we need this in JavaScript. Yeah. Makes sense. Cool. Is it possible that React was just not the right tool for the job here? This seems like a lot of added complexity to work around the React render cycle.

Cool. Is it possible that React was just not the right tool for the job here? This seems like a lot of added complexity to work around the React render cycle. So, I mean, we do have... Azure Grid works in vanilla JavaScript. It works for all the different frameworks. It does work in React. And this is a trade-off thing.

So, you know, there was a previous version of Azure Grid where it was just vanilla JavaScript all the way through. And you could have this now. You could create a vanilla JavaScript Azure Grid inside your application. And then there is no React inside of it. But in doing that, you lose the authoring kind of DX experience of putting React components inside your grid. So for the vast majority of our users, it's more important that in React, that they can say, well, I've got a React component. Let me put this as the cell. Let me put this as the custom header. So all those kind of DX improvements kind of outweigh. And then we can work hard ourselves to make sure that the performance is as good as it can be, as opposed to having that complexity of you put a React component and you're looking at the dev tools and you don't actually see a React component tree.

Yeah, the DX improvements are quite nice. Yeah. Cool.

Question. Ooh, this one's got a lot of upvotes. What if React does re-render the component? Wouldn't you lose inline styles made with the ref? Is there a guarantee the component won't re-render? So this is where, I guess, we are working on... You are working on this, that React won't touch things that it isn't in control of or that it isn't being told to update. So yeah, this is something which we've looked into and we haven't had any issues with it yet. But, you know, that is a valid question. Okay.

This one might be answered by the compiler work you referenced. Is the use callback hook for the callback ref necessary as a React 19? I wouldn't expect it to be. Because, you know, in other places where we can define functions inline, I think that's being resolved. If I'm wrong on that, then we will need to use callback. But I think there may be other people in this room who could answer that for me. Cool. All right, more on that.

Have you tried the new React compiler to minimize re-renders? And if so, have you had any results? I've done a quick check on this. And I think it will do some improvements. But then I guess we have spent quite a lot of time, you know, doing these kind of investigations. So the code, you know, that I was demonstrating the issue, that was, that never really got released. So this was something that we, I guess, profiled before we released this React version.

Let's take a step back from these deep technical ones for a little bit. I want to ask you about your day-to-day. How much of your work is building AG grid features versus fitting it in or making it work with frameworks? That very much depends on what tasks that we're working on. So like when I was looking at React or supporting React 19, then I guess my whole day was spent on, well how do we make sure that we're compatible? So like that change where strict mode was now double calling in React 19, these ref callbacks. So that was then something which I had to validate and make sure that everything that we did in those callbacks was, we could clean it up and come back, which I think is a good thing that in the end that React has kind of patched that hole, because then it forces you to make sure you are cleaning everything up and making it all pure. But at other times, you know, at the moment, we're just working on making AG grid really tree shakable. So I've been looking at minified files. How do we, if we rename this or if we make this a standalone function, how does that impact what ends up in the bundle? So yeah, it's very much about what task we're working on.

Sounds exciting. It is good, yeah. Taking even further step back, how do you know if you need, they say it's, I'm guessing need AG grid? How do you know if you need AG grid? Well, I mean, the easiest thing is just to start using it. You know, it can give you very simply a data grid with lots of features, sorting, filtering, all things out of the box. And even if you just want it as a plain HTML table, it's a great place to start. Because so many people have started building their own table and it is very simple to start building your own table. But very quickly, the data size grows, you need to add virtualization. A feature request comes in, I want to change the order of the columns. And suddenly all these things are very expensive as a developer to do yourself. So I would say just start with that and it will grow with the complexity of your project or it will just meet your needs and you don't have to do much.

That sounds like a reasonable plan. We only have technical questions left. So two minutes of this. Do you have any advice on how to store and work with refs that need to be available on a feature or application level? On a feature application level? As in, say, passing an element to another feature? I don't know, it's hard to know without knowing what these features are. But I guess, you know, that once you've got it as a ref, you can pass it around. But I think as soon as, if you're doing that too much, that might become a bit of a spaghetti mess. So I think you want to be careful, but it would depend on exactly what you are trying to achieve. I don't know if, maybe they can come and speak to me afterwards and flesh it out a bit more. If you have some very deep technical questions, something very specific to your application architecture, perhaps talking to Stephen after this would be the right next step for you.

But speaking of spaghetti, how about using Redux to manage the state? It seems like it's quite complicated and Redux might be useful. So we have got a, I guess a vanilla JavaScript implementation of the state of Agigrid. And so that's not using any libraries. And one of the big things that we are proud of with Agigrid is that there are no external dependencies, which makes it much easier from a security purpose for people to say, well, I'm just going to use Agigrid, and we are also, we're not dependent on breaks and anything else. So yeah, so we, as a principle, we probably wouldn't introduce Redux to resolve this. Seems reasonable. I don't think we quite have enough time to answer any of the next questions. So I'm going to say, for anyone else who wants to find Stephen afterwards, this, there's a whole set of good stuff you can ask him about. Stephen, thank you again. Let's give him one more round of applause. Thank you. Thank you.