๐ง๐ต๐ถ๐ป๐ด๐ ๐ ๐ถ๐ป๐ฑ๐ถ๐ฟ๐ฒ๐ฐ๐๐น๐ ๐ฑ๐ถ๐ฑ๐ป'๐ ๐ธ๐ป๐ผ๐ ๐ ๐๐ฎ๐ ๐ฑ๐ผ๐ถ๐ป๐ด.

Yeah, I've written react apps for a while now and I've indeed improved over the years. But little did I know, I have actually been using the ๐๐๐๐๐ principle in React. Yes, SOLID principle. You read that right. And I got to know this from reading a colleague's code and advising them on some "๐ฃ๐ฆ๐ด๐ต ๐ฑ๐ณ๐ข๐ค๐ต๐ช๐ค๐ฆ๐ด".
S - Single Responsibility Principle (SRP)
"๐ด ๐๐๐๐ ๐ (๐๐๐๐๐๐๐๐๐ก) ๐ โ๐๐ข๐๐ โ๐๐ฃ๐ ๐๐๐๐ฆ ๐๐๐ ๐๐๐๐ ๐๐ ๐ก๐ ๐โ๐๐๐๐".
Each component you create should focus on one responsibility. Mixing UI, state management, and API calls in the same component usually makes it hard to maintain. Use reusable components and custom hooks to minimise this.

O - Open/Closed Principle (OCP)
"๐๐๐๐ก๐ค๐๐๐ ๐๐๐ก๐๐ก๐๐๐ ๐ โ๐๐ข๐๐ ๐๐ ๐๐๐๐ ๐๐๐ ๐๐ฅ๐ก๐๐๐ ๐๐๐ ๐๐ข๐ก ๐๐๐๐ ๐๐ ๐๐๐ ๐๐๐๐๐๐๐๐๐ก๐๐๐"
In React, instead of modifying a component's core logic every time requirements change, extend it through props, composition or HOCs/hooks.
Another way you can look at this. Assuming your project uses a button but has different colours used at various portions, you can just use props to extend this by creating variants.

L - Liskov Substitution Principle (LSP)
"๐๐ข๐๐ก๐ฆ๐๐๐ ๐๐ข๐ ๐ก ๐๐ ๐ ๐ข๐๐ ๐ก๐๐ก๐ข๐ก๐๐๐๐ ๐๐๐ ๐กโ๐๐๐ ๐๐๐ ๐ ๐ก๐ฆ๐๐๐ "
In React, specialised components should behave like their general counterparts.
For example, if PrimaryButton extends Button, it should work anywhere a Button is expected, without breaking UI or functionality.

I - Interface Segregation Principle (ISP)
"๐ถ๐๐๐๐๐ก๐ ๐ โ๐๐ข๐๐ ๐๐๐ก ๐๐ ๐๐๐๐๐๐ ๐ก๐ ๐๐๐๐๐๐ ๐๐ ๐๐๐กโ๐๐๐ ๐กโ๐๐ฆ ๐๐ ๐๐๐ก ๐ข๐ ๐".
For this, simply do not create giant components with dozens of props, or even states you don't really need. Split responsibilities into smaller, focused interfaces, components or hooks.
D - Dependency Inversion Principle (DIP)
"๐ท๐๐๐๐๐ ๐๐ ๐๐๐ ๐ก๐๐๐๐ก๐๐๐๐ , ๐๐๐ก ๐๐๐๐๐๐๐ก๐๐๐๐ "
Components shouldn't directly fetch data or rely on low-level implementations. Instead, use hooks or contexts to provide data.

You will realise UserCard does't know how data is fetched. It depends on an abstraction, useUser, not on the actual API call.
So if you also write React and you try to
* Keep your components clean and focused
* make them reusable and substitutable.
* Design smaller, focused APIs and props.
* or even decouple UI from the implementation details.
If you do any of this, then you are also using the SOLID principle.
๐๐๐๐๐๐ค ๐๐ ๐ฃ ๐ฃ๐๐๐๐๐๐ ๐ฅ๐๐๐ค.
Let me know what different ways you also use the SOLID principle.
0
7
0