Tales from the Library: A Prologue
Ensuring your component library is effective and reusable
This is the first in a series of posts about a React component library we recently completed at thirteen23. If you have no idea what that is, there are a ton of resources on this pattern and its benefits. We recommend the following articles here, here, and here.
What I like most about agency work is the encapsulation of our projects — everything we do eventually gets bundled up and shipped off to our client.
Things never grow stale at thirteen23 because every few months we start over with a fresh problem. The downside? The divide can go both ways. We can’t always be around to explain our code to clients. We tend to compensate for this by prioritizing for clarity and reusability of code.
The Task
This focus only intensified with our last project: a web reusable component library for a company that we’ll hypothetically call… oh, let’s say Acme Corporation.
So Acme enters, and we essentially get to Ikea-fy our typical deliverable. Instead of delivering an end-to-end application, we’re making the parts and leaving assembly to the client.
Unassembled goods can be a tough sell, but Ikea has ease of use down to a science. As developers, we took a page from our Swedish friends and sought to prioritize easy integration with our code. More specifically, we wanted to tackle this through three vectors:
- Clarity: Code should be easy to understand. This goes far beyond careful documentation. Code should avoid curveballs in structure (I don’t care how fancy it looks when you curry four higher-order functions in a single line). Components must be broken up into subcomponents where necessary, so we can easily reason about and test complex behavior.
- Flexibility: Components should be fluid enough to work in any container or context. They also can’t leak CSS or otherwise affect their surroundings after integration.
- Meatballs: Okay, okay, we’re running with the Ikea metaphor here, but if we serve a plate of Swedish meatballs halfway through our project, our clients will be pleased and eager for more.
The Tools
If you have the ability to choose your tools, you can start optimizing for usability before writing a single line of code. Consider things like type safety or affordances for pure functions. But before we jump in, let’s go over our stack:
- Typescript: We recommend a strongly typed language if possible— not because we hate debugging weak types (we do), but because explicitness of types act as a powerful tool for self-documentation.
- React: Ha ha! It was me all along, the Obnoxious React Evangelist™!
In developing just components, we couldn’t make any assumptions about any higher-up architecture. By defining views as outputs of given props, we get two things: first, by making our information come from the outside, we defer data fetching to whatever environment the component’s going to live in. Second, we gain explicitness by having the components dictate what they need to function. - SCSS Stylesheets: Sassy CSS, or SCSS, is a godsend for ensuring your stylesheets are not only organized, but easy to change. SCSS supports programming-like constructs such as variables, functions, and even loops. We’ll explore this further in the next post.
- Storybook: A staging framework to demo your shiny new components. Storybook is to your project as a model kitchen is to a Williams Sonoma catalog. Unless you’re deploying components straight to an existing page, your components need somewhere to live so you can show them off to investors and your mom. Not only does Storybook provide this context, it organizes your components and offers a suite of plugins to help streamline the review process.
Next Steps
Groundwork = laid. In our next post, we’ll start demoing code with a collection of stylesheet tips to ensure your components are a breeze to integrate. Stay tuned!
Find us on Facebook, Twitter, and Instagram or get in touch at thirteen23.com.
