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.
@@agoristic 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...
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
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!
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.
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.
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.
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.
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!
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.)
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.
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.
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
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. )
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 !
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?
3 месяца назад
No github links in description? That's like the most important thing you can do.
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 ?
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 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
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
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 😁
@@agoristic 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'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...
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
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
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!
RUclips lacks these kinds of videos! Because they're so awesome! 😃 Good job ByteGrad!
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.
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.
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
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!
Check out Feature-Sliced Design (Architectural methodology for frontend projects). Design patterns: compound components, render props.
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.
Another one is using a progression of multiple useState-> single useState object -> useReducer to manage a component that grows in complexity.
Loved it! Need more "best practices videos" about different stuff. Thanks!
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?
This might be the most useful React video ive seen. Great work!
@19:15 - you might not be reusing them in the project, but it also makes reuse across projects easier :) Cool video, thanks!
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.
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
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!
Would love to see a video on good coding patterns to use in React or Next and also coding principles, like SOLID and more
hi, you can use import classnames from 'classnames'; its a function that allows to merge classnames just like your cn function
Amazing Guide to all newbies. Thank you so much.
Sir, You make always a great tutorial ! Awesome work
Great video, btw what VS Code theme is this?
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
Amazing. I want more best practices like this.
This is real gold. Thanks for explaining this to us and showing every best practices with example. This is very helpful in may ways. ❤👍
Thank you so much for this video! It is incredibly helpful. We appreciate your work 😊🤝
Your voice sounds great ngl
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 is exactly what I am looking for
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.)
you give a lot of food for thought
Thanks Byte Grad for your contents
thank you for sharing this valuable information 🙏
Thank you Wesley! Very much appreciated! 🙇
Great video! You are sharing very useful information. Thank you!
Loved it, just great! Thanks so much for this.
thanks for
best tutorial
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.
Great content. Learned a lot. Thanks for the video, cheers.
if you have flex use gap, easy tip to add spacing between components. no need for extra coding or anything.
Thanks for this.
great list
Thanks. Your explanations are clear and helpful.
the kind of videos that are really useful!
This video is a real gem! Thanks for all the tips! It will help a lot of people to use cleaner practices.
Thank you for this video!!!
It is very practical.
I like the way you explain things. More videooos
You're the best man
I love your videos
Really good content man!
please consider REACT UNIT TESTING also your future videos
Great video, thank you!
Hi man! What are you using for AI autocomplete?
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.
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.
Thank you so much
thank you, mate
Great content!
nice to see how generic programming best practices translates to react because react components are just functions.
1:35:43 by the way conditional display of StartScreen component better to move from view to separate variable in component
@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
Awesome video, loved it :)
One questions to the H1 class issue chapter 5:
I’ve always used template literals to add classname props like
Thanks
Great video, thanks 🔥
What theme you use
0:05 we really need to do what ?
MASTER IT 😀
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. )
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?
My first thought was “why React 17? (Not 19)” 😊
Nice, Thank a lot.
worth watching
Enjoy!
1:09:12 short recap
Nice guide. I mean I know it is gonna be nice.
Ha, enjoy!
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 !
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.
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?
No github links in description? That's like the most important thing you can do.
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 ?
What theme and extensions are you using in this video?
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??
At 55:41 did you mean to put the form event in the arguments and not todocontent?
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
@ 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?
Love your content man
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
the best
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’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.
1:21:30 how do you access URL query params?
ruclips.net/video/ukpgxEemXsk/видео.html found it
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?
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
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.
31:00 why use utils when we can do className={`default-styling ${className}`}
58:00
avoiding constants and hard-coded values are just basic programming principles, and not really much to do with react best practices.
"primary" | "seconday" ... this is literal type, not union type ... no? Cause it's union of values and not of individual types ...
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?
Use react query.