Great video! When you work with react every day for a few years, you slowly realize exactly the things you showed here. It would've been nice to see this 2 years ago :)
I think that when you have prop drilling issues, before reaching for context or redux, it's usually best to consider if you are using the `children` prop effectively. A lot of the time if you aren't using the drilled prop in the intermediate components, they can render `{children}` and that prop can be passed directly from the origin parent to the component that needs it.
@@Bobobratwurscht You have a parent component and a child component. The parent component accepts a bunch of props which are just used to pass (or drill) it to the child component. What you can do instead is to just accept a children prop in the parent component and render it. When you now render the parent component, you pass the child component as the children prop of the parent.
Very important thing with context - any item that consumes that context (i.e., the `const count = useContext(CountContext);` in the example) will ALWAYS rerender when the context value changes, regardless of if that component actually uses that value or not. A very common pitfall is to use Context as a sort of 'big store', where you've got a ton of values in the context that are consumed by components that only need one or two of said values. This means that every time the context component updates, EVERY SINGLE CHILD COMPONENT THAT RELIES ON THAT CONTEXT WILL ALSO RERENDER. It's a huge, huge performance issue in very large apps. Keep context to items that will change extremely rarely - themes, authentication states, etc - and never use them for data that changes somewhat frequently unless you're making a very tiny app that won't see the exponential performance loss of this. If you need something passed down but don't want to go through the whole heavy mess of Redux / MobX / etc, minimalist state management libraries like Recoil, Zustand, and Jotai are very easy, approachable, and lightweight ways to do this the 'right' way.
@@adeleke5140 yes that’s how react does it meanwhile other frameworks only re render what needs to be re rendered when you call the info somewhere and not every spot that your store somehow reaches its a stupid expensive way to make sure your UI is updated
That's why more opinionated frameworks like Vue exist, so you don't have to learn every way you can do stuff. I myself would honestly stick to Svelte for personal projects, it's one of few frameworks that don't actively piss you off on each step. (And yes, React is a lib - as long as you don't slap JSX on top of it)
@@amirhoseinhesami9336 react came first and that was huge advantage.. i would go with vueJS or svelte or even angular for complex Enterprise apps. The non opinionated react is not really my thing
@@lahcencodery vue and svelte in the enterprise world is not a real thing and also the funniest joke ever however the "angular" used to dominate the enterprise world however it is not relevant today because react is dominating the enterprise as well
Man you are a genius. Your channel and then 10 places are empty and then everyone else, it's amazing how original you are with content and just keep going! Big greetings from Serbia! :)
There's an instructor named John Smilga and his 14 hour long react video on yt covered all of these tips and tricks along with so many other things for free. I am glad that people like you guys exist.
I've been doing some stuff you said here without knowing it myself, I'm a self learner and have been following you for code quality improvements. You have once again upped my bar, thank you very much 🙏
@@niklasstahl98 Not really. Most JS developers with a little bit of experience will be familiar with the fundamental types. It's only jarring for the first couple of days using them in a strict manner but after that it becomes natural.
when fetching data, the AbortController (native API) can be used, or a library that abstracts this away or avoids this issue can be used, like react-query
edit: apparently currying is still the correct term, i've just never ever seen it used for general function generation. regarding 9: in the example that _you show_ it's a curried function, but what _you describe_ is just a factory function. curried functions basically let you specify the multiple arguments of a function A in multiple steps where each step or function call returns you a function where that value is "stored" in the closure and you can specify the next argument with the next call on the returned function.
@@creatorsremose they're not. currying means the final function arguments get composed in this staged fashion. every curried function is a function factory, but function factories don't have to receive or provide any arguments up or down the chain. when working with react, you probably never need currying.
@@BuyHighSellLo it's a functional programming pattern for when you have a target function with more than one argument. if you look up currying you should find good examples.
He is correctly describing a curried function. Also, factory functions return objects, not functions (unless we're being strict with how we define a function in Javascript).
If you curry a javascript function in es6, you dont' need the braces and return statement, you can double up on the arrow syntax: const handleIt = v => e => console.log(e, v) equivalent function to the one shown at 7:31
This content was a gold mine. Started using React more in depth a few weeks ago to build a booking app, and I was just getting to the point of needing something like Suspense to conditionally render UI. Thanks!
This is such a good video. When you're new to React, it's flexibility and minimalism makes it unclear how you *should* be doing things, the only thing that is exposed obviously is how you *can* do things.
I was just going through your react videos as I have a big interview coming up tomorrow. This is the best addition to my revision. Thanks a lot! You work in mysterious ways
The 100 seconds course sounds fantastic. Small chunks of knowledge delivered without any bullshit. I hate when I look for a solution or example, and the article 10x times the length it could be if it skipped the obvious parts, like setting up the project
Another useful feature "functional state update" if the new state depends on the previous state, you can pass a callback to setState like `setState(previousCount => previousCount + 1)` instead of `setState(count + 1)` Using functional state update will help in the memoization of the event handler using `useCallback` as the dependencies can be an empty array and it will also help in avoiding stale state closures
Yeap..it is a known issue. Everytime you need the current state value always use the callback. You can even end up in weird bugs if you the state value gets stale (like in an interval)
I was trying to determine why your voice is so familiar. Then I realized I took a React Native course with you! Just wanted to let you know, it taught me enough that I ended up developing a full stack app using similar architecture!
I stopped naming my files index.js because of that, not sure if I will switch to what you showed, it's amazing how you talk about stuff nobody anywhere talks about Also that vs code extension, HOLYY what a lifesaver
I just got accepted as a frontend dev on a startup company. A year ago, CEO hired some devs to create mobile app and web app using react native. Devs finished the contract and left. And this is where i get in. Imagine me, a react newbie, who have to fiddle with a messilly coded and stinky class based component react app. The worst part is, there's almost zero class based component tutorials on youtube. At least the pay is nice
@@blackkitty_42 I'd avise you to rely on the React docs, fortunately they have an excellent documentation (which is actually rare), and with plenty of class-based examples. And try sell your boss a progressive refactoring of your code.
i remember when my team first work on React before it got hooks but 3 months later, hooks got introduced and people didn't want to jump ship. tried convincing others to move all to hooks, but too late. we end up half of the code in hooks
@@blackkitty_42 the majority of react developers stop using classes and try to avoid it. because functions give almost the same result and with more readable and clean code. classes still has some render cycle methods that are not exist in functions but you will not need them in 90% of the cases.
@@blackkitty_42 I set aside an hour every workday to refactor one or two class components into hooks-based function components. A week of that taught me more about the codebase than the previous two months, and after two weeks my boss took me aside and asked me to refactor everything. Refactoring to hooks is such a win in performance and complexity that you should try to make it happen however you can, everyone around you will notice the improvements quickly
React's flexibility comes with great responsibility. I once worked on a React project where everything is memoized. We thought it would improve performance, but lately I realized it was a premature optimization
Definitely a problem I see often. Using memo/useMemo/useCallback is a tradeoff between spending processing time and memory. JavaScript engines are really fast nowadays, and React isn't slow either. For most UI you won't notice any performance issues unless you do something really complicated; at which point you have a few options; If your component does something that results changes the DOM or needs to do offload rendering where it doesn't matter whether React can keep track of it, you can use imperative APIs; e.g. for animations. You can use refs to grab the context of underlying DOM nodes of React elements you want to access. In most cases, splitting out components into logical parts that can do their own work, such as subscribing to specific state or doing computationally expensive things that aren't easy to optimize otherwise, you can memoize it, optionally with a comparison function. The less props you pass those expensive components the easier it becomes to manage at the cost of less reusability-again a compromise you'll have to make.
Awesome, educational video! Really appreciate the effort (and also the humor) that went into this. Also, this is the first tutorial video I watch on default speed and not 1.5x 😅
Great video! It’s crazy to me though how many of these patterns are encouraged out of the box with something like SvelteKit. First principles approach with a clean slate has done the Svelte team wonders.
Why did you take a break if I may ask?, Was it due to a burnout or something like that?, I'm just curious so you don't have to answer if you don't feel like doing so :).
@@daumienebi I started a marketing and business development company. So for the majority of my time doing other things. I still built websites and coded it was just in WordPress more than anything so mostly code snippets and changing things in a theme. Recently, my company has grown to the point where I can spend some time doing new things and I picked up design and software development a lot more!
TypeScript, deservedly, gets a lot of praise, but it's really under-discussed how much you have to change the way you code in order to use it properly. I think it's lighthandedness is pretty overstated
@@teacul I personally don't try to fight it too much, it's an addition here to simplify our lives but if it ends up becoming cumbersome that's not a great deal anymore
7:31, I couldn't think of that. I was at least familiar with some coding tips you have provided until 7:31 as i am watching, but i knew that i can return a function.
In number 9 while technically correct there is a pretty decent size caveat. React 16 and 17 will batch setStates as long as it not in an async function. If you are in an async function you can use unstable_batchedUpdates to batch setStates. The latter being pretty hacky in my mind, but can save you from a large refactor
for the context API i like to use this pattern where i have a single file that - creates the context with the default value undefined, but does not export it - creates and exports a provider component - creates and exports a custom hook that uses useContext and throws if the context value is undefined this way you always only import one thing (useMyContext hook) and you'll also always immediately know if you're using a component and there's no provider in it's parent hierarchy.
@@shawnc7381 I can't post a link here, but google "kent c dodds how to use react context effectively" there's a post on his blog that covers this pattern.
5. That only works if you style your components with plain css, however most modern react applications are done with a framework or Sass, in that case i suggest splitting components with use case and create a index.js in the folder and export all components from that folder
i know i'm late to the party, but this is a lot to do a few simple things. I am coming from vue and needed to see habits for react development. no offence though, I think both get the job done, but react is more common in this region. That refactor markup -> component thing is really good.
Redux is not a heavy handed approach in my opinion. The reducer itself is a pretty simple function and Redux allows for a much better separation of concerns when couples with reselect and sagas. I’d argue that for any react app you’re being paid to make, react+redux+sagas+reselect is a must and the morally correct setup to use.
Some of these are anti-patterns as well. Spreading props is an anti-pattern because it is not declarative and it can cause unneeded exporting of types between components. Additionally, your curried function should be nested within a useCallback() to prevent extra re-renders. If you want to teach against anti-patterns, it would be better if you taught your audience eslint recommended settings for common plugins.
I agree with the second half but not so much as the first. Spreading is a fine pattern if you as the developer are aware of what you are doing. Not to mention typescript ensures you use it properly
@@_guru ESLint has a bunch of default rules, but if you really wanna give it a go, try the Airbnb rules. Those are opinionated, and I enjoy them very much.
Hey, I've actually thought of using curried functions, but my initial thoughts tell me that it is going to going to consume more memory as for each call, a new big function will be made again to be called. In contrast, the one without function currying I suppose would call the same function, not create a new one, but with different params, hence better perf and memory. I have yet to test if this is true or not. Is that how it works in JS? I'd like to know the results for this.
Doesn't matter. With curried function on 3 calls you create and return 3 functions. If you use 3 arrow functions, you created them as well, but manually, not programmatically.
I don't think that's the case. See, what you're thinking is that the onChange function runs the currying on every call, but what it does is that each call runs the returned function. The curry function only runs on re-render.
@@isqueirosbic Idk if you were responding to me or Nathan, but let me make it clear: In both cases on each render you create three functions that live in memory. In the first example you create them manually writing three arrow functions. In the second example you create those three functions by running the "creator"/"factory" function. In the second example you have "more calls" but that doesn't matter. The memory footprint is close to being exactly the same.
In either case, it creates 3 new functions on every render. If you *really* want to try to avoid this, you can create a useCallback function but this is most likely overkill over-optimisation. const handleClick = useCallback((param) => (event) => clickHandler(event, param, state), [state]) Button text
Rather than creating a custom hook just for storing related state, useReducer can be more ergonomic as it can also provide you with a single dispatch function that can update that state using actions. As for the second point about nesting; this also comes with a gotcha in that the parent component will update all its children when it updates state that may just be used for a few or a single child. It's useful if child components are reusable, but unnecessary otherwise. It's fine to co-locate state and event handlers in child components and is often easier to reason about; If you truly run into performance issues due to unnecessary re-renders, you can wrap child components in React.memo.
Another good way to manage state is with the react-tracked library, it offers the flexibility of the context api, the advanced usage of reducers like redux, but the main goal is to avoid rerender of components when it's not needed. Check this library, it's a good one in my opinion 👍
curried functions won't prevent rerenders because when you call the function it returns a new function, so the reference is new each time. useCallback won't help here either, but if you set up your callbacks to target child component's return signature, then you can simply use useCallback
Tip #3 put a smile on my face, I was expecting useEffect and it being called out for being a major footgun but he actually highlighted useMemo in a completely novel way.
Now I know why I messed up when first trying to build a thing on RN. This framework and Js project really need a simpler structure and easier to manage.
I'm writing my first react app and prop drilling is the first thing I've noticed as not very elegant with my code. Now I can name it and think about solutions.
Not all heros wear capes, so much good nuggets in here. I use currying all the time but I didn't know about glean and now I know how to deal with the index.tsx index.tsx index.tsx issue in my vscode tab bar ☺
Have you done rxjs before? I think it's great to learn it since it has changed how I think and solve problems related to data handling. It feels like shaping a river with your own hands like a god.
I really really like your style. Did you ever make public your "youtube stack" would be very interested. I want to do similar videos for the Data / Backend side.
Thanks again for the tutorials Jeff your style of teaching is very straight forward and to the point. I am curious if anyone has seen a similar extension for JetBrains (glean)
For the currying comment, rather than having a function outside of the component, use a useCallback or with every render it's producing a new function which then means when you're passing that as a prop it's seen as a prop change and causes a re-render for those components
PLEASE MORE VIDEOS LIKE THIS!!! I love code reports and 100 seconds series but wish we got videos like this more often! Keep up the awesome job!!
Great video! When you work with react every day for a few years, you slowly realize exactly the things you showed here. It would've been nice to see this 2 years ago :)
This is by far the most efficient way to learn code and environment optimization I've seen. Every language needs a video like this, amazing work!
I think that when you have prop drilling issues, before reaching for context or redux, it's usually best to consider if you are using the `children` prop effectively. A lot of the time if you aren't using the drilled prop in the intermediate components, they can render `{children}` and that prop can be passed directly from the origin parent to the component that needs it.
Thank you. This is great.
And it always more flexible. For free.
Sorry I don't understand this. Can you explain it a bit different?
@@Bobobratwurscht You have a parent component and a child component. The parent component accepts a bunch of props which are just used to pass (or drill) it to the child component. What you can do instead is to just accept a children prop in the parent component and render it. When you now render the parent component, you pass the child component as the children prop of the parent.
@@Dekatelon I'm still not following.
Very important thing with context - any item that consumes that context (i.e., the `const count = useContext(CountContext);` in the example) will ALWAYS rerender when the context value changes, regardless of if that component actually uses that value or not. A very common pitfall is to use Context as a sort of 'big store', where you've got a ton of values in the context that are consumed by components that only need one or two of said values. This means that every time the context component updates, EVERY SINGLE CHILD COMPONENT THAT RELIES ON THAT CONTEXT WILL ALSO RERENDER. It's a huge, huge performance issue in very large apps.
Keep context to items that will change extremely rarely - themes, authentication states, etc - and never use them for data that changes somewhat frequently unless you're making a very tiny app that won't see the exponential performance loss of this.
If you need something passed down but don't want to go through the whole heavy mess of Redux / MobX / etc, minimalist state management libraries like Recoil, Zustand, and Jotai are very easy, approachable, and lightweight ways to do this the 'right' way.
But why even have this problem in the first place why is sharing info in react so awful in every way possible
using useMemo to prevent re-renders is a much more minimal approach as you don't need to install any dependencies
great notice thank you
@@feritperliare2890 do you mean why react re-renders? if so, it is a way of keeping application UI updated as the state changes.
@@adeleke5140 yes that’s how react does it meanwhile other frameworks only re render what needs to be re rendered when you call the info somewhere and not every spot that your store somehow reaches its a stupid expensive way to make sure your UI is updated
9 months later and I can finally understand this video! First time I watched it, I had no idea what any of this was.
React's flexibility is its greatest strength, but if you don't know what you're doing, it can sometimes lead to weird things
That's why more opinionated frameworks like Vue exist, so you don't have to learn every way you can do stuff.
I myself would honestly stick to Svelte for personal projects, it's one of few frameworks that don't actively piss you off on each step.
(And yes, React is a lib - as long as you don't slap JSX on top of it)
@@shapelessed That's why other libs/frameworks like Vue, angular and svelte in the second, third and fourth place
@@amirhoseinhesami9336 react came first and that was huge advantage.. i would go with vueJS or svelte or even angular for complex Enterprise apps. The non opinionated react is not really my thing
@@lahcencodery vue and svelte in the enterprise world is not a real thing and also the funniest joke ever however the "angular" used to dominate the enterprise world however it is not relevant today because react is dominating the enterprise as well
@@amirhoseinhesami9336 backed by Google and Facebook/meta 🤷🏻
Any other reason which is better!?
Man you are a genius. Your channel and then 10 places are empty and then everyone else, it's amazing how original you are with content and just keep going! Big greetings from Serbia! :)
☝️☝️☝️Thanks for your feedback
I am using Svelte exclusively, but the concepts here in React still apply when it comes to componentizing. Super useful advice, thanks!
Svelte saved my fucking life. React is garbage in comparison.
There's an instructor named John Smilga and his 14 hour long react video on yt covered all of these tips and tricks along with so many other things for free. I am glad that people like you guys exist.
I've been doing some stuff you said here without knowing it myself, I'm a self learner and have been following you for code quality improvements. You have once again upped my bar, thank you very much 🙏
One of these for Angular would be amazing! Great video as always Jeff
Angular is dead (This comment was paid for by Ben Awad)
@@invinciblemode AngularJS to be exact, killed by google since December last year
Eh, that would probably confuse most Javascript viewers who've never heard of types lol
@@niklasstahl98 Not really. Most JS developers with a little bit of experience will be familiar with the fundamental types. It's only jarring for the first couple of days using them in a strict manner but after that it becomes natural.
Another anti pattern is doing component updates on unmounted component resulting to memory leaks. Majorly caused by asynchronous Javascript
☝️☝️☝️Thanks for your feedback
@@chatmeup8917 not actual firebase
Many people forget to use useeffect's cleanup function!
when fetching data, the AbortController (native API) can be used, or a library that abstracts this away or avoids this issue can be used, like react-query
calling an async function without setting the state would not lead to memory leaks right?
edit: apparently currying is still the correct term, i've just never ever seen it used for general function generation.
regarding 9: in the example that _you show_ it's a curried function, but what _you describe_ is just a factory function.
curried functions basically let you specify the multiple arguments of a function A in multiple steps where each step or function call returns you a function where that value is "stored" in the closure and you can specify the next argument with the next call on the returned function.
Which is better in terms of implementation though? Factory or Curried? Because they're technically the same...
@@creatorsremose they're not. currying means the final function arguments get composed in this staged fashion. every curried function is a function factory, but function factories don't have to receive or provide any arguments up or down the chain. when working with react, you probably never need currying.
When would you need currying?
@@BuyHighSellLo it's a functional programming pattern for when you have a target function with more than one argument. if you look up currying you should find good examples.
He is correctly describing a curried function. Also, factory functions return objects, not functions (unless we're being strict with how we define a function in Javascript).
Your videos are amazing man. Whenever I need a quick refresher you're the go to! Really appreciate all your hard work.
If you curry a javascript function in es6, you dont' need the braces and return statement, you can double up on the arrow syntax:
const handleIt = v => e => console.log(e, v)
equivalent function to the one shown at 7:31
True, but this also comes at a cost of readability
Talk about antipatterns
He uses TypeScript so if you want to define a type for the parameter you need to use parentheses
I hate this syntax with a passion. I use regular function declarations for named functions and arrow functions for callbacks
i love that you're explanations have no ummm's or aaaaa's, making them bearable and even entertaining to watch. love the edits
This content was a gold mine. Started using React more in depth a few weeks ago to build a booking app, and I was just getting to the point of needing something like Suspense to conditionally render UI. Thanks!
You don't REALLY need to use suspense to conditionnally render UI, it's not mandatory.
This is such a good video. When you're new to React, it's flexibility and minimalism makes it unclear how you *should* be doing things, the only thing that is exposed obviously is how you *can* do things.
I was just going through your react videos as I have a big interview coming up tomorrow. This is the best addition to my revision. Thanks a lot! You work in mysterious ways
The 100 seconds course sounds fantastic. Small chunks of knowledge delivered without any bullshit. I hate when I look for a solution or example, and the article 10x times the length it could be if it skipped the obvious parts, like setting up the project
Another useful feature "functional state update"
if the new state depends on the previous state, you can pass a callback to setState like
`setState(previousCount => previousCount + 1)` instead of `setState(count + 1)`
Using functional state update will help in the memoization of the event handler using `useCallback` as the dependencies can be an empty array
and it will also help in avoiding stale state closures
Always followed it to save myself from trouble
i use for handleinput functions
Yeap..it is a known issue. Everytime you need the current state value always use the callback. You can even end up in weird bugs if you the state value gets stale (like in an interval)
I remember seeing this in a PR and was very confused.... Now I use it all the time
setState(count++) ; )
I was trying to determine why your voice is so familiar. Then I realized I took a React Native course with you! Just wanted to let you know, it taught me enough that I ended up developing a full stack app using similar architecture!
I stopped naming my files index.js because of that, not sure if I will switch to what you showed, it's amazing how you talk about stuff nobody anywhere talks about
Also that vs code extension, HOLYY what a lifesaver
to the people who still use classes components: make sure to keep cleaning your caves, bad environment effect the productivity of the developer.
I just got accepted as a frontend dev on a startup company. A year ago, CEO hired some devs to create mobile app and web app using react native. Devs finished the contract and left.
And this is where i get in. Imagine me, a react newbie, who have to fiddle with a messilly coded and stinky class based component react app. The worst part is, there's almost zero class based component tutorials on youtube.
At least the pay is nice
@@blackkitty_42 I'd avise you to rely on the React docs, fortunately they have an excellent documentation (which is actually rare), and with plenty of class-based examples. And try sell your boss a progressive refactoring of your code.
i remember when my team first work on React before it got hooks but 3 months later, hooks got introduced and people didn't want to jump ship. tried convincing others to move all to hooks, but too late. we end up half of the code in hooks
@@blackkitty_42
the majority of react developers stop using classes and try to avoid it. because functions give almost the same result and with more readable and clean code. classes still has some render cycle methods that are not exist in functions but you will not need them in 90% of the cases.
@@blackkitty_42 I set aside an hour every workday to refactor one or two class components into hooks-based function components. A week of that taught me more about the codebase than the previous two months, and after two weeks my boss took me aside and asked me to refactor everything. Refactoring to hooks is such a win in performance and complexity that you should try to make it happen however you can, everyone around you will notice the improvements quickly
React's flexibility comes with great responsibility. I once worked on a React project where everything is memoized. We thought it would improve performance, but lately I realized it was a premature optimization
Definitely a problem I see often. Using memo/useMemo/useCallback is a tradeoff between spending processing time and memory. JavaScript engines are really fast nowadays, and React isn't slow either. For most UI you won't notice any performance issues unless you do something really complicated; at which point you have a few options;
If your component does something that results changes the DOM or needs to do offload rendering where it doesn't matter whether React can keep track of it, you can use imperative APIs; e.g. for animations. You can use refs to grab the context of underlying DOM nodes of React elements you want to access.
In most cases, splitting out components into logical parts that can do their own work, such as subscribing to specific state or doing computationally expensive things that aren't easy to optimize otherwise, you can memoize it, optionally with a comparison function. The less props you pass those expensive components the easier it becomes to manage at the cost of less reusability-again a compromise you'll have to make.
In react everything depends on the developer’s knowledge, it can get to a complete mess or a solid structure. Great video 👍
Awesome, educational video! Really appreciate the effort (and also the humor) that went into this. Also, this is the first tutorial video I watch on default speed and not 1.5x 😅
Great video! It’s crazy to me though how many of these patterns are encouraged out of the box with something like SvelteKit. First principles approach with a clean slate has done the Svelte team wonders.
Ok, glean was a blessing from this video. I did not know it existed lol. I used rfc and rnfc, but this is next level. Thanks man!
Very helpful as always. As someone just getting back into coding after a break these help a ton. I'd love to see one over Tailwind CSS
Why did you take a break if I may ask?, Was it due to a burnout or something like that?, I'm just curious so you don't have to answer if you don't feel like doing so :).
@@daumienebi I started a marketing and business development company. So for the majority of my time doing other things. I still built websites and coded it was just in WordPress more than anything so mostly code snippets and changing things in a theme. Recently, my company has grown to the point where I can spend some time doing new things and I picked up design and software development a lot more!
@@ChristianHelmsOther ohhh okay, congratulations on your Company!!
@@daumienebi Thank you very much! It's been a blast
Terrific video! Every point is... well, on point. 🙂
You have a new subscriber. 👍
I'd love to be able to vote financially for what content you focus on, because I'd love more of these code this not that videos
I love this guy's humor and explanation style😂😂
The "prop plowing" technique is great but I tend not to do it much because TypeScript won't validate the input against the component's input props
TypeScript, deservedly, gets a lot of praise, but it's really under-discussed how much you have to change the way you code in order to use it properly. I think it's lighthandedness is pretty overstated
I believe TS validates spreaded objects `{...childProps}`, but it might only work if the object created was typed explicitly.
@@teacul I personally don't try to fight it too much, it's an addition here to simplify our lives but if it ends up becoming cumbersome that's not a great deal anymore
This video just made me very happy that I work with Svelte...
It is inevitable. React will die eventually. Long live Svelte!
It's funny enough you are happy with Svelte but watching video about React patterns :D
@@yevhenkozlov286 It's like watching videos of life in Africa, that make you appreciate what you have.
Many people are asking about vscode settings. According to me :
Font : Fira Code
Theme : One Dark Pro
A masterclass in both react and instructional videos. Thank you!
"... that leaves us developers with plenty of room to screw things up with our own stupid ideas." So underrated.
7:31, I couldn't think of that. I was at least familiar with some coding tips you have provided until 7:31 as i am watching, but i knew that i can return a function.
Context is not only "cool" to prevent prop drilling, is very helpful to separate state logic for a bunch of components
In number 9 while technically correct there is a pretty decent size caveat. React 16 and 17 will batch setStates as long as it not in an async function. If you are in an async function you can use unstable_batchedUpdates to batch setStates. The latter being pretty hacky in my mind, but can save you from a large refactor
never heard about glean. Tested it this morning, it really has potential to speed up my work. Thanks for sharing!
Two minutes in and there's a gem of a VSCode extension already. 👏🏽👏🏽👏🏽Can't miss!
for the context API i like to use this pattern where i have a single file that
- creates the context with the default value undefined, but does not export it
- creates and exports a provider component
- creates and exports a custom hook that uses useContext and throws if the context value is undefined
this way you always only import one thing (useMyContext hook) and you'll also always immediately know if you're using a component and there's no provider in it's parent hierarchy.
Interesting….where can I learn this method?
@@shawnc7381 on your own 🤣. Just understand the context API and custom hook deeply 💯
@@shawnc7381 it's really nothing more than i described in the comment :D
@@shawnc7381 I can't post a link here, but google "kent c dodds how to use react context effectively" there's a post on his blog that covers this pattern.
Dude, I like your content so much that I feel like I owe you money every single video you post. Great work Jeff!
HOLY S**T glean is amazing!
thank you for letting me know about this! this was a dream for me
With great power comes great responsibility! Fantastic video, and I am definitely going to be using a few of these tips and tricks. Thank you.
5. That only works if you style your components with plain css, however most modern react applications are done with a framework or Sass, in that case i suggest splitting components with use case and create a index.js in the folder and export all components from that folder
☝️☝️☝️Thanks for your feedback
Great video. As a beginner, i learned a lot in these 9 minutes. Thanks! 🔥 🚀
Just installed glean. Thanks for the tip!
I was in a trouble in today with react, and you uploaded a video about it. thank you very much
Great video! I need this course for my start up project im currently working on.
Thanks!
i know i'm late to the party, but this is a lot to do a few simple things. I am coming from vue and needed to see habits for react development. no offence though, I think both get the job done, but react is more common in this region. That refactor markup -> component thing is really good.
Even before this video I thought my event handlers were ugly. Now I'm going to rewrite them as curried functions. Thank you so much!
Redux is not a heavy handed approach in my opinion. The reducer itself is a pretty simple function and Redux allows for a much better separation of concerns when couples with reselect and sagas.
I’d argue that for any react app you’re being paid to make, react+redux+sagas+reselect is a must and the morally correct setup to use.
Happy code this not that videos are back. Hey did Jeff switch away from angular and why???
I guess Nextjs motivated him or something?🤣
Some of these are anti-patterns as well. Spreading props is an anti-pattern because it is not declarative and it can cause unneeded exporting of types between components. Additionally, your curried function should be nested within a useCallback() to prevent extra re-renders. If you want to teach against anti-patterns, it would be better if you taught your audience eslint recommended settings for common plugins.
What are those eslint recommend settings?
I agree with the second half but not so much as the first. Spreading is a fine pattern if you as the developer are aware of what you are doing. Not to mention typescript ensures you use it properly
@@_guru ESLint has a bunch of default rules, but if you really wanna give it a go, try the Airbnb rules. Those are opinionated, and I enjoy them very much.
Spreading props isn't an anti-pattern, there's a major difference between personal code style and actual anti-patterns
Callstack's eslint-config package is really nice to use. Not a big fan of AirBnb rules though.
Hey, I've actually thought of using curried functions, but my initial thoughts tell me that it is going to going to consume more memory as for each call, a new big function will be made again to be called. In contrast, the one without function currying I suppose would call the same function, not create a new one, but with different params, hence better perf and memory. I have yet to test if this is true or not. Is that how it works in JS? I'd like to know the results for this.
Doesn't matter. With curried function on 3 calls you create and return 3 functions. If you use 3 arrow functions, you created them as well, but manually, not programmatically.
I don't think that's the case. See, what you're thinking is that the onChange function runs the currying on every call, but what it does is that each call runs the returned function. The curry function only runs on re-render.
@@isqueirosbic Idk if you were responding to me or Nathan, but let me make it clear:
In both cases on each render you create three functions that live in memory. In the first example you create them manually writing three arrow functions. In the second example you create those three functions by running the "creator"/"factory" function.
In the second example you have "more calls" but that doesn't matter. The memory footprint is close to being exactly the same.
@@CzajekTutorialowiec I was answering nathan ;)
In either case, it creates 3 new functions on every render.
If you *really* want to try to avoid this, you can create a useCallback function but this is most likely overkill over-optimisation.
const handleClick = useCallback((param) => (event) => clickHandler(event, param, state), [state])
Button text
i didnt know there were this many antipatterns in react, i will be using all of them now! nice video
Rather than creating a custom hook just for storing related state, useReducer can be more ergonomic as it can also provide you with a single dispatch function that can update that state using actions.
As for the second point about nesting; this also comes with a gotcha in that the parent component will update all its children when it updates state that may just be used for a few or a single child. It's useful if child components are reusable, but unnecessary otherwise. It's fine to co-locate state and event handlers in child components and is often easier to reason about; If you truly run into performance issues due to unnecessary re-renders, you can wrap child components in React.memo.
I feel so good that I knew all of this and predicted all your solutions without even looking into the topic.
Another good way to manage state is with the react-tracked library, it offers the flexibility of the context api, the advanced usage of reducers like redux, but the main goal is to avoid rerender of components when it's not needed. Check this library, it's a good one in my opinion 👍
The JS solution for everything: just install another library and hope it still works when you deploy :D
Suuuper pumped for the new React course on Fireship Pro
Your course is surely gonna be awesome 🔥💪🏻
Points 5 and 9 really help me, thanks!
Thank you, Jeff! This might save me as a newbie-ish React developer for damn sure!
curried functions won't prevent rerenders because when you call the function it returns a new function, so the reference is new each time. useCallback won't help here either, but if you set up your callbacks to target child component's return signature, then you can simply use useCallback
Thanks! Was learning react today and this was like, not even let me choose the wrong path from start!
you don't get better at something without sucking at it first
@@mentoriii3475 ikr, still this is a good starting point
☝️☝️☝️Thanks for your feedback
@@chatmeup8917 shut up impersonator
Hey. One cool thing is you can also return multiple components in array, like return ([,]) instead of wrapping them in React.fragment
Interesting, I think the ... Syntax is way nicer to read though.
Bring it bruh!! I want that course
I love 4:30!! Have been struggling with multiple index.tsx files for a while now 😂
This is an amazing vid. Use react for work and a lot of the problems and solutions you mentioned apply to my everyday life.
So hype for the react course!
this was awesome. i love that last tip!
Tip #3 put a smile on my face, I was expecting useEffect and it being called out for being a major footgun but he actually highlighted useMemo in a completely novel way.
Thanks, knew most but nice reminder as we often forget things if not practiced lately
The vscode refactoring extension is a huge lifesaver.
Thanks for the extension Glean. Saves my life
Now I know why I messed up when first trying to build a thing on RN.
This framework and Js project really need a simpler structure and easier to manage.
I'm writing my first react app and prop drilling is the first thing I've noticed as not very elegant with my code. Now I can name it and think about solutions.
I really enjoyed this. Good job 👍🏻
Never heard of Glean before. Thanks a lot for sharing
Thanks for the PRO discount! Just subscribed for life :)
Can you go back three years in time and put this video out? Would have saved me a lot of time figuring these all out one by one...
Not all heros wear capes, so much good nuggets in here. I use currying all the time but I didn't know about glean and now I know how to deal with the index.tsx index.tsx index.tsx issue in my vscode tab bar ☺
Zustand in 100 seconds please. As always , great video. Thanks for your time.
Have you done rxjs before? I think it's great to learn it since it has changed how I think and solve problems related to data handling. It feels like shaping a river with your own hands like a god.
I love you. This was amazing. Please do other technologies in the same way. Angular, rxjs, firebase? :P
Awesome explanation! Thank you so much for making this video!
I really really like your style. Did you ever make public your "youtube stack" would be very interested. I want to do similar videos for the Data / Backend side.
This is a super helpful video. Thank you for the great video!
the curried function for event handlers is my new favorite piece of code.
Thanks again for the tutorials Jeff your style of teaching is very straight forward and to the point. I am curious if anyone has seen a similar extension for JetBrains (glean)
Hey! I just learned about antipatterns in my softwares engineering class today. What a coincidence 😮
React antipattern #1: AngularJS
Then goes Vue and Svelte...
Ben Awad wants to know your location
Thanks! With this video I appreciate more the simplicity that is rendering html with go html template
☝️☝️☝️Thanks for your feedback
Really helpful video, thanks a lot!
For the currying comment, rather than having a function outside of the component, use a useCallback or with every render it's producing a new function which then means when you're passing that as a prop it's seen as a prop change and causes a re-render for those components