Kent C Dodds: 0:00 Hey, everyone. My name is Kent C Dodds. I'm super excited to be joined by my friend Ben Ilegbodu. Super jazzed, Utah Jazzed to be joined with my friend here. He just loves the Jazz, so I like to put that in there. Ben and I have known each other for...I don't remember when we first met. I think it was maybe at React Conference, React Rally. I'm not sure.

Ben Ilegbodu: 0:27 Likely. Maybe even before that. It was the conference that was in New Orleans.

Kent: 0:34 Yeah, yeah, yeah. Which one?

Ben: 0:36 JazzCon? Was that?

Kent: 0:39 No. You know what? I've never been to a conference in New Orleans, but I do feel like there was....

Ben: 0:44 It's the same people, but it was in Atlanta.

Kent: 0:47 Yeah, yeah, yeah. Connect.Tech.

Ben: 0:49 Connect.Tech, there you go.

Kent: 0:51 That's right.

Ben: 0:51 That was it.

Kent: 0:52 That's been four years or something like that or maybe longer. It's been a good time. I've enjoyed following you on Twitter and seeing you.

Ben: 1:01 Likewise.

Kent: 1:01 Actually, so you post tech stuff, but I enjoy watching the snippets of basketball plays and stuff.

Ben: 1:09 OK. Cool.

Kent: 1:10 That's fun. Anyway, why don't you introduce yourself to us? Then we can get talking about how great the Utah Jazz are.

Ben: 1:20 Not that part. Anyway, my name is Ben Ilegbodu. The reason why Kent is talking about the Utah Jazz is that I'm originally from Houston, so I'm a Houston Rockets fan. I detest the Utah Jazz. It's been 23 years. I went back 1997.

1:38 Western Conference Finals, John Stockton hits this shot to take us out of the Finals to play the Bulls. The Utah Jazz, apparently you all call it "The Shot." I have other choice of words for what it was. Anyway, not a Jazz fan, but Kent and other folks from Utah love to give me flack about that. Anyway, love basketball.

Kent: 2:05 Actually, I don't follow basketball at all. I don't know who's on the team or anything.

Ben: 2:09 Good to know.

Kent: 2:10 I watched Tyler McGinnis poke fun at you and so I take my poke there too.

Ben: 2:18 Yeah, you joined in. It's OK. I love that the last couple of years, the Rockets have knocked the Jazz out of the Playoffs. It'll never replace the original, but it does make me a little happy. I am a Principal Frontend Engineer at Stitch Fix.

2:38 I joined, it's almost a year. It'll be a year in October. I work on our frontend platform team, our burgeoning frontend platform team.

2:49 My responsibility is to help all of the other teams who are focused on building their applications, help them level up their experience with React, make it easier for them to build their React applications, and just enable people to know more about React and the nitty-gritty detail, so that when they are building their apps, they feel more confident that they're doing the right thing.

Kent: 3:15 Do you build tools and things for them, so they don't have to worry about infrastructure-related stuff?

Ben: 3:24 Yeah, there's two aspects of what I do. One aspect is the typical UI frontend. That's our design system. That's one half. The other half is the tooling aspect of it, so configuring Webpack, or Babel, or Jest, or Prettier, or ESLint.

3:45 All of those things that enable you to build a React app, if you don't have create-react-app, for instance, which we are not able to use at this point. All of those things, all of those toolings are both sides of what I work on.

Kent: 4:04 That's precisely what I did at PayPal before I left. I worked on PayPal scripts and pp-react. In retrospect, pp-react is probably not a great name.

Ben: 4:17 Yeah. Also, like...

Kent: 4:21 I didn't want to have to type PayPal React every time I imported, but yeah.

Ben: 4:25 Got you.

Kent: 4:28 That stuff was huge impact to the company. They tell me this now, like everybody at PayPal is using these tools and it's just enormous velocity improvement. Has that been your experience?

Ben: 4:48 Yeah, exactly. Now, we are building, I guess what would be PayPal scripts right now. A first version of it, because every team is configuring their Webpack, their Babel, they're all doing it differently, but not with a real purpose. It's just, "Snapshot in time. This is how you did it."

