SOLID Principles in React, explained
Using a series of X threads
A while back, I set out to explain how S.O.L.I.D principles can be applied to React’s functional programming paradigm to build maintainable projects.
I wrote a series of X threads, walking backwards from Dependency Inversion all the way to Single Responsibility, because that was the best mental model I could come up with for explaining the concepts.
In this article, I’m sharing these threads on my Medium, hoping someone benefits from the insights I’ve cultivated over the past few years of developing with JavaScript and TypeScript.
5. Dependency Inversion
This is the golden standard for DI.Whatever tool you're using to coordinate data fetching and state management, should allow your components to explicitly declare their dependencies.Here, the ProfileScreen declares
getProfileas its dependency, and states its interface. https://t.co/poQmwzKKix pic.twitter.com/LQJC7PE1E0
4. Interface Segregation
Let's talk about Interface Segregation, the I in SOLID principles.What does it mean? Why should you be concerned with it as a front-end developer? pic.twitter.com/VPwL5hNgzE
3. Liskov’s Substitution
It's my first Father's day tomorrow as a Dad, so let's talk about Liskov's substitution, the L in SOLID principles.It's hard to talk about Liskov's substitution without talking about inheritance in OOP, because it's literally implied in the principle, which states that: pic.twitter.com/84h3xNzWpb
2–1. Open/Closed Principle + Single Responsibility
The Open/Closed principle (OCP) and Single-responsibility principle (SRP), go hand-in-hand, and You cannot achieve one without the other.What are they? And why should you bother with them as a front-end developer? pic.twitter.com/kpw5WdusoL
Let me know what you think? Are these principles as universal as I think they are (applying them to React’s functional programming), or am I under a delusion, perhaps 😅?