I’ve heard a lot of horror stories about teams that don’t version their component library. I’ve only heard one success story. Not great odds for team no versioning.
Sometimes teams don’t version their library because they want to automatically propagate newly-available changes across all subscribing applications. It would be great if teams that own individual repos didn’t have to upgrade their codebases to work with new components?
Sadly, this dream is too risky for most teams.
Other teams don’t configure versioning because they want to ship components right away. They don’t want to “waste time” with infrastructure and automation. I think we especially notice this with component libraries because design systems teams have to prove their value every quarter to stay funded. …
Web developers used to hard-code all of their style data. If a button needed a background color of blue, they’d assign the background color right at the source:
That worked for smaller systems that didn’t need a theming layer and weren’t undergoing frequent redesign. But if you needed a large-scale redesign, this was a painful approach.
Picture a fully-fledged design system. You can bootstrap a new project, pull a bunch of components from the system, and have a page in minutes instead of days.
When you’re first starting to build your own, it seems too good to be true. You might be asking yourself, “how do I get from nothing to a system that supports multiple teams and hundreds of happy engineers?”
There’s a lot to consider, but in this post we’re going to talk about design system architecture, and specifically the concept of component hierarchies.
We can use the metaphor of a wedding cake to understand this a little better. When you see a wedding cake, your brain first thinks, “oh look, a cake.” As you look closer, you start to see that it consists multiple layers and elements. …
This article was originally published on Design Systems.
Most component libraries share an origin story. A growing company offers a new product or service; engineers write new code to support the new products; someone notices that the engineers keep rebuilding the same (or similar) features. Eventually, the company realizes that if it wants to scale its engineering team, applications across its architecture need to start sharing code.
Until recently at Harry’s, we were following that same general trajectory. We had no scalable way to share code between applications and found ourselves rebuilding features across our two personal care brands: Harry’s and Flamingo. …
As an engineering team, we are committed to providing women with a body care experience tailored to their specific needs. It’s important to us that our customers enjoy their interactions with us not only while they’re in the shower, but also when they shop for their blades, wax kits, or razor handles online too.
To simplify shopping for razors we built a performant, visually-appealing, and secure site. Our architecture performs well across browsers and devices, emphasizes developer ergonomics and modern tools, and lets us continuously deploy with confidence. We think shopflamingo.com …
React 16.6.0 introduced
React.lazy, which allows you to code-split using the new Suspense API.
I’ve built a Github clone based off of Siddharth’s example. Hopefully this will help people who prefer reading to watching videos, or who to be walked through it step by step!
React.lazy allows developers to block UI from rendering until a pre-determined condition is met. …
Rumors are flying! Could Context replace redux? Does it make prop drilling extinct? Even if Context !== world peace, the React team has introduced a fantastic tool to simplify one of the most difficult problems frontend developers deal with daily: state management.
Over the past six months, there has been plenty of hype about the new Context. At the end of this post, you’ll know what it is, whether and when you should use it, and how to implement it in your applications.
The React ecosystem offers multiple ways to pass data and manage state in a client-side application. A developer might choose between prop drilling, redux, MobX, and the new Context API introduced in React 16 depending on the size and complexity of the application they are developing.
A developer can use prop drilling (or threading) to pass data from a component higher up in the component hierarchy to a child component further down. …
If you’ve worked at an early-stage startup, you’ve seen a system break down before. There’s a process in place. It works (or the team thinks it works). It breaks. The team keeps using it because they don’t have time to fix it. Eventually, the team accepts that it has outgrown the system. They build and adopt a new one.
I knew that the project management process wasn’t working, but I wasn’t sure why. I needed to fully understand the problem before I could even consider solutions. …
Developers frequently talk about the importance of reusing code. We talk about the DRY principle (Don’t Repeat Yourself), code reviews are rife with comments like: “can you encapsulate this into a function and reuse it on line 19”, and we frequently explain to product owners why it’s important that when we change something over here, it changes over there automatically.
But these discussions lack some nuance. They often make it seem like reusability is binary — code is either reusable or not. I’d argue there are actually three levels of reusability.
The first, and least reusable type of component cannot be reused at all. Experienced developers build this type of component under strict, inflexible deadlines. Inexperienced developers build this type of component when they just want something to work or haven’t yet learned about reusing code. …