I've been doing this professionally for years and years and I'm here for interview prep. These are all concepts I know well, but I too get debilitatingly nervous. Or sometimes the questions are phrased in a strange way and you can't understand what they're driving at. You're not alone, it's just a broken system.
Based on my experience I recommend using other patterns: 1) Higher Order Component: I prefer using hooks to share logic. More readable and easy to understand and use. 2) render props: I rather recommend using compound components with a context to share state. Also more readable.
Also when using Tailwind it’s easier to apply the style you need with compound components. A dropdown component for instance you would need to create a million props like dropdownClass, dropIconClass and so on… I even use custom hooks to extract logic sometimes, even if it’s used by a single component, mainly for readability
Great Video Peter! I would like to add on the custom hook part. A custom hook might not be the best solution if we want reusability without redundancy, meaning, the components sharing the hook, will create their own copies of the attributes/functions imported form the hook. This is fine unless we expect it otherwise, but generally you would want to go with a context if you want SST for all the components, sharing the values simultaneously. Also, "use", apart from being just a convention, helps react to identify the called function is a hook, to apply all the security checks (like whether a hook is called inside a functional component or not) on it, automatically. This is mentioned in the docs.
It's funny. This is classified as hard and I definitely agree these are more advanced concepts of react, but I could easily articulate these in an interview. So that puts me as a more advanced or senior react dev? The reason I mention is I just recently went through a technical interview for a "React Developer" position and my questions were like explain the javascript event loop, and where would you access cookies from a server response. Not saying you shouldn't know this, but to me it's just so inconsequential in the real world. The event loop sure, it's good to know for some reasoning and problem solving, but I don't know about other people I just don't commit these topics or specifics to memory. Like that's an easy 1 minute google search and read for a refresh. I guess my point is I think tech interviews are pretty bogus and make no sense. You can be randomly hit by some obscure question about inner workings of libraries that you literally don't need to know about to be successful for the position.
Thanks for this video! I'm teaching myself React and I was worried that I'm super behind. I do have a basic understanding of these concepts so I feel better now knowing that's fine and I don't need a high level of understanding for entry jobs
Dang I haven’t even gotten an entry level job since I’m in graduate school but I’ve been working with react for 3 years by myself and I know this stuff. I think what helped was this textbook I read for react 17. It pretty much explained everything about react to me that I didn’t already know so I would recommend a textbook if you are looking for more info. Preferably an up to date one that’s 18.
Isn't Higher Order Components a redundant practice after the introduction of Hooks. So, HOCs added an additional logic to the existing components. And it is reusable. Doesn't Custom hooks provide the same funcionality??
They cover different use cases. Hooks are for sharing re-useable stateful or side-effect-producing logic, while HOCs are for sharing reusable rendering logic. Take data-fetching as an example - when you fetch data, you may want to render a fallback component while loading, or an error component if the call fails, and only render the final component once a successful response is received. Instead of writing guard clauses that handle these cases in the component you intend to render, you could extract the fetching logic and the loading/error/success rendering logic out into an HOC. You could then wrap every component that fetches data in this HOC, so you no longer need to write error and loading rendering logic in those components. This is just a simple example, but you'll likely encounter other use cases out there in the wild. If you find yourself writing a lot of common rendering logic in different components - it's probably HOC time.
Oh I really like this one. I'm in my second Frontend job now; and still haven't really done enough with JS frameworks to be really comfortable answering questions like these ( though, I"m sure I'd get pretty close ). I was a mess in one interview at the beginning of the year trying to explain state-management. Since all my experience was in a Vanilla JS app 😂. Though I am working in React now to replace a legacy PHP app piece by piece ( not as a SPA since the Front end and Back end are glued together ). I've been doing a little daydreaming about looking for a role where I can sharpen a few tool sets that I'm more interested in: SPA framework, building according to designs, rub shoulders with UX design ( I'd like to develop a UX/UI design skillset 🦄).
@@PeterElbaum Oh yes. It has gotten to be pretty fun imagining React in a way where each component will essentially be it's own mini app that gets rendered to different places through the PHP. It's been a real deviation from everything I've learned about JS frameworks ( and from. most of what is written online ). Probably means I should start a blog. But ⏰.
Awesome video thanks for sharing, I hope you reply after 2 years of uploading this video, For the render prop , i always have this question when i see it, Why dont we use the children prop instead since they have the same outcome
I still don’t understand the render props stuff, or why I’d use it, or how, or what it actually is. Examples i see do this: ( { values, setValue } ) => etc And I just don’t know where these arguments even originate from. Is it the props given to that component at the time it is called/rendered? And what would this pattern be used instead of? I write react apps and have never had such a use case nor seen the need yet.
Yep, I think this is a fair question. It's basically just a way of making your components reusable (just like HOCs). You may not have a real use case for it though. Personally, I'd likely reach for the HOC pattern first.
@@PeterElbaum thanks for your reply. So is it an implicit way of taking props instead of explicitly? I guess I need to google more examples of each but is it like HOCs take components as arguments whereas render props takes them as props?
When you just started with React, use just functional components with hooks, I would understand someone doesn’t know what a HOC is. No reason to think someone is not suitable for the job.
So, hooks in general allow you to use state without writing a class component, which used to be required. In general, I'd say the main difference is that a hook is typically going to be part of/used in a component. Does that make sense?
in addition to what Peter said, I would just add that components are more for display where hooks are more functionality. So like, the `Car` react component might render out a car, while the `useDrive` hook might return to you some information and/or functionality about the car, i.e. the `isDriving, setIsDriving, isBraking, setIsBraking` information. In this way, you could have multiple react components like `Car`, `GolfCart`, `Tank` etc... and internally, these components could call `useDrive` and have access to those getters and setters. It's important to note that, as he states in the video, the state is not shared. so if both Car and Tank components call `useDrive` calling `setIsBraking(true)` on the Tank will *NOT* cause `isBraking` on the Car to be set to true. They are two different states. It simply prevents duplicating code.
Cool video! Would you say a private route react router component that checks something like a Boolean if a user is logged in then redirects them to the correct component or sends them back to the login page (for example) is a HOC?
Definitely. If the component is (for example) from react router then it likely is a HOC under the hood. If you're using withRouter, it's definitely a HOC. Even if not, if you're wrapping the component in question with data from elsewhere (say, in a component called withAuthentication) then I'd also consider that a HOC.
HOC components are bad.. you should write components that are pure and can be moved to another project for example just by copying the component’s folder.. including tests for that component etc. Aand ”two of the components using the same hook don’t share state”? Impressive to mention? 😅 you can use any other hook in your own hook, including global state from Redux etc. so basically you can share state with custom hook.. and that’s one off the main purposes of hook..
Is it good to mix patterns within the same project? I mean, it sounds like you can use Hocs or custom Hooks to solve the same problem in different ways, is that true?
Yes, that's true. Though I'd say HOCs are more for sharing data as props, whereas custom hooks are more for sharing functions (a bit of a oversimplification, but you get the idea).
how is this "advanced"? Its not for absolute beginners, but intermediate or devs with 1-2 years of experience must know this... I was looking for cool non-obvious patterns that are not part of react itself, but rather some that you could use to solve problems while working with complex components. While using Ag grid i saw it exposing an API which you can use in the parent component for example, or an event listener for certain state changes which you can also use outside the grid itself. The patterns you've shown are almost the basics of react. Thank you for sharing, but unfortunately it is not what i was looking for. Otherwise good content.
live coding is so difficult for me because i just get super nervous and forget everything in an instant :')
I've been doing this professionally for years and years and I'm here for interview prep. These are all concepts I know well, but I too get debilitatingly nervous. Or sometimes the questions are phrased in a strange way and you can't understand what they're driving at. You're not alone, it's just a broken system.
You need to practice more then. Live coding is a skill.
just act like each interview is a practice… you will learn from mistakes and getting better and better….
Practice makes perfect. Everyone starts out super nervous. Know it so well you can perform with only 50% attention.
You are not alone. I have passed lot's of mock interviews, but not a single live coding interview.
Based on my experience I recommend using other patterns:
1) Higher Order Component: I prefer using hooks to share logic. More readable and easy to understand and use.
2) render props: I rather recommend using compound components with a context to share state. Also more readable.
Yes, i think it's a "modern way" to do it, specially when the function components came out.
This guy is obviously full of s*** or has been living on the other side of the moon for the past 3 years.
Also when using Tailwind it’s easier to apply the style you need with compound components.
A dropdown component for instance you would need to create a million props like dropdownClass, dropIconClass and so on…
I even use custom hooks to extract logic sometimes, even if it’s used by a single component, mainly for readability
Yeah, those patterns that he is presenting are for Class components, but a lot of companies have legacy code so it's important to know!
Great Video Peter! I would like to add on the custom hook part. A custom hook might not be the best solution if we want reusability without redundancy, meaning, the components sharing the hook, will create their own copies of the attributes/functions imported form the hook. This is fine unless we expect it otherwise, but generally you would want to go with a context if you want SST for all the components, sharing the values simultaneously. Also, "use", apart from being just a convention, helps react to identify the called function is a hook, to apply all the security checks (like whether a hook is called inside a functional component or not) on it, automatically. This is mentioned in the docs.
It's funny. This is classified as hard and I definitely agree these are more advanced concepts of react, but I could easily articulate these in an interview. So that puts me as a more advanced or senior react dev?
The reason I mention is I just recently went through a technical interview for a "React Developer" position and my questions were like explain the javascript event loop, and where would you access cookies from a server response. Not saying you shouldn't know this, but to me it's just so inconsequential in the real world. The event loop sure, it's good to know for some reasoning and problem solving, but I don't know about other people I just don't commit these topics or specifics to memory. Like that's an easy 1 minute google search and read for a refresh.
I guess my point is I think tech interviews are pretty bogus and make no sense. You can be randomly hit by some obscure question about inner workings of libraries that you literally don't need to know about to be successful for the position.
I agree! They are a bit arbitrary. We do our best to prepare but there's certainly a lot outside of our control.
Thanks for this video! I'm teaching myself React and I was worried that I'm super behind. I do have a basic understanding of these concepts so I feel better now knowing that's fine and I don't need a high level of understanding for entry jobs
Dang I haven’t even gotten an entry level job since I’m in graduate school but I’ve been working with react for 3 years by myself and I know this stuff. I think what helped was this textbook I read for react 17. It pretty much explained everything about react to me that I didn’t already know so I would recommend a textbook if you are looking for more info. Preferably an up to date one that’s 18.
Quality Content Peter ! Please do more as it helps the community including me :)
Thank you! More to come :)
Finally HOCs clear explanation, thanks man!
Glad it helped! :)
render props in 2022! really!??
Isn't Higher Order Components a redundant practice after the introduction of Hooks. So, HOCs added an additional logic to the existing components. And it is reusable. Doesn't Custom hooks provide the same funcionality??
Yes. This guy wouldn’t pass most interviews.
They cover different use cases. Hooks are for sharing re-useable stateful or side-effect-producing logic, while HOCs are for sharing reusable rendering logic. Take data-fetching as an example - when you fetch data, you may want to render a fallback component while loading, or an error component if the call fails, and only render the final component once a successful response is received. Instead of writing guard clauses that handle these cases in the component you intend to render, you could extract the fetching logic and the loading/error/success rendering logic out into an HOC. You could then wrap every component that fetches data in this HOC, so you no longer need to write error and loading rendering logic in those components. This is just a simple example, but you'll likely encounter other use cases out there in the wild. If you find yourself writing a lot of common rendering logic in different components - it's probably HOC time.
@@johnblake796good to know
wow your content is so good, keep making them, this video was heplful and this will definetly help me in getting a job :)
Thank you! Your encouragement keeps me going. I hope you get the job! :)
wait, isnt higher order component just an implementation of the decorator pattern ?
Really helpful content Peter! thanks for share!! regards from Argentina!
Glad it was helpful! :)
Thanks for this video, I'm trying to get better at communication and these type of interview videos clue me in on what I should be saying. :)
Glad it was helpful! :)
Thanks for sharing. I love your clear explanation
Glad it was helpful! :)
Oh I really like this one.
I'm in my second Frontend job now; and still haven't really done enough with JS frameworks to be really comfortable answering questions like these ( though, I"m sure I'd get pretty close ). I was a mess in one interview at the beginning of the year trying to explain state-management. Since all my experience was in a Vanilla JS app 😂.
Though I am working in React now to replace a legacy PHP app piece by piece ( not as a SPA since the Front end and Back end are glued together ). I've been doing a little daydreaming about looking for a role where I can sharpen a few tool sets that I'm more interested in: SPA framework, building according to designs, rub shoulders with UX design ( I'd like to develop a UX/UI design skillset 🦄).
Good stuff! Replacing a monolith's FE with a modern framework sounds like good experience. Maybe you can make use of some of these patterns :)
@@PeterElbaum Oh yes. It has gotten to be pretty fun imagining React in a way where each component will essentially be it's own mini app that gets rendered to different places through the PHP. It's been a real deviation from everything I've learned about JS frameworks ( and from. most of what is written online ).
Probably means I should start a blog. But ⏰.
I just hope your portfolio site says you are a Webb developer
@@michaelrooze278 yeah, my cover letters say something like, “I was born to do this” 😉
HOC (Higher Order Components ) - Higher Order Function
A render prop is just an argument that is a function that will be used to make a component configurable from the “outside”.
are your questions about HOC and render props still relevant in 2024?
Awsome content! Thanks for the guide!
Glad it was helpful! :)
lol. I worked with all these pattern. I would totally bomb in an interview because I would have to read up on it again
HOC < Custom hook
Useful video.. Thanks Peter👍
Very welcome! :)
Thanks for your sharing!
My pleasure! :)
Awesome video thanks for sharing,
I hope you reply after 2 years of uploading this video,
For the render prop , i always have this question when i see it,
Why dont we use the children prop instead since they have the same outcome
SUPERB! more please :)
You got it! :)
Thank you
amazing!
Thank you.
You're welcome!
I still don’t understand the render props stuff, or why I’d use it, or how, or what it actually is. Examples i see do this:
( { values, setValue } ) => etc
And I just don’t know where these arguments even originate from. Is it the props given to that component at the time it is called/rendered? And what would this pattern be used instead of? I write react apps and have never had such a use case nor seen the need yet.
Same. It almost feels like an anti-pattern or over-engineering.
Yep, I think this is a fair question. It's basically just a way of making your components reusable (just like HOCs). You may not have a real use case for it though. Personally, I'd likely reach for the HOC pattern first.
@@PeterElbaum thanks for your reply. So is it an implicit way of taking props instead of explicitly? I guess I need to google more examples of each but is it like HOCs take components as arguments whereas render props takes them as props?
@@PeterElbaum I actually started using render props this week- solved some problems nicely, I had forgotten about them. good stuff
@@PeterElbaum What's the difference btwn passing in a function like renderProps vs already constructed components?
When you just started with React, use just functional components with hooks, I would understand someone doesn’t know what a HOC is. No reason to think someone is not suitable for the job.
Agreed. These are definitely more advanced topics.
Do you think frontend Intern-interviews would be asked these types of questions? Or is this for full time developer interviews more so
It's hard to say exactly, but if intern implies little to no prior work experience, then these questions likely wouldn't come up. (If I had to guess.)
can you take online classes if you don't mind
Great video!
just one question, how are custom hooks different from regular react components?
So, hooks in general allow you to use state without writing a class component, which used to be required. In general, I'd say the main difference is that a hook is typically going to be part of/used in a component. Does that make sense?
in addition to what Peter said, I would just add that components are more for display where hooks are more functionality. So like, the `Car` react component might render out a car, while the `useDrive` hook might return to you some information and/or functionality about the car, i.e. the `isDriving, setIsDriving, isBraking, setIsBraking` information. In this way, you could have multiple react components like `Car`, `GolfCart`, `Tank` etc... and internally, these components could call `useDrive` and have access to those getters and setters. It's important to note that, as he states in the video, the state is not shared. so if both Car and Tank components call `useDrive` calling `setIsBraking(true)` on the Tank will *NOT* cause `isBraking` on the Car to be set to true. They are two different states. It simply prevents duplicating code.
Cool video! Would you say a private route react router component that checks something like a Boolean if a user is logged in then redirects them to the correct component or sends them back to the login page (for example) is a HOC?
Definitely. If the component is (for example) from react router then it likely is a HOC under the hood. If you're using withRouter, it's definitely a HOC. Even if not, if you're wrapping the component in question with data from elsewhere (say, in a component called withAuthentication) then I'd also consider that a HOC.
Extremely helpful video, thank you.
Glad it helped! :)
video editing joints are way too close and too fast to follow. please add some breaks. thanks
HOC components are bad.. you should write components that are pure and can be moved to another project for example just by copying the component’s folder.. including tests for that component etc.
Aand ”two of the components using the same hook don’t share state”? Impressive to mention? 😅 you can use any other hook in your own hook, including global state from Redux etc. so basically you can share state with custom hook.. and that’s one off the main purposes of hook..
Can we replace HOC with custom hooks?
Potentially! They could potentially be solving different problems though.
I think render props is not used now is it?
Largely has been replaced by other patterns but it still crops up
Is it good to mix patterns within the same project?
I mean, it sounds like you can use Hocs or custom Hooks to solve the same problem in different ways, is that true?
Yes, that's true. Though I'd say HOCs are more for sharing data as props, whereas custom hooks are more for sharing functions (a bit of a oversimplification, but you get the idea).
Got it. Thank you so much!
What did I react to? There was zero input.
this isn't that hard, if I only could get a interview lol
helllog
how is this "advanced"? Its not for absolute beginners, but intermediate or devs with 1-2 years of experience must know this...
I was looking for cool non-obvious patterns that are not part of react itself, but rather some that you could use to solve problems while working with complex components. While using Ag grid i saw it exposing an API which you can use in the parent component for example, or an event listener for certain state changes which you can also use outside the grid itself. The patterns you've shown are almost the basics of react. Thank you for sharing, but unfortunately it is not what i was looking for. Otherwise good content.