Are Your React Components Too BIG?

Рет қаралды 22,386

Күн бұрын

How big is too big for a single React component? Should you nest component definitions inside of other components? Are there performance issues with huge components? Let's find out!
Code: github.com/jherr/gigantic-com...
👉 Upcoming NextJS course: pronextjs.dev
👉 Don't forget to subscribe to this channel for more updates: bit.ly/2E7drfJ
👉 Discord server signup: / discord
👉 VS Code theme and font? Night Wolf [black] and Operator Mono
👉 Terminal Theme and font? oh-my-posh with powerlevel10k_rainbow and SpaceMono NF
0:00 Introduction
1:31 Why Mega Components Are Slow?
3:49 How Not To Fix It? (Nesting Components)
6:41 Using A State Manager For Shared State
8:12 More Components Hurt Performance?
10:53 A Production Worthy Example
11:50 Outroduction

Пікірлер: 114

3 ай бұрын

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 3 ай бұрын

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

@yassinesafraoui 3 ай бұрын

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 3 ай бұрын

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!

@cb73 3 ай бұрын

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 3 ай бұрын

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 2 ай бұрын

The same but using formik

@brandonetter 3 ай бұрын

Haha the classic horror film aesthetic of the thumbnail is 👌

@tonyjaradev 2 ай бұрын

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

@developersteve1658 3 ай бұрын

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.

@thiagomoraes791 3 ай бұрын

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

@IanJamieson 3 ай бұрын

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.

@AlvarLagerlof 3 ай бұрын

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

@captainnoyaux 3 ай бұрын

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

@yogeshvanzara5553 3 ай бұрын

Introduction is awesome 🔥

@scriptedpixelsltd 3 ай бұрын

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 👍🏽

@kmylodarkstar2253 3 ай бұрын

Amazing analisis and explanation as always mr Jack. Thanks!

@tradfluteman 3 ай бұрын

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

@pjholmes2 3 ай бұрын

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.

@MrJettann 3 ай бұрын

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

@kamill34 3 ай бұрын

Great, huge thanks Jack 😊

@adityakadam2256 3 ай бұрын

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.

@cslearn3044 3 ай бұрын

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

@gregroyclark 3 ай бұрын

23 minute club! Thank you Jack.

@warlockCommitteeMeeting 2 ай бұрын

I really appreciate your content sir. Thank you.

@marcpanther8515 3 ай бұрын

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 3 ай бұрын

Thank you. This is amazing.

@danyls_trusting_the_process 2 ай бұрын

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? 😎

@moonbe77 3 ай бұрын

Awesome video!!!

@jonahtillman9608 3 ай бұрын

This was an amazing video

@josem3363 3 ай бұрын

video editing is awesome

@emilianoferreyra8221 3 ай бұрын

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.

@abhishekpratap8784 3 ай бұрын

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

@CathalMacDonnacha Күн бұрын

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 Күн бұрын

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

@cbunn81 3 ай бұрын

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.

@tradfluteman 3 ай бұрын

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.

@karolbielen2090 3 ай бұрын

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! 😉

@maxwebstudio 3 ай бұрын

thanks !

@Technology_Forum 2 ай бұрын

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

@yashrawatreact 3 ай бұрын

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

@jherr 3 ай бұрын

Night Wolf [black]

@Rpkist77 3 ай бұрын

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 3 ай бұрын

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 3 ай бұрын

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 3 ай бұрын

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

@noriller 3 ай бұрын

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.

@manishkumar1213 3 ай бұрын

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

@ErickRodrCodes 3 ай бұрын

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

@user-dd7kw3ym5i 3 ай бұрын

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

@planesrift 3 ай бұрын

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 3 ай бұрын

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

@scottpageusmc 3 ай бұрын

I migrated a large React JS app using class components to TS functional components, with most component files being at least 4000 lines long. A huge mess. Finally got it to pmpm with nx using workspaces and broke the components up to no more than 100 lines grouped into folders as needed. It started with every component, regardless of use case and will over 300 of them, in the root of the components folder.

@TheGetawayMan 3 ай бұрын

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)

@arfajarsetiaji 3 ай бұрын

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

@jherr 3 ай бұрын

JETBrains Mono

@yashsolanki069 3 ай бұрын

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

@jherr 3 ай бұрын

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

@GurbyTheGreat 3 ай бұрын

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 3 ай бұрын

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

@chandrashakharkachawa7874 Ай бұрын

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

@csIn84 3 ай бұрын

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 3 ай бұрын

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.

@kristemmerman921 3 ай бұрын

Love the way you pronounced Zustand 🥵

@erikslorenz 3 ай бұрын

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.

@peterruszel5389 2 ай бұрын

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

@waleedsharif618 3 ай бұрын

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

@jherr 3 ай бұрын

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

@Technology_Forum 2 ай бұрын

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

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

Nice

@radulaski 3 ай бұрын

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

@inakilarramendi787 3 ай бұрын

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

@jherr 3 ай бұрын

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

@karolbielen2090 3 ай бұрын

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

@skapator 3 ай бұрын

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

@arjundureja 3 ай бұрын

Thoughts on wrapping all of the child components in memo?

@jherr 3 ай бұрын

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 3 ай бұрын

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

@jherr 3 ай бұрын

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

@hardwired89 3 ай бұрын

more pls :(

@7dainis777 3 ай бұрын

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.

@jjhehe5747 2 ай бұрын

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 2 ай бұрын

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

@jjhehe5747 2 ай бұрын

@@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 2 ай бұрын

@@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 2 ай бұрын

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

@solution001 3 ай бұрын

The Application Shell is the biggest component.

@xxXAsuraXxx 3 ай бұрын

my 100 lines are from the imports only xD

@booi_mangang 3 ай бұрын

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

@genechristiansomoza4931 3 ай бұрын

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

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

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

@jherr 3 ай бұрын

Well, except the need for maintainability.

@justenjoy875 3 ай бұрын

what browser do you use..?

@jherr 3 ай бұрын

Currently using Arc, but reconsidering that.

@richardantao3249 3 ай бұрын

ZHUSTOND

@LarsRyeJeppesen 3 ай бұрын

Insert any framework.

@dave6012 2 күн бұрын

I mean, I’d rather not

@user-ty6oz3gv8z 3 ай бұрын

use signals. Problem solved

@jherr 3 ай бұрын

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.