Hot Take: (Re)usable Components
Hot-Takes are quick brain-dumps on practices that catch my eye and my ire.
What’s so great about homogeny?
One of the ideas I see thrown around the industry often is Reusable Components. From the perspective of frontend-engineering/graphic-design/product-design, its meaning is basically:
- Reusable Components
noun- Pieces of a UI that require a few engineering hours up front, and can then be continually dropped into other pages/applications to deliver the same (or similar) features without further work.
This is, of course, a pipe dream. I’m a firm believer that many frameworks that boast reusable components as a selling point gained their early traction because non-technical users could point to that and make the business case that, hypothetically, they could start spending less on developer hours once every component they need has been created. The problem here is that nearly every new page/app/feature requires a new design that doesn’t perfectly fit with what was previously built. And that’s not because the product designers made a mistake, it’s because value often comes from creating something that didn’t previously exist and hasn’t already been planned for.
Over many years in the industry, I can confidently say that applications that are useful and enjoyable are mainly made of bespoke elements. Sometimes those elements are super similar, but differ in subtle, yet incredibly important, ways. Sometimes those components look almost exactly like another component, but it was found that the other component couldn’t be reused because something behind the scenes didn’t line up perfectly. And to be fair, there’s simply no logical argument that composing your app out of the same reused pieces would make it “better”.
Not to say that no components are reusable, but the attention given to reusable components and the frameworks that support them is completely out of balance with the real world, where maybe 20% of total instances of components come from shared libraries, and everything else is either totally bespoke or a slight variation of an existing “reusable component”.
Additionally, there’s a huge number of technical constraints that prevent reuse which non-technical users aren’t aware of. In order for a javascript component to be reusable, the app that wants to use it needs to line up just-so with the component. They need to be built in the same framework, and in compatible versions of that framework (That “Reusable component library” that your company built using React in 2017 isn’t going to work with a newly created React app). If your component interacts with the backend, it needs to be compatible with how your frontends make backend requests and handle user identities (That component that uses a token to fetch data from a REST server probably won’t work in your new frontends that use JWTs and Apollo to make calls to GraphQL). The structure and content of data that you app has must match the structure and content the app expects. (That table component that renders a list of items isn’t going to magically become a pageable/sortable/filterable table of search results). The list of potential incompatibilities goes on, and it usually comes down to something invisible and unexpected.
I think the realistic view is that most components are simply Usable, not inherently Reusable, and there’s nothing wrong with that. They don’t solve every problem that will come up and they won’t work in every possible context that presents itself. Nor should they. Valuable apps need work and attention to detail that the reusability-paradigm simply doesn’t account for.