5 Years of Building React Table
AI Generated Video Summary
React Table is a popular table library that started with HTML5 tables and transitioned to React. It faced challenges with integration and user requests, leading to the development of React Table. The introduction of the Headless UI pattern and TypeScript support improved the library's capabilities and quality. Generics and TypeScript played a significant role in reducing the code size and improving development. React Table is now going framework agnostic and partnering with AG Grid.
1. Introduction to React Table and Nozzle
I'm excited to be here. I love React and open source. Let's talk about the last five years of React Table and what I've learned. In 2015, I co-founded Nozzle, a start-up that crawls Google search results. We serve the data to SEOs and marketers. We had to deal with a lot of tables.
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.
2. Transition from HTML5 tables to Angular and React
We started with HTML5 tables and then moved to Angular. Eventually, we switched to React and faced the challenge of not having a datagrid library. Luckily, aggrid had a React adapter, which saved us. We were able to migrate and continue using aggrid, but encountered some minor issues. React made everything easy with its component-based approach.
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.
3. React Table Development and Challenges
Under the hood, aggrid was not rendering using React. It had its own custom DOM manipulation engine, which made it fast. But it lacked the integration we wanted. Now aggrid has an integrated React render. In 2017, we needed a table library and started working on React Table. It grew in popularity, but we faced numerous issues on GitHub. Users had many questions and requests, but we didn't have the options. So we added more props to React Table version 6.
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.
4. React Table Development and Downshift Integration
130. 137 props. To customize every little thing about React Table. Luckily, my friend Kent was building a new library called Downshift. It gave you the state, gave you the API, and you had to hook it up yourself. I saw this and thought it was the answer. I ripped out all the unnecessary stuff and wrote a new version. The React core team loved it and we launched it ASAP.
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.
5. React Table Version 7 and the Headless UI Pattern
React Table version 7 introduced the concept of Headless UI, which separates logic from markup and styles. This approach promotes capability, inversion of control, reusability, and higher quality code. Despite initial resistance, users eventually embraced the power of writing their own tables. React Table became widely adopted, with projects like GitHub's new beta using it under the hood while retaining their own components and styles. However, open source never truly ends, and the demand for TypeScript support presented a new challenge.
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.
6. Embracing TypeScript in React Table Development
I was scared of TypeScript in open source. I didn't know what I was doing. But libraries using TypeScript were higher quality. Eventually, I had to accept it and level up.
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.
7. Embracing TypeScript in Development
I resisted it so hard, I even bashed on it on Twitter. But I started to notice that libraries using TypeScript generally were higher quality, more than mine. Eventually, I had to accept it. It was a difficult decision because it meant slowing down to learn something new and scary. But I embraced it, full scale.
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.
8. Rewriting React Table with TypeScript
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.
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.
9. Learning TypeScript and the Power of Generics
Hold on to your butts. Library TypeScript is crazy. Generics will rock your world, make you cry, and then make you so happy. They allow you to pipe types into your system and back out to your users. The create column function for React table uses ten generics. React table has at least 36 functions, each consuming a similar amount of generics. It's like 5,000 lines of code, or rather, lines of types. This led me to the idea of using an options bag to handle a large number of arguments.
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.
10. Using Generics and TypeScript in React Table
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. I was able to reduce the source code of React Table by 70 percent by implementing this pattern. All the great things about TypeScript started coming out. It's able to take all of the things that are normally just stuck in your brain and shove them into TypeScript. It's a winning technology.
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.
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.
11. React Table Going Framework Agnostic
React Table is now called TanSeqTable and is going framework agnostic. It will ship with adapters for all frameworks, making it easier to build tables in React. The last five years have been interesting, with two years dedicated to implementing and learning TypeScript. There's one more thing left to do, but we're not connected to Wi-Fi.
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.
12. TANStack Table and AG Grid Partnership
Over the next 30 days, we're converting to TANStack Query, virtual, and Ranger. AG Grid is now a TANStack OSS partner. We'll educate everyone on building better tables and when to use each tool. Shifting to the headless paradigm in React Table felt weird at first, but it's how it should be. You can ask Tanner questions at Slido.com.
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.
So, if you have any questions for Tanner, you can do so at Slido.com.
13. Accepting TypeScript and Overcoming Challenges
When I started learning TypeScript, it took me around six months to fully accept it and not feel slowed down by it. At the beginning, I didn't see the benefits and it felt like a delayed release capsule. But after about two weeks, I started to see the light and it just kept getting better. However, there are still frustrations and challenges, like the 'no overload matches this call' error.
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.
React Table Journey Q&A
The best aha moment in my React table journey was Headless UI. Convincing a team to switch to TypeScript can be done through a pair programming session. Staying sane while doing open source work involves finding distractions. To benefit from TypeScript without a network, reading the documentation and digging into source code can be helpful.
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.
Learning Advanced TypeScript and Q&A
You don't need to learn advanced TypeScript unless you write a library. The documentation in the handbook is usually sufficient. When there's an error, you can easily find solutions by searching the error code. However, type assignment errors can be challenging. That's all the time we have for Q&A.
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.