Kent C. Dodds: 0:00 Hi, everyone. My name is Kent C. Dodds. I am super happy to be joined by my friend Tejas Kumar. I'm happy to chat with you, Tejas.

0:08 I don't remember when we started interacting. I'm pretty sure it was online. Then, the first time we met in person was at UtahJS. Is that right?

Tejas Kumar: 0:17 That is right. Yeah, UtahJS.

Kent: 0:20 Good, thanks. You know what? I think the first time that we interacted online was probably with Glamorous, when you wrote the codemod.

Tejas: 0:29 That's right.

Kent: 0:31 Thank you so much. For those who don't know, I recently wrote a blog post about when I deprecated Glamorous. You could go check out my blog about...

0:40 It was like how the progress over pride and open sources or something like that, where I talked about when I deprecated Glamorous, which was my most popular open source library at the time.

0:54 I deprecated it because something better was built, and I didn't see any reason in investing my time and in contributors' time into making ours basically a late version of theirs.

1:07 I deprecated it and Tejas was awesome and made a codemod to automatically migrate everybody stuff to the new thing. No, honestly, that made it.

1:19 I don't know if I'd decided to deprecate it until I realized that that could be done, so thank you for doing that. PayPal used it. It was awesome, so thank you.

1:31 Tejas, you and I also recently had a fun little thing with Docker, where you tell me how to use Docker, so thank you. People can check out my YouTube channel where we could have a recording for that.

1:43 That was awesome. I'm definitely using Docker more. It's hard to not use more than zero. I used to not use Docker. Now, I do, so thank you for that too.

1:55 Anyway, tell us about yourself, Tejas, anything that I didn't mention that you want to bring up about yourself?

Tejas: 2:02 I love code. I've been writing code since I was eight. I've been doing it pretty much ever since. It's so fun because what I used to bring me joy as a kid is now my day job.

Kent: 2:14 That's awesome.

Tejas: 2:15 That's fun. Kent, when I wrote the codemod for Glamorous, it was...The company that I was working at at the time, we had hundreds of components. All of them styled with Glamorous. When we saw the ticket or the issue about it being deprecated, we were like, "Whoa."

Kent: 2:34 Oh, no.

Tejas: 2:36 Exactly. We were like, "Oh, man. What do we do?"

Kent: 2:39 When I opened that ticket, I was like, "They're pretty similar API. Most things could be find replaceable."

2:46 I also knew about codemods, I taught people how to make codemods. I figured if it was really that painful, we could probably make a codemod and then you did, and I was so happy.

Tejas: 2:55 Yeah, that was born out of the...As much as I'd like to tell everyone just because I'm a nice guy, it was build [inaudible] for us actually needing it you know.

Kent: 3:04 Thank you for saying that, I'm sorry that I made you do that.

Tejas: 3:08 I had fun and I got so good at codemods and babble. I should be thanking you.

Kent: 3:14 That's wonderful.

Tejas: 3:14 Any excuse to build something is always a good excuse for me. I think we also met recently at React Conf in Beijing.

Kent: 3:25 Yes, good times man.

Tejas: 3:27 Yeah, it was good. Of course, with the Docker, really happy times.

Kent: 3:33 Yeah, it's been awesome. Tell us a little bit like where do you work? What do you do for your day job?

Tejas: 3:38 Yeah, I work at a company called G2i, stands for Grace to the Internet and that's literally what we want to do. We just want to help people who want jobs with React and Node, find them, and we want to help companies who want qualified engineers.

3:53 We usually match make but in a good way like we vet both sides, we vet the developers, so that for sure, they are who they say they are, and we also vet companies to make sure they fairly treat people.

4:04 It's like we're making sure everyone's going to be nice to each other kind of thing.

Kent: 4:10 That's nice.

Tejas: 4:11 Yeah, I help them with the vetting. I help automate and make the vetting process as fast as possible using all kinds of amazing cutting edge technology that I get to play with.

4:21 Really, it's kind of like I'm like a chef with an infinite pantry and I'm thankful every day that they let me do that.

Kent: 4:30 That's very cool. I especially appreciate the vetting of the company and making sure that it's a place where people are going to stay. How do you measure that? How do you make sure that these companies are a place that people want to stay?

