We banned almost all margins from our styles and it is a blessing. It's (almost) always a bad Idea to add a margin to a component to "create spacing". When there needs to be space between components we always use flex containers with a gap defined between the items. We found that this is very consistent with how a designers thinks about the design and it makes components easily have different spacing in different contexts. The spacing between items should always be defined be the parent, not by the items themself.
This concept of ditching the margins from HTML I believe was first made popular by Max Stoiber in 2020 in the article "Margin considered harmful", a read which I recommend to anyone interested in the idea. There's also a video by Theo Browne, former Twitch developer, titled "The Horror of Margins in CSS" in which he ellaborates a bit more on the problems of margin, and Adam Argyle's (Chrome CSS Developer Advocate) prediction that the usage of margin will decline as the gap property becomes more widely adopted in all-flexbox-and-grid situations. Highly recommend these.
@@dncdan Good pointers, must read for people that need to implement reusable components. A margin is basically a side-effect that breaks composability and react is all about composability. We have yet to encounter a layout requirement that can't be implemented using just padding and flex/grid + gap. It becomes second nature fast and you will almost guaranteed not look back.
This is by far the best practical educational video I’ve ever watched. I’m a senior CS major, and if I had videos like this sooner, I’d have 20x the experience I need.
@@okkashaally2115 Not that great, i sent my resume to 5 or 6 companies and half of them rejected it, and half of them didn't even read. And the scary part is my university is going to start very soon. i don't know what to do...
Wish this video was available back when I started with React. I had to learn all the things shown here the hard way. Nevertheless, I enjoyed it very much. Keep up the good work!
As a Jr dev that came from a boot camp, I really appreciate this advice. The library folder with your utils, types, and hooks is a new concept to me. Learning about the Children pattern to avoid prop drilling is an idea I never knew about. I saw {children} being used in applications but never understood it before. Still got half way to go in the video, but I really appreciate your advice so far! The application I have been building for the past few months will benefit greatly from these ideas!
Simply just looking at the source code of well-respected open source projects (e.g. the Node.js official website) helped me to learn immensely. A lot of times when I implement a new feature I do searches of terms or packages on GitHub to see how other people do it (e.g. I did this for the web-vitals library recently - how do others implement that package?). Then you can take the parts you like from how others do it and fit it to your own needs.
watched this on/off for a week while having down time and it was well worth it. quite a long vid but you really do cover so much of the fundamentals. im glad i follow a couple of these rules already but i have like 12 more to improve on lol. also somehow never noticed i could use two useEffects back to back. i dont think it came up, but will look to see if i can separate some
20:31 about making the main tag and the div surrounding everything, a component: You could make a component, that takes childelements and displays them, so that you can still have the internal stuff in the App.tsx file.
On components which is topic number 3, for the main tag which is the container of the different components (Header, TodoList and Sidebar) you can also create a new component for it and just put it on the same file, just pass the 3 sub components as children so it is still visible, and cleaner to read.
wow. this is useful even if you have years in this. i have 8 years developing, I'm considered senior in my job, and this tips are very valuable, accurate and helpful. thanks
Some nice refreshers here, even for a seasoned developer. Oftentimes one might forget some patterns if one stays away from React for enough time. And the section on performance optimization is also valuable. Hopefully React will eventually streamline most of these manual memoization hooks and dependency arrays. They've always been a pain for everyone.
Excellent content! 48:30 I have a doubt about this pattern, in that case the jsx inside the Sidebar component (same with the other cases) is just a div, with some styling, it is not actually a Sidebar component. Does that make sense? (I understand that maybe this approach is only possible on non-reusable components, and in this case we can ignore that the content inside the component is not complete.)
Best content!, I have learnt a lot! Thanks😀 just one question if a parent component re-renders, the child component will also re-render. How can a children pattern prevent this behavior? Would you please explain? That would be a great help!
Regarding an example you use to illustrate rule no.4: within the component you have the logic that conditionally renders a button or buttons, depending on state (isAuthenticated). When I used this pattern at my job, my more experienced coworker called it an antipattern, because, in his opinion, it violates the Single Responsibility Principle. What pattern should we use in 2024 to separate that kind of logic from the component? Two components and a module with the logic?
@22:30 probably a skill issue, but I've always found that using props to apply styles always sounds great, but is annoying in practice - so like you've passed 'secondary', but what if you want that secondary button to change color at different breakpoints? sure, add media queries, but now your secondary button is coupled to the design of the page you're using it on. i often just find myself passing a larger tailwind class. shadcn even gets this wrong (as far as I can tell at least), not allowing classNames to override variant styles
I don't understand how saving input value in state is considered best practise. Why do you want to rerender on every keypress when you have access to the formdata on the submit event?
Typescript can be a pain sometimes, when you are trying to get something out the way, you want to scream leave me alone; but it improves yourself as a developer as you add an extra layer to how you think when you are creating something. Like yourself, I too get frustrated when I see tutorials without it.
@@jasonwhittaker3940 When you're working in a team on a bigger project, I'd say TS is essential. I was just helping out on a project that was written only in JS and it was hell, debugging was a true ordeal and without TS you don't even have fully functioning intellisense, so it's good to use it imho.
At 21:00 i see that we are using inline styles but doesn't it them makes it difficult to fix something if a component is deeply nested and on the devtools we just see styles defined but don't know in code where the component is. Is there a way better way to manage tailwind??
Great video, but in 1:24:00 i am confused about the todos in the useEffect depndency array todos is an array meaning its an object type not a primative type and my understanding is useEffect can know if primative value chnaged but cannot know if a object value chnaged so it will always run on each render in this case sense the todos array is an object type not a primative type please correct me if i am wrong and keep up the great work ❤
for aggregates like array and object it looks at the reference i.e. memory pointer, not the values within the array or object. (Although in useState([]) a new empty array is created on every re-render and passed into useState, it isn't actually used on any but the first render. )
If you make everything its own components then when you want to test them for example using React Testing Library then there are too many components to test ? Wouldnt it be more complicated to test ?
Isn't it better to have a folder of them? For example, when I do nextjs projects, I create a folder called actions in that directory with all actions related to that route, is that good a practice?
What if instead of creating a button component you just create a style in css? I think it makes more sense? The buttons do have the same design but their usage differ, so I would assume it’s the case of creating a css class to button…?
Yes, it's mainly css which handle designs but you have different variants of buttons and conditionally apply classes on button. We have variants such as style, size, icons etc
Another option for #13 is just keeping track of which item is selected with a boolean inside the primary state, such as adding active: true to the selected object, especially if you are keeping track of multiple selected items, little more complex but a good solution compared to using an array of Id's. Great video, very informative.
What’s wrong with using a global CSS file for things like h1? Then you can just add className without all the machinery. Why do Tailwind users seem to avoid all css? What’s the science or philosophy with these practices? Thanks!
Why don't you keep your state, types and hooks relevant to only one feature together? I found that working on a feature and having to find related files across the folder structure is very jarring and slow. If you have a feature folder and have everything together, possibly with a naming convention for files, it shortens your lookup time considerably.
nextJs + Rtk = serverside or client side video please if we dont use rtk how to write code for CRUD in Nextjs for same app if we use rtk how to write code for CRUD in Nextjs for same app what is diffrence how to deal mega app in Nextjs
Hep dear ByteGrad ! Thank you for your awesome content as always ! I don't think you'll find time to answer my newbie question so anybody knows what vscode theme he's using ? Thanks again for your videos !
We banned almost all margins from our styles and it is a blessing. It's (almost) always a bad Idea to add a margin to a component to "create spacing". When there needs to be space between components we always use flex containers with a gap defined between the items. We found that this is very consistent with how a designers thinks about the design and it makes components easily have different spacing in different contexts. The spacing between items should always be defined be the parent, not by the items themself.
That's a very, very interesting argument. I'll have to dig deeper into that because I have run into issues due to margins.
I do this and it's so effective.
This concept of ditching the margins from HTML I believe was first made popular by Max Stoiber in 2020 in the article "Margin considered harmful", a read which I recommend to anyone interested in the idea. There's also a video by Theo Browne, former Twitch developer, titled "The Horror of Margins in CSS" in which he ellaborates a bit more on the problems of margin, and Adam Argyle's (Chrome CSS Developer Advocate) prediction that the usage of margin will decline as the gap property becomes more widely adopted in all-flexbox-and-grid situations. Highly recommend these.
Agreed! Spacing is a parental task 😁
@@dncdan Good pointers, must read for people that need to implement reusable components. A margin is basically a side-effect that breaks composability and react is all about composability. We have yet to encounter a layout requirement that can't be implemented using just padding and flex/grid + gap. It becomes second nature fast and you will almost guaranteed not look back.
This is by far the best practical educational video I’ve ever watched. I’m a senior CS major, and if I had videos like this sooner, I’d have 20x the experience I need.
I like how straight to the point you are. I am senior frontend dev, but i just purchased your course for support. Keep it up :)
Awesome, appreciate it! Enjoy
I'm going to get a job as a front end developer and I wanted this video exactly right now, thanks man!
How did it go buddy?
tech market sucks atm m8, good luck tho
@@okkashaally2115 Not that great, i sent my resume to 5 or 6 companies and half of them rejected it, and half of them didn't even read. And the scary part is my university is going to start very soon. i don't know what to do...
UA-cam lacks these kinds of videos! Because they're so awesome! 😃 Good job ByteGrad!
This video was awesome. I didn’t even notice that it was over an hour I was so interested. Can’t wait to try and put these in practice.
Loved it! Need more "best practices videos" about different stuff. Thanks!
Wish this video was available back when I started with React. I had to learn all the things shown here the hard way. Nevertheless, I enjoyed it very much. Keep up the good work!
As a Jr dev that came from a boot camp, I really appreciate this advice. The library folder with your utils, types, and hooks is a new concept to me. Learning about the Children pattern to avoid prop drilling is an idea I never knew about. I saw {children} being used in applications but never understood it before. Still got half way to go in the video, but I really appreciate your advice so far! The application I have been building for the past few months will benefit greatly from these ideas!
Good luck on your journey learning React!
Simply just looking at the source code of well-respected open source projects (e.g. the Node.js official website) helped me to learn immensely. A lot of times when I implement a new feature I do searches of terms or packages on GitHub to see how other people do it (e.g. I did this for the web-vitals library recently - how do others implement that package?). Then you can take the parts you like from how others do it and fit it to your own needs.
watched this on/off for a week while having down time and it was well worth it. quite a long vid but you really do cover so much of the fundamentals. im glad i follow a couple of these rules already but i have like 12 more to improve on lol. also somehow never noticed i could use two useEffects back to back. i dont think it came up, but will look to see if i can separate some
This might be the most useful React video ive seen. Great work!
20:31 about making the main tag and the div surrounding everything, a component: You could make a component, that takes childelements and displays them, so that you can still have the internal stuff in the App.tsx file.
True
On components which is topic number 3, for the main tag which is the container of the different components (Header, TodoList and Sidebar) you can also create a new component for it and just put it on the same file, just pass the 3 sub components as children so it is still visible, and cleaner to read.
wow. this is useful even if you have years in this. i have 8 years developing, I'm considered senior in my job, and this tips are very valuable, accurate and helpful. thanks
Very nice video, ByteGrad. What about making a video on how you test your react & nextjs applications ?
Good idea
@@ByteGrad yes please ♥
Yes
Yeeeees!!!
yes Agree
Thank you so much for this video! It is incredibly helpful. We appreciate your work 😊🤝
This is real gold. Thanks for explaining this to us and showing every best practices with example. This is very helpful in may ways. ❤👍
Amazing. I want more best practices like this.
Sir, You make always a great tutorial ! Awesome work
The level of this course is perfect. Simply explained but covers the detail needed. Do we have github repo available so we can look at the code?
Great video! You are sharing very useful information. Thank you!
Amazing Guide to all newbies. Thank you so much.
There were some really useful advice in video 👍 out of all the front end frameworks I've had experience with, React is by far my favourite
@19:15 - you might not be reusing them in the project, but it also makes reuse across projects easier :) Cool video, thanks!
Loved it, just great! Thanks so much for this.
Would love to see a video on good coding patterns to use in React or Next and also coding principles, like SOLID and more
Another one is using a progression of multiple useState-> single useState object -> useReducer to manage a component that grows in complexity.
Some nice refreshers here, even for a seasoned developer. Oftentimes one might forget some patterns if one stays away from React for enough time. And the section on performance optimization is also valuable. Hopefully React will eventually streamline most of these manual memoization hooks and dependency arrays. They've always been a pain for everyone.
thank you for sharing this valuable information 🙏
Excellent content! 48:30 I have a doubt about this pattern, in that case the jsx inside the Sidebar component (same with the other cases) is just a div, with some styling, it is not actually a Sidebar component. Does that make sense? (I understand that maybe this approach is only possible on non-reusable components, and in this case we can ignore that the content inside the component is not complete.)
Best content!, I have learnt a lot! Thanks😀
just one question
if a parent component re-renders, the child component will also re-render. How can a children pattern prevent this behavior? Would you please explain? That would be a great help!
Great content. Learned a lot. Thanks for the video, cheers.
hi, you can use import classnames from 'classnames'; its a function that allows to merge classnames just like your cn function
Thank you for this video!!!
It is very practical.
I like the way you explain things. More videooos
Thank you Wesley! Very much appreciated! 🙇
Great video, btw what VS Code theme is this?
the kind of videos that are really useful!
A good one, thanks! Maybe only 1-2 points were new to me, does it mean that I am already good at React? 😅
Really good content man!
Regarding an example you use to illustrate rule no.4: within the component you have the logic that conditionally renders a button or buttons, depending on state (isAuthenticated). When I used this pattern at my job, my more experienced coworker called it an antipattern, because, in his opinion, it violates the Single Responsibility Principle. What pattern should we use in 2024 to separate that kind of logic from the component? Two components and a module with the logic?
Yeah for "login" and "logout" button components specifically the isAuth var check should obviously be within those components.
Thanks for this.
great list
Thanks. Your explanations are clear and helpful.
@22:30 probably a skill issue, but I've always found that using props to apply styles always sounds great, but is annoying in practice - so like you've passed 'secondary', but what if you want that secondary button to change color at different breakpoints? sure, add media queries, but now your secondary button is coupled to the design of the page you're using it on.
i often just find myself passing a larger tailwind class. shadcn even gets this wrong (as far as I can tell at least), not allowing classNames to override variant styles
Great video, thank you!
You're the best man
I love your videos
Awesome video, loved it :)
Thanks Byte Grad for your contents
@ 1:04:59 why not just create your handler functions outside of your component function and use dependency injection to inject the setter function in?
One questions to the H1 class issue chapter 5:
I’ve always used template literals to add classname props like
At 32:24 can't we use back ticks `${}` instead of seperate utility function ?
I had the same question, but I think it's not going to work to pass className props to tailwind className.
Great video, thanks 🔥
Great content!
it's a good practice to handle modals in the child component to prevent re-rendering other childs if you open it on parent component
This video is a real gem! Thanks for all the tips! It will help a lot of people to use cleaner practices.
1:03:56 As we learned from you before, it would probably be better to use [todos.length], due to the value / reference difference, right?
thanks for
best tutorial
I don't understand how saving input value in state is considered best practise. Why do you want to rerender on every keypress when you have access to the formdata on the submit event?
Can u tell me what is the best way to do this ?
I try to stay away from saving formdata in state unless I absolutely have to and use the submit event formdata.
I can't say that is the best way, that's why I asked 🙂
you give a lot of food for thought
Good stuff, even for more senior devs.
I can't imagine coding anything without TS. Still very surprised someone out there makes tutorials without it.
Typescript can be a pain sometimes, when you are trying to get something out the way, you want to scream leave me alone; but it improves yourself as a developer as you add an extra layer to how you think when you are creating something. Like yourself, I too get frustrated when I see tutorials without it.
@@jasonwhittaker3940 When you're working in a team on a bigger project, I'd say TS is essential. I was just helping out on a project that was written only in JS and it was hell, debugging was a true ordeal and without TS you don't even have fully functioning intellisense, so it's good to use it imho.
Hi man! What are you using for AI autocomplete?
Regarding component folder structure - I kinda like doing Atomic Design Patterns
This is exactly what I am looking for
Your voice sounds great ngl
What theme you use
Love your content man
1:35:43 by the way conditional display of StartScreen component better to move from view to separate variable in component
Thank you so much
At 55:41 did you mean to put the form event in the arguments and not todocontent?
if you have flex use gap, easy tip to add spacing between components. no need for extra coding or anything.
At 21:00 i see that we are using inline styles but doesn't it them makes it difficult to fix something if a component is deeply nested and on the devtools we just see styles defined but don't know in code where the component is. Is there a way better way to manage tailwind??
what is the contexts folder for?
Great video,
but in 1:24:00 i am confused about the todos in the useEffect depndency array
todos is an array meaning its an object type not a primative type
and my understanding is useEffect can know if primative value chnaged but cannot know if a object value chnaged
so it will always run on each render in this case sense the todos array is an object type not a primative type
please correct me if i am wrong
and keep up the great work ❤
for aggregates like array and object it looks at the reference i.e. memory pointer, not the values within the array or object.
(Although in useState([]) a new empty array is created on every re-render and passed into useState, it isn't actually used on any but the first render. )
0:05 we really need to do what ?
MASTER IT 😀
If you make everything its own components then when you want to test them for example using React Testing Library then there are too many components to test ? Wouldnt it be more complicated to test ?
I have a questions. Is it possible that in the H1 component destructure className = ‘ ‘ like this and pass it into the other tsx file ? 33:20
thank you, mate
Isn't it better to have a folder of them? For example, when I do nextjs projects, I create a folder called actions in that directory with all actions related to that route, is that good a practice?
What theme and extensions are you using in this video?
1:25:41 Not sure whether it is a good idea to use array (reference data type) as dependency in useEffect
Although in useState([]) a new empty array is created on every re-render and passed into useState, it isn't actually used on any but the first render.
What if instead of creating a button component you just create a style in css? I think it makes more sense? The buttons do have the same design but their usage differ, so I would assume it’s the case of creating a css class to button…?
Yes, it's mainly css which handle designs but you have different variants of buttons and conditionally apply classes on button. We have variants such as style, size, icons etc
Another option for #13 is just keeping track of which item is selected with a boolean inside the primary state, such as adding active: true to the selected object, especially if you are keeping track of multiple selected items, little more complex but a good solution compared to using an array of Id's. Great video, very informative.
Nice, Thank a lot.
1:21:30 how do you access URL query params?
ua-cam.com/video/ukpgxEemXsk/v-deo.html found it
31:00 why use utils when we can do className={`default-styling ${className}`}
What’s wrong with using a global CSS file for things like h1? Then you can just add className without all the machinery. Why do Tailwind users seem to avoid all css? What’s the science or philosophy with these practices? Thanks!
Why don't you keep your state, types and hooks relevant to only one feature together? I found that working on a feature and having to find related files across the folder structure is very jarring and slow. If you have a feature folder and have everything together, possibly with a naming convention for files, it shortens your lookup time considerably.
nextJs + Rtk = serverside or client side video please
if we dont use rtk how to write code for CRUD in Nextjs for same app
if we use rtk how to write code for CRUD in Nextjs for same app
what is diffrence how to deal mega app in Nextjs
Nice guide. I mean I know it is gonna be nice.
Ha, enjoy!
Thanks
Is the classname needed to be so verbose or is best practice to leave it verbose instead of moving all the style to another file?
please consider REACT UNIT TESTING also your future videos
No github links in description? That's like the most important thing you can do.
46:49 props drilling not so bad, because we still have readability, on other side we put everything as children which looks like awful…Am I wrong?
nice to see how generic programming best practices translates to react because react components are just functions.
1:09:12 short recap
Why do you use typescript in a tutorial video without using its features?
A habit
Hep dear ByteGrad ! Thank you for your awesome content as always ! I don't think you'll find time to answer my newbie question so anybody knows what vscode theme he's using ? Thanks again for your videos !
Hello Guys, at 7.55 we can see he auto import the variable "max free todos". Can someone tell me how we do that ? Tanks.
My first thought was “why React 17? (Not 19)” 😊
worth watching
Enjoy!