Learn TypeScript in practical context with React examples!

In this lesson we see how to refactor a function component into a class component with typed props and state as well as defaultProps.

react

Refactor a React TypeScript Function Component into a Class Component with defaultProps

In this lesson we start from an empty directory and bootstrap a React TypeScript app with create-react-app. Then we write our first React TypeScript Component and add our first types, including an optional type.

Write your first React TypeScript Component 

TypeScript's Basic Types are worth exploring with a view toward practical usage in React Components. Furthermore, you can comment your components and your types and have them show up in your tooling, for example your IDE, or even autogenerated documentation for your design system.

Write Self Documenting React Props with TypeScript Basic Types and Inline Comments

Because @types/react has to expose all its internal types, there can be a lot of confusion over how to type specific patterns, particularly around higher order components and render prop patterns. The widest and most recommended element type is React.ReactNode, and we build up to it by explaining the edge cases.

Use React.ReactNode for the children prop in React TypeScript components and Render Props

Individually defining props doesn't scale especially if you are wrapping native DOM elements, for example for the purpose of building up a Design System. Fortunately, there are easy strategies to lend full TypeScript support to your custom React elements, without excessive typing.

Impersonate Native DOM Elements with React Components and TypeScript for Full Reusability

There are many ways to type event handlers with TypeScript, and we use the case study of controlled components to explore the 3 major ways to do this. Then we refactor to use the createRef API to write uncontrolled components, and explore the typing strategies for that as well.

Write Controlled and Uncontrolled Components for Forms with React and TypeScript

Here we refactor a React TypeScript class component to a function component with a useState hook and discuss how props and state types can be modeled accordingly.

Write a stateful Component with the React useState Hook and TypeScript

egghead

TypeScript for React Developers

https://app.egghead.io/api/v1/lessons/react-refactor-a-react-typescript-function-component-into-a-class-component-with-defaultprops/subtitles

Instructor: [00:00] Let's take this function component and refactor it to a class component to learn how that's done in TypeScript. We're going to extend React.Component. We're going to wrap the render around the return. We still have to destructure the label.

[00:19] Now we come to a problem because label doesn't exist on the props. We've removed the props that we've manually typed. There's no way to insert it. Fortunately, the place to put it is in React.Component where the TypeScript typings define generics for you to overwrite. Generic, let's feed in the props as the first argument.

[00:47] Now you can see that it expects label as a prop. To prevent a lot of destructuring, you can move the defaultProps up to the static defaultProps property and define it over there. Now let's also add some state to our component. We'll add another type and call it MyState. We'll have an isOn Boolean. We'll pass that in as the second argument to React.Component's generics.

[01:24] Now we'll have to define the state somewhere, isOn being true from the beginning. Now we can take that isOn from this.props, and we can create some styles based on it. I'm going to give the button a background color based on whether the button is on or off, so green if it's on, red if it's off. We can pass that into the style.

[02:06] Now we're pulling in some state, and the state is properly typed, but we also need to be able to write an event handler. We'll call this toggle this.setState({isOn: ! This.state.isOn}). We'll toggle the state of it. We'll pass that into the button's onClick method, this.toggle. Now we have a working toggle.

https://app.egghead.io/api/v1/lessons/react-refactor-a-react-typescript-function-component-into-a-class-component-with-defaultprops/transcript

https://app.egghead.io/api/v1/lessons/react-write-your-first-react-typescript-component/subtitles

Instructor: [00:00] Start with an empty directory. We're going to run Create React App with the TypeScript option. Once it's installed, you can see that your package.json has a bunch of types packages alongside your regular React packages.

[00:16] We're going to run Yarn Start just to show that this is a regular functioning app. You can see in app.tsx that there's not much difference between regular React and React with TypeScript. In fact, TypeScript is a superset of JavaScript, so this is to be expected.

[00:33] We're going to write our first component. It's going to be a function component. Here, we'll see the differences. I'm going to add a button component that's going to be a regular React function component. This is going to return a button with the default text of Hello World.

