neetoUI is the UI library of neeto
At neeto we are building lots of products. As we built more and more products, we ran into the issues of UI consistency. For example, the primary button's color and size would vary from product to product. Filter features would differ from product to product. Checkboxes would look different. Label, input fields, tabs, and other elements would look inconsistent. We started putting code in the folder to solve the problems of consistency, styling, and code duplication. This folder was shared by all the products.
This solved the problem only partially. What we needed was a neeto’s own UI library. neetoUI is the UI library of neeto. It makes it easier to build consistent UI across various neeto products and is currently being used in more than 20 neeto products. It’s open source. With the help of neetoUI, we were able to get consistency in buttons, text, links, and other UI elements.
neetoUI v1 was the first version released for the public on npm. We had decided very early that we would be using Tailwind CSS for styling our products, and hence we quickly created a few UI components and published the package on npm. We used CRA (Create React App) as a boilerplate and craco to customize some configurations around CRA.
In neetoUI v1, we mainly focused on extracting standard components from each product we were building. neetoUI provided too much customizability, which led to problems. Hence, we decided to create neetoUI v2.
In neetoUI v2, we made several bold decisions.
We moved away from Tailwind CSS for styling UI components. In v1, we were using Tailwind CSS at the package and host application levels. The host application styles often override the base styles of neetoUI components, causing all sorts of issues. Debugging these types of problems was very time-consuming. Removing the usage of Tailwind CSS from neetoUI solved all these issues.
We used blueprintjs for overlay components like Pane, Modal, Alert, etc. We got rid of blueprintjs too.
Another decision was to move our color palette from Tailwind CSS base colors to a monochrome palette. One of the main reasons for using monochrome this time was that we first wished to tackle the UX aspect of products and then look into the UI aspect of it. A monochrome palette gave us the advantage of bringing in colors in the future. Our design team pitched a basic component library design system with a monochrome color palette, and we liked it. It was quickly rolled into neetoUI.
In neetoUI v2, we also dropped support for many introduced props due to quickly creating a component library in v1. We stuck to the base design system, which later helped us in making sure that all products dealt with actions in a consistent manner.
Considering this, we successfully released neetoUI v2 without external dependency on Tailwind CSS, blueprint, or any other component library. There were a few exceptions. We had decided that for a few components like DatePicker, we would not be writing custom components from scratch, rather we would be overriding the styles of an external library. The only external dependency that we had on an external component library in neetoUI v2 was antD, and that was because antD provided us with the perfect components for DatePicker and other date-time-related components.
In neetoUI v2, we started using Storybook for documenting all our components.
neetoUI v3 was a cleanup release. We made cosmetic changes along with some performance enhancements and made sure that the components would be scalable for the future.
We had reached a stage in product development where neetoUI was being used across all the products consistently, without any unwanted overrides. In v3, we decided to introduce a base color palette for neetoUI and moved away from the monochrome palette added in v2. We introduced a new primary, secondary, and tertiary colors, pastel colors, and shades of grey ranging from 100 to 800. This enhanced the UI of all products. The change in the color palette was not a breaking change, and almost all products switched to v3 in no time except for the ones that needed component-level style customizability.
V3 was also when we were rethinking our bundling process. We looked around for better tools and landed upon rollup.js. We did a quick POC and realized that rollup was superior to our webpack config. Tree shaking, bundling time, and the ease of configuration made it the perfect fit for our new choice of bundler. Using
rollup.js reduced our bundle size by quite a considerable margin.
Since neetoUI was being used in all neeto products for all the UI elements, a bug in neetoUI or a change in logic could break multiple products simultaneously in a single release. Hence, we decided on writing tests for all the neetoUI, no matter how small the component usage is in the host products. We used jest and react-testing-library for writing the unit tests. We added GitHub actions to ensure that any pull request would run these tests. This ensured that post v3, none of the changes in neetoUI brought any unknown bug in any of the neeto products.
The neetoUI v4 release focused on design systems, design tokens, a11y, semantics, and scalable solutions.
Although we had been maintaining a design system, we noticed inconsistencies between neetoUI components and their corresponding designs in Figma. This was mainly due to delays in updating Figma files after changes were made in neetoUI. We faced conflicts in terms of design tokens, color palettes, and component naming conventions between the UI and UX teams. However, we were able to build a design system from scratch that built neetoUI v4 in a month’s time.
With a solid design system ready, the neetoUI team started pixel-perfecting every component. We were also keen on introducing a11y and semantics and hence, we started off with the basics of making sure that all elements can be tabbed through, making sure that focus is trapped within an overlay, and much more.
Since the release of neetoUI, we have received multiple requests to allow for theming of the color palette from the host application. In v4, we introduced CSS variables powered by SCSS files, which allowed users to customize any color from the palette to fit their needs. This means that users no longer need to overwrite all CSS classnames if they want to change the primary color to their brand palette; they can simply override the CSS variable for neetoUI primary color.
Till v4, neetoUI didn’t work well with IDEs. We had auto-completion support only for component names. To fix this, we added
.d.ts files in which we defined the component data types. It significantly helped improve IntelliSense and autocompletion of component props served from the package.
neetoUI is our dedicated UI library, providing us with a consistent and scalable UI design across all our products. Our journey from neetoUI v1 to v4 has been full of learning experiences, and we are very happy with what we have built. With neetoUI, we are confident that we can continue to deliver exceptional user experiences to all our users.
Subscribe to this neeto blog to see what we are up to. We'll spill the beans on our out-of-this-world marketing maneuvers (we write blogs like this one). Prepare to have your jaw hit the floor as we reveal revenue numbers that make Elon Musk jealous(we might need a few more zeroes to reach "buy-an-island" status).
And when it comes to reeling in new customers, we've mastered the art of hypnotizing business folks with our mesmerizing PowerPoint presentations that make them chant "neeto!" while doing the Macarena. So buckle up, my daring friend, and hop on board the neeto rollercoaster of insanity!
Warning: Side effects may include an irrepressible desire to shout "neeto!" from the highest rooftops.Welcome to the land of outrageousness, where the mundane is banished and extraordinary reigns supreme! Let the absurdity begin as we embark on a mission to leave our mark on the world, one glorious dent at a time.