One of the crowning achievements in React (from my humble opinion) is the focus on components. A valuable part of these components is the ability to create declarative UI definitions and domain specific languages (DSL). In order to achieve maximum success with any framework it is important as a developer to exploit the strengths of the framework. Therefore, take advantage of components in React.
React allows for modular design with its component classes. As with any design pattern it is important not to over design your components but to break them down into logical chunks with single responsibility and composition as a design goal.
Let’s break down a weather widget.
Our widget will have three components: the temperature in degrees fahrenheit, an image representing our current conditions and a description of the same conditions. Considering this design, my mind automatically goes toward breaking down the components into three pieces:
- Image component used to display the image
- Degree component used to display the degree
- Description component use to display the description of the current condition
This may seem like overkill depending on which framework you are using (ReactJS vs React Native) but there’s a method to the madness. If we are thinking of creating a DSL, then describing out layout semantically gives us a nice abstraction (non-leaky, more on this later).
Consider the following:
Why the extra work?
In our example above, it could have been easily written without the extra components but the value here is that anyone looking at this can tell what each component is used for. The better thing? That the components don’t tell the user anything about their formatting (nor does she need to know anything about it!). This is what I mean when I talk about a leaky-abstraction. These occur when an api requires implementation details to be available just to use it. For example, if you needed to know how the
degree component worked just to use the component, then there’s an issue. Of course, with all software, there are exceptions to the rule. If an api is has strange behavior looking at the source code can be valuable.
My two cents
Here are a few guidelines I keep in mind when making components:
- Create single responsibility, composable React components.
- Keep them as stateless as possible! If you have some data to display, then send in the data
- Consider making your components into a domain specific language (DSL) so that you can create semantic UIs
If I follow these rules, I end up creating things that are reusable and better designed.