WEBVTT 1 00:00:00.040 --> 00:00:02.520 If you're a React developer, or maybe just you know, 2 00:00:02.640 --> 00:00:06.240 really curious about how these cutting edge web applications get built, 3 00:00:06.519 --> 00:00:09.119 you've probably felt this. Oh yeah, the React ecosystem is 4 00:00:09.160 --> 00:00:13.560 just huge. It's this sprawling, constantly evolving universe. It really is, 5 00:00:13.679 --> 00:00:16.079 And it's easy to feel a bit lost right with 6 00:00:16.199 --> 00:00:19.640 all the tools, the libraries, the best practices changing all 7 00:00:19.679 --> 00:00:20.039 the time. 8 00:00:20.120 --> 00:00:22.839 Absolutely, you might see a job posting with like a 9 00:00:22.879 --> 00:00:27.359 dozen technologies you've barely heard of. It can feel pretty overwhelming, 10 00:00:27.480 --> 00:00:29.800 like trying to map a whole galaxy totally. 11 00:00:30.359 --> 00:00:33.200 Well, today we're diving in. Our mission here is to 12 00:00:33.240 --> 00:00:37.359 try and turn that feeling of overwhelm into well confidence, 13 00:00:38.039 --> 00:00:39.200 confident understanding. 14 00:00:39.320 --> 00:00:40.079 Sounds like a plan. 15 00:00:40.600 --> 00:00:45.039 We're digging deep into an incredible source, the book React 16 00:00:45.079 --> 00:00:48.479 in Depth by Morton Berkland. He's a staff engineer at Quirky, 17 00:00:48.679 --> 00:00:52.000 a medical AI startup, and has get this over two 18 00:00:52.039 --> 00:00:53.520 decades in front end development. 19 00:00:53.600 --> 00:00:56.399 Wow. Yeah, it's a seriously insightful book. So we're going 20 00:00:56.439 --> 00:00:59.240 to pull out the most critical bits, maybe uncover some 21 00:00:59.359 --> 00:01:01.240 surprising facts along the way. 22 00:01:01.200 --> 00:01:03.600 Exactly, and help you connect the dots across some pretty 23 00:01:03.600 --> 00:01:04.560 complex topics. 24 00:01:04.840 --> 00:01:09.239 Think of this as your personal guide navigating the React universe, 25 00:01:09.400 --> 00:01:12.079 pointing out the really important stars you should probably focus on. 26 00:01:12.120 --> 00:01:15.879 Okay, let's start with that vast ecosystem. Then the book 27 00:01:15.920 --> 00:01:19.719 calls it a vast collection of libraries and tools, not 28 00:01:19.840 --> 00:01:23.439 just React itself, but everything orbiting it. It feels massive, 29 00:01:23.640 --> 00:01:24.120 it does. 30 00:01:24.319 --> 00:01:26.319 But what's interesting, I think is that tools in the 31 00:01:26.319 --> 00:01:30.239 same category aren't always just competitors. Oh yeah, the book 32 00:01:30.280 --> 00:01:33.040 says some augment one another, so you might actually use 33 00:01:33.079 --> 00:01:34.879 several together in one project. 34 00:01:35.400 --> 00:01:36.640 Like what give me an example. 35 00:01:36.959 --> 00:01:40.439 Okay, take testing. You could easily use just for your 36 00:01:40.560 --> 00:01:43.640 unit tests, React Testing library for you know, checking how 37 00:01:43.719 --> 00:01:47.719 components render, maybe Puppeteer for end to end stuff, and 38 00:01:47.879 --> 00:01:49.159 Karma for browser testing. 39 00:01:49.280 --> 00:01:51.599 Ah okay, so they all have their own job within 40 00:01:51.680 --> 00:01:52.680 testing exactly. 41 00:01:52.719 --> 00:01:55.599 They play different roles in like a complete testing strategy. 42 00:01:55.799 --> 00:01:58.359 So what does this mean for you the listener, when 43 00:01:58.400 --> 00:02:01.840 you're scanning job posts or maybe kicking off a new project. 44 00:02:02.120 --> 00:02:03.239 How do you make sense of it all? 45 00:02:03.439 --> 00:02:05.920 Well, that really brings us to understanding the technology stack. 46 00:02:06.079 --> 00:02:09.719 It's super important, right, yeah, it defines the specific tools 47 00:02:09.800 --> 00:02:11.080 chosen for that project. 48 00:02:11.159 --> 00:02:11.360 Yeah. 49 00:02:11.360 --> 00:02:14.400 I mean the term full stack developer literally comes from 50 00:02:14.439 --> 00:02:17.199 someone working across the whole thing front in the back end. 51 00:02:17.280 --> 00:02:20.319 Right, it's how all those individual pieces, those libraries and 52 00:02:20.400 --> 00:02:24.120 tools fit together to make something that actually works precisely. 53 00:02:24.159 --> 00:02:26.919 And we're talking about a lot here. UI libraries like material, 54 00:02:27.080 --> 00:02:29.199 UI tailwind, CSS, uh. 55 00:02:29.199 --> 00:02:32.800 Huh, cssn JS, things like styled components. 56 00:02:32.360 --> 00:02:35.039 Data management tools like redex Toolkit. 57 00:02:34.680 --> 00:02:39.400 Or zoos stand, even authentication providers AUTHO, Firebase, stuff like that. 58 00:02:39.520 --> 00:02:41.919 In the book gives examples, right, like different kinds of stacks. 59 00:02:42.000 --> 00:02:45.560 Yeah, it does. It mentions an enterprise stack maybe React 60 00:02:45.599 --> 00:02:49.599 with typescript, Apollo for data, style components for styling, you know, 61 00:02:49.719 --> 00:02:53.560 focused on robustness. We're maybe a rapid prototyping stack using 62 00:02:53.599 --> 00:02:56.840 tools like next JS, Redwood JS or remix, where the 63 00:02:56.879 --> 00:02:59.879 priority is speed overcrafting a totally unique U. 64 00:03:00.599 --> 00:03:05.120 Gotcha. Okay, So moving from that big picture ecosystem down 65 00:03:05.120 --> 00:03:08.439 to the nitty gritty blueprints, let's talk about building stable, 66 00:03:08.520 --> 00:03:14.840 scalable REACT projects. The book highlights three core design patterns, provider, composite, 67 00:03:15.000 --> 00:03:15.599 and summary. 68 00:03:16.039 --> 00:03:17.639 Yes, these are fundamental. 69 00:03:17.719 --> 00:03:20.080 Can you walk us through though, starting with provider. 70 00:03:19.719 --> 00:03:22.719 Sure, the provider pattern is, well, it's way more than 71 00:03:22.759 --> 00:03:26.039 just a minor thing. It's really foundational for how you 72 00:03:26.759 --> 00:03:30.639 distribute and organize data and functionality across your whole app. 73 00:03:30.919 --> 00:03:33.919 Distribute data so avoiding prop. 74 00:03:33.759 --> 00:03:37.159 Drilling exactly, that's a huge part of its genius. No 75 00:03:37.280 --> 00:03:40.159 more passing props down ten levels when only the bottom 76 00:03:40.159 --> 00:03:41.919 component needs it. Nightmare. 77 00:03:42.280 --> 00:03:43.840 Ugh yeah, been there right. 78 00:03:44.039 --> 00:03:49.800 A provider lets you just inject that global stuff, user off, theme, settings, whatever, 79 00:03:49.879 --> 00:03:53.800 directly where it's needed. Cleans up the component tree massively. 80 00:03:53.439 --> 00:03:55.639 Makes refractoring easier too, I bet totally. 81 00:03:55.800 --> 00:03:58.599 And you might have like dozens of contexts on many 82 00:03:58.680 --> 00:04:02.240 layers for global, starf or even local features. There are 83 00:04:02.240 --> 00:04:05.599 even tools like recontextual the book mentions to help manage that, 84 00:04:05.719 --> 00:04:06.639 especially with types. 85 00:04:06.759 --> 00:04:08.719 Okay, that makes a lot of sense. So building on that, 86 00:04:09.080 --> 00:04:12.280 what about the composite pattern how does that help structure components? 87 00:04:12.400 --> 00:04:16.040 Right? Composite, So imagine a really complex component, say a 88 00:04:16.120 --> 00:04:19.920 radio group, instead of building one giant, monolithic. 89 00:04:19.439 --> 00:04:21.240 Thing which can get messy fast. 90 00:04:21.319 --> 00:04:25.920 Exactly, the composite pattern says, break it down, makes smaller subcomponents, 91 00:04:25.959 --> 00:04:29.399 maybe a radio group itself, a radio option or radio. 92 00:04:29.160 --> 00:04:30.639 Label, and they talk to each other. 93 00:04:30.800 --> 00:04:34.120 Yeah, they communicate using contexts often provided by the main 94 00:04:34.160 --> 00:04:37.920 wrapper component. The book says this leads to cleaner, more 95 00:04:37.959 --> 00:04:39.879 readable code that's easier. 96 00:04:39.519 --> 00:04:42.920 To maintain, transforming those rigid structures. 97 00:04:42.399 --> 00:04:46.879 Into something flexible, scalable. It's like a harmonious symphony. As 98 00:04:46.879 --> 00:04:50.920 the book puts, it makes components reusable. Let's developers compose 99 00:04:51.040 --> 00:04:53.160 UIs really flexibly nice? 100 00:04:53.360 --> 00:04:56.800 Okay. Third one, the summary pattern. What's the goal with 101 00:04:56.839 --> 00:04:57.199 that one? 102 00:04:57.319 --> 00:05:02.000 Summary is all about giving your components a makeover, making 103 00:05:02.040 --> 00:05:06.879 them look more streamlined, sophisticated. Basically, you pack the complex logic, 104 00:05:06.920 --> 00:05:10.680 the business logic, into custom hooks like use task list 105 00:05:10.839 --> 00:05:11.959 or use new task input. 106 00:05:12.079 --> 00:05:14.040 Ah. So you pull the logic out of the main 107 00:05:14.079 --> 00:05:15.319 component body exactly. 108 00:05:15.360 --> 00:05:18.120 You tidy up all that code above the JSX return statement. 109 00:05:18.319 --> 00:05:21.560 It simplifies the component file itself a lot, makes collaboration 110 00:05:21.680 --> 00:05:24.680 easier because the component's interface is just cleaner, more readable. 111 00:05:24.959 --> 00:05:27.000 You separate the what's from the how cool? 112 00:05:27.079 --> 00:05:30.519 Okay, let's shift gears performance. This is a big one. 113 00:05:30.639 --> 00:05:34.240 Often chops people up. Why react components rerender? 114 00:05:34.519 --> 00:05:36.759 Ah? Yes, the classic question. 115 00:05:36.920 --> 00:05:39.639 There's this common idea, right that they rerender just because 116 00:05:39.680 --> 00:05:43.000 their probs change. But the book says, flat out changing 117 00:05:43.040 --> 00:05:44.199 properties is irrelevant. 118 00:05:44.399 --> 00:05:47.600 Yeah, that myth needs busting, it's not why they rerender. 119 00:05:47.920 --> 00:05:51.240 So if that's wrong, what are the actual rules when 120 00:05:51.279 --> 00:05:52.560 does a component rerender? Okay? 121 00:05:52.560 --> 00:05:54.360 The book is very clear here. It says a component 122 00:05:54.439 --> 00:05:58.399 only rerenders if one it's just been mounted, two its 123 00:05:58.480 --> 00:06:01.480 parent component just re rendered, or three it uses a 124 00:06:01.480 --> 00:06:04.839 hook like use state or use reducer that has flagged 125 00:06:04.839 --> 00:06:06.199 the component for a rerender. 126 00:06:06.399 --> 00:06:07.839 That's it, Just those three. 127 00:06:07.720 --> 00:06:10.800 That's it. It contradicts that common idea about props and 128 00:06:10.920 --> 00:06:15.600 highlights some subtle timing things react handles internally. Not understanding 129 00:06:15.600 --> 00:06:17.360 this can lead to performance headaches. 130 00:06:17.439 --> 00:06:20.480 Right, So, knowing those rules, how do we actually make 131 00:06:20.519 --> 00:06:24.199 our apps faster? Minimize those and necessary it renders? That 132 00:06:24.240 --> 00:06:26.120 brings us to memoization, doesn't it? 133 00:06:26.279 --> 00:06:26.439 Ya? 134 00:06:26.480 --> 00:06:26.800 It does. 135 00:06:26.920 --> 00:06:31.279 Memorization is key. It's basically remembering the last input and 136 00:06:31.279 --> 00:06:34.920 output of a pure function to avoid doing expensive calculations 137 00:06:34.959 --> 00:06:36.839 again if the input hasn't. 138 00:06:36.560 --> 00:06:38.319 Changed, like cashing the result. 139 00:06:38.519 --> 00:06:41.639 Pretty much, And this applies to components using memo or 140 00:06:41.680 --> 00:06:45.120 specific values with used memo or functions with use callback 141 00:06:45.439 --> 00:06:48.000 strategic caching to stop redundant work. 142 00:06:48.519 --> 00:06:51.519 Okay, and speaking of use memo and use callback, yeah, 143 00:06:51.600 --> 00:06:53.920 those dependency arrays, they can be tricky. 144 00:06:54.040 --> 00:06:57.800 Oh yeah, getting them right is crucial both for performance 145 00:06:57.879 --> 00:06:58.680 and correctness. 146 00:06:58.879 --> 00:07:01.839 So what exactly counts as a dependency? What goes in 147 00:07:01.879 --> 00:07:03.120 the array? Good question? 148 00:07:03.240 --> 00:07:06.600 The book clarifies it's any local variable that exists inside 149 00:07:06.600 --> 00:07:08.279 the component's scope. 150 00:07:08.000 --> 00:07:10.120 Not stuff from outside right imports? 151 00:07:10.279 --> 00:07:13.439 Nope, not variables from outside the component, not imports. That's 152 00:07:13.439 --> 00:07:16.560 a common confusion point, and crucially, sometimes you can even 153 00:07:16.600 --> 00:07:20.120 skip listing variables if they're guaranteed to be stable. Stable 154 00:07:20.199 --> 00:07:22.199 like what like the set open function you get back 155 00:07:22.199 --> 00:07:25.079 from you state it never changes, so you don't technically 156 00:07:25.120 --> 00:07:28.199 need to list it. Knowing that can make your dependency 157 00:07:28.240 --> 00:07:32.399 arrays cleaner and easier to understand. Prevents unnecessary reruns too. 158 00:07:32.839 --> 00:07:36.399 Huh. Okay, that's useful detail. All right, Let's look beyond 159 00:07:36.519 --> 00:07:41.240 just the React code itself. How do we ensure quality, consistency, 160 00:07:41.519 --> 00:07:48.920 effective collaboration. The book gives four guideposts linting, formatting, property constraints, 161 00:07:48.959 --> 00:07:49.759 and debugging. 162 00:07:49.920 --> 00:07:52.040 Yeah, the tooling and practices around the code. 163 00:07:52.160 --> 00:07:54.399 Let's start with linting. What's its job? 164 00:07:54.800 --> 00:07:58.120 Think of linting using tools like es lint as like 165 00:07:58.160 --> 00:08:01.120 a smart grammar checker for your code. Okay, it helps 166 00:08:01.199 --> 00:08:04.680 catch potential errors that come from JavaScript's quirks. You know, 167 00:08:04.720 --> 00:08:09.720 it's language weirdness, and it enforces team best practices. 168 00:08:09.240 --> 00:08:11.600 And it can fix things automatically. 169 00:08:11.240 --> 00:08:13.839 A huge percentage. Yeah, it can fix a huge percentage 170 00:08:13.839 --> 00:08:17.480 of these violations automatically. Cash is stuff early streamlines development 171 00:08:17.560 --> 00:08:18.000 quite a bit. 172 00:08:18.079 --> 00:08:20.519 Okay. Then there's formatting, usually with Prettier. How's that different 173 00:08:20.519 --> 00:08:22.399 from linting linting check style too? 174 00:08:22.480 --> 00:08:25.800 Sometimes it does, but Prettier focuses only on formatting, and 175 00:08:25.839 --> 00:08:28.560 the book says it's smart. It doesn't just follow simple 176 00:08:28.680 --> 00:08:32.720 rules blindly moving smart. It adapts dynamically to the code 177 00:08:32.759 --> 00:08:37.320 in question, using whatever formatting looks best for readability. It 178 00:08:37.559 --> 00:08:42.080 basically ends the subjective arguments about code style. Let the tool. 179 00:08:41.879 --> 00:08:43.519 Handle It takes the debate out. 180 00:08:43.360 --> 00:08:46.919 Of it, exactly, And the book also mentions editor can 181 00:08:46.919 --> 00:08:51.360 fig for basic stuff like indentation, line endings, foundational rules 182 00:08:51.360 --> 00:08:52.840 that work across different editors. 183 00:08:53.000 --> 00:08:56.480 Got it, So code Thatt's good follows practices. What about 184 00:08:56.519 --> 00:08:58.559 property constraints? Is that like prop types? 185 00:08:58.759 --> 00:09:02.240 Yeah? Exactly? Using reacts built in prop type system it 186 00:09:02.279 --> 00:09:04.879 makes your components more robust and easier to use because 187 00:09:04.879 --> 00:09:08.240 you specify what kind of props, they expect types ranges 188 00:09:08.679 --> 00:09:09.080 maybe if. 189 00:09:09.039 --> 00:09:10.840 They're required, and this helps at runtime. 190 00:09:10.960 --> 00:09:13.320 Yeah, it flags issues at runtime if a component gets 191 00:09:13.399 --> 00:09:17.120 used incorrectly. It's older than Typescript sure, but still offers 192 00:09:17.200 --> 00:09:19.799 valuable run time checks and serves as documentation. 193 00:09:20.039 --> 00:09:24.080 Okay, but even with all that, bugs happen, oh, inevitably 194 00:09:24.320 --> 00:09:29.000 so debugging. The book really emphasizes the React developer tools absolutely. 195 00:09:29.399 --> 00:09:31.799 Their power is that you're working right there in the 196 00:09:31.840 --> 00:09:32.759 live browser environment. 197 00:09:32.840 --> 00:09:33.600 What can you do with them? 198 00:09:33.759 --> 00:09:37.840 You can inspect and manipulate component props, check the values 199 00:09:37.879 --> 00:09:41.279 in stateful hooks, and crucially use the profiler to dig 200 00:09:41.320 --> 00:09:44.159 into performance issues see what's re rendering and why. 201 00:09:44.360 --> 00:09:46.960 And there are other tools too, loads. 202 00:09:47.080 --> 00:09:49.960 Specialized ones like reducs dev tools if you're using reducs, 203 00:09:50.039 --> 00:09:53.679 React Native debugger, React to Tron for electron apps, even 204 00:09:53.759 --> 00:09:57.440 replay dot io for time travel, debugging aerror sessions a 205 00:09:57.440 --> 00:09:58.120 whole arsenal. 206 00:09:58.200 --> 00:10:01.679 Really wow, Okay, now's hit a topic that's huge for 207 00:10:01.799 --> 00:10:02.639 many developers. 208 00:10:03.519 --> 00:10:05.440 Typescript uh typescript. 209 00:10:05.519 --> 00:10:08.360 Yes, the book calls it your bridge to a world 210 00:10:08.480 --> 00:10:11.919 where code becomes more predictable and maintainable. How does it 211 00:10:11.960 --> 00:10:13.080 do that? Well? 212 00:10:13.120 --> 00:10:17.559 Fundamentally, It adds spatic types to JavaScript right, which significantly 213 00:10:17.639 --> 00:10:20.600 reduces the likelihood of runtime errors. Things that would crash 214 00:10:20.639 --> 00:10:23.720 your app in production get caught during development. Plus, it 215 00:10:23.799 --> 00:10:27.440 simplifies collaboration on larger codebases. How So, because the types 216 00:10:27.480 --> 00:10:32.039 act as documentation, you can define union types, interfaces, optional properties. 217 00:10:32.120 --> 00:10:35.080 It brings clarity and confidence, especially when multiple people are 218 00:10:35.080 --> 00:10:36.480 working on complex code. 219 00:10:36.600 --> 00:10:39.960 And the core concept in typescript is generics, right, how 220 00:10:40.000 --> 00:10:41.159 do they help? In React? 221 00:10:41.679 --> 00:10:45.519 Generics are super powerful. They let you create versatile components 222 00:10:45.519 --> 00:10:48.480 that can adapt to different types of content, like a 223 00:10:48.519 --> 00:10:53.000 reusable component exactly. Imagine one pageantable component that works perfectly 224 00:10:53.080 --> 00:10:55.759 for a list of employees and a list of high scores. 225 00:10:56.159 --> 00:10:58.799 Generics make that possible and type safe, and. 226 00:10:58.759 --> 00:10:59.960 You can manipulate types two. 227 00:11:00.639 --> 00:11:03.200 With omit and pick right, you can take an existing 228 00:11:03.240 --> 00:11:07.039 interface and omit certain properties or pick just the ones 229 00:11:07.080 --> 00:11:10.519 you need when extending. It gives you really granular control 230 00:11:10.600 --> 00:11:14.840 over your type definitions. Makes components both powerful and precisely typed. 231 00:11:14.960 --> 00:11:17.919 Okay, so when you use typescript with React toos, you 232 00:11:18.080 --> 00:11:22.080 state use memo, use callback. Are there any common gotcha's 233 00:11:22.320 --> 00:11:23.240 things to watch out for? 234 00:11:23.440 --> 00:11:25.919 Definitely? With you state. You got to be mindful of 235 00:11:26.000 --> 00:11:29.039 initial values that might change type later, like starting is 236 00:11:29.120 --> 00:11:32.480 null exactly null boolean for instance, you need to tell 237 00:11:32.480 --> 00:11:35.679 Typescript that's possible. And while use memo and use callback 238 00:11:35.720 --> 00:11:39.200 are pretty good at inferring types, there are edge cases. Yeah, 239 00:11:39.759 --> 00:11:44.120 edge cases like using forward ref or memo with generic components. 240 00:11:44.200 --> 00:11:47.639 Sometimes Typescript kind of forgets the generic types, so you 241 00:11:47.679 --> 00:11:50.759 might need to give explicit type arguments or use something 242 00:11:50.799 --> 00:11:54.480 called global type augmentation to remind it. Otherwise you lose 243 00:11:54.519 --> 00:11:56.200 the type safety you wanted good to know. 244 00:11:56.480 --> 00:11:59.360 Yeah. The book also mentions the new React compiler. 245 00:11:59.600 --> 00:12:03.879 Yeah Briefly. It suggests the compiler might make explicit memorization 246 00:12:04.039 --> 00:12:07.279 with use memo and use callback less critical in the future, 247 00:12:07.480 --> 00:12:11.080 which could simplify some of this exciting stuff but still evolving. 248 00:12:11.320 --> 00:12:15.480 Interesting. Okay, let's switch focus again Styling CSS and React. 249 00:12:15.879 --> 00:12:18.720 The book talks about the entire reason why CSS and 250 00:12:18.799 --> 00:12:21.919 JS exists. What was wrong with traditional CSS? 251 00:12:22.000 --> 00:12:24.919 Well, the core problem CSS and JS really tries to 252 00:12:24.960 --> 00:12:28.840 solve is collisions. Name collisions right like class names exactly 253 00:12:29.279 --> 00:12:31.720 as your app grows. The book says collisions are likely 254 00:12:31.919 --> 00:12:34.759 because CSS is global by default, you can only have 255 00:12:34.799 --> 00:12:37.519 one class named dot group anywhere in your app, and. 256 00:12:37.440 --> 00:12:39.960 Someone else might use the same name accidentally. 257 00:12:39.559 --> 00:12:45.840 Precisely, leading to styles overwriting each other unexpectedly MESSI. That's 258 00:12:45.840 --> 00:12:49.600 where things like CSS modules came in first, generating unique 259 00:12:49.600 --> 00:12:54.039 class names automatically scoping styles to components right to prevent 260 00:12:54.080 --> 00:12:55.480 those accidental conflicts. 261 00:12:55.600 --> 00:12:58.840 But the book seems to lean more towards styled components 262 00:12:59.000 --> 00:13:00.960 as a popular modern approach. 263 00:13:01.080 --> 00:13:04.159 It does highlight it. Yeah, styled components lets you literally 264 00:13:04.519 --> 00:13:08.519 write your CSS directly inside your JavaScript files, right next 265 00:13:08.559 --> 00:13:12.279 to the components using those styles. Callocation big benefit. Offers 266 00:13:12.320 --> 00:13:15.519 a much better overview of small components. Plus you get 267 00:13:15.559 --> 00:13:18.919 dynamic styling based on props true encapsulation. It's kind of 268 00:13:18.919 --> 00:13:20.559 the default choice for many teams. 269 00:13:20.720 --> 00:13:22.759 The IBM of styling, the book says. 270 00:13:22.639 --> 00:13:25.240 Uh huh, Yeah, nobody gets fired for using it. It's 271 00:13:25.279 --> 00:13:28.879 widely adopted, battle tested, but it's not perfect. No approaches. 272 00:13:29.279 --> 00:13:32.879 The book mentions potential drawbacks like maybe slower build times, 273 00:13:33.200 --> 00:13:36.360 and some argue it blurs the separation of concerns. 274 00:13:35.919 --> 00:13:38.159 Too much, so no single best way. 275 00:13:38.519 --> 00:13:41.000 The book's takeaway is clear, there is no one best 276 00:13:41.000 --> 00:13:44.240 way to style a React application. It really depends on 277 00:13:44.279 --> 00:13:47.039 the project, the team. The requirements makes sense. 278 00:13:47.720 --> 00:13:50.360 Okay, data management, we've touched on U state, but for 279 00:13:50.559 --> 00:13:53.879 really big complex apps you need more, right. The book 280 00:13:53.960 --> 00:13:57.120 uses a goal tragging app example to explore five approaches. 281 00:13:57.399 --> 00:14:01.039 Right beyond just U state or use reducer context, you 282 00:14:01.120 --> 00:14:06.080 have libraries like Redux Toolkit, zoostand x state offering more structure. 283 00:14:06.159 --> 00:14:09.159 What about Immer. You mentioned that with used reducer h Immer. 284 00:14:09.279 --> 00:14:12.279 Yeah, it's often used with US reducer or Redux Toolkit. 285 00:14:12.440 --> 00:14:16.600 It drastically simplifies writing immutable updates. It lets you write 286 00:14:16.639 --> 00:14:19.600 code that looks like you're directly mutating the state, which 287 00:14:19.600 --> 00:14:23.840 you normally shouldn't do exactly, but Immer cleverly intercepts those 288 00:14:23.919 --> 00:14:28.039 mutations and produces a new immutable state object behind the scenes. 289 00:14:28.600 --> 00:14:31.559 The book uses this cool analogy like dark matter. You 290 00:14:31.600 --> 00:14:34.159 don't see the complex mechanics, but it clearly works and 291 00:14:34.240 --> 00:14:36.080 gives you clean immutable state. 292 00:14:36.399 --> 00:14:38.559 That's a neat way to think about it. Now. A 293 00:14:38.600 --> 00:14:41.639 more advanced idea of the book covers is state machines 294 00:14:42.120 --> 00:14:45.440 using x state. That sounds like more than just data storage. 295 00:14:45.200 --> 00:14:48.440 Oh much more. Xdate isn't just about what data you have. 296 00:14:48.559 --> 00:14:52.360 It's about defining the explicit flow of a complex. 297 00:14:51.919 --> 00:14:53.720 Operation, like a user sign up flow. 298 00:14:53.919 --> 00:14:58.480 Perfect example, a multi step signup X state lets you 299 00:14:58.519 --> 00:15:03.279 model all the possible states, entering email, verifying CODs, setting passwords, 300 00:15:03.559 --> 00:15:07.200 and the transitions between them. It makes complex flows much 301 00:15:07.200 --> 00:15:10.919 more predictable and prevents impossible states. You still manage data 302 00:15:11.000 --> 00:15:14.320 within the machine's context, but the focus is on the flow. 303 00:15:14.519 --> 00:15:18.039 Okay, so we have context, redux, zoo stand x state. 304 00:15:18.720 --> 00:15:19.480 How do you choose? 305 00:15:19.919 --> 00:15:22.120 Yeah, that's the million dollar question, isn't it? 306 00:15:22.120 --> 00:15:22.840 It seems like it. 307 00:15:22.960 --> 00:15:24.879 Well, the book notes reducs is still one of the 308 00:15:24.879 --> 00:15:28.559 most used huge community lots of tooling zoostand is described 309 00:15:28.559 --> 00:15:31.039 as maybe the easiest library to use for such a 310 00:15:31.080 --> 00:15:35.919 tiny application because it's simpler, less boilerplate. But ultimately, ultimately, 311 00:15:35.960 --> 00:15:38.279 if you have the choice, the book basically says, go 312 00:15:38.399 --> 00:15:42.559 with whatever is most comfortable for you. Team, familiarity, project needs, 313 00:15:42.600 --> 00:15:45.879 the actual complexity of your state. Those factors usually guide 314 00:15:45.879 --> 00:15:46.360 the decision. 315 00:15:46.480 --> 00:15:49.639 Right, makes sense? Okay, connects to the outside world remote data. 316 00:15:49.799 --> 00:15:52.519 Modern apps almost always talk to server almost always, Yeah, 317 00:15:52.559 --> 00:15:58.039 and the book points out that server complexity brings challenges, latency, security. 318 00:15:57.519 --> 00:16:00.080 Issues, definitely. And this is where library is like tan 319 00:16:00.120 --> 00:16:02.240 stat query formally react query really help. 320 00:16:02.399 --> 00:16:03.080 How do they help? 321 00:16:03.159 --> 00:16:06.639 They formalize things, They structure how you handle remote data 322 00:16:06.679 --> 00:16:09.799 around this common dichotomy queries versus mutations. 323 00:16:10.000 --> 00:16:12.960 Queris fetch data, mutations change it exactly. 324 00:16:13.080 --> 00:16:17.799 Queries fetch, mutations, create, update, delete, And they employ smart 325 00:16:18.000 --> 00:16:22.480 caching strategies like stale wall revalidate, stale wall revalidate. 326 00:16:22.519 --> 00:16:23.679 What's that It means? 327 00:16:23.759 --> 00:16:26.799 If you need data, the library gives you the cached 328 00:16:27.120 --> 00:16:31.080 stale version immediately, so the UI updates fast. Then in 329 00:16:31.120 --> 00:16:33.720 the background it refetches the fresh data from the server 330 00:16:33.840 --> 00:16:37.879 and updates the cash balances responsiveness and freshness clever. 331 00:16:38.279 --> 00:16:40.759 So when there is a delay waiting for the server, 332 00:16:41.039 --> 00:16:42.600 what does that mean for the user? How do we 333 00:16:42.639 --> 00:16:44.320 make that waiting less painful? 334 00:16:44.480 --> 00:16:48.559 Good question. For any noticeable delay, say over one hundred milliseconds, 335 00:16:48.639 --> 00:16:52.720 the book says you absolutely need loading indicators, spinner's progress bar. 336 00:16:52.759 --> 00:16:54.200 Something standard practice. 337 00:16:54.320 --> 00:16:58.919 Yeah, but even better the book suggests are optimistic. 338 00:16:58.200 --> 00:17:01.000 Updates optimist stick. How does that work? 339 00:17:01.200 --> 00:17:05.880 You basically pretend the server requests succeeded immediately you update 340 00:17:05.920 --> 00:17:08.200 the local cash with what we expect the server to 341 00:17:08.240 --> 00:17:10.039 do before you get the confirmation back. 342 00:17:10.200 --> 00:17:11.960 Ah, so the UI updates. 343 00:17:11.640 --> 00:17:15.759 Instant it feels instant. Yeah, perceived instant feedback. If the 344 00:17:15.759 --> 00:17:18.839 server request fails later you roll back the change, But 345 00:17:18.960 --> 00:17:22.079 most of the time it makes the app feel incredibly snappy. 346 00:17:22.160 --> 00:17:24.039 Cool trick. What about partial data? 347 00:17:24.119 --> 00:17:27.359 That's another technique, also called initial data. You show a 348 00:17:27.359 --> 00:17:30.920 skeleton view like gray boxes where text will be or 349 00:17:31.119 --> 00:17:33.960 maybe a description with dots instead of the full text, 350 00:17:34.359 --> 00:17:36.960 missing timestamps perhaps while you wait for the full data. 351 00:17:37.119 --> 00:17:40.640 Gives the user something to see immediately improves perceived performance. 352 00:17:40.839 --> 00:17:45.200 Lots of ways to handle latenciesm okay. Last major topic, testing, 353 00:17:45.640 --> 00:17:48.200 how do we make sure our apps are solid, reliable, 354 00:17:48.440 --> 00:17:51.880 future proof against bugs? Unit testing absolutely trucial. 355 00:17:52.160 --> 00:17:55.960 The book focuses on using vitised and React testing library. 356 00:17:56.079 --> 00:17:57.839 Why those specifically. 357 00:17:57.279 --> 00:18:01.119 Because they encourage writing tests focused on test resilience, tests 358 00:18:01.160 --> 00:18:03.759 that don't break if the JSX changed in even the 359 00:18:03.839 --> 00:18:04.559 slightest way. 360 00:18:04.960 --> 00:18:08.720 So testing behavior not implementation details exactly. 361 00:18:08.759 --> 00:18:12.440 Focus on functionality. Does clicking this button do the right thing? 362 00:18:13.000 --> 00:18:13.079 Not? 363 00:18:13.319 --> 00:18:17.079 Does this button contain this exact CSS class? And the 364 00:18:17.200 --> 00:18:21.119 user Event library is highlighted as great for simulating realistic 365 00:18:21.200 --> 00:18:25.359 user actions, clicking typing makes tests reflect actual usage. 366 00:18:25.440 --> 00:18:28.240 Okay, but components often depend on other things, right, Yeah, 367 00:18:28.359 --> 00:18:32.519 APIs context. How do you test them in isolation? That 368 00:18:32.559 --> 00:18:34.599 brings up mocking dependencies. 369 00:18:34.759 --> 00:18:38.240 Yes, mocking is essential for true unit testing. How do 370 00:18:38.279 --> 00:18:41.240 you test your component without external factors messing things up 371 00:18:41.319 --> 00:18:42.839 or making the test unreliable? 372 00:18:43.119 --> 00:18:44.000 So what can you mock? 373 00:18:44.319 --> 00:18:47.720 You can mock browser APIs like maybe navigator, dot geolocation 374 00:18:47.759 --> 00:18:50.880 if your component uses location. You can mock libraries like 375 00:18:50.960 --> 00:18:53.759 axios if you're making API calls. Or you can even 376 00:18:53.799 --> 00:18:56.880 mock a context provider to give your component specific context 377 00:18:56.960 --> 00:18:58.400 data just for the test. 378 00:18:58.279 --> 00:18:59.640 So you control the environment. 379 00:18:59.319 --> 00:19:03.200 Completely ensure as you're only testing your component's logic, no 380 00:19:03.319 --> 00:19:06.880 flaky tests due to network issues or changes in external services. 381 00:19:07.119 --> 00:19:08.200 Gives you real confidence. 382 00:19:08.359 --> 00:19:10.759 Makes sense? Yeah? Okay. Let's wrap up by looking at 383 00:19:10.799 --> 00:19:15.400 the really big picture building complete web experiences with React, 384 00:19:15.920 --> 00:19:18.799 specifically server side rendering or SSR. 385 00:19:19.000 --> 00:19:21.319 Right, moving beyond client only React. 386 00:19:21.400 --> 00:19:23.720 What's the big win with running React on the server. 387 00:19:24.039 --> 00:19:26.799 The main advantage is it allows you to run React 388 00:19:26.799 --> 00:19:30.079 on the server to generate the initial HTML. This enables 389 00:19:30.319 --> 00:19:32.119 full stack development with React. 390 00:19:32.319 --> 00:19:34.359 One codebase for front and back. 391 00:19:34.279 --> 00:19:37.960 End potentially yeah, or at least much tighter integration. You 392 00:19:38.000 --> 00:19:42.119 get optimal collocation of rendering, logic and data fetching, potentially 393 00:19:42.160 --> 00:19:45.960 simplifying things like API layers, brings the whole stack closer together. 394 00:19:46.039 --> 00:19:47.920 But there's a catch, right, something called hydration. 395 00:19:48.400 --> 00:19:52.640 Ah Yes, hydration crucial detail. It's the process where the 396 00:19:52.680 --> 00:19:55.720 client side Ravascript basically takes over the HTML sent by 397 00:19:55.720 --> 00:19:59.000 the server, attaching event listeners and making it interactive. And 398 00:19:59.000 --> 00:20:01.759 for the performance benefit of SSR to work, the HTML 399 00:20:01.839 --> 00:20:04.799 rented on the client must be identical to the HTML 400 00:20:04.880 --> 00:20:05.559 sent by the server. 401 00:20:05.720 --> 00:20:06.599