Maelstrom-Futurism

Learnings and Explanation

The internet is absolutely loaded with component libraries and styling systems, so why build my own? The primary issue with all of those component libraries is very simple - they are not my component library.

While working at AWS, I led a redesign project for a training tool that required the creation of a new component library that would be shared between 4 - 6 teams. The component library is still in use at AWS, but there were several decisions I wanted to explore.

• The use of emotion / CSS-in-JS as the primary theming solution. While I like the flexibility of emotion for creating shared themes, it requires project changes for use in Next.js and other frameworks. As a result, MF uses SASS and css modules for styling in components that I want to use in easily.
• Mono-repo management. Because my first component system was built at Amazon it favorited a multiple package approach with custom scripts to tie it all together. For MF, I chose Lerna to manage a mono-repo. It isn't perfect, but it manages dependencies great.
• It is very hard to make a component that covers all possibilities. You have to either set an opinionated style and a single "golden path" or you have to create some kind of utility system that allows overwriting component behavior.
• Having tests are a life-saver. Since MF was a low stakes personal project, I didn't build in any unit tests. This was fine, but as I attempted to use my own library I found new features and immediately created regressions trying to fill them in. If I was using this more, I'd certainly have lost time trying to work testless.