5:12 It makes it difficult for us, if we're trying to update or add a new improvement to stuff. Everyone's different, so it may break this configuration versus that configuration. We were trying, "Oh, let's keep all the configurations the same," but then there's drift and things.

5:31 Now, first pass what we're doing is we're building a shared configuration library, essentially. One, JavaScript library or NPM package that you import. That's versioned, of course. Then all of your configs inherit from those, from our configs, basically. In general, all of your configs are going to be empty, extends, whatever. That part is nice.

5:58 Ideally, we'll get to the point where we'll have a CLI similar to PayPal-scripts or react-scripts, so that you can run command lines. You don't even have to maintain a config at all. This is the first pass to get towards there.

Kent: 6:14 That's a good call, because it takes some time to get those scripts working. If you can get the configs in place first, then people migrating...Here's the really cool thing, is once you get your CLI, then you can add ESLint, Prettier, and Webpack as dependencies of your CLI. Now people add it.

6:33 That git diff in the package.json is so great. It's like, there go all those Babel plugins and all the ESLint config. It's all gone and just this one little line of added this new dependency. It's so awesome.

Ben: 6:45 Exactly. That's where my passion has been lately, is in this tooling space. I actually built my own CLI. I call it the benmvp-cli.

Kent: 6:56 Nice.

Ben: 6:57 It's because I found myself, similar to your kcd-scripts, I think is what it's called, I found myself building all these different libraries. Same thing, having to upgrade. I never go back to fix the other ones. My first library, I wrote it in ES5, because ES6 was just coming along. There was no Babel and everything. To go back and to do all that stuff is a pain.

7:23 Creating my own library of sorts in TypeScript to do all these things was a huge learning. The way that I end up learning how Babel works, how Webpack works, ESLint, is struggling. Then not being able to figure out how it works. Then finally getting to it, and I'm like, "OK, now I know these little pieces."

7:44 All of those tools, like Jest and the ESLint, they assume that they're running in the host app, not in a library that does the app, that is doing it for you on your behalf. They don't all have node APIs that you can use. It was fun.

Kent: 8:04 Very interesting.

Ben: 8:05 Lots of learning there.

Kent: 8:06 Fascinating stuff. I learned a lot from react-scripts, create-react-app stuff, patterned lots of PayPal-scripts after what they did. It's brilliant. Once you have it in place, then upgrading all the dependencies. Every couple weeks, I'll upgrade all the dependencies of kcd-scripts.

8:27 Then when I come into a project that hasn't been updated in a while, I'll just update the version of kcd-scripts, and I'm done. It's so easy.

Ben: 8:35 What's great about react-scripts, specifically, is they went from Webpack 2 to 3, I believe, at one point, or 3 to 4. One major version of Webpack. They ended up being a patch of react-scripts, because it was just a bump and now you've got all this greatness and all this improvement of Webpack.

8:55 They figured out all the hard work of Webpack and upgrading the major version, it became a minor, or a patch, even, for us.

Kent: 9:01 It's amazing. It really is. All of a sudden, your app is faster, or you build is faster.

Ben: 9:06 Exactly. The build times was great.

Kent: 9:09 Fantastic stuff, man. Would you say that you're currently like most excited about the tooling and design systems, that's your corner of React that you're excited about right now?

Ben: 9:22 Yeah. It's been a while since I've actually built apps and such. I'll join teams and help them build little features here and there, but most of mine is enabling others to be awesome themselves. The tooling side, as well as the design-system side. That's really key, too. That is also a multiplier.

9:43 That the team doesn't have to rebuild a modal or rebuild even a button, all of that stuff is on brand. It's configured to look like Stitch Fix, but they don't have to worry about it. They have to go to the docs, configure it, and then there you go. They built it. It's been great.

Kent: 10:03 Are you building on top of existing abstractions for the modal and stuff like that? Are you wrapping things, or are you building everything from scratch?

Ben: 10:10 Depends. For the modal, yes, because that one is complicated from an accessibility standpoint, so you have to trap...

Kent: 10:19 What are you using?

Ben: 10:20 We're using Airbnb's modal, I believe. I believe so. We have to trap focus. If you're tabbing, you can't tab underneath the modal, for instance. It has to select the defaults, interactive element by default, and all these different things in order to support it. Clicking behind so it dismisses. There's a lot that people don't realize goes into a modal to make it correct, at least.

