Video details

5 Years of Building React Table – Tanner Linsley, React Summit 2022


React Summit 2022 #ReactSummit #GitNation Website –
Follow the link to watch the full version of all the conference talks, QnA’s with speakers and hands-on workshop recordings →
Talk: 5 Years of Building React Table Join me as a I dive into the history of React Table and discuss everything it’s taught me (both successes and failures!) since I built the first component-based version 5 years ago. We’ll cover tons of sub-topics including, but not limited to: .... takes a breath ... Headless UI, React Hooks, Advanced TypeScript, Branding & Naming-Things, Build Pipelines, Open Source Software, API Design, React/JavaScript performance and even Framework Agnostic Tooling!
This event would not take place without the support of sponsors:
🏆 Platinum Sponsors Ag Grid → Toptal → →
WPEngine → Vodafone →
🥇 Gold Sponsors StackHawk → Bitvavo → Ionic → JetBrains → Kontent by Kentico → Decentology → Xata → Docker → Shopify → Wix Engineering → NearForm → Focus Reactive → Sanity → Snyk → Contentful → Nx →
🥈 Silver Sponsors Firebase → Callstack → Mercari → vpTech/ → NativeBase → Stream → SiteGround → Yoast → Novermber Five → Twilio → BCGDV → Fullscript → Utopia Music → SISU →


All right. I'm excited to be here. I have a lot to cover. I'm jet lagged and tired, but I 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 cheerle gets his shirt. Yeah, it was exactly the person. Perfect. I'm out. I'm sorry. That's it. All right. 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 is 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, I'm not going to do that. I'd rather talk about take it back, old school. The very first library I ever built that kind of 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. And it's just a fun talk, but we got to go all the way back even further to 2015. I was invited to co found a startup called Nozzle with some friends, and Nozzle is basically Google, but against Google, we are reverse crawling Google search results at scale time, like billions of results a day. We're measuring them and extracting out all the data and just shoving it 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 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, right? Everybody starts with the HTML Five 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 Swise Teller was able to teach us, like, have an opportunity to improve. So it was like, go as fast as we could. We're using Angular at the time, and we were using tools like Ng Grid and UI Grid, which honestly were fantastic. They were built in Angular, like for Angular. Great integration. And eventually got to use AG Grid, which is also an amazing tool. There we go. We have some AG Grid fans here, 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. We're like, Okay, let's do it. Investment time. We moved everything over to React. I'm talking everything in like three weeks. And then we got there and we're like, crap, we don't have a data grid library. And I was like, wait, a grid has a react adapter? We're like, we are saved. And guess what? We were like, 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 AG grid was not rendering using React, it was shipping with its own custom Dom manipulation engine, which explained why it was so crazy fast. Right? But in the process of shipping that crazy fast engine reacts kind of got burned a little bit. There wasn't the level of integration we were looking for. Now I'm really happy that as of today, aggrid has an integrated React render. And it's amazing. Niall from Aggrid is going to talk about it here in a few minutes. So 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. And I was able to offload a lot of stuff to React. All the rendering, the state management. I mean, we are still using this set state, but it was pretty good still. We even had smaller bundles because React was doing so much for us. And we replaced it by thinking it was just going to kind of be whatever. And React Table started to grow. People wanted tables and Reacts to work together. And so 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? Like, can I do anything with the markup? And 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. And 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 six. Come on. 137 props to do everything. They're all right there to customize every little thing about Reacts 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 dropdowns and auto completes. 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, 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. So I'm almost done writing this new version. The React core team is like, boom hooks. Seriously? It just killed everything. Like, functions as children render props. I was like, yes. This validated the exact approach I was trying to take. So I was able to take this Dinky component child as a function saying 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 like, ASAP. As soon as it was done, React Table version seven 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. 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's a process of taking all of your logic and your handlers 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 a lot more capability. Inversion of control, reusability. I think it results in higher quality code, almost in the same way that moving your state into a state machine does. So we launched version seven and it was great. It took a little bit of time for people to convince people that they had to write their own tables, but once they tasted it, they loved the power 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 of your users. I really wish I had sound for this next slide, but I'm pretty sure Paranormal Pictures would like, 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 and they're just like, give us TypeScript. And literally, I'm like, stay away. I had no idea what to do. It's a true story. It's like closing issues and hiding, locking things. It's like, stay away, right? If anybody's ever done open source, you have TypeScript coming at you. It is scary. Like, 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 that 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. Like, 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 and 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 like subliminal messaging. I started rewriting react table version eight two years ago with TypeScript and I was like, I'll have a new version out in like 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 typescripts, this is like super advanced stuff. I didn't even know how to use TypeScript, like, 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 Type script team and I just wanted to thank them publicly because they're awesome, but they all basically said, yeah, thank you. They all basically said the same thing, though. Hold on your butts, because library TypeScript is crazy. Oh, also generics, they're going to rock your world. Like they're going to make you cry and then they're going to 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 form of, like, autocomplete. Right? Everybody loves that about Vs code, whether you're a TypeScript user or not. Library generics are on another level, right? Like, look at the create column function for Reacts Table. That's ten generics and okay, let's run that through Prettier. Okay, that's actually what we're going to see, right? It's okay. We got some options on a column and I don't know if anybody noticed, but we're not even like returning. We're not even doing the implementation yet. And this is how much code we have. Imagine like, okay, there's at least 36 functions in Reacts Table and they all consume about the same amount of generics. Does anybody know how many lines of code that is? That's like 50 lines of code and it's like lines of code. It's lines of types. This was something that I had a hard time grasping with types. You'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? 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 my generics, like a can of JavaScript object. It's called Generic Maps, and I don't know why it's called Generic Maps. I think it should be called Generic Bags. But I was able to reduce the source code of React table by 70% by implementing this pattern. I'll probably have to talk more about this in like a TypeScript talk. But this was the point where I started feeling confident, I'm dangerous, and I know a little bit of generics, like, I'm feeling good. All the great things about TypeScript started coming out. All the refactoring, less bugs, better design. I was 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 in a TypeScript and just like, sleep at night because I'm not remembering dependency trees of my code. I think it's a necessity. So much more we need to talk about 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 Reactable, but it's also the future. I just want to reassure everybody right now. I promise. I love React, okay? 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 use belt. All right, come on in. I think that they deserve tables as well. I think they deserve a greater table that I could build and react. And in the time honor tradition of pushing the limit at the last moment, I decided to take React table and go Agnostic. So React Table is now called Tan Stack Table, and it's going to ship with all adapters for all the frameworks angular. Yeah. 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 these 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 of it devoted just to implementing and learning TypeScript. It was crazy. There's really only one thing left to do. Should we do it? Yeah. All right, let's do it. 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. Over the next 30 days, we're going to be converting over to Tansack 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, brand new in particular that you wouldn't expect, but AG Grid, normally Tan Stack Table. It's kind of weird saying that now. And AG Grid have been viewed as competitors it turns out that that's not really the case. They're so very different. They solve uniquely different problems with very different 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 that it was time to work together. So today I'm announcing that Aggrid is the first Tanstac 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 tools. 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 That's it.