Tejas: 4:44 Yeah, it's hard because it's not something you can put numbers to and that's the problem because process engineers, we're always like let's give them a score and there's like the Joel test and stuff, but we find that less human and a bit more binary. A lot of this comes out of conversations.

5:01 We have people, who specialize in those conversations, and the ability to discern things. Really, we do have an internal checklist that I'm not probably allowed to reveal, but we figure those things out based on conversation.

Kent: 5:16 Interesting. I think that's a wonderful goal, so thank you for doing that. That's good. Making the world a better place. I appreciate that. Cool.

5:26 Tejas, you and I have been doing React for a while. How did you get into React?

Tejas: 5:33 Dude, I got into React before I even moved. I live in Germany. I got into React when I lived in Qatar. I was 18, 19 years old at the time probably if I remember correctly. I heard about it because I was working at a branding agency at the time doing digital stuff. We were using jQuery, pretty much industry standard at the time.

5:56 One of the product managers came to me and said, "Hey, there's this new thing. It's brand new. It's called React. Do you think we should use it? Everybody's using it." I went, "It's probably just some hip new trend, whatever. It's not going to go anywhere."

6:09 Then I started looking into it. I saw JSX. It was advertised as being some type of XML super set. I remember this very clearly. XML was a big key word in JSX, JavaScript XML. I was like, "I don't like how this mixes things." The thing that made me feel averse was, "Why are you including HTML inside your JavaScript? That's weird."

Kent: 6:34 I had the same reaction.

Tejas: 6:36 I was super against it in the beginning. I think when Airbnb started adopting it was a turning point for me because I was like, "OK. If these guys are using it, then there's probably something to it." I started exploring it more. Once it became clear how React handles state and makes state predictable, that for me was the sell.

Kent: 7:03 Oh, the state-management story for React. That's interesting that you say that was the big sell for you. I think a lot of people are frustrated, like pulling their hair out, about state management in React because there are a million solutions to it. Do you think that some of these solutions are creating problems for their own solution?

7:27 Is there a reason that the React state-management thing really spoke to you?

Tejas: 7:34 The reason it spoke to me was because it was encapsulated. State wasn't global. That's why, when Redux came out with the notion of global state updated only by reducers, I didn't know how to respond to it. Global state bit me very painfully in the past.

7:55 The fact that everything was a component and the component had its own state, and the state wasn't allowed to be explicitly mutated, that for me was just a massive...It spoke to me because previously I'd just been reassigning things all over the place. I had to rely purely on scope. The clean encapsulation was what spoke to me, yeah.

Kent: 8:17 When you say "scope," are you talking about dollar-sign scope from AngularJS? Is that what you were using at the time?

Tejas: 8:23 No, I'm talking about just syntactical, lexical JavaScript scope when you have a block and your variables are defining it, because this is also around the time where constant let one to think. Nothing was block-scoped. Everything was lexically scoped. I'd assign something higher up in my app and then use maybe a plus/equals operated to increment it.

8:44 That would change the value in other places. Everything was unpredictable. React made things a lot more predictable.

Kent: 8:53 I agree. This was one of the things that really drew me into React. For me, I had been using AngularJS. For all intents and purposes, everything really is global because it goes into a global name space. You have your services or your factories or whatever. Because they have change detection, their digest cycle, and everything, mutation is an API for state updates.

9:21 I loved it because it demos really well. You're like, "Look. I just have this little bit of code. Then that's all." It's so easy to do it that way. It's easy, but is it simple? That's what really won me over for React.

9:36 Is there anything else about React that really spoke to you? The fact is that, when I saw React, I was like, "Well, but does it handle HTTP?"

9:49 Does it handle all these other things that I was getting from my framework or choice? It didn't really do any of that. That was my knee-jerk reaction. Did you have any similar feelings?

Tejas: 10:00 I thought React was really minimal because I had also used Angular at the time. Angular is this full-fledged beast. You have literally everything you could imagine, including templating I think.

10:12 The state management was definitely a big sell for me. The biggest sell, for sure, is the fact that they've, face looks particularly, has nailed the level of abstraction on React.

10:26 They don't give you too much. They don't give you too little. I'm not on the team so I can't say it was meant to be this, but it seems like it was made to be like the logo represents an atom that combines together to form molecules and then organs and so on. Organs? Not organs. That's cells.

10:49 You get the idea. A lot of people would complain like, "Hey, where's my router?" This was a big complaint. "Where's the router? Angular has a router. What's going on?"

