5 Years of Building React Table

Rate this content
Bookmark

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!

24 min
17 Jun, 2022

Comments

Sign in or register to post your comment.

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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.

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.

10. Using Generics and TypeScript in React Table

Short description:

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.

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.

11. React Table Going Framework Agnostic

Short description:

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

Short description:

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.

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.

13. Accepting TypeScript and Overcoming Challenges

Short description:

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.

QnA

React Table Journey Q&A

Short description:

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 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.

Learning Advanced TypeScript and Q&A

Short description:

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
JSNation 2022JSNation 2022
28 min
Full Stack Documentation
Interactive web-based tutorials have become a staple of front end frameworks, and it's easy to see why — developers love being able to try out new tools without the hassle of installing packages or cloning repos.But in the age of full stack meta-frameworks like Next, Remix and SvelteKit, these tutorials only go so far. In this talk, we'll look at how we on the Svelte team are using cutting edge web technology to rethink how we teach each other the tools of our trade.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Featured WorkshopFree
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn