The Biggest Mistake Intermediate React Developers Make

In this video, I want to show you a mistake that  I see a lot of developers make in their React applications that's not so obvious, because  this mistake doesn't really affect junior developers all that much, but it mostly affects  developers that have some experience with React, they understand how to use React and kind of the  mental model of React, but then they still fall into this mistake because it's very easy to fall  to, because it comes from good intentions. And this is actually a mistake that you're probably  not going to find if you do a search on Google or YouTube on like top React mistakes, because people  don't talk about this one. Again, it's a little bit more nuanced, it's not so black and white,  but it's extremely important because it really makes the difference between a mid developer and a  senior developer, in my opinion.

So if you're down to explore this mistake with me, then sit back,  relax and enjoy the show, and also subscribe. It's completely free, and I plan to make a  bunch more videos just like this one. Alright, cool.

So let's begin. So over here, as usual,  I have an application that I'm going to use to essentially demo you this mistake, and everything  is going to happen in the app component. And then in the user card component that we have here  at the top.

Now, the mistake over here is, like I said, in the introduction is a mistake that  actually comes from good intentions. It's come, it comes from the intentions of wanting to use React  the way that it's supposed to be used, right. So when you think about React, right, React is a  framework or a library, whatever you want to call it, that is designed to be made up of multiple  components, multiple small pieces, and you put those components together.

And more importantly,  you should as a developer, try to find ways to reuse components in multiple places, instead of  duplicating code, and writing the same thing over and over again in all these different places. And  while that's generally a very good thing to do, and it's something that I try to teach in all of  my videos, and I recommend that all of you here watching actually learn this, there comes a point  where you can do that too much, and it actually becomes detrimental to the actual project, it  becomes overcomplicated, over engineered. And it's not the way that I would recommend that you build  your application.

So with this, with this example, I want to actually show you one of such cases  and show you why it's bad. And then we're going to spend a little bit of time just fixing it  to see how this could be better. And actually, that's very important.

As we go through this code,  I want you to keep in mind that this is not bad code, I'm not here telling you that this is bad  code versus good code, it's not, this is actually good code. I'm here to tell you the difference  between good code and better code. So with that being said, now, let's actually look at the code. 

So what we have here in this component is we have this object over here, it is called employee data,  and it has a bunch of properties that are related to an employee. And then what we have here right  below is we have another object that says customer data that also has a bunch of properties that are  related to a customer. Now, both of these objects here, employee data and customer data actually  will share some properties like their ID over here, it's the same in both objects.

But they will  also have some properties that are different. For example, an employee is going to have years of  service and project count. And then a customer is going to have total purchases and then last  purchase date.

So some things are similar and other things are different. And so now if I asked  you to use these objects over here to use this data and actually build me and show this data in  the actual UI, how would you do it? How would you create your components?

Like how would that look  like? How would the structure look like? Well, let's see how this looks like here.

So what  we have here is we have a user card component, right? So not an employee card component, not a  customer card, but a user card component that I guess just by looking at this is supposed to  encapsulate both entities, both employees and customers. And if you look here, that's kind of  what this component is doing, right?

So here we're passing employee data as the data property of the  user card, then we're specifying that the type of this user card is of type employee. And then we're  passing here all of these properties to show the header to show the footer, the statistics, and  so on. And then also some custom actions, some configuration, a theme layout, and optionally, a  class name here.

And then we have another instance of the same user card component. So here we see  a great example of something that is reusable, right? Use the same component multiple times. 

But here, we're passing customer data as the data property. And we're specifying type customer  and then passing all those same props, obviously specific to the customer, but to the same  component. Now, here's the thing, right?

Are you going to tell me that this is bad code, right? Is  anyone any developer going to come in here and say that this is bad code? Probably not.

Because when  you look at this, this isn't necessarily bad code, right? We're following all of the best practices  and design patterns in react, right, we're following the methodology, the mindset that react  wants us to follow by creating a custom component, and actually using it in multiple places. But  now let me show you if you actually come here to the user card component, let me show you some  of the sacrifices that we had to make to actually get this working.

