Are Your React Components Too BIG?

Рет қаралды 24,145

Күн бұрын

Пікірлер: 113

11 ай бұрын

Breaking down components into smaller reusable ones is one of my favorite tasks. Unfortunately not all companies understand that the time you usually spend by rewriting them will pay off in the long run.

@martapfahl940 11 ай бұрын

7:15 as a German, I can assure you, this pronounciation was EXCELLENT =)

@cb73 11 ай бұрын

These are great tips thanks! I just have one use-case that is much more difficult to work around. It's when you are using React Hook Form. At the parent, you instantiate the form, then either pass it down (prop-drill) to all the children OR create a context hook at the parent to allow children to grab the form from the hook (the way I chose to do it). The problem is that React Hook Form manages the state of the entire form. Any children that updates the state of the form, will re-render the parent and all of the children. I am not sure if there's anything that can be done about it.

@jherr 11 ай бұрын

Is your form so huge that this is a performance problem? RHF and React sit on top of the VDOM, so components re-rendering doesn't necessarily mean that the DOM will actually be updated, only when it changes. A reasonable frequency of re-renders, limited to the part of the application that is actually change, is to be expected.

@oscarrojas3968 11 ай бұрын

The same but using formik

@tonyjaradev 11 ай бұрын

Thanks Jack, first time I see a practical use case for the react extension. Awesome vid!

@yassine-sa 11 ай бұрын

I actually once asked v0 to generate a dashboard and it looked sooo good and I copy pasted it and continued on... Later on I found than I literally was scared of opening the file of that component, it was crazy hard to modify ever so slightly. And even if it's you who wrote that code, I'm pretty sure you won't remember what the hell where you thinking when you wrote it after a few weeks. TL;DR: simplify your components for readability and more importantly maintainability !

@WillKlein 11 ай бұрын

I only want 2-3 components (usually app-oriented) to be over 100 lines. Pure UI components that are necessarily big are hopefully coming from a design system library or maintained as shareable components. Having worked in design systems, most of those components were also broken up into smaller components with less than 100 lines each. Great thumbnail by the way!

@developersteve1658 11 ай бұрын

This whole video goes through the process I like to take when building a complex feature. Start with getting the feature built and functional in one component, then refactor for performance and maintainability. It takes two different mindsets to solve a problem vs. making that solution "good," so I try to avoid premature optimization as it can confuse the implementation details. Overall I disregard line length and try to code based on requirements and architecture. Some components are a few hundred lines (never more than 500), and some are 25. Depends on the need.

@IanJamieson 11 ай бұрын

You're final setup is bang on. Exactly what I do. On occasions if it's a huge app I'll also split it into modules, with each module having it's own component, store, utils etc.

@sgtduckduck 11 ай бұрын

Haha the classic horror film aesthetic of the thumbnail is 👌

@thiagomoraes791 11 ай бұрын

great video, I'm gonna change the way I do components and have an extra eye on rendering when testing my applications

@pjholmes2 11 ай бұрын

Excellent video. Exactly how I make components except I use context for state. I really wanted to use preact/signals but just can’t make them work. I’ll look at Zustand again.

@scriptedpixelsltd 11 ай бұрын

Really good breakdown, not even just restricted to React. Coming from Vue and looking at React again and it's nice to see how much better it's got since it was 1st released. Feels like these points are easily relevant to Vue3 👍🏽

@yogeshvanzara5553 11 ай бұрын

Introduction is awesome 🔥

@CathalMacDonnacha 8 ай бұрын

Great video. I noticed in the finished version you are importing each component individually. I know some folks are against using an index.ts file, so curious on your thoughts?

@jherr 8 ай бұрын

Yeah, we are trying to avoid "barrel imports" nowadays.

@Rpkist77 11 ай бұрын

Couple of questions/concerns here. So outside of an external state manager, it looks to me like there is virtually no way to avoid re-rendering the entire page on this using standard react hooks. Because on things like the color picker and the clothing size, those state definitions will have to be defined within the parent component because the Add to Cart button needs access to both of those states in order for it to add the correct shirt to the cart. So therefore, every piece of state has to be defined in the parent component and then passed down to the sub-components along with their state setter. So when you run the state setters for the color picker or size, the set state will cascade back up to the parent component and cause it to re-render. This seems like a massive oversight in React to be forced to do this. Am I missing something here? I've personally never used an external state manager but have also never had a ridiculous enough component that I experienced any performance issues with this model.

@jherr 11 ай бұрын

You can use context providers in the layout and only components that consume that specific context will re-render when the context changes. I just used Zustand because it's slightly easier.

@Rpkist77 11 ай бұрын

Ah I think I understand. So in the case you describe, you would pass the value and setValue via useContext to the color picker and shirt size component to let them both modify this context. The add to cart button would also access the value only from the context, which would mean that the page doesn't rerender when the context changes because it is not directly consuming that context anywhere?@@jherr

@jherr 11 ай бұрын

@@Rpkist77 If the add to cart button references a specific piece of context then it will re-render if that context changes, unconditionally. That being said, granular updates like that aren't a bad thing in React. A re-render does NOT mean that the DOM will be updated. React will only update the DOM if the component renders something different than it rendered the previous time. The issue with full page re-renders is that you are creating a TON of VDOM objects unnecessarily with that size of re-render, and that's a perf and memory management hit.

@adityakadam2256 11 ай бұрын

That's a great video. I m personally a big fan of ATOMIC design principles. Even though there are lots of components but helps in design consistency and also in the overall performance of the page.

@AlvarLagerlof 11 ай бұрын

This is a great video! Bunch of concepts covered all at once.

@captainnoyaux 11 ай бұрын

Thanks a lot for the video and code examples ! Like you I like way smaller LOC than most people !

@cslearn3044 11 ай бұрын

Tbh I just come here to like the video, as I have learned so much i don't need it anymore, just showing support

@cbunn81 11 ай бұрын

Are there any tools you'd recommend to get some quantitative performance metrics for React? I'm planning some refactors and it would be nice to have some numbers for before and after.

@kmylodarkstar2253 11 ай бұрын

Amazing analisis and explanation as always mr Jack. Thanks!

@tradfluteman 11 ай бұрын

You have a knack for making videos about things I was just dealing with. 😅

@gregroyclark 11 ай бұрын

23 minute club! Thank you Jack.

@emilianoferreyra8221 11 ай бұрын

Hi Jack, I would like to know what extension you use in chrome to make it look like this, thanks for the content always learn something more with you.

@abhishekpratap05 11 ай бұрын

He is using Arc browser, and for react rendering visualisation he is using react dev tools

@Technology_Forum 11 ай бұрын

how do you highligth a particular line of code or block of code during presentation what settings or command do yo use

@csIn84 11 ай бұрын

Not because I'm being difficult, but does this have similar issues in Solid? Since Solid uses reference points for its signals, as you click-through, shouldn't it reasonably handle these minor changes? This is not me suggesting that someone should build 800+ lines of jsx into a component, but thinking about the functional differences between Solid and React.

@jherr 11 ай бұрын

Yes, Solid removes that element from this issue. I'd argue the second point about still not doing even though you can because of maintainability, but we agre on that.

@danyls_trusting_the_process 11 ай бұрын

Great video. Actually helped a lot optimizing and understanding performance aspect of some of my react code. By the way, what terminal theme or configuration are you using? 😎

@warlockCommitteeMeeting 11 ай бұрын

I really appreciate your content sir. Thank you.

@christophergabba5431 5 ай бұрын

Is there a way to get this state flicker in react native? This would be super helpful!

@Technology_Forum 11 ай бұрын

how are you selecting a particular code line in vscode and all other code is dimmed for presentation of code

@kamill34 11 ай бұрын

Great, huge thanks Jack 😊

@MrJettann 11 ай бұрын

I'm personally, trying to make my components single responsible too and size of my components usually is around 20-50 lines of code. Sometimes it's impossible to make components that small, but 100-120 is the limit for me, if more it become unreadable and really hard to maintain peace of smelly code:)

@manishkumar1213 11 ай бұрын

I really love your zsh theme. Can i know where I Can find it?

