The Biggest Mistake Intermediate React Developers Make

[@ZynthCode]

You are absolutely correct! However, it did feel a bit like an extended way of saying, "Consider creating separate components for each use case instead of adding numerous prop configurations, which can introduce unnecessary complexity into our code as it grows." :'3

[@ShawnSandy]

Another approach is to design the card as a presentational component paired with a data container for managing data operations, such as loops. The card should focus solely on rendering the UI and remain agnostic about the type of content it displays, whether for an employer, user, or any other entity. This separation of concerns ensures clarity and modularity in your codebase. By isolating the data layer from the presentation layer, you can achieve a cleaner architecture, allowing each component to serve its specific purpose. This strategy also enhances reusability and simplifies testing and maintenance. Enjoy your work, and keep it up!

[@rand0mtv660]

But his code does that in a way. CustomerCard and EmployeeCard both just render data passed to them without knowing where the data comes from. In my experience, trying to come up with a super abstraction that would be agnostic for these different types of entities is a waste of time because most of the time you don't show same UI for them. You might show similar UI in some cases, but not the same UI usually so you end up with a mess of conditional logic to render all different variations as was shown in his initial code. Sometimes you might be able to abstract it and make it somewhat agnostic, but other times it's just better to create separate components and do basic abstraction such as BaseCard that was shown in this example.

[@cosdensolutions]

yep that's another way of doing things. I personally find it easier to colocate data with the UI since the complexity isn't there when your components are small in the first place

[@psychoedge]

While I agree with your idea I think most of the time you end up making things more abstract than they need to be, and especially junior or intermediate devs might stumble across this. Also only works in very very streamlined UIs, not if they're a bit more diverging for the sake of more specific wording or layout depending on context.

[@NeChannelXxX]

@@cosdensolutions in my current project I decide to create a component connected to Zustand so that I can place it every where, can set the correct data via store setter from the ui somewhere in the app and read the needed stuff from the component (MyUpsertDialog) via getters. After that I realize that I have another Thing that need same logic but I decide to create separate store and separat UpsertDialog. The only what is really reused now is the Shadcn Dialog stuff. It works like a charm btw. But I am not sure if I maybe overseeing some pitfalls with trpc.

[@adrian34234]

As a junior programmer before watching the whole episode, I immediately thought that while in react we shouldn't duplicate the same code unnecessarily, in this case, the best option in my opinion would be to separate UserCard into EmployeeCard and CustomerCard, because even though they are very similar, there can be a lot of interdependencies and you need to pay special attention to make sure everything is implemented correctly. By splitting this card into two different components, we duplicate the code, but save ourselves the trouble of type-based conditional rendering. Edit: after watching the video, I see that I was right and it feels really cool, and as for the code, it now looks much better and is more readable. Thank you very much for this form of learning, it helps a lot and it is easy to remember such things, please more haha

[@amackzie]

the wrong duplication is better than the wrong abstraction

[@frstylol]

I've been really falling in love with render functions lately. Inside of writing ugly ternaries for stuffs like that inside return, I just create a render function and handle the if statements in a cleaner fashion.

[@shwetanshu13]

I cannot thank you enough for this video. I have been stuck with this problem for so long. Whether to prioritise dry technique or scalability while writing code in react. Very helpful video. Thank you so much

[@Shuyinz]

This is quite common methodology if you are going to follow single responsible principle and then high coupling, and low cohesion.

[@elieghanimeh02]

I'm a react native developer with 2-3 years experience, and about a month ago that is EXACTLY how I approached the situation, like you said I had about 13 different types of "cards" and they some similar data (logId, date, employeeName, etc...) but the others are just different. Difference is that I was fetching the data from an API and each card had a cardType. Used the baseCard for everything in common and then used a switch case to see which component I had to use for each type of card. No messy ternary operator, each card has its own component with a clear name to it and obviously a baseCard for the common data between all of them. Love your videos btw

[@KoOcie92]

You made plenty of good points. Based on my experience, the biggest mistake many React developers make is falling into the rabbit hole of over-abstraction, particularly in the early phases of a project. While the DRY principle looks great on paper, in practice, React development often demands flexibility due to frequent context switching caused by changing business requirements. This can turn "reusable" abstractions-whether components, hooks, or utilities-into a nightmare for maintenance and refactoring. Sometimes, duplicating a bit of code is a better choice early on to preserve simplicity and adaptability P.S. To all junior developers: Focus on creating structure and logic that is simple and easy to read. If you work in a well-organized team, rest assured that any opportunities for improvement will likely be pointed out by your senior or lead developers during code reviews, which are one of the best ways to learn and grow as a developer

[@ifeoraokechukwu1346]

Nice video @CosdenSolutions as always Yet, binding presentational UI widgets to application data (e.g. Customer-Card or Employee-Card) more-so with static types is not a good way to build software in React or any other UI library. Huge props for the use of AI but still needs a bit of work Cheers!

[@Yoband706]

I see this pattern very often and wholeheartedly agree with you. Thanks for bringing it up and explaining it.

[@MattElisa97]

Nice job that's very smart organization .I love this kind of video !! MORE MORE :)

[@pawelswietek825]

Hi, is it good practice to keep subcomponents in the same file if they are only used by the main component? I received negative feedback on this in the past. I also keep custom hooks within context files if they are closely related

[@cosdensolutions]

yeah it's totally fine, but it's up to preferences of the devs and the project. Best to follow the patterns of the project, but if you want to adopt this one, go for it!

[@jlrodriguezfragoso]

We could also leverage the Compound Components pattern and lean first towards AHA (Avoid Hasty Abstractions) over DRY (Don't Repeat Yourself).

[@moneyDev1111]

do senior developers use MUI or bootstrap or they prefer to use tailwind with vanilla html components? Does it make sense not to use any components library to gain in app perfomance? will there be any after the build? thanks in short what's the most optimized react "stack"?

[@AlexanderBelov-y8o]

You will end up having to create your own component library anyway. Starting with one will save you a lot of time, and you won't have to maintain your own.

[@deveshrawool6035]

In short just check what props you're passing to a component, if you see they are almost same use one component and if not prefer different components and then decide if you need common child components based on the data set you're passing

[@jorgecarlos6277]

How did you set claude in our vscode environment?

[@jerryknows7765]

"Inversion of control" is the magic formula here.

[@moneyDev1111]

hi, what do you use to see the colors in the tsx files? color picker extension or sth else? thank you

[@peterjordanson4201]

Nice video! What is the AI that you are using?

[@DevwithMus4867]

Cursor

[@go5555went]

Thank you for the wonderful video. Engineers like abstraction, so components often tend to become complex. I'd like to try to create simple components like in this video. What's great about this video is that it doesn't say this is 100% correct.

[@ikirachen]

i do not think local functions and locally created data are good idea... or something in the latest version of React is changed ?

[@hoaxygen]

For your functions "renderStats()" and "renderHeader()", don't they escape the React lifecycle and lack the reconciliation step when you render them like that instead of regular components? Why is that better than a and a ?

[@wilson12365]

I had the same thought!!

[@Tanner-cz4bd]

I agree

[@frstylol]

Nope they don't becuase it's the same as writing the jsx inside the return body, it's still inside the user card component so it's lifecycle is same as the lifecycle of the component it lies within

[@frstylol]

It's not better than creating a separate component for header and status, but it's not worse either. Technically it's the same but for readability the render functions are better because then you have similar concerns close to eachother

[@toastyy1455]

You're correct, it's just a plain function, so it essentially opts out of anything to do with Reacts component lifecycle/state. I use both, but with slightly different use-cases. Plain functions in the jsx/tsx like { renderHeader() } are useful when the render logic depends on some conditions within the same component, and is usually not very reusable outside of these components. I believe there is less overhead using a plain function, as it skips out on the React optimizations, although i kind of doubt this makes any sort of performance increase lol, just an observation i had. Think of it as a more simple version of a component for a one-off case that doesn't really need an actual component built. An example of where i've used this before is for rendering an icon based on a condition in a switch statement. You could technically do it all within the jsx/tsx, but it's nice to keep that clean looking and move the statement into a render function. Using the version is considered a true React component. So it'll benefit from React lifecycle stuff, memoization, state, etc. These are your usual standard components that you'd create to be usable across the app. They're not limited to the component they were created within, highly reusable, and can house their own logic/state/etc. Usually the go to method when building components. If your component is extremely simple and doesn't really rely on any context/state/props, then it could be overkill in creating one. In the end though they're extremely similar and i've seen both methods in all of the codebases i've worked in.

[@kamill34]

as a junior developer, probably I would use discriminated union, because some keys in obj are in common, then some type detection and to get shape of data and split components into small chunks as you did.

[@nedimkulovac6394]

Love seeing you using AI! It's part of our lives now, and practical examples of using it are highly welcome. Also, I love your videos in general - most of the instructors talk at the basic level, while your videos are perfect for mid-level developers!

[@cthinkzz]

So, You are saying, you will write a new component for Employee, Customer & Admin (duplicating the same code all over again). And if I have to change how Title looks, I will have to change the code in all of its parent components

[@untlsn]

You probably should make reusable parts reusable. So Title component should be used in every card He used AI, so a lot of video just mist a point

[@cthinkzz]

@untlsn yeah right, it was misleading from the video

[@macigli]

This would also be a good place to use compound components pattern.

[@alfonsoalejandroespinosade1728]

this will lead to a lot of problem if you have a big teams, people wont know when and how to use this components, plus you are passing the same object over and over again, my soultion (nitpick) 1) create a card provider that handles passing the data down children 2) use compoound component, as you kind of did inside basecard, but going more into detail, that is the real composition and flexibility, because the type of user is not tied to UI, and UI could change the layout easily, it always happen, so with render functions, generics and compound componets is easier to mantain, and easier to add test

[@untlsn]

From my experience making data "global" make refactoring pain Because if you need to change one subcomponent instead of going with tree to see where data is provided. You need to tract where provider was declared Plus it's mean that this subcomponents cannot be reused in other usecses, because that tight to provider

[@alfonsoalejandroespinosade1728]

@@untlsn i guess it will have the same reusability as usercard, admincard etc, is not a generic a component, if reusability is the issue, we would need to create a card component with just layout, and passing down as props the other elemtns, this way we prevent re-renders as well

[@TomGrubbe]

The original UserCard component didn't follow the single responsibility principle of clean code so it was a bad idea to begin with.

[@stephenoshilaja365]

Do you mind rendering your code so we can at least have a Visual representation of what your code creates.

[@dukim632]

dry is the most dangerous design pattern

[@francescolasaracina3964]

The usercard component is bad code because that is what it is known as "God Class antipattern" in OOP

[@amaury_permer]

I genuinely thought you was going to do a mix of render props and compound component for some reason.

[@dawidziomalify]

Wrong repo is linked in Description

[@TusharSrivastava-raziel121]

This is most certainly bad code because it is breaking at least 2 of the 5 S.O.L.I.D principles. The first being the single responsibility principle, and the second being the open close principle. 11:53

[@AlexanderBelov-y8o]

I would do say that the initial code is bad code. Too complex. Single-Responsibility principle! The final code is not just simpler, but easier to read.

[@enyelsequeira3619]

I would disagree with this. This is not bad code, but definitely not senior code, and also this is kind of a bummer saying to AI to just write “senior code” 🤦🏻‍♂️🤦🏻‍♂️

[@viophile]

What AI are you using? Apparently not copilot.

[@ptolemyhenson6838]

It's Cursor

[@bintangnaufal]

great and agree but this video could've been 8-12 minutes shorter

[@laurentlahmy277]

thanks for the work but please make it way shorter. there's a reason fireship videos are so short.

[@Sales-ki7lx]

So true king

[@paulo2357]

render functions are like nested component definitions, not the way react is meant to be use

[@paulo2357]

Oh cursor already knows that

[@rand0mtv660]

Like the example you have shown. One thing I think is that last refactor to split components into smaller parts was unnecessary in this case. It is unnecessary mental overhead now, even though it's all in the same file. For bit larger (or more complex) components it does make sense, but for something like this to me it's just unnecessary burden.

[@cosdensolutions]

that's fair. One advantage is that when those components grow (they will), you already have them separate and can directly go there to add new code

[@rand0mtv660]

@@cosdensolutions Yeah in that case I'll just abstract at that point in time, no need to do it sooner. I mean it's not a rule or anything, but I've seen people do these abstractions early and ending up with 3-4 layers of components for something that could have been in the same original component without issues.

[@the_saliheen]

I would say these 2 examples are not good and better. They are actually bad and good. Let me explain: 1) No reusability. While it looks like we are reusing logic, we are actually "colocating" 2 separate pieces of logic in 1 poor UserCard component. The good code actually reuses the logic by introducing the BaseCard. The bad code has 2 different logics residing next to each other. 2) Single responsibility principle is violated in the first example. Now the UserCard is trying to handle different goals of showing different data. 3) Not scalable. Imagine there's a third slightly different use case - are you expecting me to add 5 more props to UserCard component? While it looks like the UserCard component is flexible - it's actually not in reality. It has a rigid structure depending on the input data. Other use cases might easily break these fragile rules. Props in UserCard are repeating each other. Why have the "type" field and have all those flags as well? The component is so dumb, it cannot evem decide what to render based on the data provided.