And then I'm going to re ask you  the question and tell me if this is the best way that we could have done this. So in here, if you  scroll down here to the actual user card props, let's see what they are. So first of all, we have  this data here, right, which we passed employee data and customer data into.

What we did here with  this type is we put this as an any type. So we lost here some type specificity. Instead of making  it either an employer or customer, we put any here to kind of encompass both types.

Now we know what  some of you are saying you could easily fix this by doing something like employee over here. And  then customer, right, you could do it like this, right and have both of these types here. And  I would say that that is a better solution to putting any here.

But you're still missing the  main problem of this. The main problem is that now you have to specify every time that you want  to add a new entity to this user card, you have to specify it here in a type and also in the data,  sorry, and then also in this type property here. So let's say for example, we also had over here  something like admin, right, and we put admin over here, right now we have three different  entities that this user card can represent.

And we have three different types as well. And are  you going to tell me that there's not significant differences between an employee, a customer and an  admin, right? There's not any permissions checks or any sort of extra logic that we might want to  have on the admin, for example, if we did it this way, like this component is, we now have to do all  of that inside of the user card component and make this component receive all the props that it need  to essentially make sure that it works correctly as it's supposed to in all these different cases. 

And if you scroll down here, you're going to see exactly what that is starting to look like. So  over here, we have this render header function, which is local to this component, it just renders  the header, which is a good thing, you want to see this in your components, right. But then if we  look here at the actual JSX, what it returns, we're checking here if type is employee.

And if it  is, we're rendering this part over here. If it's not, we're rendering this, which is applying to  a member to a customer, right. But now if we have admin, we're also going to have to add the actual  admin check over here as well.

And this is just going to complicate things directly, because now  we have to make all of these checks and make sure that no matter where this component is being used,  it's going to work correctly. And this is actually going to introduce a lot more work, right? Because  now every time that we need to put this in a new place, we have to add more props to it, we have  to mix and match more props.

And you can I promise you, you're going to get a bunch of edge cases  that you haven't thought about. And you might even get some impossible states where you render  something for an admin, for example, when you're on the employee page, just because the props are  not going to figure properly. And it's a mess to kind of figure out how to set them properly.

So  already, you can see the kind of sacrifices that we have to make the actual downgrades in developer  experience that we have to make, just because we wanted to make this reusable. And we wanted to  follow the way that react was supposed to be used, right. And that's exactly what I mean, right? 

Like, this is not bad code, nobody's gonna say that this is necessarily bad code, right? Because  we are trying to follow react in the way that it was supposed to be used, but it comes with some  sacrifices. And then if you scroll down here, we're doing similar things in all of these  functions in the render stats, for example, right, we're also checking here the actual type. 

And if it's an employee, we're rendering projects, otherwise purchases, right, these are two separate  things, they should not belong at the same component, right? Why are we putting all of these  things here, right? We're doing it here as well with the employee as well, right.

And we're doing  it in all of these other functions here, checking the type here as well, right, this is going to  become very complex very quickly. And it's not the way that I would recommend that you do things.  Now what I do like about this component, and one of the reasons why it's not so black and white  is if you look here at the actual body of this component, this is actually really great.

I love  to see that in an application. These you have all of these separate functions, right, that kind of  act as separate components, which is totally fine to do it even this way through a function, because  a component in react is just a function. So this is the same.

And because we're doing it like  this, we also now have the flexibility to say, for example, I don't want to render the header,  right, so I can just kill it. Or I want to put the header over here. And I can just do that super  easily, without having to deal with like super messy code and trying to find my way around.

This  is really, really good, right. And we like this, and we want to see this in actual applications. So  we've established that this is good code, this is okay code, and it's code that you could reasonably  ship in production if you wanted to write.

