Four Hurdles when Prototyping with Material-UI for React

September 05, 2018 0 Comments

Four Hurdles when Prototyping with Material-UI for React



Google created the Material Design design language to be used across devices. If you’re using Material Design with React, I’d recommend Material-UI for React to get the ball rolling. It’s a library of components or pre-styled elements (similar to the Bootstrap framework) that are easy to add to a page, and the components look and function well out of the box.

My Experience

When I first started working with the Material-UI library, it was new to the team, and we were working on a rather tight deadline to create a prototype. I was pleasantly surprised with my experience, especially with the docs, which were easy to digest. Material-UI got us working quickly and ultimately helped us deliver a powerful, yet simple, user experience.

Material-UI Hurdles

Most of the implementation went well, but there were a few items that were a little sticky. I’m detailing them here in hopes of saving you some time.

1. Complex components

The way you implement the Material-UI components is like designing a stuffed animal at Build-a-Bear, where you select which “sub” component that should be shown. Components do work in isolation as promised, but things got a little tricky when we wanted to add a more complex component like a text field.

Each component needs to be imported into the project from the Material-UI library, not just the parent component. In the case of the text field, there can be one component wrapping three sub-compontents that define the input, label, and help text. On top of that, you must be sure to include each of the four components at the top of the page.

When you think about how components are compiled into HTML, it does make a lot of sense to gut-check what’s needed to display the information.

2. The typography component

Using the typography component took some getting used to. At first, it seemed like a lot of extra work to define styles. It also tended to make the code more cluttered and longer in length.

As I followed the pattern illustrated in the docs, it slowly started to become more intuitive. However, no matter how many times I typed it, my brain didn’t want to map the component’s variant (variable that controls the output type, i.e. H1, H2…) to the corresponding HTML tags. After putting in a number of hours using this component, I’m not convinced that it’s any easier than using HTML tags with classes.

3. Styling components

Material-UI has a number of ways to style components, including using classes/ID, inline JSX styling, or built-in component props. There seemed to be a time and place for each styling approach. To reduce the amount of CSS I had to manage, I defaulted to using the component props for styling. This approach worked pretty well for handling 80% of my basic styling needs.

The downside was when we had CSS rule to change. It began to seem irresistible to inline the styles in the React code. This was such a strange concept to me, as I would rarely consider doing this in an HTML framework. However, given the limited scope of the prototype and the time it takes to set up a className, this seemed like an appropriate option. My brain kept saying, “Why not just write it right there in the JSX?”

4. Setting up icons

Material-UI also has an npm package for the Material Icons. However, this is a separate package. I learned this the hard way by trying to incorporate a component that used an icon. Though it was properly referenced, I received an error saying the file wasn’t in the npm package. How could that be?

After a little detective work, I came across the link to the icon npm package. This package installs into the same Material-UI directory, which made it quite confusing.

Have you used Material-UI with React? I’d love to hear about your experiences.

Tag cloud