[@balduin_b4334]

hell yeah, my cards are scalable 😎

[@rand0mtv660]

Yeah initial code is bad code, but I've seen it a lot of times. People focus on keeping their code DRY as possible that they end up creating super unnecessary abstractions with conditional logic like this. I mean, we've all done it or are still sometimes doing it. I know I've done it way more when I was less experienced. No shame in that because there is no perfect code. This example was simple, but still nasty. As you've mentioned, if he added that another role, component would just get way worse.

[@cosdensolutions]

it's better than everything in the `App` component 😁

[@lnezzzardl]

i love your channel but since you write code with ai the videos have become less interesting

[@unusuariopromedio4229]

Why?

[@Fybuh]

what matters is the lesson we learn. he explains the codes even if its with the help of copilot. it shouldnt be a reason to say his videos have become less interesting

[@cosdensolutions]

Interesting 🤔

[@WarayVan]

That’s an opinion, and you’re entitled to it. Here’s mine: AI is a tool, just like a keyboard is a tool. Did devs in the 1900s dunk on other devs for using keyboards and terminals instead of punch cards? Maybe. 😉

[@jimking2692]

You might as we'll use vim instead of vs code 😂

[@RaizenFaust]

Almost 18 minutes wasted for this. I mean the intention and the code is good, but it ain't worth all this blabbering, sorry. I don't know why the trend on youtube is to upload videos as longer as possible. For everyone else, to spare you the trouble, if you have different data shapes that are being passed into a component, don't try to use that component for everything and conditional render stuff like: "data.type === type_1 render content_1", "data.type === type_2 render content_2" and again down the line: "data.type === type_1 render content_1.2" and: "data.type === type_2 render content_2.1" "data.type === type_2 render content_2.2" in the same component. Instead, use separate components so you have more modularity and less crammed code. There, couple of rows and 2 minutes, that's all it took.

[@nikita3543]

Idk, but last videos I see on this channel little bit disappoints me, because every time you try to say me in other words how to reuse components, seems you just lost ideas for videos and trying to just put some advertising here. Second thing is you try to put AI in your lessons and it's not best way to teach people how to do, I stopped of using Copilot because I felt it makes me dumber and I couldn't write simple things by my hands, because it does it for you. Now I see AI even in lessons on KZbin and after update you have to think what happened just few seconds ago after such a global changes, you aren't showing it to us completely code, I mean best way for learn something is make it as deep as possible and you're just showing us the title of the article instead of the content. Also I don't understand reason why code is so zoomed, did you really see people who works with screen with 15 lanes? I'd prefer to see whole components than part of code and imagine what is on the top when you scrolling. I know you have to focus us, but isn't better way? It's just my opinion, ofc I learned some new things from this channel and I thank you for this, but I think you can do it better

[@youarethecssformyhtml]

Exactly. I hate using AI because it makes me so lazy. I can't tell you how dumb my colleagues in university are because of it and I can't take their stupid questions anymore honestly.

[@Hiro2k10]

Interesting to see how this wave of AI is burdening learners due to content being churned out heavily leveraging it. I'm definitely glad I'm not trying to learn in this day and age. Hopefully you guys can find some more old-school creators who stick to teaching without AI ❤

[@youarethecssformyhtml]

@@Hiro2k10 IDK if I'm also one of them but I'm not against using AI in teaching or in general. I'm against using it too much because it makes you lazy. I also use it when I'm stuck but not that much.

[@Hiro2k10]

@@youarethecssformyhtml That's really good that you're only resorting to AI when needed! I think having AI in tutorials depends on the audience. Juniors benefit more from no AI, while I'd say high mid - seniors it's fine. As an 8th year senior I expected 95% of what he ended up with anyways, so cutting out the manual coding parts was beneficial to me.

[@serhiiherasymov4809]

Gen z inventing inheritance

[@chomchom4679]

I love your videos a lot but it never fails to irritate me when you over explain every small step twice or thrice like i gotttttt thattttttttt oh god i am gonna blow something up . But you make good videos so i have to keep watching regardless. Thank you

[@cosdensolutions]

Interesting 🤔

[@Hiro2k10]

​@@cosdensolutionsthis was my first vid of yours. I think the content is solid but you definitely do reinforce the idea a bit too much. It's a good idea to use reinforcement but tone it back a bit. Much love, keep making useful content.

[@happylittlesynth]

@@cosdensolutions Reinforcement + Repetition is good. Keep doing what you're doing!

