👉 Practical Module Federation Book: module-federation.myshopify.c...
👉 No BS TS (The Book): no-bs-ts.myshopify.com/
👉 I'm a host on the React Round-Up podcast: devchat.tv/podcasts/react-rou...
👉 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 JETBrains Mono
0:00 Introduction
0:24 Mistake 1: Invoking Component Functions Directly
3:25 Let's Make It Blow Up
5:17 Fixing The Mistake
6:08 How JSX is Compiled?
7:27 So What Is CreateElement?
8:50 Mistake 2: Component Within Components
11:47 Mistake 3 : Locally Invoked Component Functions
13:34 Outroduction
#reactjs
so far this is by far your best video of the year
I am amazed I know that concept but don't know in so much depth that this can completely kill my app. omg I read about the same in kent c Dodds's blogs but did not know that this error can be undebuggable In large apps
Honestly
I have definitely seen all 3 of these mistakes at my old job, no body seemed to know it's wrong when I told them they treated me like I was wrong so thank you for this video now I can share it with them.
and they will see your comment
another issue with nested components is that the inner component lose its state when outer component re-renders because each time it's a new reference so React treats it as a new component. So it unmounts old instance and mounts the new instance.
I can relate to mistake #1 and #2, but I never thought about #3.
This is an awesome video. I've worked in a codebase with a bunch of this "Component()" instead of "". I've always avoided to do it and thought it was a bit off, but never knew why, so I've never changed it nor talked to the person who wrote it. Now I have the technical base to do it. Thanks
These videos are so good. Not clickbait. Legitimate issues we all see all the time / have made ourselves. Great in depth concise explanations, with real world examples not some contrived scenario that never happens. Amazing as always.
I've seen some of these mistakes in some codebases I've worked on. Git blame showed that it typically is a backend engineer dabbling in the FE and bringing along patterns they are used to. Great video and happy new year!
Yes! I not only made those mistakes during my React learning curve but also now that I am a bit mature my eyes have opened and I am able to identify those mistakes during code reviews. I love your videos Mr. Herrington, very educational content.
You deserve a sub after this video. It’s explained so well and isn’t over explained. It’s the perfect medium.
Your videos are pure gold Jack Herrington Sir , please keep going. If possible just write a book on React and Typescipt. You are the kind of teacher whole react community needs. simple and straight to point without jargons and over bombardment of information. Thank's onnce again !!! may god bless you
Always with the high quality contents you are like my own senior-dev at my job Thank you
Just watched your video on Brad's channel. You are the best example of "doing something so profesionally that you won't need marketing". I was astonished by your level of knowledge and the way you laid everything out for the viewers. As a medior react dev i still cannot believe i haven't found your channel earler. Keep making quality content which is unfortunately very rare nowadays.
Another great video Jack! Thanks for diving into advanced topics that no one else cares to talk about.
I'm in love with you. Your explanation is so easy to understand. Congrats and thanks for this awesome video!
Love the new effects! Another great video. Thank you Jack
I've met a lot of YT videos like that, but none of them contained a valuable advice for React devs. This one is different from the others. Thank You!
The depth of knowledge and attention to detail here is excellent. Well done!
You're the best, Jack! In terms of defining components within other component's module and/or function body - I saw it quite a few times but never got onto doing the same myself. Like you said, it bloats the component, makes it less performant (unless we use useCallback) and we're unable to reuse it/test it. I always stick to having these tiny functions as their own files even. I guess I started doing it way back in the beginning as it helped me understand React better.
Happy new year big man!
Thank you for making this video. It's one of those things in React development that I'm always finding myself un-teaching people. Now, I can just point them to this video!
I literally got the "Rendered more hooks than previous render" for the first time ever at work today doing something slightly different. Took me some googling to figure it out. I was rendering a component by invoking it as a function and any presence of a useState hook within the component spawned the error and took down my app. Jack made this video today because he was reading my mind, haha. I also for the life of me cannot work out why anyone would do mistake 3. I'd really love to know where they learned that from. Great video Jack, very timely!
Hi Jack, your videos are such a great resource! One thing I've been struggling with is hooks using other hooks data as arguments. I don't know what the best practice is for dealing with hooks return values possibly being undefined.
Luckily haven't done or come across these myself, but glad to see you spread awareness since it seems like some are taught this
Love how you explain everything so clearly
Amazing content as always. Ive made #1 and now not only I know it is wrong but most important I know WHY it is wrong, which is what I love about this channel. Thanks my friend.
Solid tips, Jack!
I didn't knwo component nesting was that bad. Thanks for this awesome video. Please keep posting videos like this
There are some mistakes that we know should be avoided no matter what but we don't really know why. This kind of videos with your gorgeous explanation let us go deeper and understand those mistakes. You're the G.O.A.T Jack!
obviously
Just want to tell you that your videos are 💯! Way to go!!
love you Jack and Happy new year
Woah the third mistake is thoroughly complicated by itself. Thanks for sharing these previous mistakes as well , I'm a newbie into the world of web development and It's much appreciated to share this sort of material. Thanks and greetings from ARG :)
Hi Jack! Your videos are pure gold. The best KZhead channel ever! I wish you to hit 1 million subscribers this year!
The fact that 3 works is really cool tbh
You give the best React content on KZhead, thanks :)
There we go .... here's Jack with another gr8 content! Thank you Sir! 🙂
I've seen mistake #2 happen because certain libraries make it almost impossible not to . They have a property on _their_ component that takes a component and the spec is that the component needs to change with the component state (for example, the label might be coming from a database). So in order to provide the component for the render prop for use by the library, people put the component definition inline. I think much of the time they're not even aware that is what they did, but even when you are aware, it can be a bit difficult to figure out how else to accomplish the goal.
Good to see you again 🎉
Great to be back. The holidays were cool. But rollin' videos feels real good.
I see this first issue so often (even in react docs examples) and it I really appreciate you calling it out!
I think it comes from porting from big class components.
Thank you so much for you explanation. Btw, how can you get suggested code like at 1:42?
This is gold, I never used this pattern but good to know :)
Thanks Jack. Great stuff, really appreciate it.
Incredible video ! Explained very nicely!
I feel that for mistake #3 a lot of people continually are told to isolate anything that might be reused (heading components aren’t too uncommon) but they try doing this over-optimization stuff out the gate instead of first working towards the presentation they want, then breaking down reusable parts
I can relate to misstake where I create create functions within the function. I guess I got in to that pattern because I wanted to make the code easy to follow in the return Statement,but at the same time not create to many small files. Thanks for the video. Will definitely take this new knowledge with me.
i saw the first and second one in a tutorial on youtube building a react native app.. Use them until i ran into a bug some months back and unlearned them. Thank you for sharing this so others could see
Thanks. So simple and effective
Hey Jack, 1 place I did nest 1 component declaration inside another component was because my inner component was dependent directly to parent's prop, and I used useMemo to memoize the result so I don't hit performance problems. And the other reason was because the inner component was not used by itself anywhere so I did declare it inside my parent component.
Nice sone! Curious, what do you recommend to prevent people from doing this? Linter?
Jack. I can't thank you enough for this. It's seriously useful!
Thank you Jack for this awesome knowledge !!!
very cool and detailed explanation 💯
This video is really helpful. Thanks for posting.Could u post a video for react redux hooks into webcomponent?
Hi Jack. Im following you for a while now. Thanks a lot for all those awesome tipps. Im a principal web dev here in germany and I really have to stress the point that every react developer should drasticly reduce "logic" inside components in general. I highly recommand to "do nothing inside jsx"". Always go for jsx-compositons at last (codewise inside your Component definition). Just reference variable inside jsx. Even your eventHandlerFactories etc.. Just wast another well-named const to expain what going on, drop it inside jsx and get around most of the footshots. Cheers!
Thanks for sharing Jack! I hope I don't see people making this third mistake. It seems strange to create a self-executing function just for fun like this. Keep up the good work!
Gold content as always ♥...I had a discussion about this 1st mistake with one of my co-workers and a couple of days later, this video pops up in my feed..! One question I have though, in the 2nd mistake did you mean that EmailField should be exported to another file? because even though it was an isolated component it doesn't matter since App.jsx only exports App component, is that right?
If you want to be able to test EmailField in isolation then you can break it out into a different module, or export it as an additional named export from App. Your call. Just don't define EmailField inside the component. Thankfully this anti-pattern is now specifically called out in the new React docs.
I've never made those mistakes because at some point, someone told me to never make nested components and always use JSX as good practices. But now I know why I'm doing it this way. Pretty interesting video, keep up the good good stuff Mr. Harrington :)
Which console you are using on vs code to display data ??
Good one Jack! Keep it up.
Great video as always. Super helpful
I did the first thing literally today. So thanks Jack and thanks KZhead algorithm. Great timing.
Good video. Can you do one in the future with more advanced examples of patterns that are good or bad?
very clear explanation great video
Awesome video as usual Jack. What are your thoughts on using component functions if you don't need state and just need need to render some markup? I admit I've done this a few times thinking that it looked clean and readable, wasn't aware that it was a faux-pas until now.
I think it's setting yourself up for an issue down the road because other devs might look at that component and say, "Oh, it's a component, lemme add some hooks..." And then ... potentially ... boom.
I'm guilty of doing the first 2 mistakes. This video was really helpful!
Best React teacher, right now! And for long 🥰
Amazingly helpfull. Thanks.
I learned so much from this video, i usually make all the three.
I first learned React using class components, and (referring to mistake 3) is the idea of having render functions defined in the class, and calling them inside the main return(JSX). It took me a minute to get over this tendency once functional components became standard, and I'd never do that now.
great explanations! thank you a lot!
I’d say for the mistake #2 where is placed inside App.tsx, not within but together with , is quite reasonable to encapsulate re-render. Probably much proper example would be instead of that is used somewhere under the component tree. Then inside there’s an effect that subscribes to input changes that’ll only re-render instead of the whole One might say that it’d be better to create another file, but sometimes it’s quicker to just write at the same file. It can be refactored later.
so how would you call components dynamically? for example if the strucutre of my app depends on some json i get from an api?
I've seen the 3rd one in many code base but I could never argue on why its wrong but now I can!
This was insightful! I have to admit that I've used the "locally invoked component functions" technique before mainly to get around the fact that a JavaScript switch statement is.. a statement. In languages like Elm and ReScript, the if/else and switch statements (and much more) are expressions. Knowing what I know now, I'll create a separate component and invoke it via normal JSX. As a side note, I use switch statements heavily because, in TypeScript, I make heavy use of discriminated unions and then switch on that shared field.
You could also just use an object as a map between values and components (not elements) e.g. const componentVariant = { variantA: VariantAComponent, variantB: VariantBComponent, } as const; then simply reference it like `const ComponentVariant = componentVariant[someVariant] ?? FallbackComponent` and call it like JSX . The fallback could be a simple ternary as well. I find this more readable, less error prone and if you use TypeScript, you can easily create types through inference from it as well: type ComponentVariant = keyof typeof componentVariant;
I need to see all of your videos! Didnt make any of these mistakes though, but you explain well. Can you also make some advanced videos? Can you explain how to make a config file ? (do you use useContext?, do you just make a file? ) How do you manage your code? What is a “correct “ directory pattern? etc..😊
Have a look around, I think you'll find a lot of what you are looking for.
One thing that I notice is zustand deprecated zustand/context in the latest version, so, is there a way to integrate zustand with react/context to isolate the same model state in a different component instances?
need more of this stuff!!! :)
12:40 i replayed like 100x haha, thanks Jack!
Happy new years Jack. Looks like you got your ears lowerd (my grandfather way of saying haircut)
Very good one here tyvm
This is what I was looking for. My senior is using function invoking & I don't know why. But I was pretty sure using JSX is the best way to declare components.
Regarding mistake number 2. I do something similar to it but I am not sure if it´s falls exactly under the same umbrella (Looking forward to hear your opinion about it). But before I share the example I will tell you the "Why" we actually do this. We only do this in the Top level components (Like the root page component HomePage, EditPage, ..etc) Where in order to construct the page you have to add a lot of inputs, buttons, cards, and layout components grouped in some way or another (based on location within the page or visual hierarchy). These groups doesn´t seem to be a good use case to make a react component as they are not gonna be used outside of this page by any means. The resulting JSX of the page component will become so big in some Pages (usually the ones with many visual sections) where it is really hard to navigate through during code development or through code reviews. So What we opted for instead is the following. Instead of having the root page component rendered in this way: function MyProfileEditPage() { const state = useMyProfileEditPageViewModel() return .... Some other components needed to render the content of the homepage .... Which is gonna make this component JSX is too huge (400 - 500 lines and in some cases even bigger) } We do this instead: function MyProfileEditPage() { const state = useMyProfileEditPageViewModel() return {renderTopAppBar()} {renderBasicProfileCard()} {renderAdvancedProfileCard()} function renderTopAppBar(){ return } function renderBasicProfileCard(){ return ... some markup } function renderAdvancedProfileCard(){ return ... some markup } } What we are trying to achieve with this approach is the following. 1- Way better code reviews: The PR reader can see the top level overview of the page (How it´s structured in the exact order) and choose to navigate exactly to the section in the page where he is more interested in reviewing (using the function names renderXXX()) 2- Way easier code navigation within development: If there is a change that has to be done in a certain part in the page you can immediately tell where to go in the markup. In the example above if we happened to make changes in the Advanced Profile form and add a new inputs you can immediately navigate to it with the help of the names of these functions. 3- No more prop drilling and extra boilerplate: In the example component there is a state object. If we happened to extract these "locally defined" functions outside of the Page component and make them a React component (In the same file without exporting them because that´s the main motive which caused this code design "pattern/issue" to exist) we would either pass down the state object as-is (aka the lazy approach but less boilerplate) or pass only the properties used in these small sections of the page causing us to write the props interfaces for each one of them (A lot of boilerplate). While On the other hand. In the "locally defined stateless" functions. We get rid completely of this problem because the state object is accessible and causes no issues. 4- Finally and most importantly. Encapsulation of these (Group Components) which happened to exist only for the purpose which is constructing the different sections in a certain page. I hope in my comment that I addressed the "Why" behind this approach. But What I am honestly looking forward to hear from you is your opinion about it and what is the proposed alternatives (taking in mind the 4 points that we were trying to achieve).
I've always done this as a set of components, so there would be a TopBar, BasicProfileCard, AdvancedProfileCard, etc. components, in the same file, but maybe not exported, or exported only in dev mode for unit tests. Addressing your points: #1, not sure that really has an impact on code reviews per se. #2, components are also functions, so if navigating to functions is easy, then it's just as easy with broken out components. #3, sure there is no prop drilling, but that also means that you have one mega component that manages all the state and everything re-renders even when it doesn't need to. #4, to me components are just as good of an encapsulation. Lemme offer some downsides. First, renderAdvancedProfileCard is a function not a component function, so it can't have its own state. Second, this single function is going to get absolutely massive over time and all of the hooks will have to be at the top, it'll read like Fortran. Third, dev tooling goes out the window with this. All of the awesome work put into props, and context, memoization, minimizing re-renders, etc. is thrown out with this renderNNN() approach. Yeah, I just don't see this approach as making the best use of the framework, IMHO. It feels like you are fighting against how the framework was intended to be used. I've certainly seen render functions in the past in small doses, but I wouldn't architect around their use.
Thanks for honestly reflecting your thoughts on this approach. I will share your feedback with my team and see how we can improve from there.
IMO, both creating new components and creating functions to decompose a big return statement are legit usecases. We use both for techniques for different reasons. I do not think any of them is wrong. Of course if things get massive, then we break down components and even create new files for them (I find this cleaner). When we need to give them their own state, again, new component is the way to go. If we want our dev-tools to treat those "fragments" as a new components, again, a new component is a way to go. Still, when our only goal is to break down a return statement into a more readable format, and not impact or complicate anything else, then function decomposing is a perfectly fine technique IMO.
@@alkismavridis1 You do you, but IMO, the intention of React is to encourage small components that are easily reused and composed into larger structures. More or less following Brad Frost's atomic model of composition. The less that you use components the less you are using the framework, and at a certain point you would be better served by a templating library because you won't be getting enough value from the 142Kb of React lib that you are dropping on the page.
Great as usual 👍👍
Thanks! Your videos are so valuable
Thank you so much!
Awesome video!
I think I saw nested definitions of components somewhere in the Material UI documentation.
Thanks again for this channel, I did learn a lot form your videos. I have a question, concerning the first mistake. In reality I found myself invoking a component as a function but in this case because I found myself calling a switch statement to define the icon to display. In fact, the main component receives the type of info as prop (INFO, WARNING or ERROR) and inside, there is function that returns an icon component according to a switch based on this type.
That's fine, that's not a "component", that's a helper function that returns a React.createElement result. As long as your helper function doesn't use hooks, or act like a component, it's fine.
@@jherr Thanks for your answer.
HI Sir l here is a senior guy who actually told us that this a good way to define components inside host components now i send you video to him
Cool, please send any articles he has posted to me in a comment. :)
Would love to see a video with nextjs13 and how to deal between server and client components when sometimes you need states after fetch fro exemple. Thanks really nice video, very helpful
Thanks for the great video. I will check my code in regard of the second mistake. By the way. What is special with the browser you used. Its was ARC ?
Yep, Arc.
Good afternoon, please tell me the name of the plugin that shows errors directly in the code?
On the topic of mistakes/components, I'm curious as to your thoughts on dot notation in relation to scoping components (i.e. ``)? It seems popular in UI frameworks like AntD and seems like a useful way to "scope" components while still leaving them testable. Typing them is admittedly a bit awkward however and I'm not sure that they should really be preferred over an agreed upon scoping convention.
I like them a lot actually.
great explan, thanks. I've seen a lot of assigning jsx to a variable inside the component. (like `const collapseButton = < .... >`) then `return < ... > {collapseButton} < ... />` from the parent component. How should we look at this? I'm pretty sure it's an anti-pattern, but is it a real problem?
No, that's fine.
Thanks for sharing this! I had no idea about 1. I often use that paradigm if I need to render a component conditionally. So I'll make a resolveComponent() function in which I am doing something to the effect of if() {return ...} else {return ...}. What is the best practicy way of handling these conditionals?
Ternaries are the easiest way to do that.
@@jherr I guess but then the code gets yucky with X ? Y : (Z ? A : B). :D
@@doritoflake9375 Sure, but you can use a simple sub-component for that. Or just drop the logic at the start of the component and set a local variable with the component to either render, or the component rendered with createElement (through JSX). Or as the result of a memo, or ... lots of options.
@@jherr I do the same thing can you do a small video about how can we handle that senario without doing messy code with lots of ternary
Hi, I usually do the second "mistake" only when components need to be created with forwarding Refs (often necessary when using Material UI embedded together with your own components or other librairies). It seems to me more obvious and easier to maintain when the "forwarded ref component" is defined in the same package as the "base" component used in the forwarded one. Especially in typescript when you need to define the good types or interfaces for both "base" and "forwarded ref" components. (Sorry if my english not that clear ;-) )
No need to apologize for your English skills mate, your English is good and perfectly understandable. 😉
@@Stoney_Eagle thks
Yes maybe I am not understanding the docs, but MUI and Bootstrap do #2 in their examples/components often
@@michaelyabut5969 This. I think the biggest source of mistake #2 are the examples given by library creators - which mostly show "simple" usages. Combined with no or minimal knowledge in using React produces this "mistake". I've also encapsulated "private" components within the components myself at the beginning of my React learning path up until I fully understood how the "export" keyword is used and that I do not need to have one file per component (over-engineering).
great video Jack! On the second point about nested components since you've only exported App, so even with this approach you can't unit test EmailField. But if you export it then it no longer remains private. So we need additional tooling if we want both things. Curious if you use any particular thing for this.
If you need it to unit test it then have it conditionally exported in dev or test node_env
@@jherr wait can we do that, I knew about conditional imports but not exports. But I don't think it'll work in ES Module syntax, may work in cjs. Am I wrong?
@@dev__adi You can conditionally attach them to the primary component export.
You just saved me from the first mistake. Thank you
So the third thing… I feel like it’s pretty common to map over something, with an anonymous closure for each element. Now, if that nested component gets complicated or particularly as as soon as it needs to deal with some internal state, then it seems necessary to factor it out, but how bad is it really otherwise? It seems like a first pass of getting the scaffolding together might often involve that, and there are probably cases where it’s unnecessary to change.
Thanks. I have function that format date using days.js. Should I call it in component like JSX or function?
That’s fine. That’s just a helper function.
So I've seen something similar to #3 arise organically in a team transitioning from a C# website builder to React. The website builder had a primitive jsx like Syntax and we did use functions returning html tags as pseudo components to make code more readable and encapsulated. Which turned into a legacy antipattern of using functions to bundle jsx instead of designing proper components. I would never think of inlining that and dropping the names cause that defeats all the organizational benefits, but I can imagine a weird legacy/cargo cult/smart coder combination where someone learnt this antipattern from a coworker, tried to smartly improve it by shortening and inlining it, and then passed that mutated antipattern on to others.
I think its a bastardized render prop pattern misapplied.
13:25 - I've only used this with React Navigation. You can use it to add or modify props to the child component conditionally. Usually props passed are from React Navigation screen, because they instance components by string name as a prop "component='SomeComponent'" instationation... {(props) => { return ( ); }} In this case the wrapper needs navigation, before rendering the child.