Are Your React Components Too BIG?
Вставка
- Опубліковано 8 чер 2024
- 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 - Наука та технологія
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.
7:15 as a German, I can assure you, this pronounciation was EXCELLENT =)
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 !
Thanks Jack, first time I see a practical use case for the react extension. Awesome vid!
Haha the classic horror film aesthetic of the thumbnail is 👌
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.
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!
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.
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.
The same but using formik
great video, I'm gonna change the way I do components and have an extra eye on rendering when testing my applications
This is a great video! Bunch of concepts covered all at once.
Thanks a lot for the video and code examples ! Like you I like way smaller LOC than most people !
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.
Introduction is awesome 🔥
Amazing analisis and explanation as always mr Jack. Thanks!
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? 😎
Tbh I just come here to like the video, as I have learned so much i don't need it anymore, just showing support
I really appreciate your content sir. Thank you.
You have a knack for making videos about things I was just dealing with. 😅
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.
23 minute club! Thank you Jack.
Great, huge thanks Jack 😊
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 👍🏽
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:)
Thank you. This is amazing.
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.
Awesome video!!!
This was an amazing video
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
video editing is awesome
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.
He is using Arc browser, and for react rendering visualisation he is using react dev tools
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?
Yeah, we are trying to avoid "barrel imports" nowadays.
seeing your subconscious suggesting to take the big pill is hilarious "What could possibly go wrong?"
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.
I really love your zsh theme. Can i know where I Can find it?
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.
Love the way you pronounced Zustand 🥵
I would have liked to see the effects on performance metrics like Core Web Vitals.
thanks !
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.
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.
Will you create a video where you talk about React 19 ? It seems to be very interesting
It will be! And I definitely will create many videos on 19.
Nice video
please someone can tell me which vs code theme is this one?
how do you highligth a particular line of code or block of code during presentation what settings or command do yo use
What theme are you using for your vscode? Looks awesome 🤩
Night Wolf [black]
We need part two on this utilising useMemo, useCallback and custom hook.
Instead of Zustand? Trying to picture when I would use those in this case.
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 😊
@@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.
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.
I'd go even further and suggest that we should try to have our components consists of components of the same level of abstraction.
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! 😉
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.
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.
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
@@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.
Reconciliation in React is a topic to read to understand this video fully.
how are you selecting a particular code line in vscode and all other code is dimmed for presentation of code
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?
Well, for a canvas, IMHO, the drawing code, unless it's really simple, should be separate from the component and in its own module.
How to set the font like yours? The second array parameter of useState's returned value is bold
JETBrains Mono
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.
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.
Nice
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.
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)
is creating multiple stores good in zustand? i believe they say you should only use one store
Can you point me to where they say that. I've used multiple stores for a while and never had a problem.
There is the other side of the pendulum. 1000 components for one page.
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)
Why would the parent component need to know the state of a child component?
@@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.
@@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.
@@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
more pls :(
The Application Shell is the biggest component.
Thoughts on wrapping all of the child components in memo?
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.
@@jherr Sorry I meant using React.memo as an additional optimization to your final solution, not useMemo
@@arjundurejaah ok. Sure. If there are perf problems.
my 100 lines are from the imports only xD
The codes in my company is 2000 lines. I was refactoring it, and they called me a madman
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.
what browser do you use..?
Currently using Arc, but reconsidering that.
ZHUSTOND
Majority of devs are lazy to create new files to isolate parts of code and refactor. It's easier to simply add a function.
A while ago I pushed a 2000 line React Component. Is that normal guys? Am I normal guys?
Insert any framework.
I mean, I’d rather not
These problems do not exist in solid js and naturally there is no need to make small components 🎉
Well, except the need for maintainability.
use signals. Problem solved
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.
Lmao what these bots doing in a coding channel
They are everywhere :D
i guess its the 'Too BIG' text in the title :p
They hit every one of my videos now. Just two posts each time though... I'm glad your having fun with 'em.
@@jherr they makin' me act up fr fr, jk lol
do not show this video to elm-lang developers : D
Are there Elm lang developers left? :O
@@jherr good question : D
Lately the tutorials you upload are for absolute noobs. I am wondering if it makes sense to be subscribed since I know all of this.
Last weeks module federation video was for noobs?
@@jherr That one I missed, I see
Wow you are so smart, Here is a medal . I want to be like you when i grow up
@@abel090713 You're welcome.