Kent: 10:47 Thank you, Web platform.

Ben: 10:49 We didn't rebuild all that, but other things, yeah, we built from scratch. It actually is built on top of our style system, which is a Sass mixin layer, because before the component existed, before I got there, everything was in Sass. Still is, but everything was in Sass, so they needed the ability outside of React to also make things look according to design.

11:17 The teams would write a button tag themselves in Rails, or sometimes in React, but then write the CSS to call a mixin themselves. That's the really nice thing, is that the design system, for the most part, is a UI-only abstraction. Something else handles the styling itself.

11:39 Which really got me thinking about, "What is a component library itself? Could I build a component library builder?" There's like some fundamental...Everybody's building these things. They all have a button, they all have a modal, they all have a text input, but they all want it to look different, really. That's what the difference is.

12:02 Could I build something that looks like wireframes from a look and feel, so that you could jump in and make it look the way you really want it to look, but it has all the functionality yourself so that you don't have to do that yourself? Like a starter kit or something for a component like that.

12:20 That's something I've been noodling around. Haven't had the time to do it. It's an idea that I have.

Kent: 12:27 It's definitely a shared problem. When you find shared problems, you're normally looking at a library, or some tool.

Ben: 12:33 Yeah. My idea is that it's like a starter kit. Not something that you would continuously update. It's something that kicks you off so that you can hit the ground running and have a design system up in two weeks that has a lot of components, instead of waiting two months to really get it to be something that lots of teams can use.

Kent: 12:57 Our design system, or at least the library that implemented the design system that I started as I was leaving, it took a lot of meetings and things trying to figure out how we wanted to approach it. At first, I was like, "We're only going to build this with React. Who cares about whatever else? Everybody's moving to React, to PayPal." I got a hard, "No," on that one.

13:30 One of the biggest impetuses, or the reason that decided I wanted to solve this problem, was because I looked at our apps that I was supporting. We had 90 percent unused CSS, even after you click around and open modals and stuff.

Ben: 13:47 Wow.

Kent: 13:48 The reason this happens is because you write the CSS, and nobody wants to touch it, so they make a new version. I was like, "We've got to be able to have some way to like when you bring in the design system, library, you don't bring in everything, just the stuff that you're bringing in."

14:08 We figured out a way to make it so that we could modularize our CSS as files, like, "Here's the button file, we'll just import that one." That way, people who are doing it the old way can just bring in all the CSS. That's the life you live if you're not using a component-based library. Then all the new folks can just import the stuff that they care about, and it works out pretty nicely.

Ben: 14:36 Exactly. My plan with the design system is that teams don't have to write CSS. Unless they're doing something crazy special or whatever, it's like they can build their whole UI, layouts, and everything, just with the component library. That's what I consider a success. We're getting there.

Kent: 14:55 I'm impressed by the stuff that Mark Dagleish has been doing at SEEK. He's got a lot of interesting ideas there.

Ben: 15:03 I borrowed an idea from him from one of his talks. It's the idea of a stack component or an inline component that's for the horizontal. The stack component just lets you separate things inside of the component by an equal number of spacing. That happens all the time, where it's like, "I need one rim in between these four different things," so, right there.

Kent: 15:28 Not one above or one below.

Ben: 15:30 Not one above, not one below. You end up writing interesting CSS selectors to solve that and things like that. I have a component that does that, and you can build layouts that way. The same thing for the horizontal direction. Just using those two components, people can build layouts that look appropriate, evenly spaced, and things like that.

Kent: 15:53 Consistent throughout the app. You limit their choices to improve consistency.

Ben: 15:58 Exactly. Just those little things. Those two components have been huge, and something that I've never thought about in a component library. I've always thought about the interactive or the visual, but this is something new.

Kent: 16:11 Like layout components. It's really interesting. I initially started with the opinion that we're going to build our component library with CSS and JS with Emotion, and we'll just export Emotion-styled component things.

16:28 Then I eventually decided, "No, actually, it's better to have your component library be regular CSS, or, really it doesn't matter too much, but if you use regular CSS, then you can have a lot more flexibility, and other people can use it."

