5 Years of Building React Table

All right. I'm excited to be here. I have a lot to cover. I'm jet lagged and tired, but I've got to bring the energy, so help me out. We got to bring the energy, okay? I have some T-shirts I got to throw out really quick and some people who are going to help me. So let's just get to it. Here, take that one too. Anybody want a T-shirt? Over here! Okay, the loudest cheerer gets the shirt. Yeah! It was exactly the person! Perfect! I'm out. I'm sorry.

Alright, I hope you like Jurassic Park. You might not by the end of my talk because, I don't know, you'll see. My name's Tanner Lindsley and I'm here because I love React and I love open source and I'm kind of addicted to it. It's a bad addiction but it's a lot of fun. Normally I'd be talking about React Query today. Not going to do that. I'd rather talk about Take It Back Old School, the very first library I ever built that kind and it took off and now it's React Table. I want to talk about the last five years of React Table and some things that I've learned through this crazy process of building an open source library and maybe you can apply some of it to what you do, or maybe not. It's just a fun talk. But we've got to go all the way back even further to 2015.

I was invited to co-found a start-up called Nozzle with some friends. And Nozzle is basically Google but against Google. We are reverse crawling Google search results at scale. We're talking like billions of results a day. We're measuring them and extracting out all the data and just shutting that into BigQuery, believe it or not, and serving it back to SEOs and marketers who want that data. It's pretty cool. Part of that product is that we have to do a lot of data visualization, a lot of querying, and of course a lot of tables. It's kind of coming together now. I wish our tables in 2015 looked like this. They did not.

We were working with a little bit lesser tech here. Not quite like this, but this is where it all starts. Everybody starts with the HTML5 table because it's awesome. It really is a great element. Try building a table with divs and you'll appreciate it.

We needed to ship and sell and just hopefully like Sweizek Teller was able to teach us, have an opportunity to improve. So it was like go, go, go as fast as we could. We were using Angular at the time. Booo. And we were using tools like ngGrid and uigrid, which honestly were fantastic. They were built in Angular, like for Angular, great integration, and eventually got to use aggrid, which is also an amazing tool. There we go, we have some aggrid fans.

So something happened we weren't expecting. This framework shows up out of nowhere, and it's like, this is it. This is where you need to be. And we're like, OK, let's do it. Investment time. We moved everything over to React. I'm talking like everything, in like three weeks. And then we got there and we're like, crap. We don't have a datagrid library. And I was like, wait, wait, wait, wait. aggrid has a React adapter. We're like, we are saved. And guess what? We were. We were able to migrate and just keep using aggrid, and it was honestly super cool. But we did run into some little issues here and there. We were working with a React component. It's just React. Everything's just components.

But something was interesting. Under the hood, we noticed aggrid was not rendering using React. It was shipping with its own custom DOM manipulation engine, which explained why it was so crazy fast. But in the process of shipping that crazy fast engine, React kind of got burned a little bit. There wasn't the level of integration we were looking for. I'm really happy that as of today, aggrid has an integrated React render. It's amazing. Niall from aggrid will talk about it in a few minutes. Stick around if you want to hear about that.

This is way back in 2017. That did not exist yet and we needed a table library immediately. Obviously, I started working on React table. It was a single component. It was 100% React. I was able to offload a lot of stuff to React. We had to do all the rendering, the state management. We were still using this.set state, but it was pretty good still. We even had smaller bundles because React was doing so much for us.

We released it thinking it was going to be whatever. React table started to grow. People wanted tables and React to work together. While we were loving the success that we were having over on the NPM downloads chart, a storm was brewing on the GitHub repo in the form of just issues. Tons of issues. We were getting inundated with issues, and they all looked like this. Can I move pagination? Give me custom props? Can I use my own row component? Can I use whatever CSS and JS library is out this week? Can I do anything with the markup? The reality is that I couldn't answer any of those questions. I didn't have the options to do that. Honestly, it was just this huge pile of crap. It was terrible. I did the only thing that I knew how to do, and that's add more props. Any guesses how many props I added to React Table version 6? Five.

Come on! 130. 137 props. To do everything. They're all right there. To customize every little thing about React Table because it was just a single component.