[00:51] I'm going to use that button component inside of my app, which is scaffolded by Create React App. I'll just delete all the old stuff that it's giving me by default. So far, we haven't written any TypeScript, but that's about to change.

[01:06] We'll take in some props for the button and we'll give types to the props. You can define the types in-line, but I prefer to define it separately because that scales better. We'll take a label prop and we'll declare it to be a type string.

[01:22] Instead of Hello World, we can just put props.label in there. If I save it right now, it's going to show an error. It expects a label prop, but it wasn't passed a label prop in the app.

[01:35] To solve that, you can actually pass a prop here as shown, or you can refactor this button component to take an optional prop by adding a question mark.

[01:49] That works as well, but there's no text inside the button. You might want to destructure it and add a default. You can do that just as you would in a regular React app, Hello TypeScript. That's how you write your first React and TypeScript component.

https://app.egghead.io/api/v1/lessons/react-write-your-first-react-typescript-component/transcript

https://app.egghead.io/api/v1/lessons/react-write-self-documenting-react-props-with-typescript-basic-types-and-inline-comments/subtitles

Instructor: [00:00] Let's discuss how the basic types in TypeScript may be useful in various conditions in React components. Here, I have a list of props that I've passed into my Button component. We're just going to go through them one by one.

[00:15] The first one is the string type. This has all the properties of strings as you might expect. You might see some older guides tell you to type readonly for your properties, but that's not really necessary.

[00:29] When it's passed in as a generic to React.Component, it's already cast as a readonly type. If I try to assign this, it's going to tell me that it is a readonly property. You don't have to explicitly assign it readonly. You can if you want to.

[00:45] Next, we have the number type. This type behaves as you might expect. Likewise, the Boolean type doesn't allow any other properties, apart from valueOf.

[00:55] To accept arrays of types, you simply particular square brackets beside any of the existing types. Then you have access to the array methods of them. What's more, once you call map on an array type, you get access to the underlying type as well. Here, I have an array of Booleans, as defined in my new props. The underlying function is inferred to be a Boolean. That's very helpful.

[01:24] String props are often used to represent multiple states, for example, failed, success, or waiting. However, it's not very robust to typos, where this would immediately fall through to the else statement.

[01:40] It's not great for autocomplete or logic checking. What might be better is using string literals, where only exact strings are specified. Here, if I refactor this, then I immediately know that I'm trying to assign a string that is not expected.

[01:58] Furthermore, TypeScript understands conditional logic. If I'm in the else block after I've already checked for one part of the string literals, the remaining statuses are all that is available to me, even though the actual prop has three states.

[02:15] There are many ways to type objects. If you don't really care what the object's shape is and you're just passing it on to another function or component, you can just type it with the keyword object or an empty object shape and just pass it on as per normal.

[02:33] If you try to access it, it's not going to let you fill in anything because nothing's valid. Nothing is a member of that object. If you actually want to use your object inside of your component, you should specify what the object shape is. Then you'll have access to the object properties without TypeScript complaining.

[02:55] Arrays of objects also behave just like the other array methods as well, where the inner object is exposed once we perform an array method on it. Similarly, to objects, if you are just taking in a function and you don't really care what the call signature is, then you can just call it a function and pass it on or pass it or call it without arguments.

[03:19] The problem comes when you try to call it with arguments because TypeScript doesn't recognize that there are any arguments to this function. Functions that don't return anything are assumed to return void. If you want to define arguments, you define it as though you are defining the function itself. Then here, you can just call it with the appropriate type.

[03:38] The self-documenting nature of TypeScript extends beyond just type annotations. You can also comment inline to have it pop up in your tooling. For example, in VS Code, you can see the comments that are laid right next to your properties. You can use multiline comments, as well as Markdown.

[04:10] For more ideas on things you can type, head over to the TypeScript Handbook and look up documentation for tuples, enums, and many other type combinations.