16:46 Then for app code, I just say, "Hopefully, you don't need one-offs, but if you do, I suggest regular CSS, or CSS and JS, because you can mesh these together in a nice way." CSS and JS gives you determinism and stuff.

Ben: 17:04 Exactly. Same with our component library. It's written in Sass, but it's exported in CSS. I actually compiled the Sass down to CSS. We have one side of the organization that uses CSS and JS, and we have another side of the organization that uses Sass, so I want both of them to be able to use the component library.

17:30 They're all using Webpack. Webpack can always compile CSS, or you import CSS, so now everybody has the opportunity to use it. It means way more work for me, figuring out all those build tools, but then far less work for everybody else.

Kent: 17:47 That's the whole thing. That's actually the interesting thing about when you get to a scale where people can specialize. That's where the total becomes more than some of the parts.

17:59 When you can say, "You focus on building the product and putting these pieces together, and I'll focus on building the pieces that you're going to use and together we can do much more than if we were both focusing on the product or both focusing on the pieces."

Ben: 18:13 Exactly. That's what's happening. It's the same thing in design as well. I know for a while designers have really balked at the idea of a design system for them, because they don't feel like they have the freedom to come up with whatever is best...

Kent: 18:31 Expressive R.

Ben: 18:31 for that thing. Now, if they have the components in the design library to use, they can focus on solving the user experience problem for the actual page, instead of having to literally make a rectangle to create a button. That's just completely a waste of time. Just being able to drop stuff is great.

Kent: 18:53 Totally. Are your designers using Sketch, or Figma, or what are they all using?

Ben: 19:01 We're using Figma. The counterparts to me in design on the design platform team, maintain a Figma library of components. Most of them I've built in React, some of them not. Then now through, they're not called symbols, that's in Sketch, but there's some kind of concept of, "Now in a team's actual Figma mock-up, they can reference back to that component."

19:33 If they go in and change the source component, it'll change in their designs, which is really nice. I can double-click or go to the source component from a design. It's really cool how Figma is set up that way.

Kent: 19:49 That's amazing.

Ben: 19:50 They're able to see what component it actually is and reference that back to the component library.

Kent: 19:56 Nice. The design team exports all of their designs and hands this off to you and then you go and implement that in CSS as well as the interactive parts?

Ben: 20:07 Yeah, the design library. I can just see it and then go and figure that stuff out. That's one of my keys that I've been really harping on when I'm talking about design systems.

20:20 One, a design system isn't a physical thing. It's an idea, a concept, brand guidelines. Then the design team creates a design library in Figma or Sketch. What I always harp on is that the JavaScript component library, React in my case, has to come after the design library.

20:42 Don't build anything that's not in the design library, because that means that the design team hasn't agreed to whatever's in your component library if you're just building abstractions out of what you see.

20:56 There's been too many times that I've done that in the past, where I'm like, "This is kind of the same. Let me create some props to abstract that out, and bam, great. Now the developers don't have to worry about it."

21:08 Then the designer comes and creates something slightly different and they're like, "We didn't agree to this abstraction that you just created in the source," and then there's friction and all that. As long as it's in the design library, that means the designers have agreed to that, and they'll create designs in that system.

21:27 If they choose to create something outside of it, then they're telling the developer, "I want you to build something from scratch. I want you to spend two weeks instead of two hours. That is what I am saying." There's more clarity around that.

Kent: 21:42 Absolutely. You also are doing teaching publicly, but internally as well. First, tell me about your internal stuff. What do you do? It sounds like your job is developer velocity and productivity. You've got the tooling, you've got design systems, and then I'm guessing that you're doing construction of some kind too.

Ben: 22:07 Yeah, it happens at a macro level and a micro level. At a micro level, I rotate between teams, like one team a month, for a month, and I'm just on their team. I'm going to the standups, going to all of the sprint plannings, everything, engaged in it, so that I can understand what's going on.

22:29 Then I'm involved and we pair on things to solve problems. I code review things and that gives me the opportunity to, one, learn what they're doing so that the design system can be better and the tooling can be better, but then also try to impart my knowledge in certain cases when I give a review.

22:47 Like, "You know what, when you use useState and the new value is dependent on the previous value, you should use an updater function instead of not using one." I can give reviews on that because I'm getting included in that, and link to the docs that say it, and then hopefully, learning happens that way.