So now, let me actually show you better code, a better way  to do the exact same thing, but just a way that is going to reduce all of these actual problems  that we have. And instead, give us a lot more of the benefit benefits of reusability, but only  when it should be there, not applied generally across the board. Now, before we continue, I just  want to take a very quick moment to really think about what it is that we're actually doing in this  video, because what we're doing here is something that is called learning by doing right, you're  not just watching a traditional lecture video, you're actually watching me build this entire  memory game, and you're learning by seeing me how to do it.

And then you can do it yourself.  That's learning by doing, which is great, because that's exactly what brilliant, the sponsor  of today's video is also doing. Brilliant is a place where you learn by doing you have 1000s  of interactive lessons in various topics such as math, data analysis, AI, and of course, more  importantly, for us programming, brilliant has a learning platform that is designed to be uniquely  effective.

Their first principles approach helps you build understanding from the ground up. Each  lesson that you have on there is filled with hands on problem solving that actually lets you play  with the concept. This is a video by Darius Cosden, from the company called Cosden Solutions, and the  audio critical thinking skills through problem solving instead of memorizing.

So while you're  building real knowledge on specific topics, you're also learning how to become a better  thinker. And they have a ton of courses to choose from. One of my favorites is one that is called  Thinking in Code, which pretty much follows what we're doing here in this video and teaches you  solid foundations for computer science that are going to directly help you as a React developer. 

To try everything that Brilliant has to offer for free for a full 30 days, visit brilliant. org slash  Cosden Solutions, scan the QR code on screen, or simply click the first link in the description,  you're also going to get 20% off an annual premium subscription. Now to do this, I'm actually going  to use AI just to kind of refactor everything so that I don't have to do it myself.

And I think  it's only fair because nowadays AI pretty much codes like 50% of my code. So it should only  be fair that it tries to like now creep into my videos as well and help out a little bit. And this  is also going to be a good opportunity for you to kind of see how I use AI and maybe get a few tip  or two from that.

What I'm going to say here, as I'm going to tell it first, give it access to  my entire code base. I'm using cursor, by the way, if you're curious about that, and we're just  going to say refactor user cards. And actually, I'm going to give it to user cards.

So it knows  exactly what I'm talking about refactor user card to have separate components for the employee and  the customer without complex props being passed around to configure everything, right, because  we want to essentially keep things simple, right. And here, what I like to always tell it is write  senior level code and keep things super simple, because sometimes AI likes to just do a lot of  different things. So I'm just going to do that, I am going to come here and just remove this admin  stuff, because if I don't, it is actually going to do the admin stuff itself.

And I'm going to remove  here and put it as any like we had it before to see exactly how it behaves. So now let's enter  this and let's see what it comes up with. And then I'm going to kind of take over, just fix it up a  little bit if I need to, and show you the correct way of doing things, because the AI is perfectly  capable of figuring this out, if you give it the actual right instructions.

Okay, so it's done.  And now I'm just going to blindly accept all and hope for the best, let's see what it came up with.  So let's start looking at the app component.

So already, I think I can see that it got it exactly  correct. So our imports here at the top, we no longer have user card. So that's killed, we no  longer need user card.

Instead, we have customer card and then employee card. Perfect. Now we still  have our same objects.

That's exactly like we had before. But now we have two components here, we  have employee card, and then we have customer card. And as you can see, we're only passing the  data here to the employee card that belongs to the employee.

And then we're only passing the  actual props that are related to an employee to this specific employee card. And we're doing the  exact same thing over here with the customer card. So now we no longer have to worry about passing  all of these props, making everything reusable, it's much simpler to just have separate components  for each individual entity, and just go that way.

And then if we look here at customer data, this is  by the way, the first time that I'm actually going to look at this at the same time as you, we have  here a type for the actual data of the customer, that's perfectly fine, we could maybe put this  in a separate file, we have here the props, right, which again, are only related to the  actual customer. And then over here, right, very importantly, I like that the AI did this, we  have a base card over here, right, and we're going to look at that in just a second. But now here, we  have all of the code that is specifically related to an employee to a customer, sorry, and nothing  else, we have nothing about an employee here, we just have everything about a customer.

