DEV Community: Bea Oliveira

Building a scalable strategy for theming and components

Bea Oliveira — Fri, 26 Mar 2021 19:55:22 +0000

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! ✌️

Nx in Storybook - part 2

Bea Oliveira — Fri, 04 Dec 2020 13:30:54 +0000

Hi there! 🖐🏻

So, the day came in which we did a big refactor on our monorepo. We were expanding the number of projects that were going to be supported in our nx project and that called for a restructuring of the libs and dependencies to assure performance and coherence. As we started refactoring the libs we realized that was impractical to launch storybook for each one of the libraries, which was going to kill the whole point of having it on our project.

I wrote a few months ago a post on how to install storybook on a nx project and if you didn't catch that first part, you can check it here:

Using storybook in an Nx monorepo

Bea Oliveira ・ Oct 26 ・ 3 min read

#components #monorepos #storybook

In this one I share on how to install storybook with nx and the main thing is that you will have to add a config for storybook on root level and on each lib. And then you run it per lib (npm run storybook:mylib).

Now, I learned a way to actually be able to run all the stories inside the project at once. I think it can be a nice addition to those working with this.

I got this idea from this video 💪👏

1: Steps to fix the problem and my experience implementing it:

In the shared library create an upper-level lib using the create lib command for nx
Install storybook inside the library
In config.js file change the path to the where the stories should be watched
- Replace:
configure(require.context('../src/lib', true,/\.stories\.tsx?$/), module);

With something like this:

configure(require.context('../..', true, /\.stories\.tsx?$/), module);

Do you see it? That first part in context call back you should adjust to a higher level path, so it will take all the stories, even the ones in deeper libs.

Last thing: run your new lib. And, there you go, it's ready! 🚀

Hope it helps, peeps!

Happy coding, everyone ✌️

Setting a Dark Mode with Material UI

Bea Oliveira — Mon, 16 Nov 2020 17:40:08 +0000

Hey there!

I recently worked on setting up a dark mode in a project using React and Material UI and I wanted to share some of the things I learned while doing that. There are each time more users that prefer using the web in dark mode for more reading comfort and it is a feature that is slowly becoming an industry-standard such as responsiveness and others. There are different tutorials online that explain how to set a dark mode theme using React Context and I really recommend you check them out if you haven't yet. In this post, however, I want to focus on my experience implementing it in a real, working commercial software, outlining some problems and ways my colleagues and I found to solve them. Here I will assume that you already have basic knowledge in React, React Context, Material Design, and Material UI.

Ok. Let's get cracking, shall we?

1. Set a ThemeProvider and a getTheme() function from the beginning of the project

When I started working on adding a different view mode I was positively surprised that my colleagues had already set up a ThemeProvider and proper getTheme() function in the project when they first started using the Material UI library. That is a cool practice because it is something that can be used both for applying themes from different users/clients (if your company ever takes that road) and it can also be used for adding a dark theme. This is a good practice when working with Material UI as it allows you to manage your primaries, secondaries, information, and error colors in one unified file. Also, as far as creating legacy code goes this one guarantees positive karma on your account, for sure.

You can find more information on how to set a theme and create a ThemeProvider in Material UI's official documentation. There are also a few videos online that are super helpful. I recommend watching this one for a nice overview (the theme stuff can be found from minute 24:07).

I think that one main thing to keep in mind when you apply this in a real-life project is that all these parts, the createTheme() function, the values from your palette, spacing, breakpoints, and so on, will be separated files. When creating your palette specifically you can follow the data structure used by MUI for their default theme, so you keep a matching structure.

2. Palette type dark magic

Okay, so you have your ThemeProvider, your function, your separate palette files all beautifully created. Now, let's say you want to create a dark theme. The beauty of using Material UI is that you won't necessarily have to manually set colors for dark theme. You can only add a type value 'dark' and boom. Magic!

So inside your dark-theme.colors.ts you will have something like this:

palette: {
    type: 'dark',
    primary: {
      light: myColors.grayLight,
      main: myColors.gray,
      dark: myColors.grayDark,
    },
    secondary: {
      light: myColors.whitesmoke,
      main: myColors.white,
      dark: myColors.snow,
    },
    info: {
      light: myColors.greenLight,
      main: myColors.green,
      dark: myColors.greenDark,
    }

Now, this will only work if you followed the Mui default theme structure. This means that for your background you used something like theme.palette.background.default and for your text color something like theme.palette.text.primary. If you did that then you are almost there.

Honestly, in this process, the trickiest part is dealing with the primaries and secondaries for the dark theme. Normally the designs are done mixing and matching the color scheme. Sometimes the primary is the background and sometimes it is the font color. This type of setting will make the dark mode harder to manage for sure and these are the situations that you will need to spend more time figuring out how to adapt to. This is one of these situations that having good design-ops and a nicely done design system that takes into account a dark version of components will come a long way (owww ideal world, how we wish you could ever be real ❤️).

3. Managing the view mode state in the AppProvider level

I guess that this is the part that is the hardest to abstract from the tutorials, after all, you will need to find a way to change the state in the AppProvider level, in which you will pass the value theme for your ThemeProvider. However, differently from the tutorials, your button that sets the state will probably not be in the same file. You probably will keep your button on a navigation bar or some other element that is elsewhere in your app. One solution we used to make this value available at the highest level was saving it as a cookie. So, when the action button for view mode was clicked, then I would set a cookie with the right file theme name. This way we could also save the user preference for the future and next time they were on our platform they would see their last preferred view mode.

Great. The value is saved. But, if the user clicks on the button we don't want the page to reload, right? Another important question for us then was how to change the value passed to the Theme Provider without triggering a reload? The solution here was to actually pass a function instead of a value to the ThemeProvider.

So, in your AppProvider.tsx level you would have something like this:

interface AppProviderProps extends RandomEl {
  randomData: {
    viewMode?: Brand;
  };
}

const AppProvider: React.FC<AppProviderProps> = ({ ...props }) => {
  const { randomData, children } = props;
  const [viewMode, setViewMode] = useState(userData.viewMode);

  return (
    <StylesProvider injectFirst>
       <MaterialThemeProvider theme={getTheme(viewMode)}>
         <ThemeProvider theme={getTheme(viewMode)}>
         </ThemeProvider>
       </MaterialThemeProvider>
    </StylesProvider>
  );
};

export { AppProvider };

This way, when the cookie value changed, we were able to trigger a state change in the AppProvider level and display a different view mode without a reload.

Of course, there are many different ways of doing this. But the idea in this article was to just bring some ideas to those who may be working on something similar.

Happy coding, everyone!

Using storybook in an Nx monorepo

Bea Oliveira — Mon, 26 Oct 2020 11:33:47 +0000

Hi there! 👋

I have been working with Storybook as a layer of component management in projects for a while now. It is quite a nice tool when working with components as it makes it much easier for myself and the team to remember all the components we have already created and how to easily implement them in other parts of the platform. Recently, I started working on a new project, and even though the project already had Storybook installed, it was outdated and it wasn't running anymore. Because I believe that it is a tool that helps the workflow, I decided to fix it. The project is an nx monorepo and when trying to fix it on our project I learned that setting up Storybook for that sort of project has a few particularities. Maybe some of you will go through this as well, so I decided I could share a bit of my experience with it.

So here are some of my learnings:

1. The CLI Installation for Storybook doesn't work in monorepos

Ok, so my first idea was to just uninstall everything and run their CLI:

npx sb init

That is the first step for installation recommended in Storybook's official documentation and it is so beautiful when it works. Very elegant and simple ❤️
It works in most types of projects however with the nx monorepo it won't do the trick. The CLI will install storybook in your project and it will work at first, however with the CLI installation the monorepo folder structure won't be respected and you will have problems afterward when deploying it. Long story short, better just skip the CLI installation in that case, because it won't work in the long run.

2. You need to follow the documentation that is on the NX website

Well, when my first attempt following standard Storybook documentation didn't work I went to look if there is anything in the NX documentation. And, voilá, there is specific documentation about Storybook for Nx that you can check in this link.

It is a two-step process. First, you need to add the plugin.

npm add --dev @nrwl/storybook

And then, inside the app you want to have Storybook you need to generate the specific configuration.

nx g @nrwl/angular:storybook-configuration project-name

PS: the command above is for projects built in angular, if yours is in react just change the word "angular" in the line above to "react".

3. You need to install it for each app you wanna have Storybook inside your project

This is the biggest difference when running Storybook in a monorepo: you will have to install it in one specific app and it will only render stories that are inside such app. So, if you have inside your monorepo one library in which you keep your components that is probably the best one to install Storybook in.

Another important difference is that when launching storybook you will have to specify which project you want to launch with that. Imagining that you installed it in your component library that is called MyComponents, to launch it you would type in the command line something like with this:

npm run storybook:MyComponents

Of course, if you keep a different folder structure and actually each app has its own components inside your monorepo you will have to install it in each project and they will have to be run separately. In this case, it could possibly make your monorepo build slower if when you build it you also deploy a public version of your storybook, for example. So, keep it in mind as well.

Hope it helps!
Happy coding, everyone ✌️

Design System: Heaven or Hell?

Bea Oliveira — Wed, 01 Jul 2020 12:15:38 +0000

Design Systems have been booming all around the tech world. Frameworks based on components and overall market need for brands to communicate the same image throughout products and channels have made design systems a popular dream between big and growing companies. Normally, the design system gathers the companies' shared components and elements that need to be reused on different apps, web platforms, Instagram campaigns, Power BI dashboards, you name it. So, to be more specific: buttons, lists, tables, colors, fonts ... Pretty much all you need to have a coherent look for the brand on a product and communication level.

The thing is, even though design systems are a very cool thing, the practicalities on how to operationalize it are still a hard thing to crack. That is because there is a complicated puzzle at the center of this whole discussion. The bigger the company, the more important to have a design system. After all, bigger companies have different products on different platforms and teams spread on different places on earth. However, the bigger you are the harder it is to make an effective design system exactly because you have different (already developed) products and different systems all around.

I have experienced first hand putting together a design system in a huge company with many different products and let me tell you, that is a hustle. If for one side you need to centralize the designs somehow, on the other you can not depend only on the design system team's workforce. Besides that, in a big company, different design needs came from different business' contexts. Also and perhaps even more problematic, when we talk about components there is a matter of implementation. Can you imagine one team being responsible for the components' design and implementation of more than 40 products? It is virtually impossible.

After starting working with this, I got the habit of going into cool companies' design websites. Many of these companies keep a .design domain - such as Spotify, Google, Airbnb, and Facebook - in which they share articles and news on their design systems. By benchmarking that way, I noticed that when it comes to this topic there is no one size fits all solution, unfortunately. And normally the approach is iterated many times. I believe that finding the sweet spot between centralizing the design and simplifying the production pipeline depends on how your company is already shaped and how much adoption you are going to find in it.

It is important to take into account that the design systems won't live outside your development process, so the rules of that development flow will apply to it as well. For example, one thing that we know well in the tech development world is that rooted legacy systems make everything harder. I would say that depending on how much legacy you have, the more realistic you need to be on your design system's potential reach. Do not go around talking about the component library and other cool-modern things if your system was build using something old, like AngularJS or PHP monoliths. In that case, I would say that there is a need to have an honest conversation between development and design on how far can we go with the unification. The trick in that situation, I believe, is to remember that the goal is to have a coherent design and even though it may seem that a component library is the only way to do that, that simply isn't true. A component library can't guarantee the success of your design system, neither its absence will necessarily result in its failure.

The situation is, of course, different for new companies. In that case, I believe that the design system should be developed from the early days on its full glory. The catch here is that early-stage companies are fully focused on survival and the rest seems secondary, but that is exactly the right time to start building good foundations for the future. Investing in openly sharing within the organization a component library, version-controlled design files, and code, will payout in the future, for sure. Having a reviewing process that expands the individual teams can also work as a way to generate accountability to the unified design guidelines.

Finally, on a more practical note, one common thing that is useful for building a design system in any size company is to offer well-documented guidelines. You may or may not be able to provide assets such as components or things like that, but you can always offer complete and clear documentation on what is the unified design patterns that represent your company as a brand. Also, the design team should always see themselves as a support system inside the company. Talented people are working on different teams and these people are probably the best at understanding that product and team-specific need. There needs to be trust, a rigorous accountability system, and clear communication so that a coherent design can be developed throughout the teams in a seemly organic way.

The impostor inside

Bea Oliveira — Fri, 12 Jun 2020 10:30:17 +0000

There is no news here: most women suffer from impostor syndrome. If you have never heard of the term before, it refers to that weird gutsy feeling you get once you get a job, a promotion, or stands out in any way. You can recognize it in that little voice that tells you you are not enough and that sooner or later someone will discover you are a fraud. It is a crippling feeling that makes a lot of things in our career harder than they should be.

I believe that impostor syndrome plays a big role in the gender gap that undoubtedly exists in tech nowadays. As a woman and a programmer, I have identified on myself and my colleagues how this feeling damages our mental health and career progression. It makes us afraid of trying and unsure of our potential. Because programming is an art of practice much more than a skill you can acquire just by reading about it, insecurity and the fear of being discovered as a fraud hinders many women from daring and taking risks, which ultimately affects women's presence on the tech market.

I understand that feeling insecure is not a women's prerogative, there are many men out there that can relate to that. However, the impostor syndrome thing goes deeper than insecurity and it plays a structural role in gender inequality in the market place, especially in the programming sector because of its particular characteristics.

As I said in the beginning, this is no news. Actually, it is a very old discussion, so why write about it again? Because I believe that only when we address this dark brain pattern, call it by its name and recognize who it is affecting the most, then we can start making real change in tech. As someone that is in the job market and lives it on a daily basis, I know that the change we need isn't here yet. And, I believe that it is women's prerogative to talk about their own experience in the area, so we can push for change.

Besides boosting the discussion around it, I believe that we also need to unite. I have been quite the nomad for the last few years and I lived in different countries. However, one thing that has grounded me during all these changes is finding women in tech groups. It is a powerful and revolutionary thing when we help one another. By talking and recognizing the common struggles we can be each other's counterpart to impostor syndrome. When we help another woman overcome its fear of failure, her success becomes a flash of hope that someday reality can be different for ourselves and others like us.

The impostor inside

Bea Oliveira — Mon, 08 Jun 2020 22:31:54 +0000

Placeholder title

Bea Oliveira — Wed, 22 Apr 2020 18:13:01 +0000

DEV Community: Bea Oliveira

Building a scalable strategy for theming and components

1. Why should we worry about Themes and Components?

2. How to organize that, technically?

3. Organizing development with a designer's mind

4. Create a clear architecture aligned with your team's design approach

5. Use tools to document the components for developers and designers

Nx in Storybook - part 2

Using storybook in an Nx monorepo

Bea Oliveira ・ Oct 26 ・ 3 min read

1: Steps to fix the problem and my experience implementing it:

Setting a Dark Mode with Material UI

1. Set a ThemeProvider and a getTheme() function from the beginning of the project

2. Palette type dark magic

3. Managing the view mode state in the AppProvider level

Using storybook in an Nx monorepo

1. The CLI Installation for Storybook doesn't work in monorepos

2. You need to follow the documentation that is on the NX website

3. You need to install it for each app you wanna have Storybook inside your project

Design System: Heaven or Hell?

The impostor inside

The impostor inside

Placeholder title

What I built

Category Submission:

Demo Link

Link to Code

How I built it (what's the stack? did I run into issues or discover something new along the way?)

Additional Resources/Info