Seedling: Planting Components for Later
We have multiple applications at Greenhouse, including our Recruiting and Onboarding platforms.
Even though these applications are separate codebases, we want there to be a similar look and feel across all of our products. Additionally, we don’t want to have to rebuild the same pieces over and over again, especially considering all of our applications are going to contain similar components to get the job done: buttons, input fields, drop-downs, modals, etc.
That’s why we built Seedling.
Why build a Component Library?
Seedling, our Component Library, is a repository that contains UI components that we use across Greenhouse applications. Open source tools like Storybook help us visualize and organize our React components into a self-documenting UI wiki.
It promotes discoverability
With a single toolbox for components, it’s easy to assess what is already available and dev-ready. This also comes in handy for onboarding new Greenies. When building features, new engineers can quickly connect the dots between design mockups and what the implementation might look like. New designers can be brought up to speed on how we use our building blocks to assemble full pages.
It promotes scalability
If we have solid foundational blocks to build off of, we will be able to focus on the bigger picture of new features, rather than individual components, and complete them faster. Not only does it benefit our current applications, but it also facilitates the creation and development of future repositories.
It promotes maintainability
Having shared components allows us to quickly make sweeping style and/or functional UI changes across applications.
Who is our Component Library designed for?
Seedling is built by and for our Designers and Engineers. This drives its development process and defines its present features and our future vision for it. Ideally, Seedling would help us answer the following:
The “What“ and the “Where”
What do we have and where can we find them? As our applications continue to grow in number and complexity, the number of components will likely continue to grow as well. Storybook has a powerful search tool to help find components easily. On top of that, we try to keep Seedling’s component stories organized in a mostly flattened hierarchy to increase visibility.
The “How”
These components are designed to be flexible and fit many use cases. Seedling should make the different variations of our components apparent to its consumers. As an Engineer, I want to know two things: can I make this button green? Okay great, so how do I make this button green?
The “Why”
Why use this component? Why use that variation? Seedling shouldn’t just display a hodgepodge of components, it also conveys the context of when to use them. Users learn how to use these components when interacting with our applications and build expectations on what they mean. We want Seedling to help ensure consistency with respect to the placement and meaning of these tools.
How did we build it?
So far we’ve looked at a lot of the benefits that come from having a Component Library like Seedling. However, nothing is without its trade-offs.
Making Building Blocks After the Fact
In our case, the applications that use Seedling predate its existence. This means that a lot of the components within Seedling first lived in a single application. Ideally, the migration process of each component would be a simple copy-paste into the Component Library.
But sometimes, more commonly-used components differ from project to project, and resolving the differing implementations and use cases can make the process more complex. It is harder to create building blocks when you’ve already constructed the buildings.
Mitigating Risk
Going through all existing features and rebuilding them with Seedling components has the potential to be disruptive and create unnecessary risks. In our first iteration of the project, our answer to this problem has been to first extract all the commonalities between projects without necessarily updating our dependent applications.
This minimizes risk in the migration of components into Seedling and allows us to isolate particular features and modify them to use the new components at a controlled pace later on.
Of course, new features are still being built while this is happening. We can mark the original components as deprecated and direct Engineers towards their Seedling counterparts, but there is still the possibility of these original components being used.
What’s Next?
With Seedling still in its “Sprout” phase, there is still more work to be done. With our component migration phase almost complete, we are going to continue converting existing features to use the new Seedling components.
Storybook also has a ton of useful plugins that we still want to experiment with, i.e. making component APIs more accessible, making it simple to generate a component’s source code and toss it into a page.
Looking for a place to be a part of projects like this? We’re hiring!
Got any handy Storybook workflows that have helped you out?
Feel free to let me know if you have any questions or comments below!