10:59 I think by intentionally leaving off and focusing on the one problem, they've done an incredible job of staying at that sweet spot of abstraction.

Kent: 11:09 I agree with that. The drawback to that, of course, means that those things do need to exist. That leaves it up to the community. What do you think the tradeoffs are that React made by saying, "We're just going to do this one thing. We'll do it super well. We'll just leave it to the rest of you all to figure out the rest"?

Tejas: 11:38 Criticism was one of the negative tradeoffs. A lot of people would be, "Hey, this isn't a complete thing." I've seen a lot of that where people literally will use Angular. I've seen this more in the enterprise world. People tend to use Angular because they get everything out of the box. What they don't consider oftentimes is the bundle size.

11:57 Especially, I've heard a lot of teams say, "Oh, we only use this internally anyway, so we don't care about bundle size." That doesn't make any sense because at some point it's going to max out. Your internal staff's going to be annoyed at the bundle size or at the load time.

12:11 One tradeoff is people will see it as an incomplete solution. Outside of that, I don't really see a negative.

12:20 What has happened is, because they've focused on solving one problem and solving it well, they've spawned the community they have today. The reason you're as well-known as you are is in a large part because they've left things off.

12:37 Same for me. I've spoken at conferences. I've made a lot of friends literally because the React team has said, "We're not going to do a router or a data-fetching in particular, things like that.

12:49 I think there's lots of positives. Really, I don't see any negatives from leaving stuff off except criticism. You're going to get criticized one way or another.

Kent: 12:59 For me, the beauty of it is that they are just so laser-focused on making their layer of abstraction so solid. It's not like they ignore the need of everything else. They provide all of the things that those other things would need. They give a declarative API for those things, which can then turn around and give a declarative API to everyone else.

13:32 It's interesting the hubris of, "We're going to be everything for everyone where we'll solve all of the problems." That means that only the engineers who work on that specific problem. Even if you accept contributions from the community, "No, we accept work from..." No, you're still going through PRs. It has to be filtered through the ideas of the core team.

14:01 There is a level of hubris that is like, "We're just going to be everything for everyone," whereas React is like, "We're going to fill this in. We'll give you a really solid idea." Then everybody can work through things, have their own ideas. They don't need to go through some sort of filter to get it into Core or whatever. They try their experiments. Then the cream rises to the top.

14:25 Then people can contribute to those different things, allowing for multiple solutions for different types of tradeoffs. I realize that not everybody who uses Vue has to use the Vue...I don't know how to say that. The Redux-for-Vue thing. That is pretty much the de facto standard. Not everybody who uses Angular has to use their Angular router. They can build their own.

14:48 It's not something that they do because it's built into Core, whereas with React, it is all 100 percent like, "This is what React provides. Now, everything else can be figured out by the community." It just increases the surface area of intelligent people solving really interesting problems just because there are so many more people working on those problems.

Tejas: 15:13 At the same time, it leads to defragmentation. We have how many? Five, six routers right now?

Kent: 15:19 For sure that's true.

Tejas: 15:21 Every day, on Twitter, I see people going, "OK, what should I choose? Should I choose Reach?" Part of my job at G2i with vetting is we vet React projects. We vet hundreds of React projects, thousands even.

Kent: 15:33 Really?

Tejas: 15:34 Yeah.

Kent: 15:34 That's interesting. You could almost provide a consulting arm where you're like, "Well, we're going to vet this thing. Then we'll charge you if you want feedback on it" or something.

Tejas: 15:43 We could and we might. The amount of React code we go through in a week is unimaginable. So much so, we're thinking about ways we can be faster because it's incredible.

15:56 What I see often is people's choice in solution, people's choice in routers, people's choice in styling. React doesn't even give you style primitives. It's really fascinating.

16:10 Oftentimes, when we interview people face-to-face, that's what we'll talk about. Yesterday, I saw someone used hookstate to manage their state in React. I didn't even know this was a library that I used it.

Kent: 16:22 I haven't heard of it.

Tejas: 16:22 I learned this by reviewing this person's code. It's a super-powered version of the useState hook that gives you Linux style state management, but it's just useState on steroids.

16:34 Ultimately, the point I'm trying to make is it's good in that it spawns a community, but it can get confusing if you can't navigate it correctly.