I was drowning. I honestly was drowning. Luckily, I didn't die. But, thankfully, while I was drowning in my misery, my friend Kent was over building a new library called Downshift.

Downshift was a library for building drop-downs and autocompletes. But it was really interesting. It didn't render any markup for you. It just gave you the state, gave you the API, and you had to hook it up yourself. I saw this and I was like, this is the answer. This is how I'm going to solve this problem. Immediately, I dove into React table source code. I was like, rip out all this stuff, we're going to go with this API approach, invert control to the user to render everything themselves.

Some people were like, you're going to make me render my own table? I'm like, yeah, I am. Because it's going to help. Just believe in me. I promise. I'm almost done writing this new version. The React core team was like, boom, hooked. Seriously, it just killed everything, functions as children, render props. I was like, yes. It validated the exact approach I was trying to take. So I was able to take this dinky component as children as a function thing and turn it into this awesome use table hook where you could just return whatever markup you wanted. It was fantastic. And we launched it. I launched it ASAP, as soon as it was done.

And the React Table version 7 was off the hook. But because of this inversion of control, I was able to close, like, 95% of the GitHub issues that we had, basically answering everybody with the same exact thing. You want to move the pagination? Do it yourself, I dare you. And I later learned that this pattern has a name. It's called Headless UI.

And Headless UI is not the tailwind product that you're thinking of. But it's conceptually, it is, you know, it's a process of taking all of your logic and everything that kind of makes up the logical parts of your application and separating them out from your markup and your styles. I think that this encourages, like, a lot more capability, inversion of control, reusability. I think it results in higher quality code. It results in the same way that moving your state into a state machine does. So, we launched Version 7, and it was great. It took a little bit of time for people to, you know, convince people that they had to write their own tables. But once they tasted it, they loved the power.

Okay. That went on for two years. And I even started to see some projects like GitHub issues the new beta is using React table under the hood to render all their tables. But they're using their own components. It's all Headless. So, they get to keep using their component library and all their styles, and everything they're used to using. I saw this, and I was just like, I made it. React table is done. Checking out. I'm going to go build React query. I basically did that. Open source has a way, though, of kind of screwing with you. You're never done with open source, and neither are your users. I really wish I had sound for this next slide, but I'm pretty sure Paramount Pictures would shut down the stream. Anyways, I'm over here enjoying my open source, and out of nowhere it's like, boom, TypeScript users come out of nowhere. They're just like, give us TypeScript, go, go, go, and I'm like, start away! I had no idea what to do. It's a true story.

I was like, closing issues, and hiding, locking things, like, stay away, right? If anybody's ever done open source, like, you have TypeScript coming at you, it is scary. If you don't know TypeScript, you're just like, I don't know what you're talking about. I'm sorry, somebody else can do the types. I'm just going to keep dinking around here. I had no idea what I was doing. But it was even scarier because I knew TypeScript was almost inevitable. It was coming for me, and at some point, I was going to have to have a reckoning.

I resisted it so hard, I even bashed on it on Twitter. We all do it. Everybody, raise your hand. We all do it. But I started to notice that libraries using TypeScript generally were higher quality, more than mine. They had less issues, and honestly, the developers working on them and using TypeScript, it was imposter syndrome. They were just rock stars. I don't know how they were doing it. Eventually, I had to accept it. It was time to level up. It was a difficult decision because it meant slowing down to learn something new and scary. But I embraced it, full scale.

TypeScript really is amazing. And I promise this is not a TypeScript talk, but maybe some literal messaging. I started rewriting React table version 8 two years ago with TypeScript and I was like, I'll have a new version out in two weeks. It'll be like an alpha, two weeks, it'll be easy. No way. I did not know what I was doing. I had jumped into the deep end and I had learned that writing libraries and TypeScript, this is like super advanced stuff. I didn't even know how to use TypeScript as an app developer yet, and I was trying to write a library. I was in over my head.