23:09 That's one half of it on the micro side. Then on the macro side, I do what are called React Code Clinics. The code clinic is once a month or so. We'll pick a topic and we'll just discuss that. I've done one on useState, the hook, and one on useEffect, and I'll do the next one on useContext.

23:36 We'll go through it and I'll have some instruction or live coding that I do examples, similar to what I do in my workshops, and then there are exercises to do to apply what they've learned.

Kent: 23:51 That's cool.

Ben: 23:52 Both aspects of it.

Kent: 23:54 Then, outside of your company, you have these "minishops." Where'd the minishop idea come from? Why are they mini?

Ben: 24:04 I'm coming into the space. I know I wanted to teach, I wanted to try doing it on my own as opposed to working through a conference or whatever, "Let's see how I could do it." I'm in the space, you're in this space, Tyler's in this space, and there are a lot of people doing workshops. It was like, "How can I differentiate myself?"

24:25 Most of the workshops are five hours, seven hours, full days, and stuff like that. I know for myself going into workshops, that sometimes after lunch...I'm much better before lunch than after lunch. Let's just say that, "Let me target that, whoever those groups of people are." That's the mini part. It's, "Get enough understanding to pique your interest, to be able to start doing stuff."

24:56 Once you know that part, then I think now blog posts, and documentation, and YouTube videos, you'll be able to understand those better because you have that baseline. I call them minishops because I wanted to brand something.

Kent: 25:10 It's great.

Ben: 25:11 Now when you Google "minishops," hopefully you'll start finding my things.

Kent: 25:18 What are some of the things that you teach in the minishops?

Ben: 25:21 I've got four right now. The most popular one is "TypeScript for React Developers."

Kent: 25:28 That makes sense.

Ben: 25:29 I recently learned TypeScript about a year ago in React. I teach TypeScript, but specifically geared towards React. I don't teach the totality of TypeScript because it's pretty complicated. It's really awesome, too.

Kent: 25:44 That'd be many minishops.

Ben: 25:45 Yes, exactly. That's one of them. That goes really well. There's a typical intro to React, but using hooks now, obviously. I'll say that if the React team needed any indication that hooks were better than classes, is that teaching React with hooks is way easier than teaching it with class components. Way easy.

Kent: 26:11 Amen, brother.

Ben: 26:12 I don't know what, but people get it a lot quicker. It's much easier to explain. It's awesome. That's one. Then another one that actually came out of my time with Stitch Fix is, "Migrating to React Hooks from Class Components."

26:33 We have a lot of people who learned React with class components, they're like, "This hooks thing, I'm not forced to use it right now. Should I use it? What is this all about? It's kind of scary." I don't know, people have a sense of apprehension around it.

26:49 Teaching that, showing, "This is how useState works versus setState. This is how componentDidMount, Update, Unmount works versus useEffect." Those sorts of things.

Kent: 27:03 Yeah...

Ben: 27:03 The last one...Oh, go ahead.

Kent: 27:05 I was just going to say, "You just said how much easier it is to teach hooks than classes and I totally agree." I've also observed that people who learn classes first have a harder time learning hooks...

Ben: 27:19 Exactly.

Kent: 27:20 because they have to unlearn a bunch of class things.

Ben: 27:23 Exactly. That's exactly it. That's what a lot of the minishop is about. It's unlearning those and learning this. It's funny that new people learning React pick it up so much easier than those moving over.

Kent: 27:38 If anybody's listening and they're like, "Should I learn classes?" Don't. Don't learn classes. Just learn hooks first, get comfortable with that, and then learn classes on an as-needed basis. There's not much call for all that.

Ben: 27:49 Likely, your code bases you're going to see classes in there and such, so you're going to want to know how they work, but learn hooks. Then the last one. It's a new one that I haven't done yet, is, "Sharing in React Components."

28:09 This is something that's come out of my design-system work. It's basically around learning render props, composable components, and HOCs, all of that stuff. You have multiple components that want to do the same logic, but they want to look differently. What are the different patterns you can use in order to solve that problem?

Kent: 28:37 Awesome. The minishops are like three hours long, is that the...?