Kent: 16:44 That's true. I've seen talks. I had a conversation the other day with Ben Ilegbodu as one of these conversations. It's a really fun one. People who are watching this may have seen that already. If you haven't, you can look forward to it.

16:59 He gave a talk years ago about navigating the ecosystem of React. You don't have that problem. It is a problem. You don't have that problem in other ecosystems. I would say that's absolutely a tradeoff.

17:20 One thing that I've observed is that so much innovation is happening within React because you have so many people involved in working on the problem. As somebody who participates in that innovation, that's a fun and exciting thing.

17:38 Then as somebody who builds applications in that environment, you do get tired of making decisions, which is why stuff like Epic React ends up working out quite nicely because I can give you an opinionated view on tools to use.

17:56 The cool thing is that, even though there are trade-offs with these different tools, most of them you're not going to choose wrong. They're pretty reasonable tools, even if it's maybe not necessarily the best tool for the job.

Tejas: 18:11 For sure. Because we spoke about the level of abstraction specifically, if you think about it, React as a product makes the right decision of where the line to say no is on every level. They say, "No, we're not going to do more than render." They say, "Each component has a definite boundary."

18:41 If you're opening pull requests adding more than is needed, that's also a no. I find the reason React is so good is because of very clear boundaries. These boundaries are best exemplified with the component model where everything is a self-contained function that gets called and then composed, including hooks. The composability only works because of the boundaries.

19:07 If I was to condense everything I think is good about React in one word, it would be the boundaries. They've just nailed the boundaries.

Kent: 19:16 Those boundaries expose declarative APIs that make it hard to use them wrong. It increases the pit of success.

Tejas: 19:24 Exactly, exactly. They're boundaries with very clear ins and outs where you can't make it blow up unless you really want to.

Kent: 19:31 Sure. Well, people might take issue with "make it blow up" with regard to effects like the infinitely looping effects and things like that. That's one thing that is a pretty reasonable criticism of React, especially the useEffect hook. People seem to struggle with that a little bit.

19:56 Why do you think that is? What do you think people can do to avoid the struggle?

Tejas: 20:02 That's a good question. To avoid the struggle, honestly the docs actually do a really good job of it. Educating yourself on effects, what they are, and how they affect a functional paradigm is absolutely key.

20:19 A lot of people come into React going, "OK. I have Render. I'm just going to return some JFX" without really understanding the fundamentals, without understanding what function composition is, why immutability is so important in these contexts, and why side effects need to be explicit in these contexts.

20:36 I think reading the docs. I've read the docs on each iteration. They keep getting better and better. That would be my first piece of advice to someone who's struggling with the useEffect is look at the docs.

20:49 It's likely that they haven't because the docs make it very clear. In my day-to-day work of vetting React projects, I've seen about five percent or so of projects, and this is being liberal, will just not have that second argument to useEffect. So much so, I've built my own tool to automatically tell me what it's missing.

21:18 What I do see more often than that though is people reassigning state to something. This, for me, is the biggest beginner mistake with React. For sure, I see where people struggle with useEffect because the expectation is, if there's no second argument, then it just doesn't run more than once.

Kent: 21:38 You mean if they provide an empty array for that second argument, like no dependencies?

Tejas: 21:44 If it's a beginner coming into useEffect, I don't think they're going to even know about that second argument. This is what I'm trying to say. You know what I mean? Unless they work out of a box.

Kent: 21:55 Actually, I really like that as the default because typically what that means is the effect is going to run on every render. As long as your side effects are really just synchronizing the state of the world with the state of your app, then it is just a performance optimization to add to the array.

22:18 There are some situations where, if your side effect is maybe posting some data or something, then that could potentially cause some problems. I'm actually glad that the default went from, "Let's just put all of our side effect stuff in componentDidMount" into something more akin to "Let's put it both in componentDidMount and componentDidUpdate."

22:44 So often what I saw with class components is people would put it in componentDidMount, but then they'd forget. "Oh, the props can change, so I actually need to handle when the props change, too."

22:55 UseEffect removes that and says, "Actually, don't think about life cycles. Just think about synchronization of the state of the world to the state of your app." That makes a big difference.

23:06 A problem that I see now with the useEffect is people not putting their dependencies in that dependency array. Then sometimes having memoization problems when you're putting in an object that's generated during Render in there.