[@kapxapot]

So it's just tell your AI to write the code as a senior developer instead of an intermediate developer, right? Otherwise, instead of all this long video you could just say "use component composition". 😏

[@romantyniv5381]

I dont like "={true}". Can be without that

[@sebastianmihaiprisacariu8975]

This would have been a prime opportunity for component composition with a context for passing the data around.

[@cosdensolutions]

there is always more than one way to solve stuff!

[@sebastianmihaiprisacariu8975]

definitely! Loved the point you made about not all components needing to be reusable. It’s much more difficult to make a good reusable component than to create components for a specific use case. I’ve had my share of problems with trying to reuse components that were not ready to be reused and ended up in a really complex component that was a nightmare to maintain. Making changes to it would often destroy a bunch of other things.

[@Hiro2k10]

​@@sebastianmihaiprisacariu8975 Interesting suggestion of Context/Provider for the Card level. What would the performance implications be if that were mapped out across 1000 cards?

[@dummy_code]

I really like your videos but this one makes no sense. Is that really intermediate code? It looked more like very bad code even a beginner won't write

[@SirBenJamin_]

This whole idea that because you're a senior developer means you'll always write better code than a junior is nonsense. It comes across as being really quite arrogant. Good code is good code. It doesn't necessarily mean it was written by a senior developer. I have worked for several companies where I have seem junior developers excel the seniors, and the only reason there was a role difference was because of the time they'd worked at the company.

[@untlsn]

Because many companies treat juniors and seniors based of they years of experience Where 1yr junior can have way more experience with for example RSC, Trpc and tailwind Then 6yr senior that have experience only with SPA react class components

[@youarethecssformyhtml]

​@@untlsnexactly. Years of experience should not be a major factor when hiring.

[@Hiro2k10]

In the truest sense, a Senior will always write better code than a Junior. The real problem is people who aren't senior level devs reach senior status just by spending ~5 years as a dev.

[@SirBenJamin_]

​@@Hiro2k10 I guess what I am trying to say is that for the most part, being senior (or higher) simply means you have more years in software development, perhaps in completely different languages. It doesn't at all mean you will write better code in all cases. It's a fallacy. One that I see time and time again. Judge the code by itself, not by the persons role that authored it.

[@Hiro2k10]

@@SirBenJamin_ Yeah I agree. Titles are bs, build your own opinions of others skill level. Devs are known to have egos, but some places have healthy work environments where people set seniority aside and seek to learn from anyone.

[@icetmzz9074]

bro just said ai can do everything,.

[@bastiendufour3841]

I’ve to tell that even if I used to love your videos… this one looked like useless to me. Let me explain, you basically did nothing in this video. You didn’t brought your expertise. You just sent some prompts around and explained what the ai has done… I didn’t found this video really interesting. That’s my opinion and I hope you’ll come back to the time you were coding ❤

[@cosdensolutions]

Interesting, because I feel I used the AI to just do the boring work of writing. I told it exactly what to do and that comes from my "expertise" It's very interesting because enough people commented like you about the AI, but at the same time this was my best performing video ever in terms of views and view duration so I'm not sure 🤔

[@Benjamin-Chavez]

The ai thing was kinda lame man. Generally dig your videos otherwise though.

[@Naz-h8z]

Video is so slow i had to stop at 4 min

[@Aioah...]

Mistake, not using tamagui ❤

[@youarethecssformyhtml]

Just because you find it good doesn't mean it's a mistake if others don't

[@Edgars82]

That is bad code. And noone actually writes code like that. You are just making up non existing problems to create content.

[@yezinia]

Thank you sir, this is the best comment here

[@steve23063]

Why exactly is it bad code? I write code like that. It makes perfect sense if you come from an object oriented programming background. You keep common logic in a base class (or component in this case) and extend it as needed.

[@Edgars82]

@@steve23063 you should create separate component for each card section. Card component does too much things. Also intermediate developer would create compound card component in case like that.

[@Hiro2k10]

The AI output isn't amazing code, but It's a structural improvement over the existing. I separate data layers from presentational, and create single responsibility components all the time. Guess you only know what you're surrounded with.

[@Edgars82]

@Hiro2k10 i'm not about AI output. Initial code is bad.

[@NanumGamerDhaan]

First ❤

[@strategistaow3520]

Sorry, I have switched my framework. I have switched to Vue. I might unsubscribe in the future

[@cosdensolutions]

all good! vue is great

[@cafecafeo]

Wowzers, thank you for letting us know! Please, keep us informed!