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! :)
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
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
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.
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)
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).
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.
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
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.
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.
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!
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.
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
@@user-yy3ki9rl6i 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
@@user-yy3ki9rl6i 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.
@@user-yy3ki9rl6i 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
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
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
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!
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.
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 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
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 😅
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!
Doing batched export with index files (4:35) stops vscode from being able to automatically refactor function and variable names when using F2. It applies the refactor as an alias in the exported object of the index file
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.
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
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.
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
07:31 to my knowledge, the call of a function with params without the arrow function syntax causes it to run immediately regardless of the event firing, doesn't it?
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 👍
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.
For subscribing to state, it's ok. But you're right that if you need to update state, you'd need a way to provide those dispatch functions. An alternative is to use useReducer instead, which gives you a single dispatch function that you can use to update state through actions.
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 ☺
0:12 There is no way into that maze with the entrances in front of that guy lol. One leads straight back out and the other is a dead end. Unless the one that leads straight back out is the solution.
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 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.
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
9. You could also use something like this: onClick={handleClick.bind(null, e, someParam1, someParam2)} while the actual function will look like this: const onClick = (e, param1, param2) => {}
Arrow functions cannot be bound to a context. It's also less ergonomic than creating factory functions. However, I highly discourage factory functions in React as they have their own gotchas that can be avoided simply by passing multiple arguments.
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 :)
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
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!?
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!
9 months later and I can finally understand this video! First time I watched it, I had no idea what any of this was.
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
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 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.
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?
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.
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++) ; )
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).
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 🙏
i love that you're explanations have no ummm's or aaaaa's, making them bearable and even entertaining to watch. love the edits
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.
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
Your videos are amazing man. Whenever I need a quick refresher you're the go to! Really appreciate all your hard work.
Terrific video! Every point is... well, on point. 🙂
You have a new subscriber. 👍
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.
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.
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.
In react everything depends on the developer’s knowledge, it can get to a complete mess or a solid structure. Great video 👍
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.
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
@@user-yy3ki9rl6i 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
@@user-yy3ki9rl6i
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.
@@user-yy3ki9rl6i 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
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
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!
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
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!
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.
Thanks!
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
Many people are asking about vscode settings. According to me :
Font : Fira Code
Theme : One Dark Pro
I love this guy's humor and explanation style😂😂
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
Just installed glean. Thanks for the tip!
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.
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 😅
Context is not only "cool" to prevent prop drilling, is very helpful to separate state logic for a bunch of components
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
Two minutes in and there's a gem of a VSCode extension already. 👏🏽👏🏽👏🏽Can't miss!
Doing batched export with index files (4:35) stops vscode from being able to automatically refactor function and variable names when using F2. It applies the refactor as an alias in the exported object of the index file
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.
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
I love 4:30!! Have been struggling with multiple index.tsx files for a while now 😂
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.
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!
Dude, I like your content so much that I feel like I owe you money every single video you post. Great work Jeff!
"... that leaves us developers with plenty of room to screw things up with our own stupid ideas." So underrated.
never heard about glean. Tested it this morning, it really has potential to speed up my work. Thanks for sharing!
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
A masterclass in both react and instructional videos. Thank you!
Great video. As a beginner, i learned a lot in these 9 minutes. Thanks! 🔥 🚀
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
Great video! I need this course for my start up project im currently working on.
07:31 to my knowledge, the call of a function with params without the arrow function syntax causes it to run immediately regardless of the event firing, doesn't it?
Happy code this not that videos are back. Hey did Jeff switch away from angular and why???
I guess Nextjs motivated him or something?🤣
i didnt know there were this many antipatterns in react, i will be using all of them now! nice video
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
I was in a trouble in today with react, and you uploaded a video about it. thank you very much
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.
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.
Your course is surely gonna be awesome 🔥💪🏻
Shouldn't the useMetadata hook return a set function as well? Otherwise That wouldn't work would it?
For subscribing to state, it's ok. But you're right that if you need to update state, you'd need a way to provide those dispatch functions. An alternative is to use useReducer instead, which gives you a single dispatch function that you can use to update state through actions.
@@dealloc hahaha to state
I love you. This was amazing. Please do other technologies in the same way. Angular, rxjs, firebase? :P
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 ☺
Suuuper pumped for the new React course on Fireship Pro
0:12 There is no way into that maze with the entrances in front of that guy lol. One leads straight back out and the other is a dead end. Unless the one that leads straight back out is the solution.
I feel so good that I knew all of this and predicted all your solutions without even looking into the topic.
Thanks, knew most but nice reminder as we often forget things if not practiced lately
Zustand in 100 seconds please. As always , great video. Thanks for your time.
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.
Thanks for the PRO discount! Just subscribed for life :)
Points 5 and 9 really help me, thanks!
this video temporarily cured my impostor syndrome as I knew and do all of these. thanks, Jeff!
So hype for the react course!
6:41 the way i work around prop plowing is like this
And it is pretty
would useEffect( ()=>{}, [count]) work for the example in 2:56 the same way useMemo works? Or does that still run on every state changes?
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.
I really enjoyed this. Good job 👍🏻
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.
Awesome!
05:52 - Great movie ("Pi"), as well as the joke...
React antipattern #1: AngularJS
Then goes Vue and Svelte...
Ben Awad wants to know your location
Awesome explanation! Thank you so much for making this video!
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
7:30 Why don't we use .bind() method for that, writing a wrapper function is like inventing bicycle to me.
9. You could also use something like this:
onClick={handleClick.bind(null, e, someParam1, someParam2)}
while the actual function will look like this:
const onClick = (e, param1, param2) => {}
Arrow functions cannot be bound to a context. It's also less ergonomic than creating factory functions. However, I highly discourage factory functions in React as they have their own gotchas that can be avoided simply by passing multiple arguments.
What are those newer frameworks he talks about at 0:17 ?
4:57 Next.js v12 is now based on SWC which is much more faster than Webpack.
Holy moly! I felt most of what you said. I must be on the right track then. F***in' tutorial purgatory.
That Currying mentioned....which will impress your Friends and family😂😁...
Great Videos bro..😍😍
6:53 Destructive assignment of the component.
For the prop plowing problem you can also use destructuring to just pass your object as a whole to the User and handle it inside your component no ?
Thank you, Jeff! This might save me as a newbie-ish React developer for damn sure!
this was awesome. i love that last tip!
This is a super helpful video. Thank you for the great video!
Hey! I just learned about antipatterns in my softwares engineering class today. What a coincidence 😮
Thanks for the extension Glean. Saves my life