Tejas: 23:23 That's a point I'm trying to make. People don't seem to get what that second argument is, oftentimes. We just now spoke about boundaries in React. Man, if you compare componentDidMount or componentDidUpdate to useEffect, the whole semantic changes.

23:42 It's because in componentDidMount and/or componentDidUpdate, you would have Window event listeners. You would have data fetching. You would have Bob's-your-uncle of effects. You would have all the effects in that one method.

23:56 With useEffect, you can have four, five, six useEffect calls explicitly saying, "This is one effect. That's another effect." You could granularly describe, "Only do this effect when that thing changes." It's leaps and bounds from class component life cycles.

Kent: 24:12 Then the composition possibilities there. We used to have to do higher-order components, render props, and all this weird stuff to share stuff. Now, it's like, "How do you share a code? You make a function, and that's all." It became so much simpler.

Tejas: 24:29 Exactly. Then again, it's because with hooks as well they've just nailed the boundaries. So much so you can make a hook and unit-test it even. If you had a class component with some methods, that would be a bit harder to test than just a function.

Kent: 24:46 On the testing side of things, I still strongly advise against testing custom hooks unless they happen to be a library or highly reusable hooks. I typically recommend you test the component that uses it, but you're right. You can package up these set of hooks into a single custom hook. It becomes infinitely easier to share that everywhere. It's just a matter of calling a function.

25:19 Really, hooks changed the game. It took what we had already as a really great abstraction and set of boundaries and simplified it further.

25:30 Simple is not easy, either. That's an important distinction. It takes familiarity. This is where I think what you're talking about with people struggling with useEffect. It's a familiarity problem. They need to familiarize themselves with the API.

25:46 Then it becomes much more natural. Whether or not it's familiar to you, it is simple. That simplicity is what makes your application maintainable in the long term.

Tejas: 25:59 Definitely, and predictable in the short term and long term.

Kent: 26:02 From buck free.

Tejas: 26:03 For me, it's all about predictability. I would really like some insight into how the React team makes decisions on what to pursue and what to not because I've been a part of so many teams that will try to do everything.

26:19 Why not? Right? It's our inner ego that makes us want to, "I'm going to create the ultimate library that solves everything."

26:27 The ability as an engineering team and as an engineer yourself just to say, "That's not our problem to solve. That's not our level of abstract," is incredibly powerful. That's something I might pursue after and maybe even made a course about it.

Kent: 26:46 The power of saying no or the skill of saying no...

Tejas: 26:50 At the right time.

Kent: 26:51 at the right time.

26:53 This has been a fun conversation, Tejas. Is there anything else that you want to bring up or mention before we wrap up?

Tejas: 27:02 No, I'm quite happy to wrap up here.

Kent: 27:05 Awesome. Thank you so much for giving us some of your time and your wisdom and perspective.

Tejas: 27:11 Actually, I did remember one thing I wanted to say as I wrap up.

Kent: 27:14 Sure.

Tejas: 27:14 In the world of so many options for libraries, do I use emotion, do I use style components, whatever, one thing in the React ecosystem that really stands out and makes all of this simpler and really gets time from zero to production down to seconds is Next.js.

27:36 Man, I want to publicly applaud Next.js and its team because it is incredible software.

27:43 It makes all your decisions for you. It is a full-fledged React framework, meaning it gives you primitives for routing, for code-splitting, for server-side rendering. It gives you literally everything. All you need to do is make components in a pages folder. You've got pages in your website.

27:59 For people wanting to shortcut the decisions of router, styling, and all this...Next still requires some CSS, but it works out of the box in CSS. Next.js, for me is like the pearl in the oyster that is React.

Kent: 28:17 That's awesome. I'm a fan of Next.js. I had Guillermo Rauch in one of these conversations as well. Next is some pretty powerful software. I'm glad that you mentioned that. That's great. Cool.

28:32 All right. Thanks, everyone, for joining us. Tejas, if people want to keep up with the stuff that you're working on, what's the best way for them to do that?

Tejas: 28:42 Twitter. I'm on Twitter @tejaskumar_ because tejaskumar was taken. If there's some way I can get it, I will. Anyway tejaskumar_.

Kent: 28:52 Cool. Very good. Thank you so much. We'll see everybody in the future. Goodbye.

Tejas: 28:57 Bye.