@chandrashakharkachawa7874 10 ай бұрын

Nice video please someone can tell me which vs code theme is this one?

@peterruszel5389 11 ай бұрын

I would have liked to see the effects on performance metrics like Core Web Vitals.

@tradfluteman 11 ай бұрын

One thing that generates giant components is pooling all of the logic for every part of the application tree in one place. A component should encapsulate the logic of its identity, to the largest extent possible. So if it can provision resources independently, it should. And if it can have its own handlers defined inside of it, it should. And if it doesn't need a prop API, it shouldn't have one. I try to only take advantage of props when wrapping a component, at the first layer of abstraction. By following these rules you basically turn components into file-like modules, with data treated as runtime dependencies, which is also a big part of the idea behind React Server Components and Suspense boundaries.

@marcpanther8515 11 ай бұрын

The same reasoning for "don't define components inside another components" can be extended to "don't put business logic into functional components". Functional components are basically equivalent to "onPaint" functions which could be hit frequently. I just don't know why the current trend is to put application logic there as well (the introduction of hooks made it so I think). It should just contain UI logic and translate states to jsx, with the occasional controller code to update states. As Mark Erikson of Redux once said, there are 2 camps of people: state centric vs component centric. It's unfortunate that the latter won just because of "lazyness" to separate concerns.

@naresh9643 11 ай бұрын

Thank you. This is amazing.

@Digitalkmusicproduction 11 ай бұрын

This was an amazing video

@yashrawatreact 11 ай бұрын

What theme are you using for your vscode? Looks awesome 🤩

@jherr 11 ай бұрын

Night Wolf [black]

@arfajarsetiaji 11 ай бұрын

How to set the font like yours? The second array parameter of useState's returned value is bold

@jherr 11 ай бұрын

JETBrains Mono

@waleedsharif618 11 ай бұрын

Will you create a video where you talk about React 19 ? It seems to be very interesting

@jherr 11 ай бұрын

It will be! And I definitely will create many videos on 19.

@kalideb-y3y 11 ай бұрын

as a self-thought I never thought that I would put a nested component and just first time seeing this, and I never seen someone done this

@moonbe77 11 ай бұрын

Awesome video!!!

@planesrift 11 ай бұрын

How would you deal with a component when you have to listen a lot of state changing/canvas manipulation events on a single canvas element/window?

@jherr 11 ай бұрын

Well, for a canvas, IMHO, the drawing code, unless it's really simple, should be separate from the component and in its own module.

@inakilarramendi787 11 ай бұрын

is creating multiple stores good in zustand? i believe they say you should only use one store

@jherr 11 ай бұрын

Can you point me to where they say that. I've used multiple stores for a while and never had a problem.

@josem3363 11 ай бұрын

video editing is awesome

@yashsolanki069 11 ай бұрын

We need part two on this utilising useMemo, useCallback and custom hook.

@jherr 11 ай бұрын

Instead of Zustand? Trying to picture when I would use those in this case.

@GurbyTheGreat 11 ай бұрын

Should have used react-hook-form for the form example... But I guess if you are trying to generalize it for all components it makes sense 😊

@jherr 11 ай бұрын

@@GurbyTheGreat I love RHF, I'm not sure I'd use it here. Generally speaking the design of the CTA portion of an e-Commerce site is setup so that you can never get into an invalid state. There aren't usually open text fields, or things you could mess up. It's usually quantity, color, variant, etc. with radio buttons and a 'Add To Cart' button. But if you had open fields then sure RHF.

@erikslorenz 11 ай бұрын

Switching files with control p is much easier than messing around searching in the file. Otherwise I wouldn’t really care. Although I do keep multiple in a file when they are a simple one that I’m rendering in a loop.

@kristemmerman921 11 ай бұрын

Love the way you pronounced Zustand 🥵

@karolbielen2090 11 ай бұрын

For me, 150 lines of code is a really nice size, 200 is the limit of comfort; if a component is longer than 200 lines... it better at least be cool! 😉

@ErickRodrCodes 11 ай бұрын

