React Clean Code: Advanced Examples of SOLID Principles

Key Takeaways

so if you want to learn more about solid principles applied and react but this time with more and more advanced examples well in this video we're going to cover up solar principles Advanced examples compared to the previous video where we went through about solar principles and actually explained solar principles at the basic level for every single principle from single responsibility to open clubes to list cost substitution interface segregation and dependency inversion so we're going to go through a very Advanced examples of how to apply solid inside of react and how to get from a junior in BR and clean code into a senior developer so before we get started everyone should know that this video is going to be more of a continuation compared or with previous Soul principles video the main video the video if you like if you go to my channel Cod one in here you're going to find like this is the right only right way to write react clean code and solid so this is like the main principle video that explains everything the basic level for beginners and everybody to basically understand what is solid how to apply every single principle in react and explaining pretty much everything so if you're not familiar with solid or you don't know how to apply solid react you got to go ahead and actually watch that video this particular video first before you can come back into this video which is more of an advanced example sort of video so you can actually continue and watch this video and actually understand everything because we're not going to go through into the fundamentals of this video so we're going to cover up a lot more of an advanced stuff so we're going to be using the same repo that we used before for applying the S principles is still going to find all the code inside of there but this time instead of like we're not going to touch the principles forer but we actually created a new folder that's named Advanced and inside of that going to find every single principle in here with Advanced example so let's start with the first principle which is the single responsibility principle for a quick definition of the single responsibility every component should do exactly one thing so for example here we got this simple component here which is edit user Pro profile component which has like a profile picture where you can click and choose in profile picture you can update your name email and password and you can click in here update profile to actually update and save the changes of your new data or new profile so this is a little more of an advanced example compared to the previous one which we covered previously in the previous video which is a bit simpler compared to this one so for this one here we have a simple form of course so this one in here we have a form reactive react form in here we have some font picker in here where you can dust them out uploading and stuff like that and basically uses like HTTP or rest for apis to update the profile in the database so if you're look into the first component here which is the bad component where we haven't applied the single responsibility principle just yet we've got this component here is pretty simple like edit user profile bad we have like oh we using US state in here to keep track of the form data like the name email password and image we've got another state in here to keep track of the errors if there are any errors like you know when the user tries to enter the name maybe you say oh we do some validation and actually say oh the name is is not valid choose another name or like the email or the password in here has to be a strong password and y y y and here for the handle input change where basically we just like handle what is the you know the current like whenever a name put changes in here we just go ahead and set the form D using that state and we do some validation so for example if it's a name we validate that this name is basically like required if it's if there's anything wrong if there's no name or if it's an empty thing we just do set errors and set the name the same thing for the email in here we do some rejects validation in here and as well as for the password in here we'll also use another regular expression to validate how strong the password is if it's not we just do oh password must meet the criteria and last but not least in here we use the handle image change which is another Handler in here to basically just take care of whenever we you know upload a new image and actually save it into the state and we have another Handler in here for handling the image change like whenever changes we set it on the state as well and last but not least we have this handle submit where it actually handles you know the data we have on our form and it submits it on that particular API like Local Host a user update it does a post for this and of course it does some try catch in here to you know catch any errors if there are any and last but not least in here we have a handle submit where he handles the submitting to you know the updating the data in here the form data inste of the HTTP in here our user update we do a post method and we use axios in here and just you know save the data and everything we use try catch in here to catch any errors if there are any okay that's pretty cool it looks pretty decent and everything now for the GSX which is the most important part of course there's a lot of things going on like literally a lot of stuff from like the Buton in here submit in to a lot of inputs that are being put together the code isn't really that well readable you can't actually read it that much you have to focus a lot on it there's a lot of input in here that put straight through like row input they're not encapsulated into like separate components or anything the form isn't great there's a lot of lowlevel handling of the form data and stuff like that so there's a lot of work to do in this particular component to make it work with the single responsibility principle so for example here I can already spot a couple of them like starting with the image apploader in here or the preview of the image you see this like form data image this can be encapsulated into a completely separate component that is only going to be taken and and responsible for rendering that preview image and uploading the image into the server maybe for example for this one where we have you know this is the input uh maybe for each input in here we can create a separate component like a form field or something for every single one of those just to render every single input separately and also well like for data handle in here we can handle data differently we can handle validation differently because validation in here is just super W and and we're not using any Library which we should use for validation because super powerful is going to make our lives easier and as well going to make our code super super easier and super tied up as well as like errors in here and the form data now if you go inside of the good one in here after applying single responsibility principle I'm going to find oh the you know we've we've done a couple of stuff in here so we start with the good one in here so this is our good e user profile component so we're going to start in here with the form in here so for the form in here we're using a separate Library which I recommend every single time for handling forums in react which is called the react hook form in here which going to make it 10 times simpler you're going to type less code you're going to have less gibberish inside of your components and it's going to make it super super clean and easy to read like for example in here we just do use this use form hook we provide it with the use form input which is just an interface of what is the POS like what are the fields we have like the you know the typing of the fields like we're going to have a name email and a password and of course for validation in here we're going to use Zod which is another really great library in here that actually takes care of validation it's very easy to do that as well it provides a very simple API like we can use this Z we can make sure this is actually a string and it minimum has one so if if it has you know less than one in here we're going to just like go ahead and display the oh please enter your email message error in here for example if an email we can just check if it's an email if it's not we can display this error as well or for the password in here we can make sure it's a string and it actually aderes to this particular regular expression otherwise we can just display this airor and we can make sure there OB is required as clear say here with this simple API we could completely replace this whole gibberish code in here of like manual validation which I don't recommend at all and now the code looks a lot simpler and basically just a single block of code that does everything for us for validation and this everything is going to be provided to the used form of like react hook in here it's going to take everything for you it's going to return return to you like a register function a handle submit and some state in here to get the errors now the next most important thing we did in here we went through for our inputs that we have before and actually encapsulated them into a completely separate Standalone component which called input field and this input field in here can actually basically render input for us if you open it up I have it like input field. TSX in here so this inut field in here is pretty simple so you have like inut field it takes a couple of props in here like oh the label text the field register in here and if there are any error in here to basically render the error down here and of course this is just a pretty simple the GSX in here is just rendering input with the label on top of it like using the label text and the different props in here passed into the input now the most important part you need to make sure you actually do this field register in here is actually what needs to be provided from our hook the use for hook in here from like the third party Library using to manage our forums this will actually go going to be able to go ahead and register the form with the hook or with the library so you can keep track of the state and actually update the value and everything so we simply just using you know the same time that it actually uses from the react hook form in here use form register return we do the field register in here we just pass it through that one through props and here props actually playing a major role for us and that's actually you know a really positive thing for us in in as react developers and that's pretty good now if we go back in here we just doing oh field register we do register and we make sure just register this field with a name and this field with an email the other field with a password and the same thing goes for the errors now errors in here we do access errors name message email and as well as the password in here so if there is any issues with that we can just you know the are is going to be popping off they're going to be put right over here and instead it right over here and the user can view them easily and of course now each component does one thing only because this is an input field so it does take care of input and in validation and displaying the errors and everything we got a button in here which is still doing a single thing as well so that's good the other thing that we needed to do as well is the profile picture apploader so we created a separate component for actually apploading profile picture and previewing it and everything now here it's the same the jsx uses it input again it does image data in here to actually preview the image you're trying to upload and of course it does image or upload image to server so it uploads the image for you and everything here again is tied up into its completely separate components that you basically don't need to do anything with it you don't need even need to pass any props to it because everything is encapsulated inside that one it has it State managed with that one and it works just flawlessly as well well as for submitting the data into the server in here or just like you know calling the API with the actual data we need so instead of doing it this way like the rway everything is set of one component what we need to do is actually go through and actually split that one and create a new file that's called services so this service f is going to just export a simple function that's called oh update us your profile where it takes care of one thing and and actually this is just to make sure we follow single responsibility principle so it updates user profile it takes data it calls the API and updates that one it Returns the response or an error and that's it now you can just go ahead and do await update user profile we passing the data and we're done the second principle is the open close principle so for the simplest definition of open close principle a component should be extended without needing to actually to modify the underlining source code so for example we've got this simple component or more of like drump down sort of button where you can click on this button you can get a list of drop down in here and you can click oh for example new projects new draft or new page and you can click in here and you can just toggle between the menu in here which is just a normal drop down right now if you look into the source code in here it's just a functional component that is a drop down it takes a bunch of props in here from a title that gets displayed right into this you know the button here like create or something the list of items that gets displayed right over here and whether or not to hide these list items icons now of course for the rendering part here we're just using a button to toggle that one and we just do toggle drop down to change the state and if the drop down is open we just go ahead and render the drop down where we Loop through all the items provided through the props and actually render a drop down item which is a standalone item in here that renders every single item as well and of course this one takes other props like the icon name description and everything now I may seem this component is pretty good aderes to like the single responsibility Principle as well and it adheres somehow to the open close Principle as well right all right cool so let's go ahead and see how basically the usage of that particular component so for the usage to drop down we do drop down we provide title we provide the list of items in the whether or not to hide icons and for this one here items are going to be an array of objects each one is going to Define an icon a name and a description and all of those are actually going to be displayed right over here now our code is sort of extendable because now we can play around with the icon and we can like swap the icons for example with this and the other one we can have like for example the same icon where now they're showing the same icon we can switch and do whatever we want that's at some point is sort of extendable right without actually needing to change or modify the source code but let's imagine let for example on the drop down here let's say we want to add like in like last thing of the drop down like a footer of the drop down we add another notion or sort of like a note below over there you say oh all changes are saved automatically or something like that or maybe we're going to change the order of you know how the title of the item and description of item are displayed or something of that sort like a very deep extension now when we really apply the LCP or open close principles into this it's going to turn our component into this really made up drop down component into this really good drop down component so here it's just a simple function it's drop down good so on this one as you can clearly see in here we're actually doing some compound sort of like rendering where each part is supported completely separately so for example in here drop down. drop down this is like the main container of the drop down is like exported you know all of them are exported from the drop down here but we do like Drop down. dropdown then we access the botton list item and here we can render as many items as we want and of course because this is basically we just like we can customize the drop down however we want we can like for example move the button you know Below in here maybe when I can add something to the foo as we wanted to do before in here like we can just you know this pad in here we can add it and it's going to be added right below in here like all projects would Autos saved and everything now this what will look like when you apply ocp so how we're actually doing that so if you go inside of the drop down here which is the good dropdown so we simple in here first creating a context because it's very important to actually share the state between all the components of the drop down starting from like the button the items the footer and the container and everything so here the main drop down here just simply holds up the state where we hold up you know each drop down open or to toggle the drop down has another function and he actually uses the provider like the context provider we already used to basically provide the state values so the children can use them the next thing in here for example the button you can take children of course like the button name and everything and here you can use the use context drop down provider to basically access to the state we are already providing from the parent drop down container and as well the same thing for the list in here using the children in here to basically render whatever we needed like the list name in here and the same thing we use use context to access the state in here and we can do oh if it's not open we can return n for that basically the same thing for the item in here so pretty much every single part of the drop down is completely independent from the other and all of them are linked through this really nice context through the provider and all of them sharing can have access to the same state pretty much and this is actually what it would look like and it looks pretty nice now it's actually have like small building blocks of different parts of the actual drop down from like the button the list in here every single item and you can utilize those in different plac places however you want but the different drop out items are still having the same source code literally having the same thing in here the item is not going to have a different source code but you can basically customize it who however you want you can like you know provide different props maybe or maybe a different class name for Style on it differently or maybe you want to put it different place like you can go ahead and put the item here right on the top which of course it doesn't make sense but it's just like a quick example and to Showcase how that basically works so using the compound in here and actually applying LC or open close principle makes the code super super clean easier to read and of course you can extend it and customize it however you want for the third principle is listov substitution principle so for the quick definition subtype components should be easy to replaceable with super type components so let's say for example this simple UI in here where we have a dialogue to read the privacy policy like for example we've got here General private privacy policy for our application and website where the user can go through that one actually read it whether to deny it and accept and continue so everything looks pretty good here just a simple dialogue simple component and everything so if you look into the code in here the bad code of course so we got the pairing component here which is the Privacy dialogue so this component basically you know it's the main one that renders the privacy policy has some GSX in here that renders all the privacy policy and has some handlers in here whether to handle basically when the user clicks on accept so you can basically you know uh provide like a specific ID for example of that user or that particular terms of agreement or privacy policy and actually go ahead and submit it take it to the homepage or whether to completely deny it from entering the website or using the services now let's say later on we needed to basically update our privacy policy where the EU and you all know the EU regulations we needed to basically provide a completely separate privacy policy from the rest of the word EU only so EU in here is going to be a child component of you know the main privacy policy dialogue right so e here basically should follow at some point of how the first one works or what constraint is should follow and how to basically hander everything sort of like independent right so this isn't actually following the listov substitution principle because you cannot basically just take this EU privacy dialogue component here completely replace first parent dialogue with it just like that without ensuring that they both have the same functionality and they both produce and take the same props and they both have the same behavior so for example in here if you notice like we have an unaccept here inside of the EU it basically takes it set of like a different set of parameters like the name and ID in here but for our you know main one it only takes the ID doesn't take the name or something so we cannot just go ahead and drop this one and expect it to work the same way I mean you can go ahead and actually just I mean you can go ahead and just easily swap between you know the main privacy policy in here with the EU privacy policy but keep in mind that they do not follow the the LOF substitution principle so you technically cannot ensure the same behavior so you cannot replace the Privacy dialogue with the EU privacy dialogue that easily so instead for the good example here what you should do to make sure you actually adhere and work with the lisov substitution principle is actually you can go ahead and create them like on separate components in here for example we got our general privacy policy which is the main component again but now they actually following and adhering and basically tied up with a specific interface which is called the privacy policy dialogue props so here it's going to make sure so every single time we add a new privacy policy we need to go ahead and use that same interface that means we need to implement basically the same API like the same unaccept and on deny API and if you notice for this unaccept it's taking exactly the ID it's doesn't take the name or something so it makes sure a consistent workflow between all the ones that actually extend from this so for example here the privacy policy uses that one so unaccepted here that means going going to only provide the ID in here like unaccept is going to provide the specific ID if you go for the EU one the same one in here actually follows the same interface so like it has to provide unaccept and UND deny and of course again it provides and it uses the same parameters in here so it provides the same ID only and it doesn't provide the name or anything other than actually needs so it basically provides the same parameters and of course inide of our component here where we use both so for Point here the privacy policy dialogue in here implements the same on accept on UND deny so they basically have you know the same things in here the same handlers and everything the same parameters in here because they're basically following the same interface and if you ever want to replace it and sweat up it up in here with the EU privacy policy that's going to be the same thing because they're both following the same interface and that means using and following the listov substitution principle made our components very easy to replace for the fourth principle we got interface segregation principle so the simple definition for interface segregation principle is components should not depend on props they do not need it's just as simple as that so let's say we have this simple example in here where we have like a user dashboard let's imagine this is a user dashboard and for user dashboard it can do like uploads appload images videos and stuff like that and of course when those kind of like you know jobs are actually finished they get a notification so like for example here project export finished or something with you know the email of the user and everything so if you take for example the interface aggregration principle the bad approach so for instance if we take the bad approach for this one let's say for notification component here let's say we have a main component that's called a notification component that basically takes care of rendering both the user project notification so it's kind of like rendering two types of notifications inside of the same component and of course it takes two props it take projects or user and depending on that so he checks oh if it's a project only renders the project GSX in here and the project notific ification otherwise if it's in user it renders the GSX for the user now of course both projects and user in here have a specific props in here for example the interface of user can take name or email and for the project in here it can take name only of course for notification props in here it can either take in a user which could be an optional prop in here so user in here have the possibility where it could be undefined the same thing for the projects in here now for instance if you quickly look into that component we can EAS know that this component is not adhering to the interface segregation principle because this component is literally taking two props two indpendent props in here like the user and a project and both of them could be object and he only uses one prop on the top so you can either use project or user so if like if he user project that means a user is kind of like a not needed prop right or another case if he uses the user that means the projects prop in here is not needed at all so that means it's not actually following the interface agregation principle and of course when we try to use that when we just do like notification we pass it to user in here or we can either pass it in the Project's object in here and it should work fine now to make our component follow the interface agregation principle in here we still have the same interfaces and everything but now instead of having one component that rules them all and actually renders both notifications for users and projects like we can simply create two separate components in here for example we can name this project notification that it only takes a projects and he only takes the props that he needs which is the projects prop and he renders the GSX that he needs period and the same thing goes for the user notification here only takes the user with its own interface of course in here and it renders the GSX needs un L bolt needs in here we can either render user notification or project notification depending on what we need as simple as that you can follow the interface agregation principle for the fif and the last principle is dependency inversion principle so the simple definition for dependency inversion is components functions or modes should not depend on concrete implementations but rather depend on common abstraction now to better visualize and actually understand dependen the inversion principle let's say we've got this submit feedback in here which is like a small dialogue for where the user can go in and actually submit a specific feedback by providing his name the feedback he needs in here on this text area and click send feedback to send it feedback about our website or application now simply for our feedback format here we simply just like you know take care of having the state to you know save the form data in here handle the change and everything and the most important part in here is actually handling submit so here handling sumage basically when we click or when the user goes ahead and click on send feedback to send the feedback and save it on our database so here it's basically depending on concrete implementation where it basically uses you know all the details so like it accesses the you know API your in here right inside of the component Like It prepares the D as well it does some error hand hand leing for that which is a little too much for our component and that makes this not adhering to the dependency inversion principle because actually has a very concrete implementation of the API handling side and for instance if you for example like let's say you know you ship this version version one of this send feedback form and everything and after like 6 months or something you decided to actually change the feedback you are in here where you needed to move from like a third party service into your own API service with your own database and you're completely different properties in here and everything and all the data are completely different so you got to go ahead actually inside of the component again actually change everything in here which going to make it a little harder and it's not going to make it very very maintainable but instead of doing it the other way you can do it in this really good way in here where we have this feedback component and you can actually use this feedback form and we can actually inject right into it feedback service and as clearly in here we have two versions of the service in here feedback service version one and version two and here feedback form can take it from there using whatever service provided and of course both the services in here have actually the same API so here you can actually swap between the services very very easily without even touching the code inside of the feedback and this will inverse the dependency so if you go inside of the good feedback form here it's a normal form the same thing as we did before it has basically the same thing but instead of actually having the concrete implementation of our API handling here we're just deleting this into this feedback service and the feedback service is provided throughout the props now the feedback service in here we have it inside of services feedback service so we have created you know a separate folder it's always a good idea to create a separate folder for your services we called it feedback service and the feedback service in here just like a normal class that actually has a Constructor so it can take whatever endpoints if you ever wanted to change the endpoint you can easily do that and actually takes a method in here submit feedbacks it has the feedback as a string and name of the you know user that is submitting the feedback and you can go ahead and manipulate the data however you want from like adding IDs preparing feedback data column in here into a separate function and most importantly here when it comes to the API it is actually using a completely separate endpoint that is being fed up from the Constructor on top over here so anytime you can easily access this feedback endpoint submit of course we can easily change this feedback endpoint whenever we need to so now we can have like for example this endpoint object in here provides feedback Endo version one and version two and we can swap between them very easily and of course later on we can create two instances of the feedback service in here each with a different version and we can easily swap between either version one or version two and that actually makes it adhere to the dependency inversion principle so anyway thank you guys for watching this has been an advanced examples of the Sol principles applied in reacts which is a continuation to the previous video of explaining SW principles to beginners so anyway guys thank you for watching hope you guys enjoyed and catch you hopefully in the next ones