12 Sep 2019
On this post
In the previous post, we talked about ”plumbing” in React and how it affects the readability of our code.
We used React Context to avoid passing down the same props to multiple layers of components and to avoid repeating PropTypes definitions.
While React Context did eliminate the repetitions in our code, it introduced a different problem.
Our components became less explicit:
hiding the fact that both of these need some data in order to work. We could argue that not passing down props negatively affects the readability and maintainability of this code.
So I asked myself, could we stay explicit without repeating PropTypes? The answer is yes, by using TypeScript to describe the props of our components.
We’ll work on the sidebar-table app from the previous post, which still has the prop repetitions. To get started with TypeScript in your project, I recommend following one of the official guides. Here we’ll jump straight into adding types to the app.
One of the things I like about TypeScript is that you can add it incrementally to your project. You can introduce TypeScript only to some parts of your codebase and leave the rest of the app untouched.
Having that in mind, first, we’ll convert the
Table component which currently looks like this:
We immediately notice a few things:
productshas the same props as
selectedProductwrapped in an array
isSelectedfunction receives two products but there is no indication of that
Let’s start by defining our first type:
When rewriting existing, PropTypes-based components to TypeScript we’re looking for basic TypeScript types that could replace PropTypes, but essentially:
PropTypes.bool ➡ boolean.
PropTypes.number ➡ number.
PropTypes.string ➡ string.
PropTypes.arrayOf(PropTypes.number) ➡ Array<number>.
any to opt-out compile time checks for a variable.
void to indicate that a function returns undefined.
A function that accepts any parameter and returns undefined (could be a click handler) would look like this:
Yeah, I know, such handlers are called with a specific event type, but we’re going to talk about that later.
After having a basic understanding of which TypeScript types could replace certain PropTypes, we can define Product as:
Don’t forget to rename the files when you’re adding types, js to ts and jsx to tsx:
Now that we have the Product type ready, we can replace the
propTypes part of the
TypeScript also makes your editor smarter by giving clues about where you could improve your code:
Components with TypeScript
Table component looks like this:
TableRow in the same fashion:
We notice the repetition of the
onProductChange: (event: any) => void; function in
TableRowProps, and we’re going to use Interfaces to solve this problem.
Interfaces are constraints between the interface and the implementing type. They make sure that all (or some) properties or functions are present on the type that uses the interface.
Interfaces and types are mostly interchangeable, but there are some restrictions:
We can create an interface with a method and share it between
We’ll use MouseEvent to describe the incoming event of our click handler (Spoiler alert: this declaration is wrong, but TypeScript will warn us 🎉):
Both types and interfaces can extend other interfaces, but the syntax is different:
types extending interfaces:
interfaces extending interfaces
Catching early bugs
TableRowProps, the editor immediately warns us about the error we made:
We defined our interface method to accept
MouseEvent instead of
Product. Let’s fix the interface declaration:
We successfully cleaned up these two components from PropTypes repetitions, and you can find the updated code here.
Are you already using TypeScript? I think it adds slightly more complexity to your code than PropTypes but also provides more benefits.
Let me hear your thoughts on this in the comment section below or on Reddit!
If you found this content useful, please show the love by sharing it with others. Thank you!comments powered by Disqus