Correction (1:21) - First put the returned array from users.concat(newUser) in a new variable (i.e. newUsers). Then pass it to setUsers: setUsers(newUsers).
6th example is a incorrect example and less performant one, the explanation is also wrong, but the advise is correct, same goes for 7th example too, tanstack query also uses useEffect, it just got abstracted away, again explanation is incorrect , but advise is good, this video has 60K views, so may be try to put a overlay text, so that your audience is not miss informed
Using indexes as keys is not always a bad idea. If the set of items is known and never changing, there’s no reason you shouldn’t be able to use the index. It may be an anti-pattern in most cases but if you know when it is fine to use, just keep that in mind and do it.
Well that's what I thought. Then I found myself using them in multiple positions in the same app (rendering more than one list using indexes as keys). And I had that warning then a bug that it failed to render properly. There's no written rule that you can't, but only do it if you're doing it only once through the whole app.
its important to know that UseEffect runs TWICE after mount, but only on dev enviroments with strict mode on. I learned that after hours of debugging...
5:51 i don’t recommend adding count to dependency array in this case.. as we can always use the previous value of the state inside setState and use that instead of directly using count
@@NamesAreVacuous You can pass a function to setState(). This function has the correct state value as a parameter. Instead of setCount(count + 1), you can do setCount((previousCount) => previousCount + 1). const [count, setCount] = useState(0); useEffect(() => { const intervalId = setInterval(() => { setCount((previousCount) => previousCount + 1); }, 1000); return () => clearInterval(intervalId) }, []);
Althought what you wrote is true, keep in mind this is just a very simple example. In a real world case you caould be using a completely different state variable or some derived value.
6:41 I agree a simple fetch call in a useEffect is a naive approach and Tanstack query is great, however how do you think they implement this under the hood? Also using useEffect. Much in the same way it also starts requesting the data after the component renders.
Correct, Tanstack Query doesn't fix all the problems of data fetching in React. It does have patterns like prefetching and suspense mode, however, which allow you to render-as-you-fetch. Every pattern has its tradeoffs.
For the "Keys Should Actually Be Unique" part, the purpose of this is list ordering. E.g. if you use a non-data-derived `index` as the key and the list order changes, the renderer won't know and it will not update correctly. If your list is not changing order, it's fine to use an index. Also, it only needs to be unique per parent - so you can e.g. have identical keys in two separate lists rendering as long as those lists have a different parent.
The useEffect code at 5:48 will be constantly setting and clearing intervals. Might as well use a timeout for that. A better approach would be to keep the dependencies array empty and use function to update the state setCount(oldCount =>oldCount +1).
Honestly, this person produces some of the cleanest videos on React concepts. I am amazed how he makes the videos look simple yet packs it with quality information. Keep it up 🫡
React Router 6.4 data loaders allow you to fetch data on the route level, so that is another approach to consider alongside solutions such as Tanstack Query and SWR.
The example at 1:21 doesn't work as well, you are not calling setUsers with the new array created from the concat metod so that example wont do anything just like the faulty example. To solve it use the result from the concat method as the argument in setUsers :)
Idk how I feel about "just use dedicated hooks to fetch data like swr, react query, or other library." It's alright to make the code work for now, but we introduce vendor lock-in to the project, a haunting tech debt that will lead us to long hours in the long run. However, I also agree that we shouldn't freely use the clunky-ass, hard to understand useEffect. To mediate this problem, I would introduce a context that contains the interface of "useDataFetcher," which is used by the components. The implementation is decided once at the top of the component tree, and this is where we the vendor hooks like swc and react-query are passed. It's not a perfect solution, as there is an extra layer of indirection now between the components and the vendor hooks, making it overkill for small projects. However, it will ease the whole process of migrating from one library to another.
Good points and summary; However, the useEffect with a fetch does allow the component to render and TanStack Query under the hood uses useEffect. Sure it should be used for other benefits, but implying at the end that useEffect prevents rendering is not accurate.
Love the tips here. Even an experienced dev can learn some things. But, I think useEffect is getting a bad rap. React was originally designed to fetch data after a component is rendered, so you'll always have some type of loading state, regardless of the library used. I wouldn't necessarily call that a "bad" UX. If you need the data earlier, then SSR is the way to go.
If I'm using Next.js with app router, I like fetching data on the server in a React Server Component. If I need something more complex and across client components, I like Tanstack Query. I think each choice has its tradeoffs.
It said the component will rerender when the props change but I think a component only renders when a parent component renders due to a state change. Props changing does not cause a re render right?
hey men i really love the like your video it is deep and very helpful but right now i really struggle about file management like every time when i want to do some practice i always install react app again and again specially i am very confused by the installation of necessary files like nodemon , express ,node ,buble and run my file on terminal and like so on things really hard for me so can you make a tutorial video on how to handle files and folders, do we have to install every time when we want run our app or so many things please?!
The thing about not using indexes for keys flat out is a bit silly and you're doing yourself a disservice if you take it at face value. This tip is very commonly shared as an axiom, but it is really not. In many cases, indexes are perfectly safe as keys, especially when the array you're rendering won't change or it will only grow at the end but not shuffle or grow at the beginning / in the middle.
Please do one for JavaScript too. You can't live React without JavaScript too. Waiting for it eagerly...
8 месяцев назад+5
Blowing app your project with extra libraries it is not good either. You do not really need, for instance, React Query to perform fetching data unless your case is very specific.
6th example is a incorrect example and less performant one, the explanation is also wrong, but the advise is correct, same goes for 7th example too, tanstack query also uses useEffect, it just got abstracted away, again explanation is incorrect , but advise is good
I really don't understand why immutability was pushed so hard with React. It's JavaScript. It's single threaded. It can only perform a single action at a time. What race condition are we protecting against exactly?
i think it has to do with virtual dom because when you mutate array or an object it still references the same address and virtual dom needs a new value to cause re render which only happens if you make a deep copy of the array\object
because React can't track such changes for reconciliation. The culprit is the concept of VDOM. Biggest mistake the React team did. If you want React without the immutability bs you can use SolidJS.
Not sure why you keep saying it's bad to use useEffect to fetch data and to use libraries instead. They use useEffect under the hood - It's just abstracted. Saying this to junior devs and not clarifying that is kind of pathetic imo.
These hangups show just how terribly React is designed. We’re all learning it because it’s big not because it’s good. These frameworks promise but don’t deliver 2-way data binding in anything but the most trivial primitive examples.
Correction (1:21) - First put the returned array from users.concat(newUser) in a new variable (i.e. newUsers). Then pass it to setUsers: setUsers(newUsers).
i need to learn to read pinned first lol, beautiful video
You beat me to it. Haha
6th example is a incorrect example and less performant one, the explanation is also wrong, but the advise is correct,
same goes for 7th example too, tanstack query also uses useEffect, it just got abstracted away, again explanation is incorrect , but advise is good, this video has 60K views, so may be try to put a overlay text, so that your audience is not miss informed
Using indexes as keys is not always a bad idea. If the set of items is known and never changing, there’s no reason you shouldn’t be able to use the index. It may be an anti-pattern in most cases but if you know when it is fine to use, just keep that in mind and do it.
Well that's what I thought.
Then I found myself using them in multiple positions in the same app (rendering more than one list using indexes as keys).
And I had that warning then a bug that it failed to render properly.
There's no written rule that you can't, but only do it if you're doing it only once through the whole app.
@@mustafawagih3429Well, technically, you can. According to the definition of “Unique” - A key cannot be identical to that of a sibling component.
Use ESLint and it would tell if the index is "OKAY" for the key or not
its important to know that UseEffect runs TWICE after mount, but only on dev enviroments with strict mode on.
I learned that after hours of debugging...
same, had to debug it to find the culprit :D
What’s the reason?
@@kid1412621 It's a feature of Strict Mode, it's meant to encourage you to follow the guidelines and good practices
@@karolbielen2090 it's meant to encourage you to implement the workarounds needed to fix React's own failures*
5:51 i don’t recommend adding count to dependency array in this case.. as we can always use the previous value of the state inside setState and use that instead of directly using count
Explain Please
@@NamesAreVacuous setCount(prv => prv + 1 );
@@NamesAreVacuous
You can pass a function to setState(). This function has the correct state value as a parameter.
Instead of setCount(count + 1), you can do setCount((previousCount) => previousCount + 1).
const [count, setCount] = useState(0);
useEffect(() => {
const intervalId = setInterval(() => {
setCount((previousCount) => previousCount + 1);
}, 1000);
return () => clearInterval(intervalId)
}, []);
Althought what you wrote is true, keep in mind this is just a very simple example. In a real world case you caould be using a completely different state variable or some derived value.
6:41 I agree a simple fetch call in a useEffect is a naive approach and Tanstack query is great, however how do you think they implement this under the hood? Also using useEffect. Much in the same way it also starts requesting the data after the component renders.
Correct, Tanstack Query doesn't fix all the problems of data fetching in React. It does have patterns like prefetching and suspense mode, however, which allow you to render-as-you-fetch. Every pattern has its tradeoffs.
For the "Keys Should Actually Be Unique" part, the purpose of this is list ordering. E.g. if you use a non-data-derived `index` as the key and the list order changes, the renderer won't know and it will not update correctly. If your list is not changing order, it's fine to use an index. Also, it only needs to be unique per parent - so you can e.g. have identical keys in two separate lists rendering as long as those lists have a different parent.
The useEffect code at 5:48 will be constantly setting and clearing intervals. Might as well use a timeout for that. A better approach would be to keep the dependencies array empty and use function to update the state setCount(oldCount =>oldCount +1).
Honestly, this person produces some of the cleanest videos on React concepts. I am amazed how he makes the videos look simple yet packs it with quality information. Keep it up 🫡
React Router 6.4 data loaders allow you to fetch data on the route level, so that is another approach to consider alongside solutions such as Tanstack Query and SWR.
The example at 1:21 doesn't work as well, you are not calling setUsers with the new array created from the concat metod so that example wont do anything just like the faulty example. To solve it use the result from the concat method as the argument in setUsers :)
Thanks for catching that. Missed that in the edit. The spread operator example is correct though. Check my pinned comment
Idk how I feel about "just use dedicated hooks to fetch data like swr, react query, or other library." It's alright to make the code work for now, but we introduce vendor lock-in to the project, a haunting tech debt that will lead us to long hours in the long run. However, I also agree that we shouldn't freely use the clunky-ass, hard to understand useEffect.
To mediate this problem, I would introduce a context that contains the interface of "useDataFetcher," which is used by the components. The implementation is decided once at the top of the component tree, and this is where we the vendor hooks like swc and react-query are passed.
It's not a perfect solution, as there is an extra layer of indirection now between the components and the vendor hooks, making it overkill for small projects. However, it will ease the whole process of migrating from one library to another.
what a god tier video, i even not understand a react basic until i watch this video. great video!
i already know all of this right now, but i wish i saw this video 2 years ago. Btw thank you so so much. Keep it up ! Peace
Good points and summary; However, the useEffect with a fetch does allow the component to render and TanStack Query under the hood uses useEffect. Sure it should be used for other benefits, but implying at the end that useEffect prevents rendering is not accurate.
Loving the channel
2:38 why shouldn't you use states for stuff that needs to be rendered tho
Is it purely because of it's async nature or what
bc it's unnecessary. If it will be rendered, it will be recalculated on render anyway
Love the tips here. Even an experienced dev can learn some things. But, I think useEffect is getting a bad rap. React was originally designed to fetch data after a component is rendered, so you'll always have some type of loading state, regardless of the library used. I wouldn't necessarily call that a "bad" UX. If you need the data earlier, then SSR is the way to go.
If I'm using Next.js with app router, I like fetching data on the server in a React Server Component. If I need something more complex and across client components, I like Tanstack Query. I think each choice has its tradeoffs.
It said the component will rerender when the props change but I think a component only renders when a parent component renders due to a state change. Props changing does not cause a re render right?
indeed
A video on suspense 👀?
Can anybody share your experience of his bootcamp!?
These are great! Thanks!
Also, this feels like an advert for React Query. No complaints, though. ;)
hey men i really love the like your video it is deep and very helpful but right now i really struggle about file management like every time when i want to do some practice i always install react app again and again specially i am very confused by the installation of necessary files like nodemon , express ,node ,buble and run my file on terminal and like so on things really hard for me so can you make a tutorial video on how to handle files and folders, do we have to install every time when we want run our app or so many things please?!
The thing about not using indexes for keys flat out is a bit silly and you're doing yourself a disservice if you take it at face value. This tip is very commonly shared as an axiom, but it is really not. In many cases, indexes are perfectly safe as keys, especially when the array you're rendering won't change or it will only grow at the end but not shuffle or grow at the beginning / in the middle.
dude, i just came across your channel, great content, can you increase the frequency of videos ?
I'm on it!
Insightful💡
Could you please create a video on JavaScript Data Structures and Algorithms
Please do one for JavaScript too. You can't live React without JavaScript too. Waiting for it eagerly...
Blowing app your project with extra libraries it is not good either.
You do not really need, for instance, React Query to perform fetching data unless your case is very specific.
React query provides so many cool benefits like the stale while revalidate pattern or whatnot. I'd use it in every project.
please make video like this for next js 14 before all thanks for your videos
life is much easier with svelte
Life is much easier when you just use react the way you’re supposed to use react
rich harris is the goat
@@JakeLuden Using React the way you're supposed to is much more cumbersome than using Solid or Svelte
what about fetching data in server side using nextjs and server actions
I'll do some Next.js videos to cover that
pleas manke this types of vlideo more it actualy help to understand concept very great
That was a good video I liked it
You seriously are very underrated.
Conclusion: I can't wait for Solid to become the standard
Man, you don't even speak my language and I understood every word you said, thanks
Best explanation I have ever seen for React.❣
hi can u make a vid like this on NextJs
We need more tutorials about DSA
State must be immutable ... unless you are using a state management tool like mobx
Please turn on the dark mode
JavaScript is the Wild West, thus the large number of frameworks people write to make JavaScript more usable.
6th example is a incorrect example and less performant one, the explanation is also wrong, but the advise is correct,
same goes for 7th example too, tanstack query also uses useEffect, it just got abstracted away, again explanation is incorrect , but advise is good
next video on next js Thanks
nothing will happen at 1:14 either lol
Typo on my part. See the pinned comment
same bro , immutable mutable 🤷♂🤷♂🤷♀🤷♀😂😂
I really don't understand why immutability was pushed so hard with React. It's JavaScript. It's single threaded. It can only perform a single action at a time. What race condition are we protecting against exactly?
i think it has to do with virtual dom because when you mutate array or an object it still references the same address and virtual dom needs a new value to cause re render which only happens if you make a deep copy of the array\object
because React can't track such changes for reconciliation. The culprit is the concept of VDOM. Biggest mistake the React team did.
If you want React without the immutability bs you can use SolidJS.
@@giorgikochuashvili3891 that makes sense.
Not sure why you keep saying it's bad to use useEffect to fetch data and to use libraries instead. They use useEffect under the hood - It's just abstracted.
Saying this to junior devs and not clarifying that is kind of pathetic imo.
Pls make in Hindi language
When will you learn english, you know coding requires english
why should he learn Hindi just for you
These hangups show just how terribly React is designed. We’re all learning it because it’s big not because it’s good. These frameworks promise but don’t deliver 2-way data binding in anything but the most trivial primitive examples.
Number 8: don't use react. The year is 2024, there are better options available
Nextjs? Lol
Angular
@@dereksnipermumps
@@dereksniper Solid, the code is basically React without the bs
R19 use(…) hook & ;)