So I put the bat signal out onto Twitter, and I had some awesome people come to my rescue, offered their time, and all of their energy towards helping me learn TypeScript in all the various ways, like looking at their patterns, live calls with everybody, support through maintenance. This is my TypeScript team, and I just wanted to thank them publicly because they're awesome. But they all basically said this, yeah, thank you. Thanks. They all basically said the same thing though. Hold on to your butts. Because library TypeScript is crazy. Oh, also, generics, they're gonna rock your world. Like, they're gonna make you cry, and then they're gonna make you so happy. They're so cool.

In fact, let's talk about generics really quick. It's basically the process of taking something that would be typed statically, like a string, and giving your types variables so that you can pipe those types into your system and back out to your users. This is a really simple function, but you can also use multiple generics to extract information out of types, and provide it back to the user in the form of auto complete. Everybody loves that about VS Code, whether you're a TypeScript user or not. on another level, right? Look at the create column function for React table. That's ten generics. Let's run that through Prettier. That's actually what we're going to see. It's okay, we've got some options and a column and I don't know if anybody noticed, but we're not even returning, we're not even doing the implementation yet. This is how much code we have. There's at least 36 functions in React table and they all consume about the same amount of generics. Does anybody know how many lines of code that is? That's like 5,000 lines of code. In some lines of code, it's lines of types. This was something that I had a hard time grasping with types where we're like, why am I doing this, right? Yeah, the implementation wasn't even done. So I was pretty sad, but I had this idea. Anybody else run into this situation with JavaScript? Like holy cow, that's a lot of arguments. What do we do? You put it into an options bag. Boom. Options bag. Bagging it.

So we can do the same thing with generics. We can take all these generics, pull them out into a generic type and reuse it as a variable. This is something very new, and I haven't seen it a lot in the wild. I hope it pans out, because it's amazing.

After making this change, I was able to access all of my generics like a can of JavaScript objects. It's called generic maps, and I don't know why it's called generic maps. I think it should be called generic bags. I was able to reduce the source code of React Table by 70 percent by implementing this pattern. I'll probably have to talk more about this in a TypeScript talk. But this was the point where I started feeling confident. I was like, okay. I'm dangerous, and I know a little bit of generics. I'm feeling good.

All the great things about TypeScript started coming out. All the refactoring, less bugs, better design. It's able to take all of the things that are normally just stuck in your brain that are going to fizzle away if you walk away for two weeks from your project, shove them into TypeScript, and just like sleep at night because I'm not remembering dependency trees of my code. I think it's a necessity. There's so much more we need to talk about with TypeScript. I just can't do it. It's a winning technology. Take it from someone who was a full 180 from last year. You need to try it. You need to use it.

Not a lot of time left, but there's one more thing I want to talk about that is a little bit of a battle story with React Table, but it's also the future. I just want to reassure everybody right now. I promise, I love React. I'm here to stay. But we would all be very naive to think that React is some superior species and it's the only thing capable of producing amazing apps and UI, right? I know we love it, but we need to take it off the pedestal once in a while. There are other frameworks out there. Solid, Vue, Svelte. All right. Come on in. You know, I think that they deserve tables as well. I think they deserve a greater table that I can build in React.

And, in the time-honored tradition of pushing the limit at the last moment, I decided to take React Table and go agnostic. So, React Table is now called TanSeqTable, and it's going to ship with all adapters for all the frameworks. Angular, you want to work on the Angular adapter? Come talk to me. Okay? But it's framework agnostic. And this normally would be very difficult, but apparently, standing on the shoulders of headless UI makes it a lot easier. We're already separating out markup and styles, and that makes up a lot of the differences between a lot of our frameworks out of the gate. And it turns out we just needed a few adapters to sit in the middle, kind of wire up the internals of reactivity and context. This is the solid table adapter. That's it. And all the other adapters basically look exactly the same, even React.

So the last five years have been really interesting with Tansac Table. Two years have been devoted just to implementing and learning TypeScript. It was crazy. There's really only one thing left to do. Should we do it? All right. Let's do it. Wait. Wait. We're not even connected to Wi-Fi.

I'll do it after the talk. It's okay. There's also some other things I want to talk about really quick.

So over the next 30 days, we're going to be converting over to TANStack Query, virtual, and Ranger, and the rest of the libraries are coming soon.

