Hi there! 👋🏻
As development advances, we want to make things as efficient and easy as possible. Technology moves forward and users start to expect new and better standards for their digital products. Developers, as the main builders of these technologies, go after those standards, pushing for more independent, clean, and maintainable code bases. On the front-end side, these discussions have boiled down to component-based development and the appearance of modern frameworks, such as React and Angular, that push for those changes as an industry standard.
In this article, I will discuss my vision on how to make your theming and your components as efficient as possible, sharing some learnings I had along on my journey developing in such structures.
1. Why should we worry about Themes and Components?
Scalability: these types of strategies make your development faster as it re-uses the same UI through the entire app. Creating a new page is easier as it becomes mostly putting elements together and focusing on developing new things only when really introducing new features. This means, developers working more on adding value to the user and not constantly reinventing the wheel.
Consistency: it makes it much easier to keep your page experience consistent, almost effortlessly.
Good-karma: when you develop like this you create a well-documented code, without writing one line of text. This decreases the mental load on the entire team (that can easily use the right colors, fonts, and elements) without weighting on their memory. And, besides, it makes it much easier for other developers to jump on board and start contributing to the product with a much softer learning curve.
2. How to organize that, technically?
Ok, you are all convinced, I bet!
To start implementing this approach you first need to have an objective talk about using or not external component's libraries with the other stakeholders on your company. In this discussion, you need to align product vision with resources available.
If your product has a very strong visual appeal, using a very different style then you will probably have to create your own component's library. You will most likely hit that situation if you are working with "cool" B2C products that focus on, well, being cool. Something in the likes of Spotify or Instagram or Tik Tok. That is because even though libraries offer good customization it is a more standardized approach.
However, for most businesses, even though you want to have the freedom to add your themes and put together flows in different/ creative ways, you can achieve the wanted effect using an external library. If your business can use an external library, it really should. This approach saves a lot of development time and allows you to build on top, using a bunch of out-of-box solutions that will really speed things up.
There are many external libraries out there, to mention a few: Ant Design, Semantic UI, Evergreen, Grommet, Material UI, and many others. It is always good to test many libraries until you find one that has the level of customization and diversity that you want for your project. When analyzing them, keep in mind the type of UI you will need to put your project together and the level of customization you request.
I must admit that I do have a favorite and that would be the libraries based on the Material Design. I really like it because they are one of the most used ones in the market and, therefore, have a giant community discussing it. Also, whenever you have some doubt on how to approach a certain thing, like a dark theme or something of the sort, you can always refer back to the original Material Design and get the implementation answers you are looking for, in a faster way.
3. Organizing development with a designer's mind
It creates nice sync in the team if the front-end project is architecture taking into consideration how designers approach layout creation. This means, starting from the basics. The first thing that needs to be easy, available and reusable in your app are colors, shadows and things like that.
Material UI has a really nice approach to it as it offers a theme object that can be replaced and used throughout the entire app, being available in a global state.
breakpoints: Object
direction: "ltr"
mixins: Object
overrides: Object
palette: Object
props: Object
shadows: Array(25)
typography: Object
spacing: f e()
shape: Object
transitions: Object
zIndex: Object
`
(I know, it is so beautiful that I wanna cry 😢 )
That object is consumed inside a createMUITheme() function that renders the theme in the ThemeProvider - a context Provider that normally wraps the main component. The beauty of this setup is that you can programmatically pass different theme objects inside that function and, as long as they follow the right theme structure, they can be applied hassle-free. This is super useful for creating a dark theme on your application, for instance.
Of course, if you are not using Material UI you can still follow the same approach. Create a state on a global level, store a theme object and pass it in a way that it may be available through your entire application. React Context or Angular services are probably a good starting point to structure this. I think the key part here is to take your time creating this structured theme object with your design team. It will pay-off, for sure!
4. Create a clear architecture aligned with your team's design approach
When we are talking about Component-Based Development we are also (probably) talking about atomic design, which means, thinking about app layouts as smaller structures that compose a bigger entity. This means having small components, that compose functional compositions that end up forming a page. If that is the logic your design team is going to use (which is highly likely at this point in time), structure your folder also following that same naming pattern and distribution.
There are some techs out there that push for that project structure approach and is worth it to check them out. Next.js is a very known one that will bring this structure to your project out-of-the-box. Of course, Next.js brings many other things under its hood, so you don't really need it for folder structure but if there are other parts of it that will help out on your project, it is a nice tech to check out.
Side note: Even though that is not the point of this article, it is also valid to note that such a project structure will also help you out to structure your tests. So, your unit test probably will be more useful in your components, whereas your integration ones should go with your compositions and your e2e, well, probably on your pipeline, testing entire pages.
5. Use tools to document the components for developers and designers
You are making something so cool, right? Now we have to make sure that people know what they can (and can't) re-use when creating something new. In that sense, creating alive documentation to be the source of truth in your organization is key.
On the development side, you can use a tool for developing UI in isolation, such as Storybook for example. You just need to install it once and remember to create a .stories file whenever you create a new component. That will automatically create a folder that will display your developed UI.
To better consolidate this shared understanding of the components, it is also recommended to keep a design system documentation that uses Storybook to show the available components displayed in Storybook plus extra design patterns of the organization. I normally use one called Zeroheight, even though there are several other commercial software from Figma and Adobe XD, for example. This step is normally maintained by a designer with the help of a developer.
I hope this helps! These are just a few points for consideration that I think can help you build your front-end faster, more efficiently, and with less heartache!
Happy coding, everyone! ✌️
Top comments (0)