🎉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.

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

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!

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

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

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

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!

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!

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.

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

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.

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

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

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..

Great explanations! As a "native" JS developer I always struggle to understand/translate those OOP principles since I use a lot of functional programming just as React does. This video is pure gold, I will be glad if you make some others videos about things such as design patterns. Thank you!

I know this is difficult for beginners to understand but it is totally worth it to learn. thanks for sharing.

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. :)

Nice, good video. I had to look up #2 and 3 to really get it but I found the React examples useful.

Amazing videos ! Theorical principles alone can be quite tricky to conceptualize. Here. Every step make sense and you grasp the perfect case each time to explain the benefits of this implementation Great job. Thanks :)

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

The best React SOLID tutorial ever! Awesome!

Only push back that I would have is that SOLID principles aren’t meant exclusively for OOP. In fact, Uncle Bob makes that explicitly clear in his book Clean Architecture along with providing some examples of how they might apply in other non-OOP paradigms.

for the LSP I think one way to summarize what you're trying to say is: the custom searchInput component and the regular input component should be replaceable So, by passing all the "input" props to your "searchInput" you could simply exchange one for the other and the code would still work

Senior engineer here, and I came in very skeptical about this because I think of solid principles as an OOP thing. But I found this to be a surprisingly good way of thinking about solid code in a functional application. One thing I am curious about though... why do you deconstruct your props on the line after they are declared in the argument of your component/function? I would argue that this pattern can cause issues. For example, if you had an onChange prop for a input-field wrapper, where you actually abstracted away the event itself and just passed the target.value back to the onChange function prop that you took in, then you might do something like this: onChange(e.target.value)} {...props} /> But when you spread ALL of the ORIGINAL props, you'll override your onChange here. Whereas if you deconstructed your props in the function argument like this const Component = ({ onChange, ...props}) => ... then you wouldn't have that problem. TypeScript would catch this error, but it can still cause a headache for no reason.

This video has saved me from a lot of pain 😭 thank you!

Thank you for this piece. I learned a lot.👏

13:51 Alternative suggestion: use `{product: Pick}` for the thumbnail props. Your principle is kept, but a) you don't break existing usages, b) you're much more opened to using other Product's properties in the future, and c) it makes more sense from a consumer perspective, that might have a Product object and doesn't want to be aware of the internal implementation of the Thumbnail (and what it needs) Note: in this particular case your way might make more sense, because you might want to use "thumbnail" for stuff that are not "product", but it's still a nice option that makes a lot of sense in many situations.

This might not be the OOP but it's still great to know this method to have a nice and clean code using React. Thanks bro for sharing!

Finally, we have dev care about paradigms and solid principles, 2 thumbs up!!

Thanks, nice work, all examples make sence! Would love to have more "code quality" videos

Awesome! I have seen this for the fourth time to understand it better. Kudos!

Amazing cideo! I think the solid principles are a double-edge sword. Lots of abstractions can make a codebase harder to understand for a new dev. So I try to be pragmatic and allow to deviate from SOLID when necessary.

Thank you for this video. It's good and rare to see someone explaining SOLID principles in the React context. I want to make one addition below. For the Liskov Substitution Principle, we should also make the current Tailwind classes overridable by using an npm package like tailwind-merge and combining classes that come from parent to the already existing classes in child component by making each individual class overridable. Otherwise when className prop is inside the restProps that are spreaded, a single class like "p-1" passed to the parent would reset all the classes the child component has. Also, instead of passing creating an `isLarge`, you can just pass the tailwind class `text-3xl` to the parent. Otherwise, each time when the designer wants to add a search input, small, big, medium, extra large, etc. you would have to define a new prop which breaks the open closed principle.

Damn, without knowingly, I am actually applying these principles. I came to realize to use practices like these while building my very first production level application, where you need to handle complex components and make them easy to reuse and readable.

Great to see SOLID principle in React, as reading SOLID in the form of back-end coding languages kinda bore me a lot tbh :D

Serious. I have been using this principles in my react code and I had no idea I was using them. I mean I never knew there was something called SOLID principles but because I have been coding for long and I always come up with ideas to make my code clean, I kind of knew about this but never thought its a principle out there that's been used by the community. Wow

"...Make no mistake, there is a principle like that. A function should do one, and only one, thing. We use that principle when we are refactoring large functions into smaller functions; we use it at the lowest levels. But it is not one of the SOLID principles - it is not the SRP. Historically, the SRP has been described this way: 'A module should have one, and only one, reason to change' " (c) Clean Architecture by Robert C. Martin

For the last principle (D), I would note that this is especially useful for testing and for allowing to not tie up your code with specific concretions. For example, you are working on an application that has Firebase login. During development and testing you don't want to call Firebase each time with a test account but rather you can just inject a mock auth provider instead, making tests run a lot faster. Equally important, if in the future you want to change your auth provider, you just implement a new concretion of the new auth provider (a single class) and then all of your application works fine with it.

I think it's important to point out (especially for new developers) that "responsibility" in SRP is not synonymous with function. It would be easy to confuse a responsibility with a single function. The word "responsibility" in the context refers to the sate of the object. In true SRP fashion, a class, component, module, etc, should only have 1 reason to change. That reason is its responsibility. A good example of this would be an "Employee" class in an HR application. Let's say that class is responsible for holding employee information, like name, age, start date, department, etc. Changing any of those parameters is still within the realm of the class' responsibility. However, if an employee's performance management was added to that class, then that would be a violation of SRP because the class is now responsible for the basic employee information as well as handling the employee performance. The SRP method would be to create two separate classes, EmployeeData and EmployeePerformance.

