Michael Chan of the React Podcast discusses React, a front end JavaScript framework. Host Jeremy Jung spoke with Chan about what React is, when to introduce it, and how to learn it without being overwhelmed. Michael explains how JSX combines JavaScript and HTML-like markup to build components and how it decides how to automatically manipulate the DOM. He shares how his team introduced React by adding it to a single page in an existing application. He details how companies can build their own set of reusable components and how to design flexible APIs for them. Finally, he gives resources for getting started and reveals why the Hooks API has made many past tutorials and patterns obsolete.
Show Notes
Related Links
- React Podcast
- React
- CodeSandbox
- Create React App
- Next JS
- Guest twitter: https://twitter.com/chantastic
Transcript
Transcript brought to you by IEEE Software
Jeremy Jung 00:00:21 Hey, this is Jeremy Jung for software engineering radio. Today I’m speaking with Michael Chan. Michael Chan has been teaching Reacts since 2013 and is the host of the React podcast. He currently works at ministry center technologies as a front end architect. I’ll be speaking with Michael about React when and how to introduce it and navigating the React ecosystem. Michael, welcome to software engineering radio.
Michael Chan 00:00:43 Thank you so much for having me. You have such a wonderful lineup of guests on this show. I feel very honored to be sitting here and talking with you today. Awesome.
Jeremy Jung 00:00:53 First, I want to start with defining what React is. So in, in your words, what is React?
Michael Chan 00:00:59 Oh man, who is coming out with the big guns right off the bat. So React is a view library effectively. So it’s a tool for building out user interfaces. Uh, so managing that view layer and they give you one tool, which is the component, and you can define components to make complex trees of elements or just rap simple elements. They’re pretty similar conceptually to web components, but they’re very different. Everything happens in React. They’re all managed by React and, um, effectively they’ve done a lot of magic to be able to make programming and React very declarative. So you create a tree just in the same way that you would create like an HTML tree of elements. And you tell, React to, Hey, insert this at this node. And from that point on React takes control over everything, all of the updates. So, you know, when the state changes and all that kind of stuff, it will very wisely and selectively make updates to the Dom kind of very surgically and it all comes together. And it sounds, you know, I’ve, I’ve given a very complicated introduction to it, but it’s all very simple. It feels a lot like writing HTML in JavaScript and just having all of those updates happen, like really quickly getting this really nice model for defining your own types of elements and it’s, um, it’s great. But yeah, mostly just a view library.
Jeremy Jung 00:02:30 You were talking about how it has a declarative interface. Could you kind of go a little bit more into that? Like how does that look compared to traditional web development, working with the Dom and things like that?
Michael Chan 00:02:43 Yeah. So this is a very different kind of mindset from web components. And I’d say that this is one of the biggest difference is between React and web components is web components is very imperative. You know, when you define a web component, you’re handling everything you’re telling you’re, you’re telling the Dom how to actually do the mutations to update itself in React. There’s this one function at the bottom of your application, and it will Mount your React application, however big that is into a single node on the Dom. And so usually the way React app looks is you’ll have like an HTML file and it’ll have a, just a single div with like ID root in it. And that’s where React is going to, to render your application. Now, this can be something as simple as hello world or a to do app or a full blown application.
Michael Chan 00:03:38 So this could be like facebook.com renders a React app into that node. And the difference with React is, is that you get to think about your application at like any given point in time. So because React manages all of the state for you, the best way that I’ve found to describe it is it feels a lot more like when we have written server-side applications in the past, there’s that kind of feeling where it’s like, I am going to click this button and I’m going to make a request to the server, and then I get a whole page back, right? It’s very similar to that, but it happens all in the client. So you click a button and then React is going to do whatever action it was that, you know, that that button does, it’s going to redraw the full application, but instead of like reinserting into the Dom, which could be dangerous because you’d lose like input state, you know, if you had any transient forms filled out, anytime you updated focus would get lost and all that bad things would happen.
Michael Chan 00:04:38 Right. Um, React just very carefully says it looks at what has changed and what is currently in the Dom and says, okay, these two things are different. So we’re just going to insert those, this one thing down here in the corner, it’s not there anymore. So we’re going to take that out and it does the minimal change set to, uh, to update the Dom for you. So instead of you saying like, okay, do all of those things like input, insert this, insert this, remove this React, just does all of that for you. And it’s just like, you’re just writing the view, just given the state that you have. And you just think about it in terms of like what’s happening at exactly any given moment. And I think that’s the main difference between like, you know, declarative and imperative is how much do you have to tell the Dom
Jeremy Jung 00:05:28 If I understand correctly, if we had, let’s say a list of names in traditional Dom development, uh, if we wanted to add a new name to the list, we would have to find the Dom element that has all of these, all of these names in it. And we would have to find it by like an ID or a class name. And then we would append a new Dom element to the end after we found the correct element we wanted to append to. Right. Yup. Yup. And in Reacts case, we would have a component and that component, it would take in a parameter that would be that list of names. Right. So let’s say Michael and David that’s currently in the list. So we pass in Michael and David as a parameter and then React would figure out what HTML to output to the browser based off of what we passed in. Right.
Michael Chan 00:06:26 Yeah. So you would still define the HTML that that’s going to get used. Um, but then yeah, uh, React would kind of decide how, how any updates to that happen. So if you, you, you, you re render it first with, with Michael and David and then something happens, you know, so now we add Jeremy to the list. It will now rebuild that, that list, but instead of pulling that whole list and then inserting a new list, which could, could be very large, right. You could have maybe hundreds or thousands of items in that list. And that would be very slow. Um, it’ll say like, okay, we already have Michael and we already have David. Um, so we’re adding Jeremy. So we’re just going to do an insertion for Jeremy. And, um, you know, if you were programming this yourself, you would, you would have to take, take efforts to make sure that that happened so that it was performance, but in Rackspace they’ve, they’ve abstracted away, all of that. And it just, uh, it just kind of works like magic exactly. Like you would want it.
Jeremy Jung 00:07:25 And the way that you write the HTML within the React component is using something called a JSX. So could you kind of explain a little bit about what JSX is and how that works?
Michael Chan 00:07:37 Yeah. JSX is one of the weirdest things ever. I it’s, it’s like a really weird like demonic HTML, so it looks a lot like HTML. It is an XML syntax for writing functions. Um, which sounds really weird, but what it, what it is is it allows you to write that style, that like HTML XML type of style for these elements in React inside of JavaScript. So React happens all in JavaScript planned, unlike libraries, like view or, um, I think angular. So does this definitely Amber, there are no templates. So, you know, in the past we’ve had like handlebar temp, or even currently we have a handlebar templates or, you know, a view template and they are effectively just strings of HTML. And there are these little, you know, areas where we can interpolate things. And when we compile our, um, our data to our view templates, those get, get rendered out and inserted into the Dom.
Michael Chan 00:08:44 Now React is totally different. It all happens in, in JavaScript. There’s no kind of like compiling view templates. And when you create components, you’re returning React elements, and these are just templates for actual Dom elements. So you’re not returning down the elements, you’re returning React to elements and they tell, React how to draw the Dom elements. And this all gets like super confusing. It’s like the just JavaScript thing is a little bit of like a white lie in, in React. Because as you mentioned, JSX kind of screws that all up a little bit, but React knows this function called React, create element, and you can use this in any React app that you want. It’s, it’s what all React apps use. Um, but that gets abstracted into, um, in, in typical apps into JSX. So we’re, you could say React dot, create element div, and then give it some parameters.
Michael Chan 00:09:43 Instead we use this syntax called JSX, which looks a lot like HTML, and you would just right. Angle bracket div, and then your parameters as attributes. And the way that is all empowered is through Babel transforms. And so every time it sees these angle brackets, it’s like, that’s not JavaScript. Uh, so you tell Babel like, Hey, yeah, that’s not JavaScript is JSX. And when you see those, just turn it into this function, React dot create element. And once you get the hang of it, it all kind of like makes sense. But if you don’t really know that that’s what’s happening under the hood, it looks super weird because it looks like you just have a function that’s returning HTML, which is impossible as we all know. And, uh, yeah. So that’s, that’s what JSX is. And it’s not React specific on, you could have JSX, you know, by default in Babel, I think it does React, create element, but you could have that. Do any, any function, it could run the function H or my element or whatever you want. Yeah. That’s JSX and it is, I think the biggest stumbling block to getting into React, because beyond looking funny, there are a bunch of kind of weird things like, uh, instead of writing class for a blank style classes, um, you would write class name and sort of for it’s like HTML four for hooking up form elements. Um, so there’s a lot of kind of gotchas like right up front in React with, uh, with JSX.
Jeremy Jung 00:11:14 So if you are writing JSX you, you said it looks very similar to HTML, but what what’s actually happening is it’s taking this markup that looks like HTML, and it’s compiling it down to regular JavaScript codes. So instead of writing, let’s say a, um, a div tag in HTML, it’s actually creating a JavaScript function call that says React dot, create element div, for example, is that a, is that correct?
Michael Chan 00:11:46 Yeah. So it’ll actually create a bunch of objects. And so they’re basically just blueprints for what element would look like. Um, and so it would say like, you know, type is div or whatever, and then have, you know, the attributes that would go on there. Let’s see it doesn’t do properties because React has its own idea of, of props. Um, but yeah, any kind of nested children, and it would just build up this big object of all of these elements. And then it would use that to determine which elements needed to get inserted to the Dom, which ones have changed.
Jeremy Jung 00:12:19 And what are some of the benefits of this approach? Like what are the benefits of having it generate JavaScript code versus the template approach that you were mentioning? Some other frameworks used?
Michael Chan 00:12:30 Yeah, that’s a great question. I know that one of the things for me is just the practical advantage of having my code and my template in the same place. I know not, not a lot of people like that, but I’ve found in front end development, I’m typically changing my, my view and that, you know, controller or whatever it is that feeds data to the view, uh, in tandem. And so I love that React to puts those together. So for me personally, there’s a practical advantage of having those co located. I know that there’s, you know, maybe some, some speed advantages is to not parsing strings. I couldn’t speak to that specifically cause I’m not, I’m not that bright. I, I just make views, but I know that there’s some, uh, you know, some theoretical, uh, speed advantages to that. Uh, I know that it’s, it’s easier to kind of like diff these objects before they become, become views, but that’s a little bit outside of my depth. I couldn’t speak knowledgeably to the, to the performance gains. Cause I know that there’s a lot of really cool stuff happening in some of the other libraries where they’re pre compiling a lot of those templates and turning them into functions anyway. So I, I couldn’t speak to that side of it.
Jeremy Jung 00:13:45 I’m not sure if this has changed recently, but I remembered working with things like angular one in the past where you would write a HTML template. And if you would make a mistake, when you wrote the template, then the HTML, once you actually looked at the webpage, you would just get nothing and you would have no idea like what was wrong. Whereas I believe with React when you write the JSX markup, if you make a mistake, I think because it compiles down to JavaScript, the tooling can tell you what kind of mistake you made.
Michael Chan 00:14:20 Definitely if you had to, if you have a syntax error in any of these, which is, um, that’s a, that’s a great point. If you have a syntax error, it’s a lot easier for JavaScripts to report that to you when you are compiling it, because it won’t, it won’t compile. And so you’ll, you’ll get some kind of error, which is really helpful, you know, versus, you know, in a traditional view, if you have like two angle brackets on one side and just one on the other, you really wouldn’t know until you ran that code, right.
Jeremy Jung 00:14:48 You run it and then you just get a white screen or something like that. Yeah.
Michael Chan 00:14:52 We’ve all seen those views where it’s like, you got these like weird curly braces and it’s like, hello, first name.
Jeremy Jung 00:14:57 Yeah. Oh, right, right. Yeah. I want to go a little bit more into the components we were talking about earlier. What kind of information is, is stored inside a component? I believe in Reactors, things like props and state and things like that. And I was wondering if you could go a little bit more into that.
Michael Chan 00:15:15 Yeah, absolutely. So you can think of components a lot, like functions at their very base layer. You’re going to have, you’re going to create a component with a function. So you say function my component. Uh, and then you’re going to take only one argument and that’s going to be props. That’s, uh, an object of, of properties. We’ll come back to that. Um, but then that component is just going to return a React element. So that could be a div, uh, that could be a button. It could be any of the HTML elements, or it could be another component now. So going back to those, those arguments, uh, so we have props, they always come in as an object and in props is kind of a mix of things is going to be all of the attributes that your component was called with. So that could be ID, class, name, data attributes, all of the regular HTML attributes are going to be in that bag of props, that object of props.
Michael Chan 00:16:16 And then in addition to that, it’s going to be any API that you want to support. So let’s say we have a greeting component and it has a first name and a last name and you joined them together or something like that. Um, you would pass those props into this, this object that we get as an argument as to our component as HTML style attributes. So, you know, in JSX we use this, uh, we’re using XML type type markup, and it’s going to be, so you would do like first name equals, you know, quotes, Michael or Jeremy, and then, uh, you know, last name and you put your last name in. And so now that passes those on to our component and then the component within merge those together and re however it needs. Now, that’s the one interface for managing data in React. That’s the, that’s the first one.
Michael Chan 00:17:08 So just passing arguments effectively. The second one is with state. Now, the other white live React is that it’s not just a layer. It does also manage state. Um, so you could write an entire application, you know, from, from data fetching to, you know, to, to rendering in a React component. Now, a lot of that’s changed over the, the handful of the last year effectively, but components can effectively hold on to state as well. So if you have, you know, a simple example of this is just like a click counter, you’ve got a button every time you tap on it, it just increments a number. Um, so that’s that state a component can hold onto that. And the most recent way to do that is through, through hooks. Um, you would have these, um, you have these like kind of like magic little functions in React that you can stick inside of your, your components that allow you to hook into React and maintain pieces of state. So every time you tap that button, you would kind of tie into this, this hook and, you know, update it w you know, saying, Hey, increment yourself, increment yourself, and then use data returned from that hook to, to render that number. It’s all kind of like complicated over, over, uh, over voice. It’s a lot simpler.
Michael Chan 00:18:30 The React docs have some really good examples, specifically the ones that I mentioned, and they show these are like two liners effectively, but yeah, so, um, components can also have state. And, um, that is anytime a component has state, you know, it’s owned by that component. You know, the only way to move state around would be to have another component own it, and then passing it in his props, or, you know, use some other type of global state library that manages all of that for you. Um, but the React method is to the current one is to use a hook and just kind of hold it in a, in a component.
Jeremy Jung 00:19:07 And so just to break it down a little bit, you said we have props, uh, the, a component is a, is a function. So it takes in these props, um, and those props determine what, uh, is kind of shown inside the component. And then you have state, which allows changes within the component to be persisted for the duration of, I guess, for the time the person is on the page. The next thing I want to talk a little bit about is could you give us an example of how components React to changes such as things like somebody clicking a button or entering information into a text field, how are the components getting notified of these changes and how is that information getting to the components?
Michael Chan 00:19:55 Yeah. So React has had this long standing idea of one way data flow. And this is, this is kind of like a big concept. I’m not going to go into a lot of it right now, but that if you Google anything with inputs, you’re going to find, you know, this term one way data flow. And so we’ll touch on that a little bit, but React has its own event system. And so they call these like synthetic events. So if you wanted to hook one of these up on your component, let’s say you have like a, my input and it’s just a single input. You could just spit an input out on the page and it’ll behave just like any other, other input, but the React way of managing the state for that input field is you would have an change. You’d, you’d put an on change prop on that thing.
Michael Chan 00:20:46 And you would it a function now with hooks, you actually get that function. So you, if you used a state hook, it would return an update function, and then also the current state. Um, and so you would kind of hook both of those things up onto your input. So you would say, Hey on click call my hook function, which ups updates this piece of state. And then the value is going to be the piece of state that we get from that hook. So that’s kind of like how we would hook things up in, in React. Now this gets a little bit complicated because first of all, you can just use like the regular inputs without kind of managing the state. Um, but then also many React apps will use a totally different library to manage the state of these elements. So, you know, that might be Redux.
Michael Chan 00:21:35 Uh, they might use a form library specifically. It has its own way of doing it, but the, the built in mechanism is to use some type of, you know, use state hook or use reducer hook. Um, and what those do is they provide you that again, they hook into React, they provide you the, the current state and they provide you a function for updating that state, both of which you would wire up to your React element. And this gives you the, what React developers kind of refer to it as like this one way data flow, um, where the component doesn’t update its own value. It calls a function which updates the state somewhere else, and then uses that return value to, uh, to display the output. You know, it’s funny, I’m realizing as we’re talking, why so many people find React complicated? Yeah.
Jeremy Jung 00:22:26 Yeah. I mean, it’s like the example you’re giving with, uh, just a input, like a text input, right? If someone was building a traditional form without say a framework, they would type whatever they want to type into the form and they would submit it and the browser would kind of automatically pull out whatever the user had typed into that field. Right. Whereas it sounds like with React, the typical way you would make that work is you would have to add an event to the input field that is basically saying, like call this, uh, event every time somebody types something new into the input field. And then you would have a function that is being passed into that component that is updating its state, I guess, based off of these, on change events. And then that state would be passed back into the component to make the input change based off of props. Did I kind of get that right?
Michael Chan 00:23:33 Okay. Yeah, yeah, yeah, no, you did get that right. And it is all in service of kind of protecting that prop boundary so that things are told what to do. They don’t have some secret knowledge of like how they’re hooked up into system. Um, and so it Reacts really does try very hard to be explicit about relationships. And so having that like kind of one way data flow and like basically asking to update and then getting your new state via props kind of allows you to control the application very fine grained way. Now, I think you bring up a really interesting point because this isn’t required. This would be something that would empower you to make highly interactive forms. So like, you know, as this piece of state changes, now we’re using that data, not just to update the value of the input, but maybe modify some other fields in a different way.
Michael Chan 00:24:22 If you wanted to just have like a straight inputs and then have, um, you know, on submit, take that data and do something with it. Um, you can totally do that as well. You can just have a simple form and then have a form element do on submit and then give that a function for handling all of those that, that entire form, um, when you’re done with it. And you could put that in state, if you wanted to, or you could, you know, just use that data to fire off some type of, you know, uh, S server query or, you know, whatever you want. Um, but yeah, you could handle that with a less complex form doing that just on the, the form element itself.
Jeremy Jung 00:25:01 So it kind of gives you the option. Like they have these ways of doing it using props and state, but if you decide that you don’t want React to manage that part of your application, you can still use the regular Dom, I guess, and write your app kind of how you would normally write it.
Michael Chan 00:25:21 Totally. Yeah. You could basically everything in that form could feel very familiar. You don’t have to use any of the special attributes. And then on submit would be the only place where you’re really interacting with React and say like, Hey, this, this form is complete. I have all this data now, you know, do something with it. Got it.
Jeremy Jung 00:25:37 One of the things people say with React is that its components are composable. How does React help you build out your UI and sort of using components?
Michael Chan 00:25:48 Yeah. So it’s, it’s really fascinating how many ways you can compose elements together when you have the full power of JavaScript behind you. And that’s one of my favorite things about React is because at the end of the day, these elements are an artifact of, you know, however you want to compose these functions together to, to make them. So there are a ton of patterns that you can use to compose components together. And, you know, the most basic of this, of these is going to be a component that creates an element from another component. So you have maybe a greeting component and it just renders an H one with, you know, hi, your name. Well, then you can have a header component that use that renders that greeting component along with other components. So that would be a, you know, the first kind of form of, of composition that you can create components that render other components.
Michael Chan 00:26:50 So that’s, that’s really handy because now you only have to do that greeting once and you can use it in a bunch of other components to, to compose new views together. However, you can also use components to compose views and data. So you can have a component that is only responsible for gathering data. So you, you say, Hey, uh, when this component is rendered go fetch this data from the server, and we want you to then take that and render whatever component we give to you as props. So you could pass a component in this props and say, render this component with the data that you have. Um, so that’d be another way that you can compose components together now in a way that allows you to merge data and views. Um, and they’re just like a ton of patterns that you can use for composing these things together. There is an API called context. And what the, what context is it allows you to say a bunch of values, um, that you could use inside of all of these components by just like basically just grabbing them out of the air. So it’s kind of a third mechanism for, uh, for, for data. So it props, um, state in context is a way of like distributing data to a whole tree. So I could say like, you know, user context, I could create a context for all of the, um, for my user, which has their name, their birth date, and, uh, favorite food or something. And then when I use that context, when I wrap a certain part of my subtree in context, I can then just snatch those, those, those pieces of data out of the air, in my components without having to pass them around as props. And this can be really, really nice way of composing related components. So ones that, you know, are always going to have access to certain types of data.
Michael Chan 00:28:47 Um, and instead of having to pass them around as props, just basically put them in the air of this subtree, they’re kind of like local, local variables to that part of your application. And then they just, uh, just grab them out of the air and like, Oh, Hey, I know the first name is in the air somewhere. I’m going to grab that and use that when I don’t have any props. So, um, yeah, so these are, those are a bunch of ways that you can, you can compose components together. Um, there’s because there’s JavaScript, there’s really like endless ways that you could compose components together. Um, but those are just some of the most, the most, uh, common composing views of views, composing data and views together. And, um, and then also using context to, uh, to create views that are aware of certain pieces of data. Kind of like how with traditional HTML, you know, we had tags that could just give us an input or give us a button. And this sort of is like taking it to the next step where we could create, like you said, a, let’s say a greeting component, um, or we can create a survey component. We can create these building blocks that have not just markup, but also have behavior associated with them. And we can have a component that’s made up of a set of child components. So we kind of get all these little pieces that we can connect together when we’re building an application. And we can even possibly reuse components that we used on one application and use them with another one.
Michael Chan 00:30:20 Absolutely. So, so one of the things that I do for my work is I work on a design system and a component library that we share between eight applications and the composability of rack components really comes in handy for, for me in allowing other people to kind of use the components that they need without having to do a lot of customization. So, uh, if you use something like bootstrap or Bouma, a lot of times they’ll have an API that’s like button and then button is link, or button is primary or button is whatever. And so all of these, all of these customizations or modifications exist inside of the namespace of button now Reacts kind of flips that on its head a little bit. And so in a React based component library, we can have at the very bottom, we can have a button and the button is basically just renders out a button attribute, and maybe we do something like a type equals button by default, which it should be by default anyway.
Michael Chan 00:31:24 So we do that and that’s our button component. Well, now we can, we can compose other components over that. And so we can do something like we could have like a red button and it just like applies a class or applies some styles or, or however we want to do it. And now this is a red button. Now we don’t want to write like red button everywhere in our app, because you know, it, it’s better to refer to things semantically, right? Like, so maybe this deletes something. So then we can compose that again. And we say like a delete button is a red button, which is a button. So it kind of, it cascades a little bit. So we have a delete button is red button is a button. Now at some point in the future, we say, well, actually we don’t want our, you know, w we’ve we find red to be offensive. We want it to be something like, you know, pink instead. Well, now we can just kind of like swap that out with pink button or, you know, have our delete button, just call button directly or render button directly, and then apply the style attributes at once. But these are some really nice tools of being able to like compose swap out pieces that, that, that don’t work for us anymore without having to overload this base button with a bunch of props and knowledge about the entire system.
Jeremy Jung 00:32:37 Very cool. So it’s, we’re building tools that are not just for the app we’re currently working on. It could be something that could be applied across our company, or it could even be something like, uh, let’s say somebody had built like a, a chart library or something, and that’s something that you could build out and build an API in terms of what props you accept and what kinds of, um, functions are made available. And that’s something you could put online and release it as an open source library. And now other people could use that chart component in their own application. That sort of thing.
Michael Chan 00:33:16 Yeah. Oh, absolutely. And, and one thing I love about the React component model is that in these open source projects, something I’m seeing a lot is that, you know, you, you build the first version of your chart and it’s going to have everything that’s going to be profit based presumably. And the natural inclination is, you know, when someone needs a feature, they’re going to ask for new prop to do that thing. And that’s, that’s great, like for a certain period of time, until a year down the road, now you have like 50 props that you could pass in. And it’s just super confusing to use, use this library. And what I’ve seen a lot of people do because of this composable nature of React is say like, Hey, instead of giving you extra props, what I’m gonna do is I’m gonna, I’m gonna keep this default interface the way that it is.
Michael Chan 00:34:08 But what I’m gonna do is I’m going to expose the inside parts of this as other components. So you need to change this thing. What I’m going to do is I’m going to give that to you as a component, and then you can change that thing and then recomposed them together as your own charts. I’m going to give you all the pieces that I use to build my chart. And now you have access to those. You can customize them, however you want. You could replace them with your own, if you want to, and then build, build your own chart from those same composable pieces. And I’m seeing this transformation and a lot of the React open source projects. And it’s just such a great way to, I guess, work in the same sandbox because, you know, we’ve all seen projects start out with a really simple interface and then get a really complex, you know, overrun interface with, with a bunch of customization. It’s really nice to be able to just say like, Hey, that, that default interface doesn’t work for me. So I’m just going to pull these pieces out and then use those to compose my own interface.
Jeremy Jung 00:35:06 Nice. Yeah, that sounds really powerful. And, uh, I have definitely come across, uh, API APIs and maybe he even pilled some myself where there’s so many kind of public props or calls where it’s just is very difficult to, to get started. So I think that’s really cool that you can build with that in mind and kind of offload some of that to the user
Michael Chan 00:35:30 Component. Yeah. I’ve seen a lot of people call this. The prop Calypso is silly, little React, React, community punk.
Jeremy Jung 00:35:42 So I’d like to shift gears a little bit and talk about how someone can get started with React first, when should a team consider introducing React? Like what kinds of questions should they ask themselves?
Michael Chan 00:35:57 I think that it depends on where you’re coming from. So I can speak from my experience, the team that I work with, we had eight rails applications and rails is a great platform, and they’re constantly adding to it and, or great framework. And they have some really great tools for kind of managing, uh, your, your server side application and then doing some front end JavaScript stuff. Unfortunately, the tools that were available a handful of years ago, weren’t great for highly interactive JavaScript where you make a change over here and then updates immediately over here. Um, they can be a little bit complicated and indirect. So I think that that was a natural inflection point for us, um, to say, Hey, we have these views that are highly interactive and we want to give the user immediate feedback. Um, that was the point where we started looking at React specifically.
Michael Chan 00:36:57 We had an application that was kind of, it was almost like an event runner. I mean, it is an event runner, uh, where you would have this rundown of all the things that are gonna happen in, in invent. So think like a meetup and you know that, you know, seven o’clock, someone’s given an introduction at seven 15, you got your first talk, you got a little bit of a break for food. And then, you know, you got your second talk and then everybody goes home. And we had this tool that would allow you to see the progression of the event, see the upcoming things. Uh, it had a real time chat hooked up into it. Um, you could progress events if they kind of fired off early or kind of ran too long or ended ended early. And so this is a very highly interactive thing, and it really wasn’t something that we could do in rails because these app updates, you know, with a clock that were at least happening every second.
Michael Chan 00:37:48 So we just decided to go full bore into, to React. So this is just a single React application. The nice thing is it was totally isolated, right. We just built a small application and then we serve it at that route in our rails app. And, um, it was totally isolated from the rest of our application React. Hadn’t really, we hadn’t made a decision to use Reacts, you know, across the application. Uh, we just said, Hey, this, this is a good place for React and used it now one place and kind of tried really tried really hard to just kind of like have that be a decision point for the rest of the app. Like, do we need it, do we need to have high interactivity in this application? Do we have an endpoint that we’re interacting with already set up? Um, those are some questions that I found really helpful in deciding whether or not it was time to embrace React.
Michael Chan 00:38:40 Um, now it’s, you know, five or six years later. Uh, and I think that, that, that decision point has maybe moved up a little bit. I think there’s a lot of people who are starting in, you know, are their app is already very heavy on the client side. I think that that is going to be a little bit more of a difficult question. You know, let’s say you already have an Ember app or you already have an angular app. When do you make the decision to, you know, maybe give, React to try? I couldn’t, I couldn’t answer that one per se, but I would say find a piece that can, can be completely owned by React and just start there and see how it feels and see if that can naturally grow into other parts of the application.
Jeremy Jung 00:39:23 And in this example that you’re giving, did you use React to control an entire page or was it a traditional server rendered page that had React components on parts of it?
Michael Chan 00:39:36 Yeah, so this was, um, the, the first, our first experiment with React was it is just, it was just a page. So we had a rails route and that route just had that single Dom node. And we said, Hey, React, render yourself here. And the whole application was basically just one gigantic component, cause this was, you know, five or six years ago. And we didn’t understand how that composition works. I mean, I don’t think the industry really understood how opposition, so we had this, I mean, I think it was maybe like a 1500 line component with maybe another 2000 lines of, of, of mixings, uh, which was an API that they had at the time to basically force in other components into your component. Thank God they’ve gotten rid of it now. Yeah. So it was, it was probably like it was effectively like a 3000 line component. Wow.
Jeremy Jung 00:40:26 I guess one thing I would ask is if somebody is in sort of a similar situation where they have a traditional server rendered page, and there’s a portion of that page that has some kind of complicated user interaction, like for example, let’s say you have a page that has a form that is very complicated and you want to do a lot of client side validation, that sort of thing. Would you take the approach you did where the route just had a single Dom node that React kind of took over or would you have the majority of the page still be a rendered traditionally and then just make that one form or that one section be made with React components? Yeah,
Michael Chan 00:41:14 That’s a great question. So one of the cool things is that because React only needs a Dom node, I think either approach is valid. And that, that second approach that you mentioned is what we ended up taking in a lot of other places in our application. Once we decided that React was a good fit a company, we would basically say like, Hey, this one, like you said, this form is highly interactive and we want to be able to control that and give immediate feedback to the user. And so we would just render a dominoed there that we could render our React application to. And then, um, you know, just do that. And it was, you know, in the context of a rails rendered view, um, everything else had remained the same, but we were able to just kind of convert that one note into this interactive form. And I think that that’s a, that’s a great approach as well.
Jeremy Jung 00:42:06 You’re sort of making that decision. What are some of the pros and cons of taking the isolated components strategy versus having React take care of the entire page?
Michael Chan 00:42:17 Whew. I know for me, I don’t like to rewrite stuff rewrite the same code in a different language. So, so for me, I would be hard pressed to want to just take that entire view one that’s already working when it’s already tested and then convert the whole thing just because, uh, so for me, I always like to take the smallest possible chunk and then have it naturally grow. And I think that’s one thing I really love about React is that while some frameworks are very opinionated, you know, they need to be, they need to control the whole page. Uh, React is not. And, um, you know, one of the beautiful things of that is that you can decide how much of your application you have to rewrite to get the interactive parts that you want. So yeah, I would always recommend, you know, if you’re doing any type of transformation React or not, um, to start with the smallest amount of like the smallest piece possible. And, um, and then kinda like, see how that grows. I know some people really can’t handle the incongruity of that, but I don’t know, I would, I would just recommend, you know, training yourself to, to, to have more of that in your life because every application has, has some degree of that and being able to live with, you know, different mindsets and, you know, different, uh, frameworks is just kind of part of working on, on valuable production code.
Jeremy Jung 00:43:43 Yeah. So I guess you would say to basically be very targeted, like start small, if you have something that’s working, just change the part that you think could use that extra interactivity. And don’t worry so much about having to sort of be between two worlds, I guess, you know, having, having to understand the, the rails view, as well as the React view, you don’t consider that to be an issue. You think that’s something that most people will have to deal with? Yeah.
Michael Chan 00:44:13 Well, I think that there’s a lot of things that we just, we just don’t think about when we are inclined toward a rewrite. So, you know, some of those things are, you know, maybe a lot of that view is already tested. Um, and so now you have to redo all of those tests, you know? And, and so it’s not just changing the view, you’re, you’re changing tests. And then also, you know, in, in the case of moving from something like rails to React, those tests are changing frameworks and approaches. And I think that those types of things we tend to, I guess, like brush out of our mind when we’re thinking about, Oh, it’d be fun to redo this thing in React. We forget about all of the things that wrap that view that we’ve already established. And, you know, I think those are the things that kind of come back to bite us at that like 80% Mark, you know, like we’ve already got w we’ve got all the functionality, but now we have to backfill all the tests that we’ve deleted now and all that kinda stuff. And that’s like, that part is just like soul crushing when you get there. And you’re like, Oh man, we’ve, we’ve made a mistake. We should just, we should have done a small piece of this.
Jeremy Jung 00:45:18 Totally. I mean, it’s when you, you have something that works, you know, especially if it’s been a while and you’ve established, like, you know, we, we put this stuff out, we have our tests that’s been running in production and you know, we’re good. Like, that’s, that’s something very powerful. Right. And you don’t really want to give that up.
Michael Chan 00:45:37 Oh yeah. Never. It’s like, those were hard won battles. Like I don’t want to fight them again.
Jeremy Jung 00:45:41 Yeah, for sure. So another thing I’d like to ask about is if you have something like a Google maps page that’s not built in React, does it still make sense to use React in your application for that page? Like how would you approach that?
Michael Chan 00:45:58 Oh yeah, that’s a, that’s a great question. So React does have some escape hatches for you to be able to render some type of JavaScript thing, you know, so in this case, a map that isn’t React and to be able to, um, to, to render that without having it, having to re implement it and React. And so there’s, there’s a few API APIs for this, depending on what you need. Um, but effectively you can kind of force something into any of these notes. So there’s some videos on egghead that I’ve seen, uh, where people are demonstrating how you could use, um, jQuery, UI, calendar, widgets inside of React. And it might be a little bit too complicated to try to, you know, verbalize over the air, but there are escape hatches for that. Um, I know that one of them was dangerously set inner HTML.
Michael Chan 00:46:54 So you, um, so there’s an API that you can use that allows you to basically just tell a node in React a, this is the HTML you have to render as React. We’re not controlling it. We’re just giving you a big string and you’re going to render that into the DME. Um, so that’s one of the escape patches that you can use. Um, sometimes you can use the life cycle events to basically, you know, give the thing an ID and then render, render whatever it is that you need to, to that ID. Once it’s already in the, uh, established to be in the DME, um, depending on what you need to take and what the life cycle of the library you’re using, is there, there absolutely approaches that you can use to kind of encapsulate that into a component as like the jQuery UI calendar React component that just opts out and uses jQuery UI.
Jeremy Jung 00:47:47 Next I’d like to talk about how to get started with React, because I think React like you’ve sort of been saying throughout our conversation, a lot of times people say it’s just the view layer, but I think what people often find out is to get started with React. There’s all these other things they have to learn, or there’s all these starter kits that people recommend. And so it can get really overwhelming. So how would you recommend someone get started? Like what are the things they should focus on?
Michael Chan 00:48:22 Yeah, that’s a great question. One of my favorite tools today is called code sandbox and code sandbox is totally set up out of the, they have a playground for React apps and everything that you need to get started is in there. So if you want to just start playing with React and you know that you’re going to have some trouble, you know, getting, getting, you know, Babel set up for uh JSX and, and all of those things that are kind of side effects of playing with React. I, if you just want to play with it and get a sense of it, code sandbox is amazing. They have a re React project, you just click a button and then boom, you’re set up in a React app. You can then go through all the tutorials you can follow along in the documentation. It’s amazing. So that’s, that’s the first thing.
Michael Chan 00:49:10 And you can do pretty much anything that you would do. You can, you know, you can NPN M installed different packages. Um, you can make requests to, uh, to, to, to various data services. And, um, it’s really good when I do trainings, I will usually use code sandbox because it takes all of the setup out of it. Um, beyond that, there’s a couple starters that I think are better than others. Facebook maintains a project called create React app. Unfortunately it does require that you have at least a base level command of node because all of this stuff happens in a node process. In fact, the, the code sandbox starter is based on create React app. So the next step would be, you know, to go from, you know, you’re a code sandbox starter to create React app cause the same environment effectively. Um, but now you have to use node.
Michael Chan 00:50:04 Um, so you’d have to install node. You’d have to kind of get a sense of NPM install and NPM installing a create React app. Fortunately, they’ve made it very easy, but I’d say that that’s one of the next best places to go because it’s kind of spiritually connected to the, the code sandbox. Uh, they’ve made it easy. The documentation is great. And, um, all those things like, you know, JSX and, um, things that you might even think of, you know, if you want to load an SVG or you want to load styles, um, from CSS or something else, all of those are taken care of. They’ve given you, um, well-documented nice API. They’ve, they’ve connected all done all the connective tissue to make sure that that works for you. And then the third thing is something that I use all the time. I don’t, I don’t personally use create React app when I’m starting a project.
Michael Chan 00:50:51 Um, but there’s a company called Zeit and they have a project called next JS and it’s, it’s kind of a static site generator kind of, but I find it to be the easiest way to actually like, just get started with React. And I really love next. It’s like a NPM install, two things, and now everything in, uh, anything that you put in a pages directory, um, becomes like a React page. And, um, you can do, do all kinds of cool stuff with that. So that’s one of my, my that’s my personal favorite, uh, starting point with, with React. Um, but code sandbox definitely, uh, give that a try and create React app is probably your next step once you’ve, uh, you’ve decided to make the jump into, uh, using, using a little bit of node to control your, your app.
Jeremy Jung 00:51:41 And earlier you had talked about how, when you and your team first started using React, it was in the context of an existing server rendered application. Would you be able to use, say, create React app or a next dot JS in combination with that? Or what, what would be the approach for someone in that situation?
Michael Chan 00:52:03 A lot of frameworks will have some type of plugin or, or Jim or, you know, whatever the mechanism is for your framework to connect a React app. So, so a rails I know has generators now by default, where you can, um, generate a React app review app or an L map inside of rails. I am not too familiar with the other frameworks, but I imagine that now it’s, it’s probably pretty simple in a lot of the major frameworks, like, you know, Python or.net, um, to get started with a, um, with some type of generated rails React configuration.
Jeremy Jung 00:52:43 Another thing I’d like to ask is when someone is learning React, there are going to be a lot of resources. They see that use features that maybe aren’t widely used anymore, or maybe have better alternatives. Now, what are the things that someone should avoid when they’re looking up tutorials and looking up guides, what are the features that they maybe don’t need to consider anymore? So
Michael Chan 00:53:11 The last year has marked a lot of change and a lot of that change is around hooks. So I’d mentioned hooks earlier in our conversation, but hooks are really the, the, like do it all kind of collection of APIs in React. Um, so React has had a lot of, I guess, ways of defining components. And right now the, the, the happy path is you just do function style components. So it’s just a function that wraps, uh, you know, uh, React to element. And now when you want to do things like, you know, connect to data or have some kind of side effect where you maybe change a class outside of your React app in the Dom, or, you know, using context, um, which, which we talked about earlier using state, all of these kinds of things are now wrapped up in hooks. And the beauty of hooks is that you can use them in function components, um, which are the simplest to define.
Michael Chan 00:54:15 It’s just a function, returns, a React element. And now you can just use these. You can, you know, connect to state, connect to the outside world and update classes or whatever you want to do, connect to data. And all of that can happen in hooks. Now that used to be a lot more complicated when we had a class API for defining components, and you had to know a bunch of life cycle methods to kind of connect to state and whatnot. So if you don’t have to, if you’re not working in a legacy app that is using the class component API APIs, I think that really using the function style components and React hooks is, is where you want to be pushed as hard as you can to be living in that Wonderland. Um, cause those APIs are great. They’re so well thought out they’re much easier to use.
Michael Chan 00:55:09 And if you’re just starting out right now, I wouldn’t even bother with the other ones because you know, so many libraries now are using hooks. It’s really a lot, you can get very far without even having to learn the other, the class style and kind of all the resulting methods of composing components that were birthed out of that. Um, so yeah, so function components hooks, and, um, yeah, I would just, I would just start with that, do everything you can in that. And then I know that, you know, sometime over the next year there’s going to be a new API called suspense, or I think it exists now, but nobody’s really using it because the tools aren’t there to use it, but that is going to be the best way to connect to data. And, um, it’s, it’s really geared around giving users great experiences when they’re waiting for data or when those requests fail. And, you know, that’s a conversation for another time because it’s, you know, it’s all still being figured out, but suspense is going to be the way to connect to data in the future. And it will, it looks amazing to basically summarize like a lot of the things that people will be dealing with are going to be,
Jeremy Jung 00:56:24 Uh, props and state and contexts. And you said basically to look for solutions that use hooks for all of those things and avoid things that are using say class components
Michael Chan 00:56:40 At this point. Yeah. I think so much of the React world is going to there. There’s been a couple of people who’ve gone on gone on record saying that like, there’s going to be two areas of React, you know, the pre hooks and post hooks. And I think that’s true. I think that they have found the, the missing piece to really simplify a lot of our app code. And, um, yeah, if you’re getting started today, you’re just going to be delighted by how easy hooks are compared to maybe every other time you’ve looked at React.
Jeremy Jung 00:57:10 Another thing is there are a lot of libraries for things like routing or authentication things where when somebody is building their application using React, they may not know where to start. So are there like a list of recommended libraries or components that you recommend people use when they’re first getting started?
Michael Chan 00:57:35 Yeah. So React router is great. I think that, um, you know, they’ve, they’ve put a lot of care into that. Um, there’s a blog post now, and I know that there was a little bit of a split for a moment and there’s a, there was a reach router, uh, there they’ve, um, they’re working together again to make the next version of React router. Um, but yeah, that’s kind of the defacto choice. As far as routing goes. They’re a bunch of styling libraries. I’d say that if you, if you really wanted to avoid writing CSS, um, which you don’t have to, I write CSS all the time. I love it. There are some styling libraries, the most popular ones are styled components and emotion. Uh, so those are the two there. Uh, I’m trying to think about like what else I would like recommend across the board.
Michael Chan 00:58:21 I mean, really what’s I have a router once I have some styling solution. If you have the option of using a graph QL endpoint, Apollo does seem to be Apollo client seems to be the one that everyone loves in terms of, uh, connecting to a connecting to a graph QL data source. I see how you’d probably have to figure out how to, how to connect the data. There’s a bunch of components out there that allow you to use a hook or whatnot to fetch data from a restful end point as well. I couldn’t say that there’s like a universal winner, but there are a bunch out there. Yeah. I think that would be, you know, that’d be my starting point. I like to, I like to keep it really simple, but you know, React router is a must for me.
Jeremy Jung 00:59:02 So start with something like create React app or next JS, and then the router and install components and Apollo, if we’re using graph QL, and basically just start with that and don’t worry about anything else, like get started with those and see what you can build with that.
Michael Chan 00:59:19 Oh yeah, absolutely. And one cool thing next is that actually has a router built in. So because it uses the file system is like an API for, for routes, any additional folders that you put into the pages, directory get their own routes. Um, so you actually don’t have to think about routing at all and it works on server side or client it’s, um, it’s pretty amazing. So like when I don’t want to think about routing, I just use next and it’s it, it does everything that I want.
Jeremy Jung 00:59:42 One thing that I did want to touch on that I get a lot of questions about is when people are learning React, they often also start learning Redux or think they need to start learning Redux. I wanted to kind of get your thoughts on whether that’s something people should look at or whether that’s something that’s overkill, kind of what your thoughts are on.
Michael Chan 01:00:05 I can only say that I have never used Redux. Uh, so I’ve built a ton of applications. And for me, just the state management in React was enough. Uh, so I think that you can get really far without using Redux. One of the really neat things about re there’s two really cool things about Redux and, you know, one is, is that really teaches you how to use, uh, how to manage state with immutable concepts. Um, and so, so I think there’s some really good, valuable lessons to learn there from Redux. And then the second thing is that there’s a huge community around Redux. So there’s a ton of middleware that already exists, um, that you can just kind of NPM install and take advantage of. Um, and there’s some great developer tools, um, that you can take advantage of. But I feel like if you’re not going to take advantage of those, uh, Redux can be extremely cumbersome.
Michael Chan 01:01:00 And I think ultimately the, the thing that Redux, you know, gave us four years ago, um, has effectively been wrought into React via context, and there’s a used reducer hook. Um, so those are really the two core innovations of Redux and those exist in React now as first-class documented, you know, components. So I really don’t think that, I mean, personally, just from my experience, uh, I, I really don’t think that people should jump into React and Redux at the same time. Like I think that that’s always a bad idea. People don’t really get a good sense of where the boundaries are when they, when they do them simultaneously. However, I don’t think Redux is bad if it is a good fit for your team. And it provides you with, um, with structures that, uh, help you build better software, then I think that’s great. Um, but I think that, you know, I think that there’s a lot of stuff in React now that I would maybe try as a first, uh, first step. Um, and then kind of see if, you know, you need to take that next step and Redux.
Jeremy Jung 01:02:05 Yes. The last thing I’d like to kind of sum up with is testing with React components, how is testing and React different than how front end testing has traditionally been done? Yeah, I would
Michael Chan 01:02:20 It’s, it’s not markedly different. I think that anytime you have like, you know, asynchronous behaviors, you really have to do, um, you have to use some kind of framework that’s, you know, integrated, you have some use some type of testing framework, that’s at least a little bit integrated with the library itself. So it knows when those events have resolved. I know for me, I don’t personally do a lot of like application testing. Uh, I would say I can’t see Dodds has a really great course. I think it’s just like testing JavaScript or something, uh, dot com. He’s done a bunch to really like dive into that space. Uh, I know for me, I usually like to test, even though it’s a little bit slower, I like to test from like the most outside point when I’m doing views. So I use Cypress, which is just an end to end test, or it basically just fires up your app in a browser and, um, you know, it has, and you just kind of like, say, Hey, this thing’s here, uh, focus it, type this thing and hit submit. And you know, what, what resulted, that’s the approach that I typically like to take, just because I know it’s the most fail-safe in terms of mapping to the experience the user’s gonna get. Um, but you know, there’s trade offs. A lot of people like to, uh, test a little bit closer to, you know, the components and that’s, that’s fine, too. Awesome.
Jeremy Jung 01:03:38 So to kind of wrap up, do you have any questions I didn’t ask or any advice you’d like to give?
Michael Chan 01:03:46 Oh man. You know, I think just have fun. I know that there’s so much material out there and a lot of it comes from different areas of React and that can be really challenging to navigate. I think that if you stick to stuff that helps you with functional functioning components and hooks, you’re going to be, you’re going to have a really good experience. So, uh, the documentation’s really good. I recommend, uh, you know, checking it out there. I have a show called React podcast and I try as much as I can to have it be a beginner friendly. And so we have, you know, a lot of experts talking about all kinds of stuff. So, you know, graph, QL, hooks a React router, a bunch of stuff that applies to open source, like versioning animation in React. Uh, we just had some episodes on that. And, um, yeah. So if you, if you’re interested in React and hearing from a lot of people who are kind of making it happen, um, I think that that’s, that’s where I do a lot of my learning. And so hopefully other people can learn along with me.
Jeremy Jung 01:04:47 Yeah. I’ve listened to a lot of the episodes and it’s really a great resource. I mean, you get to hear from the people who are basically building the future of React or building the components, building the libraries and you really learn a lot. Awesome. Awesome. Well, thanks finally. So how can people follow you or follow the React podcast?
Michael Chan 01:05:06 Yeah, so, um, I am, chentastic on, uh, on Twitter, I guess in some other places, uh, I started doing a little bit more writing on dev dot too, trying to get in with that community. But yeah, chin fantastic on Twitter is probably the best connection point. I linked to a lot of my, my writing. I have a, a small resource called React patterns that I’m going to be kind of reworking to, uh, or it’s React patterns.com. I’m going to be reworking that to start showing off hooks. Um, and so hopefully that’ll be, um, it’s been a really helpful resource to get some, uh, newcomers into React in the past. And I’m hoping that I can refresh it to be that same resource for people today.
Jeremy Jung 01:06:15 Awesome. Well, Michael, thank you so much for coming on the show. Thank you so much for having me, Jeremy. This has been super fun. This has been Jeremy Jong for software engineering radio. Thank you for listening.
[End of Audio]
This transcript was automatically generated. To suggest improvements in the text, please contact [email protected].
SE Radio theme: “Broken Reality” by Kevin MacLeod (incompetech.com — Licensed under Creative Commons: By Attribution 3.0)
Good episode. ReactJS is very popular now. We migrate from Backbone to ReactJS. The thing is that I like about ReactJS is that it is going to replace AngularJS which is extremely confusing 🙂 On the other hand it doesn’t have it own UI libraries, so you still need to use Bootstrap or similar.