WEBVTT 1 00:00:06.440 --> 00:00:10.919 Hello, Welcome to React around Us, the podcast where we keep you updated 2 00:00:10.960 --> 00:00:17.160 on all things React related. This show is sponsored by Breakdown and produced by 3 00:00:17.160 --> 00:00:21.000 two companies, Top and Devs and Onvoid. Top and deves is where we 4 00:00:21.039 --> 00:00:24.960 create top and devs so get top and pay and recognition while working on interesting 5 00:00:25.000 --> 00:00:31.480 problems and make meaningful community contributions an Void which provides remote design and software development 6 00:00:31.519 --> 00:00:36.159 services on a performance basis, so clients only pay when tasks are delivered and 7 00:00:36.320 --> 00:00:41.799 approved. In today's episode, we will talk about patterns for React hooks. 8 00:00:42.280 --> 00:00:47.399 This episode is going to be for you that is already used to hooks, 9 00:00:47.520 --> 00:00:51.799 already used to functional programming React, but also to all of you that are 10 00:00:51.840 --> 00:00:56.240 coming from a class based background, maybe from a back end language, and 11 00:00:56.280 --> 00:01:00.479 you're just trying to understand why is everything done way that it is done today 12 00:01:00.520 --> 00:01:07.719 with React and how can you take how can you make use of that and 13 00:01:07.799 --> 00:01:11.719 structure your code in a way that other developers are going to thank you for 14 00:01:11.760 --> 00:01:18.760 it. Joining me in today's episode is Charles Maxwood, Hey, everybody, 15 00:01:19.159 --> 00:01:26.519 Chris Fruin, Peter Oza, Hi everyone, and of course me Lucas Paganini 16 00:01:26.400 --> 00:01:32.719 and Yeah, let's get into it. So, Peter, you were the 17 00:01:32.719 --> 00:01:36.519 one that proposed this idea. So I imagine that you have a lot of 18 00:01:36.680 --> 00:01:42.560 things to share with the audience in terms of patterns for React hooks, code 19 00:01:42.599 --> 00:01:46.319 structure for that, when to isolate something in a hook, when to just 20 00:01:46.519 --> 00:01:51.560 use the native React hooks. So yeah, let's start with that. So 21 00:01:51.680 --> 00:01:57.879 I guess my first question would be when would you create a hook for something? 22 00:02:00.079 --> 00:02:05.319 Okay? Yeah, so when you create to create a hook, you 23 00:02:05.400 --> 00:02:09.520 have to consider setting scenarios, right, So like if I want to create 24 00:02:09.560 --> 00:02:14.960 a hook for a settain components, I will try to look at the component 25 00:02:15.080 --> 00:02:19.240 and see which values are changing. Okay, does it is it going to 26 00:02:19.280 --> 00:02:23.120 contain reactive states or is it going to contain setting things that are going to 27 00:02:23.199 --> 00:02:29.960 change? And then also do I need to maybe process those states those values 28 00:02:30.000 --> 00:02:32.800 and then we turn something back. Yeah. So in that kind of instance, 29 00:02:32.840 --> 00:02:38.120 when I look at those criterias, does when I decide, oh, 30 00:02:38.719 --> 00:02:42.759 I'm going to just start this to hook. Also it comes to things like 31 00:02:42.800 --> 00:02:46.879 API cause yeah, I know that the API course is the APR cause can 32 00:02:46.960 --> 00:02:51.039 be called the components. Easier for me to just live it in that component, 33 00:02:51.120 --> 00:02:55.199 I could just isolate it to the hook. Mostly it's just on things 34 00:02:55.199 --> 00:03:00.639 that are kind of changing or things that are kind of intent. Yeah, 35 00:03:00.759 --> 00:03:05.960 so that's why I use hooks. I kind of also live into So yeah, 36 00:03:06.039 --> 00:03:08.400 I think that's just what I generally do. Okay, makes sense to 37 00:03:08.439 --> 00:03:14.520 me, But when would you For example, of course, every time that 38 00:03:14.560 --> 00:03:17.879 we need state, we're going to have to use React hooks and use state 39 00:03:19.159 --> 00:03:23.919 or any other hook that is going to allow us to react to changes and 40 00:03:24.000 --> 00:03:31.599 re render a component. But when do you feel it's the time to really 41 00:03:31.759 --> 00:03:38.159 isolate that into a custom hook so that it can maybe be reused later, 42 00:03:38.360 --> 00:03:42.159 Like would you only reuse something in a custom hook if it's definitely going to 43 00:03:42.159 --> 00:03:47.680 be reused right now, or would it be advised to isolate things in a 44 00:03:47.759 --> 00:03:53.000 hook in a custom hook, even if they are used in a single component, 45 00:03:53.159 --> 00:03:59.400 just for the sake of reducing the total size of that file. What 46 00:03:59.439 --> 00:04:05.000 do you think of that? Okay? Yeah, So for me, okay, 47 00:04:05.000 --> 00:04:09.759 in cases where I need to create a customer, one thing I consider 48 00:04:09.879 --> 00:04:15.040 is actually reusability. Right, So if I'm going to create a custom book 49 00:04:15.160 --> 00:04:19.000 for a component, I mean, it has to be usable, right, 50 00:04:19.079 --> 00:04:25.920 So it's really makes sense to just create a custom book for something that was 51 00:04:26.279 --> 00:04:30.839 that's just specific to that component that can be used, right, So it's 52 00:04:30.879 --> 00:04:34.199 more much more important that, Oh I know that, Yeah, this state 53 00:04:34.319 --> 00:04:38.600 is going to be used these certain components. Maybe I have an APR call. 54 00:04:39.000 --> 00:04:41.879 I'm going to make this a PR call and different components. Yeah, 55 00:04:41.920 --> 00:04:46.240 I can just upstart that to custom book and use that. Or I need 56 00:04:46.279 --> 00:04:53.079 I need a setting value and maybe something like I need to trag like school, 57 00:04:53.439 --> 00:04:56.759 school events or something. Yeah, you know that that can be using 58 00:04:57.079 --> 00:05:00.000 different components. I could just build that to be a hook, or yeah, 59 00:05:00.120 --> 00:05:03.920 I want to do if finish school Obviously you know that many components going 60 00:05:03.920 --> 00:05:09.240 to use that or the popular one. I want to ensure that when you 61 00:05:09.759 --> 00:05:15.319 click outside, that's the one that kind of use events propagation to yeah, 62 00:05:15.759 --> 00:05:18.639 to close down setting events and so on. Yeah, I know I'll use 63 00:05:18.680 --> 00:05:24.839 the hook for that because they're kind of reusable. But in an instance where 64 00:05:24.920 --> 00:05:28.920 maybe certain things like business logically, you know that you can't really use them 65 00:05:29.399 --> 00:05:34.160 elsewhere they're just localized to that component. Yeah, I won't really that the 66 00:05:34.240 --> 00:05:39.079 best way is to just upstart them to out to hook a custom hook, 67 00:05:39.560 --> 00:05:45.399 because then it's just only going to be one used. That's it. You 68 00:05:45.439 --> 00:05:49.319 can't believe we use them anywhere, So I think increasing the costom we just 69 00:05:49.399 --> 00:05:56.160 considered with their reasonability. Yeah, so that's just my philosophy for it. 70 00:05:56.360 --> 00:06:00.120 Interesting. Interesting, Okay, I have strong feelings about this, but I 71 00:06:00.160 --> 00:06:06.120 would like to get Chris and Check's opinion on that. So, Chris, 72 00:06:06.240 --> 00:06:10.600 how do you feel about that? Like when do you isolate something in a 73 00:06:10.639 --> 00:06:16.759 custom hook? Yeah? So I kind of view hooks for me fall into 74 00:06:17.040 --> 00:06:20.160 kind of different categories. I can think of like two off the bat, 75 00:06:20.240 --> 00:06:24.600 you kind of have like what Peter mentioned. Maybe some are almost more like 76 00:06:24.720 --> 00:06:29.000 util hooks. I was just looking at a code base, and I typically 77 00:06:29.040 --> 00:06:33.879 have like the used interval or use time out. Those you probably know you 78 00:06:33.920 --> 00:06:39.360 probably use them more than once around your code base. But then even really 79 00:06:39.399 --> 00:06:44.279 truly your own custom hooks maybe their application specific. But then those two, 80 00:06:44.399 --> 00:06:48.120 you know, I'm probably gonna need this in more than one component. So 81 00:06:48.199 --> 00:06:54.000 yeah, for me, it really just comes down to I'm typically the kind 82 00:06:54.040 --> 00:06:58.199 of dev As soon as I'm using something, probably twice somewhere, I just 83 00:06:58.279 --> 00:07:04.000 refactored into a hook. And even I mean even even for one off sometimes 84 00:07:04.040 --> 00:07:08.600 I mean it might just become a standard function anyway. But if there's really 85 00:07:08.800 --> 00:07:13.160 quite a lot of logic for i don't know, some crazy complex component, 86 00:07:13.600 --> 00:07:15.879 sometimes it just makes sense to say, like, you know, like use 87 00:07:16.800 --> 00:07:21.639 whatever the use state for this component, and then you at least have all 88 00:07:21.680 --> 00:07:27.199 of your reactive code kind of separate from the market from the markdown. Right, 89 00:07:27.240 --> 00:07:30.920 So you have just probably like a one liner of accessing all the state 90 00:07:30.959 --> 00:07:34.079 that's changing, and then you can keep kind of that those two concerns, 91 00:07:34.079 --> 00:07:39.839 like the display side and then the reactive side separate at least at least in 92 00:07:40.360 --> 00:07:49.120 code. So nice. Okay, so you are like still leaning towards isolation 93 00:07:49.839 --> 00:07:55.839 only when there is reusability, but there are also some other cases where you 94 00:07:55.879 --> 00:08:03.040 would isolate is not just for reusability, but still is mostly due to reusability. 95 00:08:03.199 --> 00:08:07.439 Interesting. Okay, how about you, Chuck. I'm gonna be honest, 96 00:08:07.480 --> 00:08:13.720 I haven't done much React lately. I'm kind of still ramping things up 97 00:08:13.759 --> 00:08:18.800 and starting a project for React geniuses. So yeah, I'll have much more 98 00:08:18.800 --> 00:08:26.199 to say here in a few weeks. Okay, all right, So what 99 00:08:26.240 --> 00:08:30.959 I actually wanted to get at is, and I think Chris touched on that 100 00:08:31.040 --> 00:08:35.720 point, is when a component starts to get really complex and there are just 101 00:08:37.039 --> 00:08:41.039 too much logic happening in it, then you might want to isolate your hook 102 00:08:41.320 --> 00:08:46.519 in another file, even maybe just so that you can clean up a bit 103 00:08:46.639 --> 00:08:48.759 the logic of that component, even if that hook is not going to be 104 00:08:48.799 --> 00:08:52.240 reused anywhere else. And if you're gonna do that, you don't even need 105 00:08:52.320 --> 00:08:58.200 to put your hook in like a separate folder just for reusable hooks. You 106 00:08:58.240 --> 00:09:01.279 can put that side by side with the component if it's just going to be 107 00:09:01.360 --> 00:09:07.480 used by that specific component. And I think this should be used way more 108 00:09:07.519 --> 00:09:16.600 often. My feeling is that React component files are generally much larger than they 109 00:09:16.679 --> 00:09:24.600 should be. There's just generally way too much happening. So I think that 110 00:09:26.279 --> 00:09:31.200 most developers could definitely benefit from breaking down more things, more of what they 111 00:09:31.240 --> 00:09:35.759 have in their component files in other files, even if that's not going to 112 00:09:35.840 --> 00:09:41.000 be used in more than one place, Like even if it's used in one 113 00:09:41.039 --> 00:09:46.320 place, just one place, I still think that in a lot of cases, 114 00:09:46.000 --> 00:09:52.240 probably most, it's a lot more beneficial to do that than just being 115 00:09:52.279 --> 00:09:54.759 on edge case. I don't think it's on edge case. I think this 116 00:09:54.879 --> 00:10:01.480 should probably be the default for most situations. Just to give you guys an 117 00:10:01.519 --> 00:10:09.600 idea, the average file size for a React file that I open is generally 118 00:10:09.639 --> 00:10:15.279 like eight hundred lines or so. That's the average. I don't know what's 119 00:10:15.360 --> 00:10:18.840 the experience for you guys, but that's what I'm used to seeing in other 120 00:10:18.960 --> 00:10:24.519 projects. And I think that's just too much. That's way too much. 121 00:10:24.919 --> 00:10:31.840 I think we should be striving to stay at at least less than five hundred 122 00:10:31.360 --> 00:10:37.759 lines, but ideally three hundred or something that that should be enough. So 123 00:10:39.000 --> 00:10:45.440 yeah, my take is I tend to isolate things in other files way more 124 00:10:45.480 --> 00:10:52.600 often than other developers, even when things are not going to be reused right 125 00:10:52.600 --> 00:10:56.879 away, even when things don't seem like they're going to be reused at all, 126 00:10:58.000 --> 00:11:01.919 I still generally isolate things. Also makes it easier for me to write 127 00:11:03.080 --> 00:11:09.720 tests for those functions. So yeah, yeah, and you you have to 128 00:11:09.720 --> 00:11:13.200 think about, like, what's what's the actual quote unquote risk or overhead. 129 00:11:13.519 --> 00:11:18.159 I mean, now that we have functional components, you're adding what the name 130 00:11:18.840 --> 00:11:22.080 okay, the props and then the name of the component, even if it's 131 00:11:22.080 --> 00:11:26.639 only just once, and then two brackets, so you've added whatever three lines 132 00:11:26.240 --> 00:11:31.440 to save you know, to get away from those eight hundred line components. 133 00:11:31.639 --> 00:11:35.720 And I've seen that, and I'm even I'm I think we're all guilty of 134 00:11:35.759 --> 00:11:39.639 that. I think it's one of the advantages and disadvantages of React is that, 135 00:11:39.759 --> 00:11:43.639 you know, once you've learned the basics, it's very easy to quickly 136 00:11:43.679 --> 00:11:46.679 build and write these these components, and then before you know it, you've 137 00:11:46.720 --> 00:11:52.519 got you've got some giant thing like yeah, it's probably even then at those 138 00:11:52.559 --> 00:11:56.840 sizes still understandable, but it's just like a lot of usually markup you have 139 00:11:56.879 --> 00:11:58.080 to skip through and see like, okay, where does this variable go? 140 00:11:58.600 --> 00:12:03.279 You know what's happening here? But yeah, that's in you know, help 141 00:12:03.320 --> 00:12:07.759 why I'm why I'm here on this podcast, why I love reacts so much? 142 00:12:07.840 --> 00:12:11.039 You can just snag you know, you've got I'm thinking of like an 143 00:12:11.080 --> 00:12:13.519 example, like maybe like a table row. You just pull out that mark 144 00:12:13.559 --> 00:12:18.559 down you see you know what state variables in there? They just become props, 145 00:12:18.679 --> 00:12:22.799 right, and then you're halfway, you know, you're halfway done to 146 00:12:22.840 --> 00:12:33.120 refactoring those those larger component files. So I'm gonna go even further and say 147 00:12:33.159 --> 00:12:39.480 that sometimes I even isolate just the styled components like sometimes I have just the 148 00:12:39.639 --> 00:12:48.159 styles dot t s file just for the diout components, because sometimes like fifty 149 00:12:48.200 --> 00:12:56.639 percent off the file is just those dumb presentational components that are taking up space 150 00:12:56.720 --> 00:13:03.919 and the bottom, and they're not really making the experience of understanding the file 151 00:13:03.000 --> 00:13:09.080 harder because they are like in the bottom. They're like isolated in their own 152 00:13:09.519 --> 00:13:13.360 in their own space. But still sometimes when they're just way too many of 153 00:13:13.399 --> 00:13:18.639 them, I just can't stand and I just isolate them in other files. 154 00:13:18.679 --> 00:13:24.240 But that one is definitely just a personal preference, is not something that I 155 00:13:24.240 --> 00:13:28.919 do that I do a lot. What I do mostly is isolating hooks, 156 00:13:30.080 --> 00:13:33.360 but even style components I think sometimes can be isolated in their own files. 157 00:13:33.559 --> 00:13:37.919 It even reminds me of the old days where we actually had like a file 158 00:13:37.960 --> 00:13:43.799 for HML, another for typescript, another for CSS. Right, so when 159 00:13:43.799 --> 00:13:48.639 I isolate the style components, it kind of feels like that's the CSS file. 160 00:13:50.080 --> 00:13:54.240 I like that, probably because I also do a lot of Angular development, 161 00:13:54.519 --> 00:14:01.120 and Angular separates those things. So maybe that's and it's something that I'm 162 00:14:01.200 --> 00:14:11.559 bringing from my Angular development stuff. Yeah, does actually true. So I 163 00:14:11.600 --> 00:14:18.679 think what an issue that most we have developers actually face is the fact that 164 00:14:18.720 --> 00:14:24.279 because the art is not opinionated quite because yeah, you could just it doesn't 165 00:14:24.279 --> 00:14:28.440 really have like an ups A style of its own. You could just do 166 00:14:28.600 --> 00:14:33.200 whatever you want, just like the the whole components is just like your your 167 00:14:33.240 --> 00:14:37.480 field to just do whatever you want to write. So a lot of people 168 00:14:37.679 --> 00:14:41.960 kind of you know, decide to be the way they want to write. 169 00:14:41.440 --> 00:14:46.879 So I think if they actually have an idea of setting patterns rights to building 170 00:14:46.960 --> 00:14:50.960 stuff, I feel it's virtually helped, for example, parking a lot of 171 00:14:52.080 --> 00:14:54.399 like logic in more, we are components. First of all, it's not 172 00:14:54.559 --> 00:14:58.840 really nice at first all. What I actually would do is a first different 173 00:15:00.000 --> 00:15:05.279 differentiate my components into two. Okay, there is a component another maybe like 174 00:15:05.279 --> 00:15:09.720 a business logic, an API call or setting things. That would be a 175 00:15:09.799 --> 00:15:13.519 setting component. That would be like a container component. Right, so that 176 00:15:13.639 --> 00:15:18.519 component would just be a container. Then I've done that. It's a presentational 177 00:15:18.559 --> 00:15:22.679 components that's you are clearly like you won't see any till I used it or 178 00:15:22.720 --> 00:15:28.799 whatever. Any hook is just receiving data from it as props. Right, 179 00:15:28.159 --> 00:15:33.360 So these kind of patterns, there's there's stillso the pattern of writer, as 180 00:15:33.399 --> 00:15:37.000 you said, isolating for setting out sets in books. Right. So if 181 00:15:37.279 --> 00:15:41.120 a lot of people adopted that as well, I think they could become more 182 00:15:41.360 --> 00:15:45.960 cleaner and more much better and they're still Like I said, I also do 183 00:15:46.039 --> 00:15:48.879 a lot of umblood development as well too. I like the pattern of amblers 184 00:15:50.080 --> 00:15:54.279 services, right, So I actually kind of adopted that aspecting react to. 185 00:15:54.960 --> 00:15:58.440 So I think there was a reference we said, as there are certain things 186 00:15:58.440 --> 00:16:03.360 we need to letting a hook, right. But if you actually have like 187 00:16:03.720 --> 00:16:07.799 an idea of a service, maybe you put your business logic in the service 188 00:16:07.879 --> 00:16:11.480 you create like a class or it will be a very big functim if that 189 00:16:11.639 --> 00:16:17.399 was just look, you won't really have any need to really isolate much in 190 00:16:17.440 --> 00:16:21.120 your component because at the end of the dagion multiple drink calculations in your component, 191 00:16:21.639 --> 00:16:25.240 everything is done in your service and you're just important it to your component. 192 00:16:25.320 --> 00:16:27.639 So it's going to be kind of it's not going to be blooted, 193 00:16:29.000 --> 00:16:34.440 right. So I think it's just how because reactive it's not openiord so a 194 00:16:34.480 --> 00:16:38.840 lot of people just gives them the ability to kind of decide what they want 195 00:16:38.879 --> 00:16:42.799 to do. And I feel maybe if design patterns can be taught very well 196 00:16:44.039 --> 00:16:45.600 about that, like, oh, you could do this, you could do 197 00:16:45.679 --> 00:16:48.240 that, Like now, I know, I feel a lot of if you're 198 00:16:48.240 --> 00:16:52.679 actually don't know the result is why hooks, right, And they really abuse 199 00:16:52.720 --> 00:16:57.000 a lot of hooks, like I've seen hooks like use memo Beiner Bese so 200 00:16:57.200 --> 00:17:04.279 much like like things we're never supposed to memoiz, it's just stumping use memo 201 00:17:04.359 --> 00:17:11.000 into it. So yeah, I think that's actually I think design patons is 202 00:17:11.000 --> 00:17:17.160 actually very important to know, mostly identical because since we acts don't have that's 203 00:17:17.519 --> 00:17:21.559 established paton, I think that's what they need to actually know so that it 204 00:17:21.640 --> 00:17:26.440 can come better. INTI the good bit. Yeah, I agree, and 205 00:17:26.519 --> 00:17:30.519 I think that can be something that we're trying to introduce here, right, 206 00:17:30.599 --> 00:17:34.960 So since reactor is not opinionated, let's bring some some opinions into it, 207 00:17:36.720 --> 00:17:40.480 see if we can help everyone out. But yeah, definitely a lot of 208 00:17:40.519 --> 00:17:45.880 what we say here is going to be it's going to be based on personal 209 00:17:45.920 --> 00:17:52.920 preferences. But also I would encourage everyone listening to think about this for a 210 00:17:52.920 --> 00:17:57.799 second because even though a lot of code patterns are going to be based on 211 00:17:57.920 --> 00:18:04.359 personal preference, that personal preference may have been built after years of working with 212 00:18:04.440 --> 00:18:12.440 that technology and understanding what reduces the mental load of other developers and what makes 213 00:18:12.440 --> 00:18:19.960 it clearer and easier for everyone else to understand. So there's always something of 214 00:18:21.000 --> 00:18:26.799 a mutual benefit in a personal preference. It's rarely the case where a personal 215 00:18:26.839 --> 00:18:32.759 preference from a senior developer at least is really something super specific to that developer 216 00:18:32.839 --> 00:18:38.559 and others are going to agree. What I've seen the most is like personal 217 00:18:38.599 --> 00:18:45.960 preferences from senior engineers in a particular technology tend to be kind of like a 218 00:18:45.400 --> 00:18:52.119 general agreement that others have. I wouldn't say that it's like an anonymous agreement, 219 00:18:52.880 --> 00:18:56.039 unanimals agreement and everyone agrees with that, because there are certainly things that 220 00:18:56.079 --> 00:19:07.440 are purely cosmetic. For example, just adding underscore prefixes to your private private 221 00:19:07.480 --> 00:19:14.240 members for example, that's very very cosmetic. But the things that we're talking 222 00:19:14.240 --> 00:19:18.839 about here, like isolating things in custom hooks, when to isolate that, 223 00:19:19.559 --> 00:19:25.880 how to organize or file structure, I think that's not cosmetic. That really 224 00:19:26.440 --> 00:19:33.640 has a strong functional value for all the engineers in the colbase. So yeah, 225 00:19:33.720 --> 00:19:37.839 I wouldn't just say that as being like just a personal preference. I 226 00:19:37.839 --> 00:19:42.920 think in most cases this is definitely like a code quality improvement. Yeah, 227 00:19:44.359 --> 00:19:48.799 let's see what else we got. So we talked about when to isolate things 228 00:19:48.839 --> 00:19:56.640 into hooks. What else do do we have with regards to common code patterns 229 00:19:56.720 --> 00:20:00.720 and React? Chris, Peter, maybe you have something your mind. Yeah, 230 00:20:00.720 --> 00:20:06.000 I'd like I'd like to add something. This gets pretty pretty specific into 231 00:20:06.519 --> 00:20:11.119 maybe what you're talking about about like fairly opinionated. But but it's something like 232 00:20:11.160 --> 00:20:17.680 that I've finally kind of solidified in my own React career, and i'd like 233 00:20:17.759 --> 00:20:21.200 to hear you guys. Maybe you disagree completely and then then we'll see. 234 00:20:21.640 --> 00:20:25.680 But I have a I have a very specific order when I have a when 235 00:20:25.720 --> 00:20:30.799 I write a component of how just how I I guess format it, so 236 00:20:30.880 --> 00:20:34.960 I what I do is and yeah, I know these will be opinionated. 237 00:20:36.039 --> 00:20:40.680 So like my first line, I'll like destructure all the props that I need, 238 00:20:41.319 --> 00:20:45.759 so you know, the big big bracket off the props. Then what 239 00:20:45.759 --> 00:20:48.799 I'll do is if I'm using reducts, so like a more global state or 240 00:20:48.799 --> 00:20:53.359 at least a higher shared state, I use the appso elector, then I 241 00:20:53.440 --> 00:20:57.359 use the dispatch. Then comes if there's any local state, I have those 242 00:20:57.880 --> 00:21:03.920 and then anything else like use ref or anything below that, and then finally 243 00:21:03.640 --> 00:21:08.400 they use effect or any other if you're doing like one of the like use 244 00:21:08.480 --> 00:21:15.160 layout or something like that, and the way. So I would maybe I 245 00:21:15.160 --> 00:21:18.960 would argue like that order doesn't matter, but maybe in a given code base 246 00:21:18.480 --> 00:21:25.640 you should probably I think it's nice to follow the same same order in any 247 00:21:25.640 --> 00:21:29.160 way You're like, I think at least like the use effect below makes sense 248 00:21:29.200 --> 00:21:33.359 because you typically need state variable in there anyway. But I think if you 249 00:21:33.359 --> 00:21:37.960 can manage kind of a the same pattern across at least one code base, 250 00:21:38.000 --> 00:21:41.480 maybe not all code bases, but at least one project or something, it's 251 00:21:41.519 --> 00:21:47.039 really nice because then when you look at a component, you know exactly like 252 00:21:47.720 --> 00:21:52.200 you know exactly where everything's going to be right and in what line more or 253 00:21:52.279 --> 00:22:00.400 less. So i'd be interested to hear you guys thoughts about that. Yeah, 254 00:22:00.519 --> 00:22:03.480 that sounds great. I'm also a fond of redocs as well. So 255 00:22:03.160 --> 00:22:11.240 yeah, although, yeah, so I started with videos, which is because 256 00:22:11.279 --> 00:22:15.559 first of all, I tried to defense it. I tried like deficiate the 257 00:22:15.599 --> 00:22:18.920 state of my application into two. Okay, yeah, I have a client 258 00:22:18.960 --> 00:22:23.000 state and I have a SABA states, right, so disavastate aspects. Yeah, 259 00:22:23.079 --> 00:22:29.720 I could use things like maybe we asked qually to handle that and then 260 00:22:29.759 --> 00:22:33.799 find a way to kind of sync it to my redox. Yeah, then 261 00:22:33.839 --> 00:22:41.039 after doing that as well, then coming to components centralized as well, then 262 00:22:41.880 --> 00:22:45.000 I, like I said, I use hooks to actually setting business logics. 263 00:22:45.039 --> 00:22:52.079 So if I like accomplish logic I need to execute in the component, I 264 00:22:52.079 --> 00:22:55.839 could put that into a hook and then put that and then my ustage is 265 00:22:55.880 --> 00:23:00.880 regularly for certain changes in that component and yeah, just changes. Yeah, 266 00:23:00.960 --> 00:23:07.079 previously I usually use states for forms. For then I saw a kind of 267 00:23:07.359 --> 00:23:12.519 bottle neck which is in use state that's using US state for form validation and 268 00:23:12.640 --> 00:23:15.839 so on. Like I know a lot of people use it. I think 269 00:23:15.960 --> 00:23:21.799 it's called I think it's on compute states patterns like yeah, whereas you have 270 00:23:22.799 --> 00:23:26.640 like I know, it's kind of like the regular or you're typing on change 271 00:23:26.799 --> 00:23:32.640 and then it's actually afflexes from the states, right, so that kind of 272 00:23:32.839 --> 00:23:38.640 but so yeah, so I think generally do you use it use I just 273 00:23:38.759 --> 00:23:44.519 use it now for just general components states. Things are going to change, 274 00:23:44.519 --> 00:23:52.000 and so then sever state is then my sever state is useful and my clients 275 00:23:52.039 --> 00:23:55.720 needed with videos. Yeah, I think that's generally how I work with I 276 00:23:55.920 --> 00:24:00.920 like that trick about the order first off, like the use the fact at 277 00:24:00.920 --> 00:24:03.759 the end. I think it's a no brainer, as you said, Chris, 278 00:24:03.000 --> 00:24:07.839 like we generally need those state variables anyway, so there's no reason to 279 00:24:11.400 --> 00:24:14.160 to not have that at the end, So I think that makes total sense. 280 00:24:15.200 --> 00:24:19.680 I would still I don't know if I would always put them in order 281 00:24:21.400 --> 00:24:25.960 of what they are, because I like to keep things in the order of 282 00:24:26.799 --> 00:24:30.079 what they are related to. But in the same sense, like if you're 283 00:24:30.160 --> 00:24:37.319 inside a particular component and that component has a very clear responsibility, then everything 284 00:24:37.799 --> 00:24:42.680 is supposed to be very close. All the responsibilities should be very close, 285 00:24:42.759 --> 00:24:47.599 so that shouldn't be a problem. But come on, let's be honest, 286 00:24:47.799 --> 00:24:49.599 like a lot of components out there, they are doing way too much. 287 00:24:51.839 --> 00:24:55.319 And then when you have components doing way too much, if you put things 288 00:24:55.440 --> 00:25:00.160 in the order of what they are, maybe you have like let's say that 289 00:25:00.240 --> 00:25:07.480 you have a component that renders users and user groups, for example, and 290 00:25:07.599 --> 00:25:14.119 then you have hooks that are specific to the user's state, and other hooks 291 00:25:14.119 --> 00:25:18.240 they are specific to the user groups state. I would rather keep all of 292 00:25:18.359 --> 00:25:22.960 them close together based on the feature that they are related to. So all 293 00:25:23.039 --> 00:25:30.039 the user related hooks together, all the user group related hooks together, then 294 00:25:30.599 --> 00:25:34.920 just having like all use effect, all use state, all use rep together, 295 00:25:36.279 --> 00:25:40.480 if that makes sense. But still like that, that also comes from 296 00:25:40.599 --> 00:25:48.359 my mentality of thinking about how to even isolate those things into even even more 297 00:25:48.440 --> 00:25:53.039 custom hooks. So I generally do that because it makes me it makes it 298 00:25:53.160 --> 00:25:57.240 even easier for me to later just create a hook that is just going to 299 00:25:57.279 --> 00:26:03.359 be responsible for exposed seeing the features related to users, and another for the 300 00:26:03.440 --> 00:26:08.759 things that are exposing just the features related to user groups. Even again if 301 00:26:08.960 --> 00:26:14.359 even if they're not going to be reused somewhere else, Yeah, I like 302 00:26:14.480 --> 00:26:19.759 to keep them grouped based on the feature. Yeah, I think as kind 303 00:26:19.799 --> 00:26:23.400 of a rule of thumb in general. I mean, as always it depends, 304 00:26:23.480 --> 00:26:27.920 but if you're finding your component has like two or even two or three 305 00:26:29.039 --> 00:26:33.960 use effects, it's not always, but it's typically a sign you're probably doing 306 00:26:33.039 --> 00:26:38.640 too much in or trying to do too much in one component. Again, 307 00:26:38.680 --> 00:26:42.559 it depends if you have a very you know, some very complex triggering triggering 308 00:26:42.599 --> 00:26:48.000 stuff. But then maybe that's even an area for refactoring anyway. Yeah, 309 00:26:48.359 --> 00:26:52.000 I would just out of my own curiosity. I'm interested because I've heard many 310 00:26:52.079 --> 00:26:56.559 different opinions. What do you think about my the props destructuring? Do you 311 00:26:56.640 --> 00:27:00.799 guys like the props dot whatever, or I like I always destructure them. 312 00:27:00.920 --> 00:27:04.079 I mean, I know it can conflict then with local variables, but then 313 00:27:06.240 --> 00:27:08.119 I don't know. I typically avoid that anyway. But I would like to 314 00:27:08.160 --> 00:27:15.119 hear you guys, which pattern you prefer or maybe it depends. Yeah, 315 00:27:15.359 --> 00:27:18.319 I go with I think I'm with you on this one as well. Chris. 316 00:27:18.759 --> 00:27:22.440 Yeah, it's better to actually there pop. So I'm kind of be 317 00:27:22.519 --> 00:27:30.039 fun of that as well. Yeah, so yeah, yeah, I'm be 318 00:27:30.160 --> 00:27:33.279 fun of that because, first of all, I think if you use types, 319 00:27:34.000 --> 00:27:38.960 if you're typing right the components, I think you know, yeah, 320 00:27:40.680 --> 00:27:45.640 obviously the type is going to have like the setame feuds so required. Yeah, 321 00:27:45.839 --> 00:27:49.799 I don't think you actually wanted to be in problem with that that. 322 00:27:51.119 --> 00:27:57.240 I think that's actually much bitter and much easier because then seem pop stop dots 323 00:27:59.079 --> 00:28:06.400 that kind of it. Yeah, I'm with both of you. I prefer 324 00:28:06.559 --> 00:28:15.000 destructuring. There are some situations where I don't, but they're generally a sign 325 00:28:15.279 --> 00:28:21.240 of a larger issue. For example, if I'm just doing a lot of 326 00:28:21.400 --> 00:28:26.400 prop drilling, and then I don't want a destructure because I want to like 327 00:28:26.000 --> 00:28:32.720 passing the like the structure the object itself to pass the properties to the child 328 00:28:32.799 --> 00:28:37.160 component. But that's generally like a very bad sign, and that's something's really 329 00:28:37.240 --> 00:28:41.599 wrong in the cow base. So that doesn't happen very often. But if 330 00:28:41.680 --> 00:28:47.039 I find myself just getting the props to to drill them downwards, then I 331 00:28:47.200 --> 00:28:52.480 might just grab the entire properties is just a variable called props and then do 332 00:28:52.640 --> 00:28:57.240 that, But mostly I do the structuring too. That works, Yeah, 333 00:28:57.640 --> 00:29:03.680 that's the best way. Kind of be fun of that. Yeah, that 334 00:29:03.880 --> 00:29:08.039 that's that's actually another topic, right, So how do you guys deal it? 335 00:29:10.000 --> 00:29:15.240 Just passing properties to two child components? Of course, like prop drilling 336 00:29:15.519 --> 00:29:26.000 shouldn't really be the the recommended approach, but sometimes it just feels like it 337 00:29:26.039 --> 00:29:32.359 would be such a small thing that it wouldn't make sense to create like a 338 00:29:32.519 --> 00:29:36.559 context for that or something like that. But how do you feel about that? 339 00:29:37.640 --> 00:29:41.400 Oh? Yeah, so for for drilling, Yeah, I'll be fond 340 00:29:41.440 --> 00:29:48.839 of for feeling the way, but probably like one or two components might I 341 00:29:48.920 --> 00:29:52.119 think the moment it takes it like we be two components, and I feel, 342 00:29:52.160 --> 00:29:56.640 oh, yeah, maybe I have to study using context because then come 343 00:29:56.160 --> 00:30:03.160 three, four, five components. The Yeah, so I kind of stop 344 00:30:03.359 --> 00:30:08.680 using props and I say, this data required is going to be like needed 345 00:30:10.599 --> 00:30:14.680 more than two components dip. Yeah, but over all, Yeah, if 346 00:30:14.720 --> 00:30:18.519 I actually see it needs to use it to actually pass down things asps, 347 00:30:18.599 --> 00:30:22.319 yeah, why not? Certainly easier to do so than to just maybe I 348 00:30:22.440 --> 00:30:26.240 think I think this is another pattern. A lot of people kind of abuse 349 00:30:26.279 --> 00:30:30.160 in the way, but they try to avoid props in general because of the 350 00:30:30.359 --> 00:30:37.119 fear of propelling that they create context for every single thing, like every single 351 00:30:37.200 --> 00:30:41.240 thing, like even like you just you certainly just look at the data and 352 00:30:41.359 --> 00:30:42.880 be like, oh, this could just pass this with the props, and 353 00:30:42.880 --> 00:30:48.680 you're seeing a very big context setting like something as something as small as or 354 00:30:48.759 --> 00:30:52.400 I have a small component. I just want this component to flick out on 355 00:30:52.680 --> 00:30:57.559 different modes, just one component, and I'm saying, no, the context 356 00:30:57.640 --> 00:31:03.799 and this on them. It's just extreme. It's like he's in the sledge 357 00:31:04.200 --> 00:31:11.720 to kill a man that's way backing right to I. Just in that stance, 358 00:31:11.839 --> 00:31:15.680 I just advice to sports, because why not it's easy and it's just 359 00:31:15.880 --> 00:31:22.319 one compient down. But then just maybe and I know that all what is 360 00:31:22.480 --> 00:31:26.039 going to be more so I use context. What do you think, Chris, 361 00:31:26.680 --> 00:31:30.599 when do you feel bob building is efficient or better? Yeah, it's 362 00:31:32.880 --> 00:31:37.680 I'm finding myself kind of internally battling because I'm to be honest, I'm I'm 363 00:31:37.799 --> 00:31:45.240 more of a I don't like when there's millions of prop options. But with 364 00:31:45.359 --> 00:31:48.839 that said, I'm also thinking of you know, sometimes you get these really 365 00:31:48.960 --> 00:31:56.559 nice, I mean very powerful components, you know, from some libraries somewhere, 366 00:31:56.599 --> 00:31:59.079 and they do have you know, just by the way you know the 367 00:31:59.160 --> 00:32:02.720 functionality provide, you have many many options. I guess, so maybe what 368 00:32:02.839 --> 00:32:10.519 I should should refine that is when there's you know, twenty required properties for 369 00:32:10.640 --> 00:32:15.400 a component, then it's then it's a little bit somehow that's a bit of 370 00:32:15.440 --> 00:32:20.000 a smell. I think you're throwing too many things around, but you know, 371 00:32:20.160 --> 00:32:23.200 like optional stuff. Then I guess maybe that's maybe that's where I would 372 00:32:23.279 --> 00:32:31.559 would draw the line. But yeah, it depends for me. Like again, 373 00:32:31.599 --> 00:32:37.519 I typically try to use or have Yeah, I would say like four 374 00:32:37.599 --> 00:32:39.839 or five props. I just I can't think of an example where I have 375 00:32:40.400 --> 00:32:45.960 a lot of stuff going around and in terms, I am more of a 376 00:32:46.559 --> 00:32:54.279 instead of context. I typically use reducts for when there's something shared. I 377 00:32:54.920 --> 00:33:00.480 typically I just haven't I haven't used context. But at the end of the 378 00:33:00.599 --> 00:33:04.160 day, it's they're quite similar, right, like a reduct slice and contexts. 379 00:33:04.279 --> 00:33:07.880 Right, you can grab at stuff where you need it across across multiple 380 00:33:07.920 --> 00:33:14.400 components. But yeah, I'm not sure if I answered your question, I 381 00:33:14.480 --> 00:33:19.480 I just lean more towards For me, it always comes back to kent, 382 00:33:19.599 --> 00:33:24.400 do I understand what this one component's doing? And typically from the mental overhead 383 00:33:24.480 --> 00:33:30.119 is you know three four required props is probably good. If you've got more, 384 00:33:30.240 --> 00:33:34.880 maybe you still need you need some other components in between, or or 385 00:33:35.519 --> 00:33:39.960 you need to move your state higher up into reducts or it does depend. 386 00:33:40.039 --> 00:33:45.920 It does depend. But yeah, that's I guess my general opinion there. 387 00:33:49.400 --> 00:33:55.000 Yeah, that's I think. One thing I know. I'm actually I think 388 00:33:55.160 --> 00:34:02.079 one thing if you a little is that, Yeah, the kind of abuse 389 00:34:02.160 --> 00:34:07.760 context in the way that they try to don't context the context API to redogs 390 00:34:08.039 --> 00:34:12.719 because I, yeah, I've seen a lot of people finding me context APR 391 00:34:13.239 --> 00:34:16.480 work for state management, right, I think that's an issue that's kind of 392 00:34:17.320 --> 00:34:22.800 very presented. So many could bees and like why don't you just use redogs 393 00:34:22.920 --> 00:34:28.039 like you want, Like this is actually just managing the state of the application, 394 00:34:28.199 --> 00:34:32.920 and then you'll see context with the miss of you use reducers and and 395 00:34:34.199 --> 00:34:37.440 that's the sure John good quite too. I think, Yeah, I think 396 00:34:37.559 --> 00:34:42.719 I get your point on using redocs as because I think that's very much, 397 00:34:43.360 --> 00:34:47.159 very very much preferred because yeahally acknowledge that, yeah, you have a kind 398 00:34:47.159 --> 00:34:51.679 of the global STI you need to work with, and they use redocs for 399 00:34:51.800 --> 00:34:54.840 that. Yeah, I think that's that's the okay as well? What do 400 00:34:54.880 --> 00:34:59.800 you think? Look as I think I answer with Chris on this, like 401 00:35:00.039 --> 00:35:04.639 the most important metric is if you can look at the component and understand its 402 00:35:04.679 --> 00:35:09.199 responsibility and you can understand why it depends on the things that it's asking. 403 00:35:09.800 --> 00:35:16.400 So why is this component requesting those properties to render? If the if you 404 00:35:16.480 --> 00:35:21.920 can look at each of the properties and you can understand why they're being asked, 405 00:35:22.519 --> 00:35:27.320 then I think that's a good metric for success. And I also agree 406 00:35:27.360 --> 00:35:32.719 with lifting states to react to reducts when there's just too much going on in 407 00:35:32.840 --> 00:35:39.159 the component itself. So yeah, I actually think that I agree completely with 408 00:35:40.159 --> 00:35:45.719 with your opinion on this, Chris. Yeah, and also I should mention 409 00:35:45.119 --> 00:35:51.159 so for listeners, I would also avoid don't just think, oh, I'm 410 00:35:51.199 --> 00:35:57.079 going to put every single state variable in reducts. I used to that was 411 00:35:57.159 --> 00:35:59.800 almost, you know, when I was starting out, that's almost the pattern 412 00:35:59.840 --> 00:36:02.400 I would go for. But then you realize when you have you know, 413 00:36:02.599 --> 00:36:07.960 then your reducs, then your reducts state itself is also looking you know, 414 00:36:07.079 --> 00:36:12.519 humongous with fifty properties, and then you realize, you know, there's there's 415 00:36:12.519 --> 00:36:15.360 a reason for the U state, you know, a local state variable. 416 00:36:15.159 --> 00:36:20.000 There's a reason for that. It doesn't need to run through your entire reducs 417 00:36:20.079 --> 00:36:23.159 tree. I just I think I'm thinking of examples. I think I was 418 00:36:23.239 --> 00:36:28.400 doing that. I think Peter was mentioned like with forms, I was throwing 419 00:36:28.440 --> 00:36:31.840 the whole form state into the reduct store. But it's like I don't need 420 00:36:31.920 --> 00:36:35.880 that. The form lives here in this component, like it makes sense, 421 00:36:36.199 --> 00:36:43.519 like keep it there. So yeah, don't don't don't throw everything into reducts. 422 00:36:43.519 --> 00:36:45.880 I guess really really think about what needs to be shared and where. 423 00:36:47.559 --> 00:36:53.400 Yeah, that that one is definitely a very important device. I think especially 424 00:36:53.559 --> 00:37:00.880 for davs, they are getting used two to the events pattern. It's just 425 00:37:01.119 --> 00:37:05.320 so easy. And by the way, for those of you that may not 426 00:37:05.480 --> 00:37:08.440 know it from by this name, like REDUCS is just event sarcing. At 427 00:37:08.480 --> 00:37:13.239 the end of the day, people say, oh, the redux pattern or 428 00:37:13.320 --> 00:37:20.199 the flux pattern, but it's events surcing. It actually is event surcing. 429 00:37:20.320 --> 00:37:27.159 That's the original technical name. And for everyone that learns events sarsing is just 430 00:37:28.079 --> 00:37:32.039 such a mind blowing moment. They're like, oh, my god, yes, 431 00:37:32.400 --> 00:37:37.679 why didn't I ever think of isolating things and building a stake machine? 432 00:37:37.239 --> 00:37:42.079 And then people start thinking that that's the answer for everything. You know, 433 00:37:42.559 --> 00:37:50.360 I myself, I got a bit crazy about SQRS, so I don't know, 434 00:37:50.559 --> 00:37:57.159 that's not like super common. But QRS stands for command uvery responsibility segregation, 435 00:37:57.800 --> 00:38:05.000 and it's basically when you isolate the actions from the events. So the 436 00:38:05.199 --> 00:38:09.840 actions are the things that actually mutate or that can cause a mutation, and 437 00:38:10.000 --> 00:38:19.239 the events are just things that already happened and they state the changes that they 438 00:38:19.280 --> 00:38:28.719 applied. So what we currently call actions in reducts is probably it's generally a 439 00:38:28.880 --> 00:38:35.159 mix of what we would call commands and what we would call queries. But 440 00:38:35.440 --> 00:38:42.599 if you have an entire system that uses QRS, then you have like such 441 00:38:42.800 --> 00:38:49.320 great scalability because every time that you're just making queries, those queries can be 442 00:38:50.960 --> 00:38:55.119 getting the data from replicas of the original database, and those replicas can be 443 00:38:55.239 --> 00:39:01.039 read only because they're not going to change anything. They're just queries, immutable 444 00:39:01.119 --> 00:39:05.760 queries, right. It's also so much easier for you to cash and then 445 00:39:06.239 --> 00:39:10.719 everything that changes the state is isolated in the commands, and these commands have 446 00:39:10.920 --> 00:39:16.679 to talk directly to the instances of the database that actually can make changes and 447 00:39:16.760 --> 00:39:22.159 that replicate the state to the to the read only replicas. So it's like 448 00:39:22.280 --> 00:39:30.599 this gigantic infrastructure mostly for back end applications. I never seen it being done 449 00:39:30.599 --> 00:39:37.199 in the front end. So it's like this entire architecture pattern to have like 450 00:39:37.519 --> 00:39:44.119 really scalable back end applications. And it all starts from events sourcing, and 451 00:39:45.880 --> 00:39:51.480 I was guilty of like getting into events surcing, learning about secure ass and 452 00:39:51.599 --> 00:39:54.599 thinking this is the way everything needs to be built. Like if I do 453 00:39:54.760 --> 00:39:59.440 a back end today, it needs to be in secure ass. Like I'm 454 00:39:59.519 --> 00:40:04.599 gonna have infinite scalability. I'm never gonna have to worry about data migrations ever 455 00:40:04.679 --> 00:40:08.280 again, because I have every single event that ever happened in my application. 456 00:40:08.519 --> 00:40:14.119 Everything is going to be event first. But if you try to do it, 457 00:40:14.480 --> 00:40:21.119 it's just such a pain. It's just so much boilerplate. There's no 458 00:40:22.039 --> 00:40:30.760 everything is eventually consistent is not immediately consistent. And another big issue is that 459 00:40:30.400 --> 00:40:37.039 even if you're just starting your new project, you're already starting with like such 460 00:40:37.079 --> 00:40:42.119 a big overhead in terms of actual server costs. Because with that structure, 461 00:40:42.199 --> 00:40:46.480 if you really wanted to be scalable, then you would at least isolate the 462 00:40:49.280 --> 00:40:55.079 the command processors from the query processors, and that alone, you're already introducing 463 00:40:55.119 --> 00:41:00.159 a micro service approach from day one. So it's like, is such a 464 00:41:00.360 --> 00:41:06.440 high complexity to just start a project that way? That over time I realized 465 00:41:06.440 --> 00:41:13.199 that, yep, this is great when the project I'm working on actually becomes 466 00:41:13.280 --> 00:41:19.480 the next Instagram before that, and that's really there's really no need. So 467 00:41:19.719 --> 00:41:23.719 yeah, there are like multiple layers of thinking that events sourcing is the final 468 00:41:23.800 --> 00:41:31.760 answer, but really it always adds complexity, so we need to keep that 469 00:41:31.880 --> 00:41:37.079 in mind. Are we really okay with having that level of complexity right now, 470 00:41:37.840 --> 00:41:43.159 or should we just keep that in the backlog or when we actually need 471 00:41:43.239 --> 00:41:46.039 that level of scalability. Yeah, I think that brings up a good point 472 00:41:46.159 --> 00:41:51.400 too in general, like what we were mentioning, like if you're trying to 473 00:41:51.440 --> 00:41:55.800 throw everything into reducs or some higher state, is this concept of performance right, 474 00:41:55.840 --> 00:42:01.840 because this whole prop story is more or less what controls the re rendering. 475 00:42:02.360 --> 00:42:06.079 Right. Of course, the IU may have internal state in your in 476 00:42:06.199 --> 00:42:09.880 your components which causes rerendering, but it's also the props. So when you 477 00:42:10.000 --> 00:42:15.480 have you know, who knows, fifteen to twenty props one may be changing 478 00:42:15.039 --> 00:42:17.960 you. If you've got that many props going around, you may not even 479 00:42:19.039 --> 00:42:23.119 realize am I even using this? Do I only need this initially? So 480 00:42:23.280 --> 00:42:27.760 all these, all these things at the end of the day can can impact 481 00:42:27.800 --> 00:42:31.440 performance. So if you're not careful and you know, taking too much advantage 482 00:42:31.440 --> 00:42:37.880 of this, this whole flexible react ecosystem, I think eventually if it can 483 00:42:37.960 --> 00:42:45.039 come and hitch you with with performance. So you know, yeah, I 484 00:42:45.119 --> 00:42:49.679 think we've we've kept repeating this the whole show, but it really does come 485 00:42:49.760 --> 00:42:53.440 down to not only readability, but you know, what is this component doing, 486 00:42:54.280 --> 00:43:00.800 What does it really need in terms of props and state and and and 487 00:43:00.960 --> 00:43:06.519 go from there and and not just not just take advantage of the flexibility of 488 00:43:06.800 --> 00:43:10.719 reacting throw everything in some some giant state or some some giant proper somewhere. 489 00:43:12.000 --> 00:43:15.840 Yeah, I kind of agree with what christis as well. So the best 490 00:43:15.920 --> 00:43:21.320 mode does bloot you redog store? Yeah, it does blooded with so many 491 00:43:21.400 --> 00:43:25.840 properties good to affect performance because at the you know it did's you kind of 492 00:43:25.960 --> 00:43:34.840 like cool javascripts, right, just saving data the bigger auditor is right. 493 00:43:35.039 --> 00:43:38.719 Procession is going to take time and approval and so on and so so also 494 00:43:38.760 --> 00:43:45.880 the times to just use some use local states for certain actions and then also 495 00:43:46.280 --> 00:43:51.960 used with dogs when you need to. Like I said, that's why it's 496 00:43:52.880 --> 00:43:58.159 like it's your global states, things that are kind of you feel a kind 497 00:43:58.199 --> 00:44:04.440 of global We kind of need that for setting components all most components, like 498 00:44:04.880 --> 00:44:10.159 putting like worth putting formed data in legal components is kind of yeah, on 499 00:44:10.320 --> 00:44:15.920 the VACU because it's kind of centralized your components. The components house in the 500 00:44:16.000 --> 00:44:22.159 form that there's a US stage they can be used to localize that from data. 501 00:44:22.199 --> 00:44:28.039 So it's actually very best better to use that, right too. I 502 00:44:28.079 --> 00:44:30.719 think I kind of agree with what you said too. It's best to kind 503 00:44:30.760 --> 00:44:39.559 of for work we said, just consider those consider like do not over bluet 504 00:44:39.719 --> 00:44:45.320 or global skits as much as possible. Right, that does minimize issues as 505 00:44:45.400 --> 00:44:50.360 most as possible. Yeah, a lot of a lot of stuff discussed today. 506 00:44:50.840 --> 00:44:54.679 So let's start wrapping up. Let's do some quick promise and then we 507 00:44:54.800 --> 00:45:00.400 can close up this episode. I hope this was helpful for lot of people. 508 00:45:00.480 --> 00:45:02.559 I know that it definitely would have been helpful to me if I were 509 00:45:02.880 --> 00:45:07.960 starting out a lot of things here, like took me a while to get 510 00:45:08.039 --> 00:45:14.519 to the to the state, so I definitely think this would have been a 511 00:45:14.639 --> 00:45:19.960 lot valuable, especially when you're working with other team members. So so yeah, 512 00:45:20.079 --> 00:45:27.440 I think this was really good. I'm gonna do my mind really quickly. 513 00:45:27.559 --> 00:45:30.119 So I'm just going to promote Onvoid. So for those of you that 514 00:45:30.239 --> 00:45:36.119 might not be familiar with that, is you n v O I d unvoid 515 00:45:36.760 --> 00:45:45.920 dot com And basically Void is the safest way to outsource or augment your software 516 00:45:45.960 --> 00:45:54.519 development staff. Why because every single other software development company is going to build 517 00:45:54.559 --> 00:46:00.719 you by the time and resources and Void is the only company that is going 518 00:46:00.800 --> 00:46:06.920 to view you just based on the actual tasks that were delivered, and the 519 00:46:07.039 --> 00:46:10.760 clients only pay after the tasks are approved. So it's not even a matter 520 00:46:10.840 --> 00:46:16.079 of just the Void developers delivering the tasks and saying, hey, okay, 521 00:46:16.239 --> 00:46:20.800 now give me the money. No, it's like they have to deliver and 522 00:46:21.559 --> 00:46:27.239 ask to actually be approved by the client, which guarantees that it's going to 523 00:46:27.320 --> 00:46:32.320 be within the quality standards that the client is expecting. So it's really it's 524 00:46:32.400 --> 00:46:40.719 a very very interesting model, and it's the most meritocratic way to hire an 525 00:46:40.800 --> 00:46:45.440 engineer because you're not just thinking about like, oh, this person is a 526 00:46:45.519 --> 00:46:49.119 junior, this is a plane, this is a senior. No, you're 527 00:46:49.239 --> 00:46:54.079 just hiring Void engineers as if it were a black box, and then you're 528 00:46:54.199 --> 00:46:59.199 just going to pay by what they actually delivered. So I think this is 529 00:46:59.320 --> 00:47:05.480 a much more meritocratic way, even for the engineers themselves, because I know 530 00:47:05.559 --> 00:47:09.639 a lot of great professionals that have three years of experience and they do better 531 00:47:09.760 --> 00:47:15.400 work than other professionals that have ten years of experience. So this model is 532 00:47:15.480 --> 00:47:22.519 actually also beneficial to the engineers because even if they have less work experience. 533 00:47:22.679 --> 00:47:24.880 If they can deliver more, if they do a better work, then they're 534 00:47:24.920 --> 00:47:29.480 going to deliver more points at the end of the day, which is going 535 00:47:29.519 --> 00:47:35.000 to reflect on how much they get paid. So really an interesting model for 536 00:47:35.880 --> 00:47:42.679 both parts. So yeah, if you're interested in either outsourcing your software development 537 00:47:42.760 --> 00:47:47.719 project or just augmenting your staff to do some other tasks that maybe your full 538 00:47:47.800 --> 00:47:54.199 time engineers are just full of other things to do and they can't tackle those 539 00:47:54.280 --> 00:48:00.000 other projects, then definitely take a look at Void dot com. And honestly, 540 00:48:00.119 --> 00:48:05.480 if you're into that, don't take too long because end of the year 541 00:48:05.719 --> 00:48:08.440 is always like kind of crazy. A lot of companies are like approving their 542 00:48:08.480 --> 00:48:15.679 budgets, so they're even there's a real possibility that if you take too long, 543 00:48:15.079 --> 00:48:19.840 I Avoid might just say hey, we're literally out of engineers at the 544 00:48:19.920 --> 00:48:24.400 moment. You're gonna have to wait a while because AVOID engineers are not freelancers, 545 00:48:24.440 --> 00:48:30.280 their employees, so they are hired and trained before before they start doing 546 00:48:30.760 --> 00:48:35.639 client work, so that takes a while. So yeah, this is gonna 547 00:48:35.639 --> 00:48:39.000 be my promo for today. Okay, so Peter, what do you have 548 00:48:39.159 --> 00:48:45.119 for us? Yeah? Well, okay, so not too much willing to 549 00:48:46.440 --> 00:48:57.480 do. Yeah, so I okay, maybe to follow up, I think 550 00:48:57.920 --> 00:49:04.719 I can give up my profile rights to follow on LinkedIn on loo custom setting 551 00:49:04.800 --> 00:49:12.920 posts right on. Yeah, should I share that? Yeah? Sure? 552 00:49:15.320 --> 00:49:19.840 Yeah, yeah, I'm kind of most kind of kind of not too big 553 00:49:19.920 --> 00:49:24.119 on titter kind of I'm just more like a LinkedIn guy. Sounds boring, 554 00:49:24.239 --> 00:49:31.000 but yeah, I just yeah kind of. I just stam on LinkedIn to 555 00:49:35.440 --> 00:49:40.639 just follow with different right too. Yeah, just give misick, let me 556 00:49:40.760 --> 00:49:45.920 share. When you have the link, Peter, you can just send it 557 00:49:45.039 --> 00:49:50.880 in the comments and everyone that is listening to us live will be able to 558 00:49:51.480 --> 00:49:57.639 to see that. Yeah. Sure, I have it here and you pasted 559 00:49:57.679 --> 00:50:05.039 it on the comments. Yeah, all right, okay, Chris, how 560 00:50:05.079 --> 00:50:10.039 about you? Yep, I'm probably just gonna send a link to my blog 561 00:50:10.119 --> 00:50:15.239 again. I have a post that's probably relevant to what we were talking about. 562 00:50:15.360 --> 00:50:19.760 So for people who are maybe brand new to hooks or coming from from 563 00:50:19.840 --> 00:50:24.440 class components, I basically tried to go through the hooks as if it were 564 00:50:24.519 --> 00:50:30.119 alphabet soup. So really ABC, very small variables, and you know this, 565 00:50:30.480 --> 00:50:31.840 this is what U state does, This is what use effect does. 566 00:50:32.639 --> 00:50:36.199 Looking at it now, I think I have to I think that I have 567 00:50:36.320 --> 00:50:40.599 to add a few more examples, but but yeah, I'll just I'll post 568 00:50:40.840 --> 00:50:45.639 the link to that that post there. I think it's a good introduction without 569 00:50:45.039 --> 00:50:52.719 without involving any other complicated actual effects from some project or whatever. Really just 570 00:50:52.800 --> 00:50:57.840 focuses on what are hooks from the ground up? All right, cool? 571 00:50:57.960 --> 00:51:01.519 Cool, A lot of a lot of learning material from you. Two how 572 00:51:01.559 --> 00:51:07.280 about you check yep. So two things. One is you can go to 573 00:51:07.920 --> 00:51:09.119 if you go to react round up dot com, or you can go to 574 00:51:09.159 --> 00:51:15.239 topendevs dot com and click on react round Up. There's gonna be an option 575 00:51:15.440 --> 00:51:20.760 on there for you to get the premium version of the podcast, which is 576 00:51:20.840 --> 00:51:27.599 effectively no ads. The other thing that it does is I'm going to be 577 00:51:27.639 --> 00:51:31.159 doing a monthly call. It'll be on stream Yard like this, except it's 578 00:51:31.239 --> 00:51:35.760 using the webinar features, so you'll actually be in stream Yard. And what 579 00:51:35.840 --> 00:51:38.719 we're gonna do during those calls is we're going to discuss the show. So 580 00:51:39.639 --> 00:51:44.519 I'm going to be getting ideas from the listeners and from the other hosts. 581 00:51:44.800 --> 00:51:46.800 So I'll invite the other hosts. This is news to them, by the 582 00:51:46.840 --> 00:51:51.880 way, I just lined this up. But what we'll do is then if 583 00:51:51.960 --> 00:51:53.079 there's a person that you want to hear from, So let's say you want 584 00:51:53.119 --> 00:51:57.960 to hear from Dan Abramoff again, or you know, let's see if we 585 00:51:57.960 --> 00:52:00.880 can get Jordan walk even though he's working on something mouse now, to come 586 00:52:00.920 --> 00:52:05.400 in and tell us more stories about working on Facebook or whatever. Right, 587 00:52:06.639 --> 00:52:09.840 So we'll get them in and then I can have my team go invite them 588 00:52:09.880 --> 00:52:13.159 and say, hey, the listeners wanted to have you on, or hey, 589 00:52:13.239 --> 00:52:15.880 the hosts wanted to have you on, and we can have that all 590 00:52:15.920 --> 00:52:20.960 put together and figure it out. So those are the two things. We're 591 00:52:21.039 --> 00:52:24.840 actually on the cusp of launching our app that has the content in it, 592 00:52:24.920 --> 00:52:29.280 so you can either get the premium content there or when you sign up, 593 00:52:29.320 --> 00:52:35.199 you'll also get an email that basically says, hey, here's a private RSS 594 00:52:35.280 --> 00:52:37.800 feed for you to add to your podcast app so that you can just get 595 00:52:37.840 --> 00:52:42.280 it with all of your other podcasts and then you can unsubscribe from the main 596 00:52:42.400 --> 00:52:45.360 feed and you can just subscribe to the ad free feed. Cool. So 597 00:52:45.639 --> 00:52:50.280 I think this is all for today. Everyone, thanks for tune in, 598 00:52:50.719 --> 00:52:52.880 and we'll see you in the next one.