Ben: 28:40 Yeah, they're three hours long. They're in the morning for myself on the West Coast, so like 9:00 to 12:00 is usually when they are. The advantage is that people in Europe, like in the London, France time zones, can also come because it's like 7:00 PM to 10:00 or 6:00 PM to 9:00 for them. It works for them as well.

Kent: 29:04 Pretty reasonable for them. Sweet.

Ben: 29:09 You go to my website. I'm going to give the plug, since we're talking about it.

Kent: 29:13 Do it.

Ben: 29:13 My website, Benmvp.com. You'll see the minishops there. I don't know when this is going to show, but I'll be scheduling the next winter series coming up soon. Check it out.

Kent: 29:28 Cool. This will launch with the Epic React at the end of September.

Ben: 29:34 Perfect.

Kent: 29:35 People who are watching this, as soon as it launched, will see that. I'm sure that your minishops are not going to be over in the winter, too.

Ben: 29:44 Yeah, that's the plan.

Kent: 29:45 That's great stuff.

Ben: 29:46 I wrote this blog post, it was, "The Best Way to Learn React." It was totally a clickbait title. What it boils down to is that people do learn differently. Some people learn short-bursts workshops, live workshops, some people learn watching videos, self-paced. People learn in different ways. Some people learn reading tutorials and blog posts or books, that's how I learn best, actually.

30:19 It's great that we have all these different ways for people to learn. Just because you're doing Epic React development, which is awesome and epic, doesn't mean that that's it, no one else should do anything around learning, because not everybody learns the same way.

Kent: 30:39 Absolutely.

Ben: 30:41 Also, it's encouraging people to write blog posts about React as well, or to do a little video, even though the content already exists, because the way you present it, the medium that it's in is a way that somebody could learn.

Kent: 30:57 Totally. I'm super in agreement with that. This is actually what I recommend as a learning pattern is you consume information, then you go and build something, and then you teach the things that you learned when you built it. That's how you learn.

Ben: 31:15 Definitely. There'll be times I'll be in a workshop, and someone will say...Actually, someone asked me this question. I was talking about useState, and how it has a lazy initialization, so that you don't do something every time useState is called.

31:33 Someone was like, "Could that be async?" I was, "Huh, I never really thought about that. I don't think so, but you know, now I have to go and investigate and see." I get opportunities to learn even more, even though I'm the instructor. People have all sorts of questions, and we can learn right there, "Let's see, let's try it, and see what happens." It's great.

Kent: 31:55 Yeah. It's one thing to try it and find out that doesn't work, but then it's another because you're the teacher, you want to be able to explain why, so, then you have to dive in deeper and that's a thing that you miss from just building stuff.

32:10 If you just consume and then just build, then you find all the things that don't work, but you don't know why they don't work. You have to go and force yourself to teach it, because that puts you in the teachers mindset of, "Well, I need to be able to explain why this is the way it is."

Ben: 32:22 Yeah, because someone's going to ask, "Why?"

Kent: 32:25 Exactly. Ben, it's been awesome to chat with you. We talked about the tooling stuff you're doing, design systems, the teaching, minishops and stuff. Is there anything else that we didn't talk about that you wanted to bring up?

Ben: 32:39 Let's see. That's basically it. We could talk more about the Houston Rockets, instead of the Utah Jazz, if you really want to.

Kent: 32:50 I wouldn't have anything useful to say.

Ben: 32:54 That's a lot of the things that I've been really interested in and really passionate about. It's been a great chat as well.

Kent: 33:03 Anyway, thanks so much, Ben and we'll see you all...Oh, quick, what's the best way for people to follow you to keep up with what you're working on?

Ben: 33:11 Oh, yeah. Twitter is definitely the best place. My Twitter account also @benmvp. You can find me there. I like to tweet out my blog post, obviously, minishops that are happening, retweeting a lot of the things Kent says, all the different stuff that I found people talking about, RBT, as well as basketball.

33:32 You have to at least be willing to accept seeing some tweets about non-coding things. That's the best place and then also my website, benmvp.com is a great place to check out all the content that I am generating. Those two places.

Kent: 33:49 Cool, man. Hey, thanks so much. It's always a pleasure and good luck with the wildfires and all that stuff.

Ben: 33:55 Thank you, appreciate it.

Kent: 33:56 See you all later.

Ben: 33:59 Bye, guys.