And this  makes a lot more sense. Now there's something to be said that we could put all of these in separate  components if you wanted to. And maybe we're going to do this as a separate step with the AI because  it's super simple to do.

But the concept remains, this is now simpler to work in and to edit and  to kind of use, then if everything was combined into one super component, if you look here at the  employee card, it's pretty much doing the exact same thing, a type here for the data type for the  props. And then we have pretty much the same thing over here, right? Again, the same flaws, it's  not in separate components.

But this essentially having two components like this is better than  having just one reusable component. And if you're thinking now that we kind of went against react,  and we're not anymore having reusable components, we didn't because we only now as you can see here,  we only created reusable components for the things that we actually need to be reasonable, like  this base card over here, if you go and open it up here, we just have a diff, right? It's again,  super simple.

This is just an example. But here would go all of the things that are common to both  cards to both customer and employee cards. Here, it makes sense to make a reusable component.

This  is actually the way that react wants you to use it make things that are reusable, but only for  the things that it makes sense. Don't try to put everything reusable, because then you're going  to shoot yourself in the foot and you're going to overcomplicate things a lot. So now if I ask  you this question, again, is this good code?

Well, it definitely is good code because we haven't  regressed from the previous code. It's not worse than the previous code. But this is  now better code because everything is now organized into a separate component.

And  we can even make this a little bit better, we can actually ask a follow up over here. So we  can tell the AI inside both components, we factor to create sub components and put them in the same  file as the main component to be more senior to be more encapsulated, and to be easier to understand.  Let's see what the AI does.

Now what I'm basically telling you to do is great, we have customer card,  it's really great. But now we can split this even further, make sub components as well and just  organize things a little bit better. So let's see what it comes up with.

And once again, we're  going to blindly accept what the AI is doing. I don't recommend that you do this unless you  absolutely know what you're doing. In my case, I know what I'm doing.

And I always look  over the code eventually in the end, and I'll update it. So it's fine. But if you don't  do this, maybe just be a little bit more cautious before blindly accepting with AI because that is  I promise you going to introduce a whole different set of problems.

So let's look at customer card  once again. So over here, now we have a header component, right, which was very similar here to  this user card component where we had a render header. Now it's a separate component, right?

Same  concept, just a little bit better, right? And all this component receives here some props as well,  which has some of the props of customer data, just handles rendering the header. And this is, again,  specific to the customer card, we have category list, same thing, we have details, same exact  thing, we have stats, same exact thing.

And now we have here the customer card component. And look  at this, we have base card, we have the header, we have the details, we have the stats, and we  have the actions. This is how React wants you to use it.

This is composability in React. Here, it  makes sense. We're passing just a few props, all the props that we're passing makes sense.

There's  no other better way that we could do things. And this is generally a better approach than just  having everything in a user card. And if we look here at the employee, I highly suspect that  is going to be the same thing, header skills list, and so on.

It's exactly the same thing. One could  argue that now because we have these separate components here, we could potentially make things  make these reusable if we wanted to. But again, maybe not because this one takes in years  of service.

And this one in the customer, which one was it was the details component. Let's  see where it is details. This one takes in last purchase date.

So it can't really make these two  reusable because it's related to the different data, right. But if they had similar data, just  like this base card over here that could be used in both places, then you make it into a reusable  component, then you reuse it in different places to not repeat yourself and write the same code  over and over again. So really, I hope that you're getting things now.

I hope that you understand  the differences and the nuances here. And I really hope they understand what I said in the beginning  of this video, that this is not about bad code versus good code. But this is rather about good  code in a nuanced way, and then better code.

And I really hope that this was clear in this video,  and that you actually get this because this is, in my opinion, very, very important. If you enjoyed  this video, and you want to see more videos just like this one, make sure to leave this video a big  thumbs up. You can also click here to subscribe or you can click here to watch a different video  of mine that YouTube seems to think that you're really going to enjoy.

And with that being said,  my name has been Darius Cosden. This is Cosden Solutions. Thank you so much for watching, and  I will see you in the next video.

Ciao, ciao.