SOLID in React: the good, the bad, and the awesome
Let’s talk about SOLID principles from the perspective of the React application. If you’re not sure what SOLID principles are, you might want to read the following first:I’m very well aware that there are plenty of articles on this exact topic already, and I know that because I’ve read most of them. And have to say I do disagree with the way the information is provided in those articles (otherwise I obviously wouldn’t have written this). The problem I see is that you’re only told how great and awesome SOLID principles are, without mentioning potential downsides or considerations; are they even applicable in React application? And that’s exactly what we’re going to discuss just now, so don’t stop reading!The very first principle is generally the easiest one to understand: your component should have a single responsibility, or in other words, there must be only one reason for this component to exist. However, if you switch your brain from the consumption mode to thinking, you might immediately notice one problem: given that any non-leaf component in your application is the root of a subtree, there is an almost certain chance that some of your components will have more than one responsibility — the component has five children and controls the state of three of them. I bet your root App component violates the principle big time! So what do we do? How do we navigate and apply the Single Responsibility Principle? If you look closely you are likely to find two groups of components: ones that are easy to design with the Single Responsibility Principle in mind; and others, some kind of orchestrators that have a lot of responsibility (or control). You can call them smart/dumb components, or container/presentational, I don’t really care as long as you acknowledge this separation.
0 Comments