Get Started with Modern React: Step by Step
S02・V23: Thinking in React (Part 1)
- We will explain that we should start with a mock of the UI.
- We will show you how to break up the UI of the app into a component hierarchy.
Thinking in React
React is, in our opinion, the premier way to build big, fast Web apps with JavaScript. It has reportedly scaled very well for Facebook and Instagram.
One of the many great parts of React is how it makes you think about apps as you build them. In this, and the next five videos, we will walk you through the thought process, of building a searchable product data table, using React.
Start with a Mock
Imagine that we already have a mock from our designer, and a JSON API. The mock of the searchable product data table looks like this:
It has a search bar at the top, with a checkbox below it to toggle showing only products in stock, and the table of products below that, with their category and price. Out-of-stock product names appear in a red color.
Our JSON API returns some data that looks like this:
[
{
category: "Sporting Goods",
price: "$49.99",
stocked: true,
name: "Football"
},
{
category: "Sporting Goods",
price: "$9.99",
stocked: true,
name: "Baseball"
},
{
category: "Sporting Goods",
price: "$29.99",
stocked: false,
name: "Basketball"
},
{
category: "Electronics",
price: "$99.99",
stocked: true,
name: "iPod Touch"
},
{
category: "Electronics",
price: "$399.99",
stocked: false,
name: "iPhone 5"
},
{
category: "Electronics",
price: "$199.99",
stocked: true,
name: "Nexus 7"
}
];
The data is an array of product items, which are objects containing category
, price
, and name
fields. And also, a boolean flag showing if a certain product is stocked
.
Step 1: Break the UI into a Component Hierarchy
The first thing you’ll want to do is to draw boxes around every component (and subcomponent) in the mock and give them all names. If you’re working with a designer, they may have already done this, so go talk to them! Their graphics program layer names may end up being the names of your React components!
But how do you know what should be its own component? Just use the same techniques for deciding if you should create a new function or object. One such technique is the single responsibility principle, that is, a component should ideally only do one thing. If it ends up growing, it should be decomposed into smaller subcomponents.
Since you’re often displaying a JSON data model to a user, you’ll find that if your model was built correctly, your UI (and therefore your component structure) will map nicely. That’s because UI and data models tend to adhere to the same information architecture, which means the work of separating your UI into components is often trivial. Just break it up into components that represent exactly one piece of your data model.
We have five components in our simple app:
- The
FilterableProductTable
contains the entirety of the example.
- The
SearchBar
receives all user input.
- The
ProductTable
displays and filters the data collection based on user input.
- The
ProductCategoryRow
displays a heading for each category.
- The
ProductRow
displays a row for each product.
If you look at ProductTable
, you’ll see that the table header (containing the “Name” and “Price” labels) isn’t its own component. This is a matter of preference, and there’s an argument to be made either way. For this example, we left it as part of ProductTable
because it is part of rendering the data collection which is ProductTable
’s responsibility. However, if this header grows to be complex, for instance if we were to add affordances for sorting, it would certainly make sense to make this its own ProductTableHeader
component.
Now that we’ve identified the components in our mock, let’s arrange them into a hierarchy. This is easy.
Components that appear within another component in the mock should appear as a child in the hierarchy.
Summary
We explained that we should start with a mock of the UI, and we showed you how to break up the UI of the app into a component hierarchy.
Next Up…
In the next video, we will continue with Part 2 of “Thinking in React”.