We used a Material-UI component in an update we made today: a small menu to allow users to quickly change the priority of an item:

Screenshot of the new priority menu.

A menu is a complicated thing. It should open when you need it to open, close when you need it to close, and when a user selects an option it should call a handler that updates the state of the application and perhaps persists the state back to the server.

As application developers, part of our job is to be diligent about not reinventing the wheel. We have some menus that we’ve coded ourselves which mostly work fine, but they suffer from several issues:

  • No documentation to explain to the next developer how to use the component.
  • Inconsistent use of the component in different parts of the codebase.
  • Patchy testing for accessibility, weird touch and mouse use cases, etc..

So when I realized that I needed a menu and that we didn’t have a bulletproof component at hand, I did a little bit of searching and quickly found the Material-UI menu: https://material-ui.com/components/menus/

When looking for a component, there are always a bunch of questions to think about: would it be better to just create a component from scratch, so we don’t have to manage yet another dependency? If we’re going to use a component, how do we pick one that we’ll be reasonably happy to work with, and that is likely to continue to be a viable project this time next year? How does it feel?

The feel of a library is probably the most important question, and the hardest to think clearly about.

Does the documentation make sense? In this case, the documentation suggested that implementing the Material-UI menu would be very straightforward, and in fact I got a first version of the menu working in a few minutes. Good documentation means it’s super obvious how to install the npm module (with a nod toward the usual twinge of guilt that I can’t figure out for the life of me if I should be using yarn instead, or how the heck to think about npm vs. yarn, or if even should). Once I’ve installed the module, I should be a able to quickly import the components I need, and make use of them.

 import {Menu,MenuItem} from '@material-ui/core';

OK, installing and importing the Menu and MenuItem components was easy. Skimming the documentation and sample code made sense:

<Menu
id="simple-menu"
//...
>
<MenuItem onClick={handleClose}>Profile</MenuItem>
//...
</Menu>

Does this component teach me how to be a better developer? I hope new code will teach me something about how to compose with React, how to organize code and be fluent in modern web development, etc. This is when I started to get stoked. The code components for the Menu were super readable; I was able to quickly make sense that a Menu would contain some number of MenuItems, and the handlers felt reasonably intuitive.

Opening one of the sample sandboxes, the example of menu state in hooks shows that the state would either be null when the menu was closed, or the parent DOM element when the menu is open. Very cool and sensible. And the aria meta tags looked like I would be able to implement it without messing up accessibility. We store most of our state in Redux and very little in state, so it was nice to see a state example using hooks that was practical and intuitive (we mostly keep state in redux so that when a user navigates away and comes back, the important parts of state will make sense). Egads! I’m only ten lines in and I feel like this new component is already helping me to think more clearly. I’m getting excited.

What about CSS? We’re moving to styled-components from Sass right now. Will that be an issue? I find clear, simple documentation on how to use styled. Sweet.

At this point, I’m pretty clear that I’ll be able to put the Menu in and use it easily, and take it out next week if it turns out to be an issue. So reviewing this with the team is key. This can be a real challenge: asking a developer to context switch to evaluate a new library can be unrealistic. Maybe they’ll be playing with something similar that they’d rather use? Sometimes we’re all a bit confused when there’s a lot to think about. In this case, the developers that I reviewed it with were just as excited to play with it as I was, and it only took a few minutes. More stoke!

Finally, I a reality check with the business team: the priority menu was a quick fix to a customer request that hadn’t gone through any review. Would this menu makes sense to them? They used it and it immediately made sense. Phew.

So now we’re using Material-UI, and we’re optimistic that it will help to be more productive and be fun to boot. Fingers crossed!

Submit a comment

You may also like

Logging AWS Lambdas to Elasticsearch
Logging AWS Lambdas to Elasticsearch
4 April, 2019

We’re in the process of experimenting with Elasticsearch to help us manage logging better than we could with CloudWatch ...

About Full, Admin, and Partner Accounts
About Full, Admin, and Partner Accounts
13 August, 2019

This month, we’re enabling the Partner account functionality we’ve been working on. This blog post provides a quick sket...

A New Wave of Productivity Software is Just Beginning
A New Wave of Productivity Software is Just Beginning
2 October, 2019

Benedict Evans of Silicon Valley venture capital firm Andreessen Horowitz (“a16z”) recently published a blog post titled...