https://app.egghead.io/api/v1/lessons/react-write-self-documenting-react-props-with-typescript-basic-types-and-inline-comments/transcript

https://app.egghead.io/api/v1/lessons/react-use-react-reactnode-for-the-children-prop-in-react-typescript-components-and-render-props/subtitles

Instructor: [00:00] Even though we may not always be typing every single prop ourselves, it's useful to talk about the children prop because it helps us understand the underlying React types.

[00:13] For example, if I wanted to refactor my button component with a string label to accept things other than strings, I would have to add additional types like so.

[00:25] One way to figure out what type to add is actually to just go ahead and use the type and let the compiler suggest to you what types it needs. Over here, it's saying type element is not assignable to string, so therefore, we're giving it an element. It's not accepting it because it expects a string.

[00:49] What if we just did a union type with element? That actually does work. What if we wanted to use React's composition model instead of a whole bunch of props?

[01:02] For example, we can refactor this and no longer use the label prop and put our div as a child of the button. There is no longer a label prop, so we have to name this children and accordingly lay down props.children and this also works.

[01:28] However, what happens if we try to have multiple children? Well this happens. In order to solve that we can make this element into an array.

[01:42] In fact, there are a number of different ways to type children and the auto-complete will suggest a whole bunch of different things.

[01:49] For example, you can have React.ReactChild which is functionally the same as string and JSX Element as an array.

[01:57] If you choose to type it with the type that's actually named React's React children, it will fail to compile because React's Reach children is meant as a utility for iterating through children and not for typing React children. All in all, the safest rule of thumb is to type children with React.ReactNode.

[02:24] Even then, it's not the be all and end all situation. If you're trying to write a render prop and expect your children to be used as a function of a child, you're going to have to change accordingly. Now you can use function as a child.

https://app.egghead.io/api/v1/lessons/react-use-react-reactnode-for-the-children-prop-in-react-typescript-components-and-render-props/transcript

https://app.egghead.io/api/v1/lessons/react-impersonate-native-dom-elements-with-react-components-and-typescript-for-full-reusability/subtitles

Instructor: [00:03] Let's say I've been making my React and TypeScript app and I've been using a native dom element for a while. Then I decide to make a reusable component to add some extra features, for example, a label property.

[00:19] Here I've defined a label prop, and I've used it as my text. I decide to swap out my small-b button for my large-b custom button and specify my label inside a prop instead of in the native button.

[00:39] This refactoring works. Maybe this is the start of my new design system. However, the problem comes in when I start to want to use the other properties of a button.

[00:53] For example, if I wanted to pass in custom styles, and for example, I wanted to make styling to have a border of five-px-solid-green and I passed it in here, that would not work because style is not a declared prop of button.

[01:19] One way to resolve this is to add a style prop explicitly declared. I can declare inside my prop. I can add a style. It will be optional. I can say it takes React.css properties. Now I can apply the style to props. Style equals to props.style.

[01:44] The problem is that this approach doesn't scale. The button inherits properties and attributes from the general HTML interface, the HTML attributes, as well as the specific button element interface. All of those things can be looked up in index.d.ts inside of your node modules, inside of @types/reactindex.t.ts.

[02:13] You could conceivably refactor to spread your props, but that still leaves the task of laboriously defining every single prop that a button has on top of your synthetic button. What you really want to have is all of the base properties of the button element, which you can copy and paste.

[02:41] Then for the remaining props that you want to continue to add, you can just use an intersection type. That resolves both your custom properties, as well as the general other properties that are required as well.

[02:59] For example, on-click is defined neatly without needing to define it manually yourself.

https://app.egghead.io/api/v1/lessons/react-impersonate-native-dom-elements-with-react-components-and-typescript-for-full-reusability/transcript

https://app.egghead.io/api/v1/lessons/react-write-controlled-and-uncontrolled-components-for-forms-with-react-and-typescript/subtitles

