This is the Only Right Way to Write React clean-code - SOLID

🎉Our Newsletter is live! Join thousands of other developers islemmaboud.com/join-newsletter

I'm glad that frontenders are starting to use the principles of good design, however, I can't help but point out some mistakes in this video. I just don't want the newcomers to be misled. SRP: Dividing a component into sub-components is not exactly what this principle says. Such a division does exist, but it is called "a function should do only one thing". SRP talks about actors and the changes they have on the component. The division into sub-components is part of the implementation of this principle, but the motivation comes from the reasons for the changes. The component turned out to be clean anyway, so the problem is only in the definition. OCP: The very idea of closing the button component for modification was great, but the unfinished implementation led to an even bigger problem. Before refactoring, we had a great abstraction + encapsulation: we passed the button type as a string, and the button itself decided which icon to substitute. After refactoring, the abstraction simply disappeared, turning the button component into a humble component. Now we will pass an icon to the component, but we will still have an abstraction in the form of a button type in our head. This violates the DRY principle, and when we want to change the icons of all the "back" buttons... good luck finding them all. After closing the button for modification it was necessary to create, for example, the `ButtonFactory` class. It would change when adding new button types (thereby having one responsibility -> SRP), the button would be closed for modification, and all button components would be created only through the `ButtonFactory`. That's the way it had to be done. LSP: The advice is very helpful. It was possible to tell more about the inheritance of a component from another component, if they are made in a style with classes, and not through a hook. ISP: The definition of the principle is not quite correct, or rather not complete. The definition goes like this: "Software modules should not depend on things they don't use." This greatly expands the effect of the principle and removes the word "interface", which may confuse someone. It was also possible to show how component A uses component B, where B violates SRP, and when B changes for a reason that A should not depend on, it breaks A, although it should not have. The example with props is useful, anyway. DIP: Additional examples have already been written in the comments/ Thank you for bringing up such important topics for the frontend community. I hope my additions will help developers better understand this topic

For the last principle (D), another good example is Create vs Edit forms. In our application, we have 2 areas where these forms are shared, but their submit logic is different for each, so we've taken the exact same approach by extracting the form itself into its own component, and then move the submission logic (React Query mutations), into two separate parents, CreateForm and EditForm, where the actual form component can be configured there. It's a very nice separation of concerns: UI vs. request logic.

Thank you because these concepts are usually explained in other languages without any connection with React. Explaining them with good examples through React helped me a lot.

Thanks a lot for this video ; as a newcomer to react with a java background it's refreshing too see how all these oop principles can be reused. You provide nice concrete examples of issues I was already confronted with!

something to keep in mind for beginners. It's ok to write 'ugly' code in the start. Sure, write a +100 lines in a single script, THEN start splitting it into different parts so that later it's easier to come back to

Having to deal with code architecture that did not implement the "Open-Closed" principle have been a long-going struggle in my 4 years of working as a software engineer. These are one of the most important ideas that I'm trying to make sure we follow in our team, but only today I learned that it has a name 😅 So thanks for that

The BEST tutorial I have ever seen for a long time. Nice explanation and simple examples. Love it.

This is great! I understood the SOLID principles before with classes in pure OOP languages like C# or Java, but it was hard to apply them to Component Frameworks. I never used React but having the SOLID principles explained with React makes it really easy to apply them to other Component Frameworks that I use, like Svelte! Also, I rarely see tutorials that show examples that are this good with beeing realistic and also accurate enough to exactly display what you want to teach. Great Job!

Can not be simpler with this explaination. Thank you so much

I am preparing for the system design and OOP coding session as a frontend. I keep finding myself forgetting what I have studied for OOP principles as though it makes sense in theory, I didn't have practical examples of why they are needed (to study lol) for Frontend. This video really helped me grasp what SOLID means to frontend! Thank you for your great work!

Great video. Past few day's I've been working with a farely big project. I just started to get overwhelmed by the amount of code i've written and how i'm going to manage it in the futue. So, decided to do a little study on clean and maintainable code. You'r video was great. Now i'm going to read the book. :)

Great video. On the example shown for the Interface Segreggation Principle you could say that doing that (imageUrl prop instead of product) also enforces the SRP because now the Image component doesn't have the responsibility of knowing the shape of a product object and what its imageUrl attribute is called. After the change now it doesn't even know what a product is, and that's beautiful. <3

I agree that components are like objects in the OOP but in React we mostly use function programming, and IMO some SOLID principles are specifically target bad object hierarchies. Developers need to think carefully before blindly applying the following suggested interpretations: O - open-closed principle. In functional programming we do not use extension at all we always use composition of functions, higher order functions etc. The example which was shown IMO does not work well to demonstrate it. The Button which you demonstrated initially was probably not just a generic button but had a purpose to encapsulate some logic to be a NavigationButton. It had a property role which is an enumeration of all possible valid variations associated with particular icon. When you changed that to a generic button with slot 'icon' you just moved that logic upwards in the component hierarchy and probably broke an S principle somewhere else. Potentially multiple places would have to choose the icon, which is even worse because now someone can use a different icons for same role. So, you would probably still have a common component like NavigationButton with enum, which brings us to the square one. L - LSP (almost Lumpy Space Princess ;)) OOP principle as you also mentioned looks weird in functional code. Probably just bad example, but passing through all of the properties from the underlying component is not always right thing to do. In the particular example the usage of the native input is just an implementation detail of SearchInput. It could be a valid intention to restrict some of the capabilities of underlying component so that main component cannot be abused. Passing rest props allows overriding all the classes on the input, which would be arguably incorrect.

Great to see comparison of bad vs good code standards in React. Thanks

Woo! Awesome explanation about S.O.L.I.D principles. I really enjoyed watching the video and learn a lot. Keep it up man.

I really enjoyed these interactive explanations! Thanks for the video!

The best React SOLID tutorial ever! Awesome!

Dude, you’re awesome. Keep these types of videos coming. Learning a lot.

Man, thank you very much!! You are so good at explaining and sharing the core idea. ❤ I already have so much more knowledge to apply on my projects..