The Right Level of React Abstraction

Yesterday while reviewing a few pull requests from my coworkers, I was struck by how easy a few changes were in some React code. The changes were easy because the codebase in question had found the right level of abstraction in the pieces that were changing. ReactJS may be the next shiny new thing, but a surprising amount of old design advice still applies.

In this case, a <DeleteButton /> component was being used in one PR and changed in another. This was possible because the public interface of that component — how it was to be used in JSX — that interface did not change even though the underlying implementation did. My coworkers realized the value of programming to an interface

Similarly, the new implementation of <DeleteButton /> favored a lot of composition over inheritance and re-used a few existing components effectively. More old advice.

The thing we’re still learning about React and other frontend frameworks (like Vue, Angular, etc.) is how they hold up over time. How they help us imperfect developers meet the needs of our projects or employers. There are no 10-year-old react projects (yet). No one has any real, react-specific advice on how things will hold up beyond the attention span of the current frontend world.

I suspect the truth is that it doesn’t matter what flavor of frontend framework (or lack of) gets used. What matters if finding the right level of abstraction that makes changes easy over time. Following some more traditional advice — advice that has proven itself in long term projects — well, that sort of advice is worth following.