Thoughts on React 179 minutes read · 2020-09-10
3 years of React 16
- 16.0 - Error Boundaries, Portals
- 16.2 - React.Fragment
- 16.3 - New Context API
- 16.6 - React.memo(), React.lazy()
- 16.8 - Hooks!
- 16.9 - Lifecycle Deprecations
From 16.0 to 16.13.1, the experience of using React was completely transformed: A lot of features that were previously experimental or unergonomic to use got first-class support (Like portals and context) and we went through a lot of trials in composability, by means of Higher Order Components, Render Props and ultimately Hooks in 16.8.
What was once a Class-based object-oriented UI framework is now a Pure-functional, algebraic effects-inspired scheduler for arbitrary computation, that yeah, is still pretty good for building UIs.
And all of that without breaking backwards compatibility: Assuming you were not using private or experimental APIs (and were not depending on a library that did it) the same project written for React 16.0 should still run under React 16.13.1, with maybe a couple warnings.
Preserving that compatibility is one of the biggest accomplishments (and selling points) of React as a framework, and it makes sense: Facebook has a massive codebase with thousands of components and pages that it needs to maintain, so API stability is a must.
All of that comes at a cost, though. Some of the highly anticipated features (like Concurrent mode and Suspense for data fetching) ended up taking way more work than expected, and will require breaking backwards compatibility. React 16.9 already deprecated a bunch of lifecycle methods and saw them marked as
UNSAFE_ for concurrent mode. It looks like the React team has decided it’s finally time to move on, and start shedding support for those deprecated methods for good.
Before they can do that though, they’re introducing an escape hatch for legacy codebases that can’t upgrade, in the form of React 17, by officially supporting a workflow where multiple versions of the React framework can more easily coexist in the same page side by side, and even nested “inside” each other. Unfortunately, getting that to work properly requires some breaking changes, albeit very small ones.