I'm a beginner React/NextJS developer. Luckily, I've componentized aspects of my page much like you showed during the SRP portion of the video. However, I feel like there is a fine line between componentizing things to make an individual page look cleaner versus having all of those component files cluttered in your project files. For example the "filter" component, which had 8 lines of TSX - is that really making a difference in cleanliness AND efficiency by having to initialize another component that ultimately requires more text data in order to function, when it's so miniscule it probably wouldn't make a difference in speed by using it without it being componentized? I'm just curious because I'm doing exactly this, but not to that extent. I am only componentizing portions of the page that relate to each other, with the size and complexity of the component determining if I should componentize it further.

nov 2023 and still a great video, thank you!

Fantastic video! Looking forward to view more!

Very well explained, thanks! BTW, what do you use to make indented columns in different colors in your editor?

Great video! The only problem I see, about OCP principle example (09:13), is that you turns the icon possibilites too generic (ReactNode), and sometimes it can turn out a problem, to just not declare the static possibilites of icon values that the Button component icon prop can receive as value. In that case, you can use DI to create a kind of interface and every single icon shall to implement that interface (I'm using the icon example, but it's better to think in any other cases where the prop is not a ReactNode).

those are really awsome videos. I just learned java from ground up and to see these principles also applied to react makes so much more sense now! some constructive criticism for you videos: when you hav a video that has a lot of text like code windows and you put some quotes" like showing a sentence that summarizes the principle you are talking about, it is really hard to read. may put a box or something behind that text you overlay on top :)

do this for every loop in a big project, good luck with that when debugging

Thank you for your work - useful points for me!

Nice one bro.... easy explanation with code. Like that one 👍

Awesome thanks for sharing

Really helpful. Thanks

a very helpful video, the content is simple understand, this is very useful

I would add that instead of fetching data with fetch, axiom of w/e + useEffect and throwing it into a hook, start using React query which does that and MUCH more for you.

That's a SOLID explanation. Great stuff. Keep up

Thank you, sir!

I believe that you must create a video about react clean architecture , keep growing , you are good at this

Every new react developer should watch this video. Very useful. Thank you!

Nice explanation, thank you

Nice explanation in the Reactive world. thanks

Wow, this is really awesome. Thank you

Great explanation.

excellent video, Thanks for sharing!

I have seen a lot of code that I call "the code of the 2 infamous geniuses". It has a lot of factories, builders, strategies, different patterns and complex tools just for simple tasks. At the same time there are big classes with a bunch of responsibilities, an incorrect inheritance tree, huge if-then-else-if-else-if and huge switches. And all of that is placed in one big file, named like "Processor". The first "genius" is the author, the second one is the reviewer.

There's a convention followed in some companies that if your component code exceeds some specific number of lines let's say 100, then that's a signal that component can be further broken down

ty dude for this masterpiece

Thanks man for a great video

You are the best!) Awesome video!👍

Thanks a lot for this video!!!

Great explanation! 👏

Coming after the Berlin React 2023, you were the only speaker interesting today. I subscribed as well, i'll be watching all of your videos :)

thank you so much 👋👏

I like the idea of trying to apply OOP principles to functional programming, even though obviously some of these are subjective interpretation of the original OOP principles.

U r the besty❤. And yhe sometimes we make some crazy stuffs like the thumbnails

it was good, thank you for the video

Thank you for your awesome video.

your useRateFilter hook is purely an alias over useState() since handleRating is identical to setFilterRate. So beside the name clarity benefits are there any principle that I miss behind this ?

Thank YOU !

Thanks!

Really nice. I like how you done all of it on one breath! Impressive! We cyborgs, doesn't need oxygen! 😂 Probably to fast for noobies but they can slow down or stop vid to reflect on every point you touch and read code that looks like perfect example. I really like it.

one really good advice to Single response principle is that keep business logic and framework logic separated.

great video thx

I have been waiting 5 years to see someone show something any good to SOLID that is not surpassed by writing easy to understand code. Lets see

Thank you!!!

I find typescript reduces the ability to read code, increasing cognitive load. Our team stripped Typescript from most of our projects and are very happy we did that

Even better for DIP is to take a services approach and maintain the logic out of component scope so you don't need to do the useCallback dance as you have stable function references. Which also solves other issues and promotes better application design.

Great~ What is the theme of vscode?

Hi, it's a very inspiring video. I have a question about adding theme support in React. Can you share some good practice of adding theme support? Our use case is that we use the React app as a component in our HTML page. We want to allow out host app to be able to support light and dark themes. How can we design our component to support that?

Great one , Thanks man

may I know the color theme you are using for VS code ? it's look a bit intuitive

Should we create a custom hook in case we need to use fetch data only in one component? Just want to ensure cause my friend dev said it’s not necessary

Please what font do you use for your VS code editor?

nice video man !!! btw what theme do you use? its look clean in my eyes

Which vscode theme are you using in your code editor?

How are you showing the package sizes next to the import statements?

great vid, subbed

Very useful

If you do not export props type from a component, what good is giving a name as "IComponentProps" instead a short one as "Props" ?

For the last principle you should always wrap function with useCallback to prevent unnecessary rerender function block.