Instructor: [00:01] Here, I have a classic React form that's made with controlled components. I've lifted this exact example from the React docs. The only things I've done to it are to type the events with an any type, which matches anything. This works if I type in "Egghead" in the form and I submit. It's going to alert back to me the same value.

[00:27] However, it's very easy to make mistakes. For example, if I mistype here, there's no errors that's going to be appearing. More crucially, if I mistype any values in my set state, no errors will happen as well, but I will be unable to type in my form.

[00:50] As we know, one way to avoid this is to specify the generics of the props and state. Here, I'm going to specify just the state since we don't have props. That immediately shows us the typos in our app.

[01:11] However, leaving the event type as any allows mistypings like this, which causes issues in actual runtime code. Here, we have a "undefined is not a function" type error.

[01:25] In order to type the event, we can often look to the event handler on the native DOM element. For example, the onChange event over here tells you that it expects a type of event React.ChangeEvent<HTMLInputElement>.

[01:43] We can basically just copy that and paste that into our change handler and do the same thing for a submit function on the form. Here, it expects a React.FormEvent with an HTMLFormElement.

[02:03] That immediately raises the error, the type error over here on the invalid property. We can delete that. Notice that we also get autocomplete, which further prevents typos. Now we have back our functioning form.

[02:26] Notice as well that this method of typing relies on type inference to infer the return method of the change handler. That may not be desirable in some situations. The other way to type it is to type on the left-hand side of the assignment.

[02:42] Here, I have removed the type for event. If I just type what handle change is supposed to be, React.ChangeEventHandler with the type of HTMLInputElement, then the return type is also assigned. Event is now known to be of type React.ChangeEvent<HTMLInputElement>.

[03:13] There are two valid ways to do things based on how you prefer to infer the type of your functions. Of course, if performance is not a concern, as it is in most situations like these, you can actually inline the entire function and rely on type inference within the actual event handler inside the JSX.

[03:38] Over here, it's known that onChange expects a function of this signature. Therefore, the function that's immediately applied here is inferred to have that signature.

[03:51] Finally, let's look at how to write this with uncontrolled components. We're going to need a ref, which we create with React.createRef. We're going to pass that ref into our input while getting rid of the change event.

[04:09] As you can see, we immediately run into this rather scary-looking error message, but really all it's saying is that it's expecting one of these types of valid inputs to the ref property. In reality, React.createRef could be filled with anything. They just want to be sure.

[04:29] Here, we know that we're going to just use this ref for referring to the input DOM element. We're just going to copy that exact thing from the suggestion. We're going to put it on the left-hand side and pull the ref object from the React namespace. That will resolve our type issues. Now we have a working uncontrolled component.

https://app.egghead.io/api/v1/lessons/react-write-controlled-and-uncontrolled-components-for-forms-with-react-and-typescript/transcript

https://app.egghead.io/api/v1/lessons/react-write-a-stateful-component-with-the-react-usestate-hook-and-typescript/subtitles

Instructor: [0:00] We have here a stateful Toggle button that toggles between red and green and accepts a default prop. Let's say we want to use Reacts Hooks to do the same thing. How are we going to achieve that?

[0:17] There are no static properties in functions, so the first thing to do is to move the default props out to a separate line. Next, we convert the class into a function. We remove the render method as well as take props inside the function arguments.

[0:45] All event handlers are now variables as well as state. You can wrap all state in React.useState as well as remove all references to "this." That gives us back our working Toggle.

[1:07] Notice that TypeScript is able to infer the types of the state, but you can also give it a hint by passing in a generic to React.useState similarly to how we passed it into React.Component. This is helpful, for example, if you want to specify a union type, and you want your state to be inferred accordingly.

https://app.egghead.io/api/v1/lessons/react-write-a-stateful-component-with-the-react-usestate-hook-and-typescript/transcript

TypeScript for React Developers

Shawn Wang

Course Content