One of the most important skills in UI development is to "convert" a desing into parts which, in React, we call components.
It's nothing specific to React or even Javascript in general. Let's take a quick look at CSS world and we can see some interesting approaches like Atomic Design, BEM, SMACSS. All of them force you to think about chunks of UI which we can call, gues how, components!
I personaly still like BEM convention if I don't use tools like CSS Modules in my react project.
I wrote this article to clarify my personal thinking process I do everytime I am going to implement UI desing in React.
Any feedback is welcome :)
The example
Let's consider search at Booking.com as an example.
Strategies
Start big and split
Easier to use in smaller projects and prefered way to create PoC/MVP.
My thinking process here is like:
- Create one big component called "Search"
- I need to have a state for each input
- I need handlers for search action
- We have two date pickers, so I am going to use any third-party component because implementing it from scratch would comsume a lot of time.
Pros
- much faster process of building UI at first time
- we have only one place to manage state for the whole Search component
Cons
- code is hard to read
- naming for functions, variables, states is becoming harder as the component grows
Start small and compose
More efficient on long distance.
We should invest some time to think about the structure and split UI into "atoms".
In our example we can have following ones:
- Icons - each icon is a separate "dumb" component containing an image;
- Button - we can assume that the button can be use in another place so let's create it with required proo called "value"
- DatePicker - to set "check-in" and "check-out"
- Dropdown - to set guests number
- TextField - a wrapper component for text input. We can use it in DatePicker and Dropdown components.
By creating atomic components, we can use them as facades for third-party components (TextField as wrapper for input components from MUI) and make them less dependent on UI library of our current choice. It will be much easier to replace UI library in the future or even write our own custom implementation.
We can (I and should) think about what data we want or need to exchange between components from application perspective rather than focusing on props we have to pass to the component because it's been designed that way in external UI library.
Pros
- It's much easier to re-use these components in other places
- Easier to replace UI library / rewrite particular component
- Easier to write tests
- Less pain when the layout design change
- Components are namespaces for functions and variables hence naming is much easier #### Cons
- Costs a lot more time to think about components before we even touch the code editor
- We write more code at the beggining
Conclusion
In theory it should be obvious for most of us that the second approach is better, because it's more DRY, SOLID etc and it makes our code much more maintanable for sure. But sometimes we just have to deliver the feature ASAP or just add interaction and data to the design in order to test it more accurately.
Top comments (0)