Episode 6 — 18th November 2016
Single Responsibility Components
The Functional Programming (FP) aspects of React are fairly prominent: by making your UI a pure function of your application state you remove a whole class of bugs that plagued earlier frameworks. If you look closely at the render method, or performance optimisations like shouldComponentUpdate, as well as popular libraries like Redux, again you’ll see a strong FP influence. But that’s not the only thing at play.
Because component-driven design is actually much closer to Object-Oriented (OO) programming. Components encapsulate state, present a public API, and map to objects in the “real world” (or in our case the UI), which are all core properties of Objects in OO. And they relate to each other, they share information or depend upon each other, which are all classical OO design problems. It means there’s a wealth of ideas, discussions and patterns that we can bring to bear in making our React components more readable, reusable, and maintainable.

In this episode you'll learn

  • What the Single Responsibility Principle is and how it applies to working with UI components.
  • The four main sources of change and how to mitigate them.
  • How to identify potential refactoring opportunities as you make a change.
  • How these principles endure beyond simply being applied to React or another framework you might be using today.