{"id":20443,"date":"2020-07-09T10:30:59","date_gmt":"2020-07-09T09:30:59","guid":{"rendered":"https:\/\/blog.marvelapp.com\/?p=20443"},"modified":"2020-07-20T17:18:26","modified_gmt":"2020-07-20T16:18:26","slug":"making-good-component-design-decisions-in-react","status":"publish","type":"post","link":"https:\/\/marvelapp.com\/blog\/making-good-component-design-decisions-in-react\/","title":{"rendered":"Making good component design decisions in React"},"content":{"rendered":"

Most of us who are using React love it for its declarative nature and how it encourages us to think about complex applications as a composition of multiple UI components.<\/p>\n

However, as developers, we don\u2019t always spend enough time to think about our component design and how components will scale and change with our application. At one point, you might start noticing massively complex pieces of code across your codebase and wonder what\u2019s going on. In fact, if you have worked on a project long enough you might not even realize there\u2019s a problem, until a fellow team member asks to be walked through a certain piece of code.<\/p>\n

Imagine you are both looking at a complex component that is part of a feature that needs to be extended. You might find that reading and understanding the code requires carefully following different props to get an idea of how user interaction changes the data this component receives. On top of that, you might also need to follow those same props in some wrapping parent component (just one level up, if you are lucky) to determine where the state of each prop is, and how that data is then used, for example, by an API.<\/p>\n

If you have been in a situation where reasoning about a particularly complex component produced some discomfort or confusion, it is good to realize that this is likely a side effect of component design being an afterthought, rather than a crucial step in UI development. So why don\u2019t we care more about component design?<\/p>\n

\"\"\"\"<\/a><\/p>\n

Every codebase has its complexities. Building a product and quickly delivering features to users brings more value to your team (and business) than having over engineered solutions. The nature of React lets you quickly compose with reusable components and add missing functionality by passing a couple of more props, but it is our responsibility as engineers to consider solutions and approaches that are resilient to change and assume that our products will evolve. The future of the product and good component design should be on your mind, but it is often forgotten. Sometimes it\u2019s hard to wrap your head around how to translate a visual design or a requirement to a functioning, testable React component. Perhaps the feature you\u2019re about to build seems complex or maybe you\u2019re dealing with a component that seems to have a lot of responsibility. Or maybe you struggle seeing how an existing component that is already overloaded with tens of props can be extended or reused in your app.<\/p>\n

Here is one approach that I like to follow when thinking about the design of my components early in a feature\u2019s lifecycle.<\/p>\n

Thinking of components in isolation<\/h2>\n

Let\u2019s think about React components in general terms. React components are functions. Regardless of how<\/em> you implement a specific component \u2014 as a class or as a function \u2014 your component probably takes some props as arguments and returns JSX that describes what would eventually be rendered in the DOM. With React, we aim for writing our components as pure functions <\/em>with respect to their props<\/a>. Meaning, for any given set of props, our components should return the same JSX.<\/p>\n

Following the Single-responsibility principle, a function \u2014 and therefore a React component \u2014 should be doing one thing. For example, a component that only renders a user\u2019s avatar given an image URL would be considered a component that follows this principle. On the other hand, the principle would be considered broken if you have a component that renders a user\u2019s avatar if it exists, and calls an API to generate a random image if it doesn\u2019t.<\/p>\n

Thinking about React components in isolation and identifying the role each component plays on its own will keep you from writing overly complex, multi-purposed code. Pure components with a single responsibility means less props which, in turn, yields a component that is easier to test and easier to reason about.<\/p>\n

With this in mind, how can we actually determine what<\/em> the responsibility of the component really is? And how can we keep it resilient to change?<\/p>\n

Thinking in terms of \u201cvalue\u201d & \u201conChange\u201d<\/h2>\n

We saw that we can generally think about UI components as functions that take some data and return a visual representation of that data. We can think about a simple input component in a similar way. A text input component (an input with a type=\"text\" attribute) takes a string as its data and renders an input field with that value. Similarly, a checkbox input component takes a boolean and renders a checked or unchecked box. You might notice that an input field and a checkbox represent different data types \u2014 a string and a boolean respectively. Understanding this can help you approach the design of your own components in a different way.<\/p>\n

Imagine you are working on a new input component for shopping items which will be used within a larger shopping form. It should look like this:<\/p>\n

\"\"\"\"<\/a><\/p>\n

The user interacting with this component should be able to type in items into the field and every item that\u2019s added should be shown as a little label. The user can then keep on adding more items or remove any existing item by clicking the \u201cx\u201d button on the label. It should also be possible to clear all the labels by clicking \u201cclear all\u201d.<\/p>\n

Take a moment to think what data type this component represents? How will the component change that data over time?<\/p>\n

You might notice that this component represents a list of strings \u2014 the shopping items the user has added. A good way to represent this data is simply by using an array of strings. I like calling this the component\u2019s value<\/em><\/strong>.<\/p>\n

\"\"<\/a>

A shopping form component that uses our new input component \u2728<\/p><\/div>\n

For simplicity, let\u2019s keep the shopping items as strings. In a real-world application individual items in this kind of use case can be more complex, but the same principle still applies.<\/p>\n

The next thing to consider is the changes the component can make to its value. We mentioned in the requirements that this component should allow adding & removing individual items, as well as having a \u201cclear all\u201d functionality. You could choose the following approach:<\/p>\n

\"Making<\/a>

Passing multiple callback props to InputWithLabels. This is what we want to avoid.<\/p><\/div>\n

You might have noticed that in this example, as well as the first one, I have omitted the implementation code for the InputWithLabels component. Regardless of its implementation detail, designing InputWithLabels such that it uses multiple callback props comes with some downsides. The first problem that arises is prop bloat. The complexity of the component increases solely by the fact that it requires 3 callback props to perform its duty. The second problem is that the parent component (in our case that\u2019s ShoppingForm) is responsible for updating the data each time any of the callback props are called, and before persisting that in its state. This means that if InputWithLabels is reused elsewhere, that logic will need to be re-implemented.<\/p>\n

Remember that our component\u2019s value<\/em> is an array of strings. Instead of having individual props for each required functionality\u2019s handler, let\u2019s focus on how our value<\/em> is changed by the component depending on its different functions:<\/p>\n