seeing your subconscious suggesting to take the big pill is hilarious "What could possibly go wrong?"

@noriller 11 ай бұрын

My guideline is to be at max 200 loc. Not only that, if most of it is jsx... then its ok as long as there's no more than ternaries using booleans or something declared above. But... If you have a file where it's 200 loc of only "logic", then you better have a good reason for that.

@maxwebstudio 11 ай бұрын

thanks !

@karolbielen2090 11 ай бұрын

Reconciliation in React is a topic to read to understand this video fully.

@TheGetawayMan 11 ай бұрын

I suppose there's a lot of nuance to the question. I think that context/scope of the problem totally matters. If performance isn't an issue, I don't necessarily think it's a problem. Sure, as a general rule, I'd agree with what most people are saying here in the comments. I could also hear the argument that scope/context doesn't matter. (shrugs)

@radulaski 11 ай бұрын

I'd go even further and suggest that we should try to have our components consists of components of the same level of abstraction.

@arjundureja 11 ай бұрын

Thoughts on wrapping all of the child components in memo?

@jherr 11 ай бұрын

I would not use useMemo as an alternative way to define components. Just make it a component and react forget will handle the memoization later this year.

@arjundureja 11 ай бұрын

@@jherr Sorry I meant using React.memo as an additional optimization to your final solution, not useMemo

@jherr 11 ай бұрын

@@arjundurejaah ok. Sure. If there are perf problems.

@jjhehe5747 11 ай бұрын

The problem in most React apps is when the homepage needs to submit something to the server. You cant easily access the states of the child (broken down components) from the parent (homepage component)

@jherr 11 ай бұрын

Why would the parent component need to know the state of a child component?

@jjhehe5747 11 ай бұрын

@@jherr When for example the homepage has a submit button that needs to send the states of the child (tshirt size, tshirt color) to the server.

@jherr 11 ай бұрын

@@jjhehe5747 Then either have the CTA section as one components (which wouldn't be too large) and then the submit button would have access to that state. Or, actually just use a form element and the form submission flow, because it doesn't care about components or nesting or any of that. Or use context to manage the state. Or use a state manager to manage the state. There are lots of options other than a mega component or doing the horrible component definition inside of other components thing.

@jjhehe5747 11 ай бұрын

@@jherr yeah I agree using state manager would be useful. I now remeber the term for the problem I was discussing which is lifting the state up to the parent

@singh.aadarsh 11 ай бұрын

Nice

@7dainis777 11 ай бұрын

800 is nothing 🤣I had to refactor components that had 2000 lines with lot's of JSX, conditional logic and other business logic. Ended up with multiple smaller components (max 150 lines) and eliminated unnecessary re-renders and prop drilling. My absolute limit for the component would be no more than 250 lines.

@skapator 11 ай бұрын

There is the other side of the pendulum. 1000 components for one page.

@ModernProjectManager 11 ай бұрын

The Application Shell is the biggest component.

@justenjoy875 11 ай бұрын

what browser do you use..?

@jherr 11 ай бұрын

Currently using Arc, but reconsidering that.

@MF-hx8or 11 ай бұрын

These problems do not exist in solid js and naturally there is no need to make small components 🎉

@jherr 11 ай бұрын

Well, except the need for maintainability.

@hardwired66 11 ай бұрын

more pls :(

@genechristiansomoza4931 11 ай бұрын

Majority of devs are lazy to create new files to isolate parts of code and refactor. It's easier to simply add a function.

@booi_mangang 11 ай бұрын

The codes in my company is 2000 lines. I was refactoring it, and they called me a madman

@prerit714 11 ай бұрын

A while ago I pushed a 2000 line React Component. Is that normal guys? Am I normal guys?

@LarsRyeJeppesen 11 ай бұрын

Insert any framework.

@dave6012 8 ай бұрын

I mean, I’d rather not

@AqibRime 11 ай бұрын

use signals. Problem solved

@jherr 11 ай бұрын

That's an interesting point. Would I use the same component factoring in Solid? Svelte 5? Or Qwik? Probably, because I'm also a single responsibility principle guy. But the equation would definitely not include performance as much of an issue.