I wanted to really thank everybody who's helped out with these projects, anybody virtual. There's a lot of maintainers and contributors working, especially in other frameworks, and I think that's really awesome. Also, all of my GitHub sponsors. Wouldn't have been able to do it without them.

I wanted to talk about one sponsor, it's brand new in particular, that you wouldn't expect, but AG Grid. Normally, TANStack Table, it's kind of weird saying that now, and AG Grid have been viewed as competitors. You know, it turns out that that's not really the case. They're so very different. They solve uniquely different problems with very different paradigms. Depending on your use case, you might want to use either one. Just like I at one point used AG Grid and loved it. We came to this realization and we knew it was time to work together. So today, I'm announcing that AG Grid is the first TANStack OSS partner with TANStack Table and together, we're going to work as hard as we can to educate everybody in the ecosystem, regardless of framework, how to build better tables, when to use each tool, and we're going to share as much knowledge as we can across this chasm and make sure that we can all be friends. So, you can read more about it on TANStack.com. That's it. Woo! Woo! Yeah.

Well, thanks a lot Tanner. As a user of React Table, I used it at a previous project. I have to say it was really, what you said, that shifting to the headless paradigm, it was a weird thing at first, but as soon as you get going with it, you're like, yeah, this is how it should be, right? Yeah. So, I can, yeah, I can tell everyone that's like, thinks it's weird. It was basically the same thing for me when I saw React the first time. It feels weird, right, writing your markup in JavaScript. It feels weird, but it feels so good when you start using it. Right. Yeah.

So, if you have any questions for Tanner, you can do so at Slido.com.

There's one question from Metin Persinski, sounds like a nice guy. So, when you started learning TypeScript, how long did it take for you to accept it and not feel slowed down by it? For me, it was like six months before I felt, oh, I get this. Yeah, honestly, it's like a delayed release capsule that you take, right? The beginning, you're like, ah, I'm not really feeling the benefits. I feel like around two weeks you start to see the light and it just keeps accelerating up into six months marker, you know? I'm still appreciating things I'm learning about TypeScript. Oh, for sure. And every day there's new frustrations also. No overload matches this call. Who's been there, right? Yeah, painful, right? Not a clue how to solve it, it's still like three years in.

Next question from Golub. What was the best aha moment in your React table journey? Headless UI. It's easy. Cool, covered.

Next question from GN. How would you go about convincing your team to switch to TypeScript? I don't know. Go through a pair programming session of refactoring something across like multiple files. That experience is a hundred times better with TypeScript. You can go and change one thing and it literally tells you everywhere in your app that you need to go and update. You can't keep that all in your head. Even the auto complete that becomes a lot better. There's just so many benefits. All right. But we're not a TypeScript conference. No, and this wasn't a TypeScript talk. Maybe a bit. So next question.

How did you stay sane doing open source work? That's not everything I do. I have a startup. It takes up a lot of my time too. I double dip a lot. If I can do one thing that benefits both of those, that's what I do. I have a family that distracts me enough so that I don't get too deep into like doom scrolling issues and everything. Yeah, just find distractions. So it's for the questions that we have. So any questions you have, you have to ask them right now. One coming in. I imagine that it was easy for you to find help with TypeScript. Given your contacts and public image, but how would other people that don't have your network get that benefit? First, just read through all the docs like the TypeScript documentation is amazing. And you know, I realized later that everything that my friends were helping me learn, I probably could have learned on my own if I had just dug into the source code of open source libraries and just kind of started to put it together.

Get granted like I don't think a lot of people are gonna need to learn that much advanced TypeScript unless you write a library of sorts. Like most of the time the documentation in the handbook is gonna get you basically all the way there.

What I like myself, which is for me was an eye opener when starting React, TypeScript, is that when there's an error, you get like an error code and you can copy paste it into Google and boom. So that was really easy for me. Just TS and some number and you'll find a stack overflow post explaining the same problem. Unless it's some type cannot be assigned to another type. Yeah that's painful.

Well that's all the time we have then for Q&A. If you want to continue the conversation with Tanner, you can do so at the speakers booth or on spatialjet. Tanner, thanks a lot. Yep. Sorry for ruining Jurassic Park.