Let me tell you a story. I was building yet another date picker component for our design system. It consisted of text input and a pop-up calendar. The calendar can be closed by clicking outside it or by selecting a date.
Most implementations of the click outside logic are made with actual click listeners attached to the DOM. However, I wanted to make our date picker accessible, so you could open a calendar with tabs and close it the same way. Additionally, click listeners may conflict with each other if you put several date pickers on the page.
What if you could just rely on native focus and blur events instead of detecting clicks outside? They naturally support tabs, touch and click events, and are already implemented in the browser. The only problem is that when you click on the pop-up but do not select a date, focus shifts to the calendar, triggering a blur event on the text input and eventually closing the pop-up. …
Every time I find myself connecting to a third-party API that doesn’t have a client library, I have to create a lot of boilerplate around it:
Companies like Airbnb, Apple, Uber, and GitHub have changed the ways they design digital products by incorporating their design language and organizing it into a system that can be used across all employees — and even outside of the company.
It quickly became popular in the whole industry: Just google the company’s name and the word “design” next to it, and you’d be surprised by how many companies have something similar. Airbnb Design, Apple Design, Uber Base Web, GitHub Primer — these are the examples of good design systems.
We won't be talking today about the reasoning behind having a company-wide design system or the organizational challenges that come with it (though it’ll be definitely covered later, so stay tuned). Instead, we’ll focus on the technical choices and implementation details. …