Zustand is an amazing library, I worked on a react project which used React Query in combination with Zustand and let me tell you they worked together amazing, I am very happy that Zustand is gaining the popularity it deserves.
Agree with everything here, except the last one in some scenarios. If you have a custom design which isn't already based on a library like MUI, it can be a real pain to customize the components to match your design. Great video! My preferred approach for custom designs is taking advantage of "headless" libraries such as Headless UI, Radix, and React Aria.
i'm on the same boat as you, but i think that one specific "dont" is aimed to either new devs or devs that dont focus too much on front end. for those ppl, things like MUI helps a lot.
Currently building a small project to learn react (and apollo) so I'm very thankful for such guidelines, thank you both (and I swear I will learn typescript more and add it to my project... soon)
This format is totally working if it can bring in heavyweights like Jack. His channel has pretty awesome advanced React, TS videos. Bring in Dave Gray next with a frontend, backend or fullstack tutorial 😅🙏
10:06 small correction - the question mark is called an optional parameter. It is equivalent to saying: put whatever type I define or undefined (e.g. someVar?: string === someVar: string | undefined). So when putting null under the address variable explicitly, typescript will complain
I am newbie, and this kind of error scares me to use typescript. I know I should learn how “null” and “undefined” are different, but what is the solution for this ?
@@tadakuniyasuda8214 better not to avoid using it. When you start writing a code with Typescript and get used to it, you won't probably want to come back. I tried to maintain a relatively big project purely written in Javascript both on frontend and backend. Man, there were so many bugs that could easily be identified during compilation. Generally, undefined means that something is missing. Simple example is when you want to access any variable from empty object. Null usually means that something is defined but its value is nothing. So my point here is you should not put undefined explicitly under variables as a value, prefer null instead. However, when defining types or interfaces, it really depends on your code what you expect it to do
This last tip was amazing. It clicked with what I have seen in many projects but it's not entirely on the engineering team. Material UI, bootstrap, etc are really hard to tweak bc most of their CSS has the "! important" attribute. But designers tend to want to leave their special mark on the layout "just because". If you are building software at the MVP stage I can't stress enough to use an UI library and follow along the design guidelines for that specific library. When the app core is set, then you can spend the resources to build your own design system and ui library but doing both on a tight budget when you don't have a clear picture of the software architecture is pure madness. Can't tell how many projects would have been spared from chaos by following this simple advice
The first time I learned ReactJS was from Bob Ziroll. Bob's a clear guy, you can understand crystal clear from him. Unfortunately I couldn't find a ReactJS course from him on Udemy. This video is a blessing from Brad, thanks Brad ❤.
Surprised me when I click on this and someone else started talking to me. Thank you, this was actually really cool to watch. I've been working with react for not that long and Jack is a great teacher
Extremely excellent summary of the primary things to pay attention to when working with React! Really well presented and easy to follow. Thanks Jack! Subscribed! 👍
Agree to all of them except the UI one, I have encountered multiple cases where libraries do not cover the design team requests. Mostly all of the time it is better to organize well your code
I didn't have idea you are on Brad's channel until you thanked Brad in the end. I picked up this video from notification just by reading title. Thank you both of you.
I am a novice, I just finished a 12 week coding bootcamp where MERN was our final project stack, this type of content is really useful for someone in my position because I went from having my skill development be 100% directed by an outside influence, to being 100% my responsibility, this will help me gain a little bit of that structure back and give me a set of skills to reach for next. I cant say I understood 100% everything, but I understood enough of each subject to know what the first steps should be. I still have to review the course material because its so fast paced that no one could possibly absorb it all, I would be surprised if anyone was even able to absorb like 2/3rds of the material. But now I can review the course material and learn some typescript basics at the same time and see if I can translate the lessons from javascript to typescript. I think I am gonna try to redo my final project in typescript and see if I can follow all these dos and don'ts while I'm at it, that sounds like a fun next step. Cheers!
Good content! Props to ya guys as always One correction tho at 10:06. The questionmark like this in typescript means that the key can be missing so it's value is possibly undefined. If you also need to include null in the range of values, you'd want to use what's called enum in typescript like this: string | null So an example would be type TMyType = { myKey: string myAnotherKey?: string | null } const myVal = ({ myKey, myAnotherKey }: TMyType) => {} // accessing myAnotherKey would give you either undefined, or string, or null
I just got started in React and transitioning from a regular html/css/js developer. Things in React are just mind blowing. And I came here to avoid all the rookie mistakes and pro tip advances. Thank you soo muchh
Great video as always. :) I do think the last topic is very debatable. I've worked on many projects where building out a custom UI library/Design System made more sense. But that choice involves a lot of factors like the design itself, future plans for the app or the company and even who needs to work with it or maintain it.
i agree, it depends on the design the client wants, i worked in a project where we used Material UI but the design they wanted was so customized that we essentially had to fight with material ui components to look that way which defeated the purpose of using them in the first place.
@@rajatgupta2625 Yea I know that struggle. An existing UI library is great to work with, as long as you can mostly confirm to those existing components.
Loved the video. Only thing was that the usage of ? in typescript is to declare that the value will be undefined. If you want to declare a null you will have to actually set that type. Something like name: string | null
Mashallah! This is a great video @Traversy Media I have been following you keenly for somewhile and I can adhere that this is my best UA-cam Channel so far and it has thought me a lot a Software Developer. One day I am gonna develop a big website Inshallah. Big love from Kenya.🚀🚀😍😍
Typescript ugly???!!! Typescript is awesome!!!! Thank Jack, great video and also thanks Brad for inviting Jack. PS: I think that making your own UI library/framwork is not that bad and a great learning experience BTW
Thanks for the video, even though lots of the stuff you talk already explained even in older React docs (there's a beta one iirc). But main culprit I believe is, people rather than reading, try to use their knowledge from other libraries and frameworks, which make them misjudge how React works. Unlike many other, React has no magic tricks (except jsx), it is plain javascript and some clever stuff like hooks. So, if one knows any programming language, not just javascript and knows basics of React (which can be read from docs), it is pretty trivial task to understand what's going on. I'd say this is the gem of the React, it being a library this way. Anyway, again, thanks for your efforts. I've seen some people doing some of those mistakes even in production, which I think is unbelivable; so having videos like this really helps in that matter (atleast that's what I hope).
I had an idea to avoid working with logic in many components, for example, you have a dashboard screen that calculates a lot of information based on some requests to apis, each calculation is used in a different component, so it would be natural for you to create one component like ProfileStats, another RepositoryStats, and each component would have its own logic of fetching the data, then treating that data and finally displaying it, but in conjunction with the idea of "Do not think of function components as templates". I DO recommend that when you have this situation (process one or more information and then display it in a component) you create a custom hook to handle all the processing, then you create a component that displays this processed data, it is probably easier to test and easier to understand what you Is doing. Maybe it is like your advice to create custom hooks, but I would increment to make sure the "clearly defined components" to be just a stateless component, just receives all data they need and show it. const profileProcessedData = useProfileStats(); const repositoryProcessedData = useRepositoryStats();
15:36 we want to add the id to the dependency array as this might change. But I think that is then defeated by adding the conditional at 16:05 which will mean that when the id changes and the user existed from the first/previous id, the useEffect will run but the fetch and the setUser won't run and the user will not be correctly updated from the new id.
It is. I just wanted to make sure that folks check to make sure they aren't unconditionally setting stuff that they are depending on. Otherwise, boom, infinite loop.
This video really made me want to check out Jack's channel. It's very clear and pragmatic. I'm a bit lost with the useMemo examples because I would not do this kind of stuff with React. Derived data and stuff like that should be in a presenter in my opinion, not in the component, and if it's pure business logic, even more so. You can memoize a function without React, it's dead simple even without a library.
Hey man, for the memoization without react, you would use a closure function that checks and stores the arguments passed to it, and only calls the callback (component ) if the new args are different from the last? Also what is a presenter? Thanks!
@@deniyii yes, that would be a way to do it, although I don't know why you mention a component here. The callback can only be a pure function. If it has state or side-effects, you are not guaranteed that the cached result is the same for the same input. I usually call this kind of function `once` because it remembers only one input/output pair and replaces it every time the input changes. I also sometimes use `diff` which does a deepEquals comparison instead of a reference comparison, and I use `memo` when I cache many pairs in a `Map` and/or a `WeakMap` What I meant by "presenter" is a middleman sitting between the model and the UI component. The component is humble and do nothing other than pushing data to the screen. It does not compute sums or averages, it does not decide what buttons should be greyed out, how things are colour coded or whatnot, it takes a simple datastructure as input which has been generated by the presenter where all the decisions involving business logic have been encoded, and turns it into UI with no second though. Originally this pattern made the view easier to test, now testing frameworks have added complex tools to mount React components, query the DOM, etc. I don't like to use them to be honest, I prefer to write simple tests, have a good separation of concerns and have no business logic dependent on the view library.
@@ApprendreSansNecessite I see, so the presenter you speak of is a compound component that passes the computed data as props to another component that only renders the UI? If so isn’t using a custom hook a better pattern both for reusability and encapsulation? Also, I mentioned “component” to represent a function that returns JSX; isn’t that what’s being memoized? I’m thinking of it from how I assume React.memo works, but I’m not sure if that’s the same mental model with what you’re describing.
@@deniyii A presenter or a memo function have nothing to do with React, they are library agnostic programming patterns. A presenter can be a module or an object, which can be tested in isolation without having to bring React into scope (after all there is no DOM involved, why the need for React?). When you test a hook, you need to have this big test harness around it which nowadays is provided by things like testing-library/react, it makes you commit to React even more because not only did you couple your business logic with your view library (which is nonsensical) but you also coupled your tests with it, that is to say you can no longer refactor without breaking your tests. This is utterly wrong: tests should test the behaviour, not the design so that you can change the design and confidently rely on your tests to catch accidental modifications of behaviour. There is also no way you can convince your coworkers to change library or even to change the way you use it after that commitment, because it would be so much work to do. It is not agile, you should be able to make your architecture evolve over time. React is not Javascript, when you use `useMemo` the compiler does stuff that is not expressed in the code. A standard memoized function is not that, it simply takes an input, and if it's an input it has seen before, it returns a cached value instead of doing the computation again. That's it. And that's what we wanted: in the 19:35 example we are not concerned about rerendering, we simply don't want the sum to be computed again, no need for a hook, but as I said in my initial comment, if you have a presenter that computation would not even be in the component in the first place, the result would simply be a value you can pass as a prop. Now it also means that the return value of the memoized function is going to be identical, value-wise but also reference-wise, so if it's passed as a prop, React is also going to detect that and prevent rerenders if no other prop has changed. It's the same functionality but achieved with other tools than React tools: general programming tools. Now the way you use the presenter in your UI design is up to you, you could call it from a hook I guess, but then you would not test the hook, it would only be forwarding stuff to the presenter. Or you could use the connect API of react-redux and use memoization and presenter to map state to props It's just another way of doing thing, a way that is less dependent on the tools and that capitalises on your knowledge of the language you are using and programming patterns .
@@ApprendreSansNecessite thanks for this explanation. It seems I need to rethink my approach to building UI as I’m very much dependent on the tools provided by react to do things that can be done without tying myself to it. And while the react tools are incredible, I agree that it can make switching from react difficult. I would ask you though, at what point do you draw a line between using tools a framework offers you versus building your own thing? It seems like your process is geared towards preventing coupling business logic to the framework, but isn’t that unrealistic especially in complex applications?
hmmm I don't love external UI libraries since they apply many things to elements and its harder to overwrite later. I think dominating CSS should be enough to create accessible components pretty fast. But overall amazing video, thanks uncle Jack once again
You made a lot of good points but for bigger projects, I really do think you SHOULD build your own UI components. It avoids a lot of the magic involved with using third party UI libraries and gives you control over consistency of your design. And usually, you don't need to build a full library, you just need to build the components that you use, which is usually just a handful.
@@aeronwolfe7072 shacdn was not a concept I'm familiar with 9 months ago when i made this comment but that said, copying components from shacdn and customizing it counts as making your own components. It is not a library that you import for the exact reason that I'm outlining here
@@aeronwolfe7072 actually the whole ethos of shacdn is that you should have full control of your components and not use a ui library so "ugh shacdn" is really just reiterating what I am saying. Not only that, version 0.1 of shacdn was released months after I have made this comment. I could not magically recommend things that didn't exist at the time.
I agree with everything except the last, I think Implementing Design Systems on your own Using things Like tailwindCSS maybe with libraries like cva, clsx and tools like Storybook to test the components seperatly will make you a better Frontend dev.
If you want to share states between components without the hassle of setting up Context or Redux or any other external state management, you should look into "use-between" which provides these features, but using the states of custom hooks. I have totally replaced Context with this and it's much easier to deal with. Only the components that import the custom hook will be able to share states between them, hence "use-between." It's even better than Jotai since you're only using useState in custom hooks to share states.
![[Vol.64_Unit 05] Astronauts Stuck in Space (Preview)](http://i.ytimg.com/vi/n0KpFnsHLy8/mqdefault.jpg)
I want to thank Jack for letting me post this amazing in-depth video to my channel.
I want to thank YOU for having me on!.
I want to thank BOTH of you for sharing your knowledge
@@jherr currently I am watching No BS TS.😅😅😅😅😅😅. Thank you both of you.
I Love jack!
@@jherr thanks jack I subscribed in your channel you are very good teacher thanks brad also for hosting
You are first person to have any real arguments against using class components. I have been seeking then for a long time.
Thanks so much Jack and Brad for your amazing videos and the meaningful work you do. Very grateful for how much I've learned with you!
Zustand is an amazing library, I worked on a react project which used React Query in combination with Zustand and let me tell you they worked together amazing, I am very happy that Zustand is gaining the popularity it deserves.
Probably the most talented tutor on youtube for FE devs! Fantastic video Jack!
Agree with everything here, except the last one in some scenarios. If you have a custom design which isn't already based on a library like MUI, it can be a real pain to customize the components to match your design. Great video!
My preferred approach for custom designs is taking advantage of "headless" libraries such as Headless UI, Radix, and React Aria.
Regarding the last point, he didn't say don't make your own designs, he said don't make your own library
You can even customize your designs with Styled-Components in combination with libraries like MUI.
Or just opt for tailwind
HeadlessUI and Tailwind is my favourite combo, I've just started using and it's so cool and really easy to build components.
i'm on the same boat as you, but i think that one specific "dont" is aimed to either new devs or devs that dont focus too much on front end. for those ppl, things like MUI helps a lot.
Love both of you guys, helped me a TON, maybe even changed my future. Don't stop doing the awesome work!
Currently building a small project to learn react (and apollo) so I'm very thankful for such guidelines, thank you both
(and I swear I will learn typescript more and add it to my project... soon)
This format is totally working if it can bring in heavyweights like Jack. His channel has pretty awesome advanced React, TS videos. Bring in Dave Gray next with a frontend, backend or fullstack tutorial 😅🙏
I'd definitely vouch for Dave Gray
Definitely, Dave is one of the best teachers out here
10:06 small correction - the question mark is called an optional parameter. It is equivalent to saying: put whatever type I define or undefined (e.g. someVar?: string === someVar: string | undefined). So when putting null under the address variable explicitly, typescript will complain
I am newbie, and this kind of error scares me to use typescript. I know I should learn how “null” and “undefined” are different, but what is the solution for this ?
@@tadakuniyasuda8214 better not to avoid using it. When you start writing a code with Typescript and get used to it, you won't probably want to come back.
I tried to maintain a relatively big project purely written in Javascript both on frontend and backend. Man, there were so many bugs that could easily be identified during compilation.
Generally, undefined means that something is missing. Simple example is when you want to access any variable from empty object. Null usually means that something is defined but its value is nothing. So my point here is you should not put undefined explicitly under variables as a value, prefer null instead. However, when defining types or interfaces, it really depends on your code what you expect it to do
@@internet4543 Thank you, I am going to learn typescript now.
Great video, love Jack's content. Just want to point out that the `?` mark implies that the field could be `undefined`, not `null`.
This last tip was amazing. It clicked with what I have seen in many projects but it's not entirely on the engineering team.
Material UI, bootstrap, etc are really hard to tweak bc most of their CSS has the "! important" attribute.
But designers tend to want to leave their special mark on the layout "just because". If you are building software at the MVP stage I can't stress enough to use an UI library and follow along the design guidelines for that specific library.
When the app core is set, then you can spend the resources to build your own design system and ui library but doing both on a tight budget when you don't have a clear picture of the software architecture is pure madness.
Can't tell how many projects would have been spared from chaos by following this simple advice
The first time I learned ReactJS was from Bob Ziroll. Bob's a clear guy, you can understand crystal clear from him. Unfortunately I couldn't find a ReactJS course from him on Udemy. This video is a blessing from Brad, thanks Brad ❤.
Surprised me when I click on this and someone else started talking to me. Thank you, this was actually really cool to watch. I've been working with react for not that long and Jack is a great teacher
Extremely excellent summary of the primary things to pay attention to when working with React! Really well presented and easy to follow. Thanks Jack! Subscribed! 👍
Agree to all of them except the UI one, I have encountered multiple cases where libraries do not cover the design team requests. Mostly all of the time it is better to organize well your code
This is super helpful.Traversy Media thank you for bringing Jack here.He is awesome as usual.
This is really amazing, I’ve been postponing for a while and finally watched. I’m excited I did. Thanks Brad, thanks Jack!
I didn't have idea you are on Brad's channel until you thanked Brad in the end.
I picked up this video from notification just by reading title.
Thank you both of you.
I am a novice, I just finished a 12 week coding bootcamp where MERN was our final project stack, this type of content is really useful for someone in my position because I went from having my skill development be 100% directed by an outside influence, to being 100% my responsibility, this will help me gain a little bit of that structure back and give me a set of skills to reach for next. I cant say I understood 100% everything, but I understood enough of each subject to know what the first steps should be. I still have to review the course material because its so fast paced that no one could possibly absorb it all, I would be surprised if anyone was even able to absorb like 2/3rds of the material. But now I can review the course material and learn some typescript basics at the same time and see if I can translate the lessons from javascript to typescript. I think I am gonna try to redo my final project in typescript and see if I can follow all these dos and don'ts while I'm at it, that sounds like a fun next step.
Cheers!
Excellently handled all the matters.
Brilliant Editing.
Super clear video looks very high resolution.
Thank you both for being part of my growth in web development.
Love love LOVE Jack's content. Definitely great for stuff "beyond the basic" - Thanks Brad for letting him guest!
Good content! Props to ya guys as always
One correction tho at 10:06. The questionmark like this in typescript means that the key can be missing so it's value is possibly undefined. If you also need to include null in the range of values, you'd want to use what's called enum in typescript like this: string | null
So an example would be
type TMyType = {
myKey: string
myAnotherKey?: string | null
}
const myVal = ({ myKey, myAnotherKey }: TMyType) => {} // accessing myAnotherKey would give you either undefined, or string, or null
I like what you did with "Props"
Loved the video. The presentation was great. Thanks Jack. It was super easy to understand. Also, Thanks to Brad for bringing this video to us.
Golden words! Honest and to the point content by you Jack 💯. Thank you so much for everything you do for us Brad ❤💯
Collaboration of the year, thank you Brad and Jack 🙏
Jack is the best and an amazing person in real life. I do love your channel as well.
I just got started in React and transitioning from a regular html/css/js developer. Things in React are just mind blowing. And I came here to avoid all the rookie mistakes and pro tip advances. Thank you soo muchh
Jack good content as always. Been a subscriber for sometime, and it's good to see you on Brad's channel.
Great video as always. :) I do think the last topic is very debatable. I've worked on many projects where building out a custom UI library/Design System made more sense. But that choice involves a lot of factors like the design itself, future plans for the app or the company and even who needs to work with it or maintain it.
i agree, it depends on the design the client wants, i worked in a project where we used Material UI but the design they wanted was so customized that we essentially had to fight with material ui components to look that way which defeated the purpose of using them in the first place.
@@rajatgupta2625 Yea I know that struggle. An existing UI library is great to work with, as long as you can mostly confirm to those existing components.
thank you, Jack. It is really simple explanation of the mentioned topics.
Loved the video. Only thing was that the usage of ? in typescript is to declare that the value will be undefined. If you want to declare a null you will have to actually set that type. Something like name: string | null
I have been working on React for about an year or soo professionally. And I have been following most these recommend do's and don'ts. 👌👍
Woah! Great to see Mr. Herrington here on Traversy Media! The "crew" is getting more and more awesome!
I just started React a few months ago, thank you for the tips..
This video was very helpful, Thank you Traversy for bringing us this amazing video.
Great content. Thank you Jack and Brad😍❤❤❤
On point with the pronunciation of Zustand 💪 and thanks for the vid Brad & Jack 😀
So cool to see Jack here!
AMAZING VIDEO!
One addition might be that react does not use triple equals but uses Object.is().
Mashallah! This is a great video @Traversy Media I have been following you keenly for somewhile and I can adhere that this is my best UA-cam Channel so far and it has thought me a lot a Software Developer. One day I am gonna develop a big website Inshallah. Big love from Kenya.🚀🚀😍😍
Amazing clear explanations at a very pleasant pace
Very good explanation, great value for an entry level react devs
outstanding knowledge, great presentation, perfect video and audio
Typescript ugly???!!! Typescript is awesome!!!! Thank Jack, great video and also thanks Brad for inviting Jack. PS: I think that making your own UI library/framwork is not that bad and a great learning experience BTW
Thank You for sharing your time with us to give us very necessary information.
Colab of the MVPs of Programmer UA-cam
Ohh, jack Its nice seeing you here
This was a very nice collection of tips. Thanks.
Jack this information was awesome dude. It needs to understand every react developer mostly for beginners.
Thanks for the video, even though lots of the stuff you talk already explained even in older React docs (there's a beta one iirc). But main culprit I believe is, people rather than reading, try to use their knowledge from other libraries and frameworks, which make them misjudge how React works. Unlike many other, React has no magic tricks (except jsx), it is plain javascript and some clever stuff like hooks. So, if one knows any programming language, not just javascript and knows basics of React (which can be read from docs), it is pretty trivial task to understand what's going on. I'd say this is the gem of the React, it being a library this way. Anyway, again, thanks for your efforts. I've seen some people doing some of those mistakes even in production, which I think is unbelivable; so having videos like this really helps in that matter (atleast that's what I hope).
Great vid, nice find! The concepts were illustrated amazingly, and were flowing in an understandable way
Starting out with react. Very helpful and deep. Keeps someone like me on a good path or road map. 🙏
Thank-you so much Jack for this knowledge.
thanks Jack and Brad! You're great teachers! I leant a lot from the content!
I'm a long time React developer and i totally agree all the thought discussed in the video.... 👌
I had an idea to avoid working with logic in many components, for example, you have a dashboard screen that calculates a lot of information based on some requests to apis, each calculation is used in a different component, so it would be natural for you to create one component like ProfileStats, another RepositoryStats, and each component would have its own logic of fetching the data, then treating that data and finally displaying it, but in conjunction with the idea of "Do not think of function components as templates".
I DO recommend that when you have this situation (process one or more information and then display it in a component) you create a custom hook to handle all the processing, then you create a component that displays this processed data, it is probably easier to test and easier to understand what you Is doing.
Maybe it is like your advice to create custom hooks, but I would increment to make sure the "clearly defined components" to be just a stateless component, just receives all data they need and show it.
const profileProcessedData = useProfileStats();
const repositoryProcessedData = useRepositoryStats();
This was gold! I'd love to see more things like this on the channel! Thanks to both of you!
This is a collab that I didn't see coming at all :O
Stoked to see 2 of my favorite people overlapping! 😎👍
Hey this was incredibly useful and informative. I'm following.
Great video as always!
Very Helpful video. Thanks man!!!
15:36 we want to add the id to the dependency array as this might change. But I think that is then defeated by adding the conditional at 16:05 which will mean that when the id changes and the user existed from the first/previous id, the useEffect will run but the fetch and the setUser won't run and the user will not be correctly updated from the new id.
It is. I just wanted to make sure that folks check to make sure they aren't unconditionally setting stuff that they are depending on. Otherwise, boom, infinite loop.
We need more React tutorials using TypeScript on here and UA-cam in general
thanks! very interesting and helpful!
This video really made me want to check out Jack's channel. It's very clear and pragmatic.
I'm a bit lost with the useMemo examples because I would not do this kind of stuff with React. Derived data and stuff like that should be in a presenter in my opinion, not in the component, and if it's pure business logic, even more so. You can memoize a function without React, it's dead simple even without a library.
Hey man, for the memoization without react, you would use a closure function that checks and stores the arguments passed to it, and only calls the callback (component ) if the new args are different from the last?
Also what is a presenter? Thanks!
@@deniyii yes, that would be a way to do it, although I don't know why you mention a component here. The callback can only be a pure function. If it has state or side-effects, you are not guaranteed that the cached result is the same for the same input.
I usually call this kind of function `once` because it remembers only one input/output pair and replaces it every time the input changes. I also sometimes use `diff` which does a deepEquals comparison instead of a reference comparison, and I use `memo` when I cache many pairs in a `Map` and/or a `WeakMap`
What I meant by "presenter" is a middleman sitting between the model and the UI component. The component is humble and do nothing other than pushing data to the screen. It does not compute sums or averages, it does not decide what buttons should be greyed out, how things are colour coded or whatnot, it takes a simple datastructure as input which has been generated by the presenter where all the decisions involving business logic have been encoded, and turns it into UI with no second though. Originally this pattern made the view easier to test, now testing frameworks have added complex tools to mount React components, query the DOM, etc. I don't like to use them to be honest, I prefer to write simple tests, have a good separation of concerns and have no business logic dependent on the view library.
@@ApprendreSansNecessite I see, so the presenter you speak of is a compound component that passes the computed data as props to another component that only renders the UI? If so isn’t using a custom hook a better pattern both for reusability and encapsulation?
Also, I mentioned “component” to represent a function that returns JSX; isn’t that what’s being memoized? I’m thinking of it from how I assume React.memo works, but I’m not sure if that’s the same mental model with what you’re describing.
@@deniyii A presenter or a memo function have nothing to do with React, they are library agnostic programming patterns.
A presenter can be a module or an object, which can be tested in isolation without having to bring React into scope (after all there is no DOM involved, why the need for React?). When you test a hook, you need to have this big test harness around it which nowadays is provided by things like testing-library/react, it makes you commit to React even more because not only did you couple your business logic with your view library (which is nonsensical) but you also coupled your tests with it, that is to say you can no longer refactor without breaking your tests. This is utterly wrong: tests should test the behaviour, not the design so that you can change the design and confidently rely on your tests to catch accidental modifications of behaviour. There is also no way you can convince your coworkers to change library or even to change the way you use it after that commitment, because it would be so much work to do. It is not agile, you should be able to make your architecture evolve over time.
React is not Javascript, when you use `useMemo` the compiler does stuff that is not expressed in the code. A standard memoized function is not that, it simply takes an input, and if it's an input it has seen before, it returns a cached value instead of doing the computation again. That's it. And that's what we wanted: in the 19:35 example we are not concerned about rerendering, we simply don't want the sum to be computed again, no need for a hook, but as I said in my initial comment, if you have a presenter that computation would not even be in the component in the first place, the result would simply be a value you can pass as a prop. Now it also means that the return value of the memoized function is going to be identical, value-wise but also reference-wise, so if it's passed as a prop, React is also going to detect that and prevent rerenders if no other prop has changed. It's the same functionality but achieved with other tools than React tools: general programming tools.
Now the way you use the presenter in your UI design is up to you, you could call it from a hook I guess, but then you would not test the hook, it would only be forwarding stuff to the presenter. Or you could use the connect API of react-redux and use memoization and presenter to map state to props
It's just another way of doing thing, a way that is less dependent on the tools and that capitalises on your knowledge of the language you are using and programming patterns .
@@ApprendreSansNecessite thanks for this explanation.
It seems I need to rethink my approach to building UI as I’m very much dependent on the tools provided by react to do things that can be done without tying myself to it. And while the react tools are incredible, I agree that it can make switching from react difficult.
I would ask you though, at what point do you draw a line between using tools a framework offers you versus building your own thing? It seems like your process is geared towards preventing coupling business logic to the framework, but isn’t that unrealistic especially in complex applications?
thanks alot Brad and jack
Awesome! Simple and well explained, great work!!
Awesome team up!
Thanks for this video Jack !
Btw who saw the squirrel behind at 00:35
I did! But only when I was editing.
@@jherr It adds a whole other dimension, more squirrel in the next videos 🤣
Thanks again 🤜🤛
That was fantastic, thank you so much for those golden tips.
Great content , Great timing . Thanks alot
Great Explanation 🤩
Awesome tips. Thanks
This guy is just fantastic
hmmm I don't love external UI libraries since they apply many things to elements and its harder to overwrite later. I think dominating CSS should be enough to create accessible components pretty fast. But overall amazing video, thanks uncle Jack once again
Excellent class
📒I learned more with this video than in hundreds 💯
You made a lot of good points but for bigger projects, I really do think you SHOULD build your own UI components. It avoids a lot of the magic involved with using third party UI libraries and gives you control over consistency of your design. And usually, you don't need to build a full library, you just need to build the components that you use, which is usually just a handful.
disagree!
ugh!!!! shadcn
@@aeronwolfe7072 shacdn was not a concept I'm familiar with 9 months ago when i made this comment but that said, copying components from shacdn and customizing it counts as making your own components. It is not a library that you import for the exact reason that I'm outlining here
@@aeronwolfe7072 actually the whole ethos of shacdn is that you should have full control of your components and not use a ui library so "ugh shacdn" is really just reiterating what I am saying. Not only that, version 0.1 of shacdn was released months after I have made this comment. I could not magically recommend things that didn't exist at the time.
The best decision that i have ever made is to switch to typescript sooner for my react apps . Its totally worth it !
Thanks it's good to hear am on the right part.
Class as always Brad. Many thanks
Always appreciate for such a great content :)
Thanks so much, that was great. But what do you think about testing your React component ?
Thanks, this was very informative!
A M A Z I N G ! Thanks💙💙
Thank you, at least now i know how to use dependency arrays correctly
Nice one about dependency arrays!
I agree with everything except the last, I think Implementing Design Systems on your own Using things Like tailwindCSS maybe with libraries like cva, clsx and tools like Storybook to test the components seperatly will make you a better Frontend dev.
Excellent video on React practice!
excellent video jack. so basically a rule of thumb would be: dont solve other problems other than your business problem. DONT INVENT THE WHEEL
Great explanation , Thank you for sharing 😊
Great content , thanks for sharing
Amazing job. So good to listen when an experienced expert have to say about React and then applying it in my own learning!
Thanks Jack!
If you want to share states between components without the hassle of setting up Context or Redux or any other external state management, you should look into "use-between" which provides these features, but using the states of custom hooks. I have totally replaced Context with this and it's much easier to deal with. Only the components that import the custom hook will be able to share states between them, hence "use-between." It's even better than Jotai since you're only using useState in custom hooks to share states.
Thanx a lot. Your tutorials are amazing. I learn a lot from you.
I am new on React but this is to die for
Thank you Jack for the great React content