WEBVTT 1 00:00:00.160 --> 00:00:03.759 Welcome to the deep dive, where we slice through information 2 00:00:03.839 --> 00:00:06.759 overload to bring you the most important insights from your sources. 3 00:00:07.040 --> 00:00:10.320 Today we're diving deep into reacts core features, drawing from 4 00:00:10.480 --> 00:00:13.880 REACT key concepts and in depth guide to reacts core features. 5 00:00:14.199 --> 00:00:17.600 Our mission to sort of demystify the art of building 6 00:00:17.679 --> 00:00:21.839 dynamic user interfaces from the absolute fundamentals all the way 7 00:00:21.879 --> 00:00:25.640 to cutting edge full stack capabilities. Whether you're a curious learner, 8 00:00:25.719 --> 00:00:28.920 just starting out, or gearing up for a big technical meeting, 9 00:00:29.160 --> 00:00:34.799 we're here to deliver those aha moments and clear actionable insights. Okay, 10 00:00:34.880 --> 00:00:37.320 let's unpack this React as a huge topic. Imagine we're 11 00:00:37.320 --> 00:00:40.759 trying to build some interactive websites starting fresh. What kind 12 00:00:40.759 --> 00:00:42.880 of problems pop up if you try to use just 13 00:00:42.920 --> 00:00:45.079 planal JavaScript? Why not stick with that? 14 00:00:45.200 --> 00:00:47.520 Right? Well, the big challenge with planin JavaScript, especially for 15 00:00:47.560 --> 00:00:50.920 complex UIs, is what we call it's imperative approach. 16 00:00:51.079 --> 00:00:52.719 Imperative meaning you're telling. 17 00:00:52.479 --> 00:00:55.280 The computer every single step to take. Yeah, like construction 18 00:00:55.359 --> 00:00:58.000 after instruction, detailing exactly how to change the UI. 19 00:00:58.159 --> 00:01:02.039 Okay, micromanaging the brain pretty much, and even for fairly 20 00:01:02.079 --> 00:01:03.520 simple things, this can balloon. 21 00:01:03.759 --> 00:01:06.239 You might hit it over underlines the code, and maybe 22 00:01:06.280 --> 00:01:09.560 three quarters of that is just fiddling directly with the dom, 23 00:01:09.840 --> 00:01:13.560 managing its state, all that boilerplate stuff. So naturally this 24 00:01:13.680 --> 00:01:17.280 makes Vanilla JS pretty error prone and honestly just a 25 00:01:17.359 --> 00:01:19.920 huge time sink. It's like being a puppeteer, you know, 26 00:01:20.280 --> 00:01:21.439 pulling every single string. 27 00:01:22.079 --> 00:01:25.680 Yeah, that puppeteer analogy really clicks. Okay, So if that's 28 00:01:25.680 --> 00:01:29.159 the old how what reacts? What what's the philosophy shift? 29 00:01:29.640 --> 00:01:33.640 The shift with React is moving from puppeteer to architect. 30 00:01:33.760 --> 00:01:36.200 Instead of telling the browser how to move every pixel, 31 00:01:36.280 --> 00:01:38.920 you just declare the final blueprint. You focus on the 32 00:01:38.959 --> 00:01:41.120 big picture, the desired end state. 33 00:01:41.480 --> 00:01:41.879 Ah. 34 00:01:42.079 --> 00:01:43.840 So like if a button is clicks, you just tell 35 00:01:43.840 --> 00:01:46.239 React okay, the tech should now be this, and React 36 00:01:46.239 --> 00:01:50.599 figures out the how efficiently it keeps the paragraph updated automatically, so. 37 00:01:50.599 --> 00:01:53.079 It handles the translation exactly. 38 00:01:52.959 --> 00:01:56.480 You describe your ideal UI. React handles the MESSI dom stuff. 39 00:01:56.840 --> 00:01:59.359 It frees you up to focus on your actual business logic, 40 00:01:59.359 --> 00:02:01.680 which is I mean a massive productivity boost. 41 00:02:01.879 --> 00:02:05.280 So for US developers it means letting React handle those 42 00:02:05.439 --> 00:02:09.879 low level dawn interactions. That sounds like a relief. How 43 00:02:09.879 --> 00:02:13.080 do we actually get started. Set up a project good question. 44 00:02:13.560 --> 00:02:16.080 To get going, You typically use a tool like vite. 45 00:02:16.240 --> 00:02:19.039 You run NPM create vite at latest my app in 46 00:02:19.080 --> 00:02:20.960 your terminal than NPM. 47 00:02:20.680 --> 00:02:24.639 Installed Fight Why fyte specifically for learning, It's often recommended 48 00:02:24.680 --> 00:02:26.240 because it's lightweight, super fast. 49 00:02:26.680 --> 00:02:29.960 Frameworks like next dot gs are powerful, absolutely, but they 50 00:02:30.000 --> 00:02:32.240 add their own concepts, their own syntax, which can be 51 00:02:32.280 --> 00:02:33.520 a bit overwhelming. 52 00:02:33.560 --> 00:02:36.520 Right at the start, makes sense, keep it simple initially, right, and. 53 00:02:36.439 --> 00:02:38.719 In that new project, you'll see files like app dot 54 00:02:38.800 --> 00:02:42.319 jsx and main dojsx. That dot jsx just tells you 55 00:02:42.560 --> 00:02:46.919 these files mixed JavaScript with that HTML like syntax called JSX. 56 00:02:47.039 --> 00:02:50.360 Got it JSX, okay, project setup. Now inside the code. 57 00:02:50.360 --> 00:02:52.879 React apps are built with components. What makes them so 58 00:02:53.159 --> 00:02:55.479 well fundamental components. 59 00:02:54.960 --> 00:02:57.960 Are basically reacts, reusable building blocks. Think of them like 60 00:02:58.000 --> 00:03:02.039 specialized Lego bricks. Okay, its own javascrip logic. Often it's 61 00:03:02.080 --> 00:03:05.840 CSS styling too, and it's JSX markup. All self contained. 62 00:03:06.479 --> 00:03:10.080 This makes your code way more manageable, promotes reuse, and how. 63 00:03:09.960 --> 00:03:11.479 Does the browser actually see these? 64 00:03:11.599 --> 00:03:13.840 And that main dot JSX file. There's a bit of 65 00:03:13.879 --> 00:03:18.319 code using reactums, specifically root dot render that's the match 66 00:03:18.360 --> 00:03:21.319 cup part. It takes your JSX components and translates them 67 00:03:21.319 --> 00:03:24.039 into the actual dom instructions the browser understands. 68 00:03:24.120 --> 00:03:26.840 So the index dot html file is just empty much 69 00:03:26.960 --> 00:03:27.360 just a shell. 70 00:03:27.560 --> 00:03:30.719 Yeah, React fills it all in Oh and a neat detail. 71 00:03:31.159 --> 00:03:34.159 Custom components they always start with an upper case letter 72 00:03:34.879 --> 00:03:37.439 pascal case like submit button. 73 00:03:37.639 --> 00:03:38.199 Why is that? 74 00:03:38.599 --> 00:03:41.039 React needs it to tell your custom components apart from 75 00:03:41.080 --> 00:03:44.680 standard HTML tags like div or p when it parses 76 00:03:44.719 --> 00:03:45.800 the JSX ah. 77 00:03:45.800 --> 00:03:48.520 Okay, good tip. And how do you decide what should 78 00:03:48.560 --> 00:03:49.360 be a component? 79 00:03:49.560 --> 00:03:51.719 A good rule of thumb is to think about your data. 80 00:03:51.879 --> 00:03:54.639 Try to create a separate component for every distinct thing 81 00:03:54.719 --> 00:03:57.520 or data entity you can identify, like an individual to 82 00:03:57.599 --> 00:03:59.879 do item in a list. That's a component the list 83 00:04:00.639 --> 00:04:01.360 another component? 84 00:04:01.439 --> 00:04:04.319 Okay, components is building blocks? Great for structure, but how 85 00:04:04.360 --> 00:04:06.800 do we make them? You know dynamics, so they aren't 86 00:04:06.800 --> 00:04:09.680 all identical? How do we pass in different information? 87 00:04:10.120 --> 00:04:13.120 Right? Static blocks aren't very useful. That's where props come in. 88 00:04:13.520 --> 00:04:17.079 Props short for properties, are how you can figure your components. 89 00:04:17.319 --> 00:04:19.639 You pass data down into them, How you pass them 90 00:04:19.920 --> 00:04:22.240 You can pass them like attributes in htmail. Right on 91 00:04:22.319 --> 00:04:25.600 the component tag or even as children between the opening 92 00:04:25.639 --> 00:04:30.120 and closing tags. React automatically bundles these into a props 93 00:04:30.120 --> 00:04:32.439 object that gets passed into your component function. 94 00:04:32.680 --> 00:04:36.000 So inside the component I just use propstock whatever you can. 95 00:04:36.199 --> 00:04:39.680 Yeah, like props dot title, But often developers use a 96 00:04:39.720 --> 00:04:43.839 technique called destructuring right in the function parameters structure. It's 97 00:04:43.839 --> 00:04:46.920 like unpacking the props object immediately. So instead of props 98 00:04:46.959 --> 00:04:51.160 dot title, you just have title. Makes the function definition cleaner, 99 00:04:51.279 --> 00:04:55.199 like function product, title, price. You see exactly what that 100 00:04:55.199 --> 00:04:56.079 component expects. 101 00:04:56.360 --> 00:04:58.000 Let's typing definitely. 102 00:04:58.120 --> 00:05:01.120 Yeah, And there's also this spread up operator. If you 103 00:05:01.160 --> 00:05:03.879 have a JavaScript object with lots of settings, you can 104 00:05:04.000 --> 00:05:06.839 use dot can fee and your JSX to pass all 105 00:05:06.879 --> 00:05:10.480 those object properties as individual props. Really handy for rapper components. 106 00:05:10.480 --> 00:05:13.120 Okay, props seem powerful, but you mentioned a challenge earlier, 107 00:05:13.399 --> 00:05:14.120 prop drilling. 108 00:05:14.439 --> 00:05:18.319 Ah, yes, prop drilling. It's well, it's a bit of 109 00:05:18.319 --> 00:05:19.199 a pain point sometimes. 110 00:05:19.240 --> 00:05:20.079 What is it exactly? 111 00:05:20.240 --> 00:05:22.639 It's when you have to pass a prop down through 112 00:05:22.720 --> 00:05:26.040 multiple layers of nested components, even if the components in 113 00:05:26.079 --> 00:05:28.839 the middle don't actually use that prop themselves, they just 114 00:05:28.879 --> 00:05:30.279 act as carriers. 115 00:05:30.000 --> 00:05:31.839 Like passing a note in class. 116 00:05:31.839 --> 00:05:34.160 Exactly like that. The components in the middle just passed 117 00:05:34.199 --> 00:05:36.480 along until it reaches the component way down the chain 118 00:05:36.639 --> 00:05:38.040 that actually needs the data. 119 00:05:38.079 --> 00:05:39.279 And why is that bad? 120 00:05:39.639 --> 00:05:43.439 It makes the code less reusable, adds clutter makes refactoring harder. 121 00:05:44.079 --> 00:05:46.959 If you decide to change how data flows, you might 122 00:05:46.959 --> 00:05:50.040 have to edit files for components that weren't even directly involve. 123 00:05:50.639 --> 00:05:53.959 It often suggests your state might be better managed elsewhere. 124 00:05:54.000 --> 00:05:57.519 Hmm, okay, avoid the note passing if possible, so props 125 00:05:57.519 --> 00:06:01.879 handle configuration. But how do we make UIs actually react 126 00:06:01.959 --> 00:06:04.680 to things the user does clicks typing? 127 00:06:05.240 --> 00:06:08.920 Excellent question. This is where state becomes crucial. State is 128 00:06:08.959 --> 00:06:13.199 managed primarily using another fundamental React tool, the U state 129 00:06:13.399 --> 00:06:14.360 hook A hook. 130 00:06:14.600 --> 00:06:14.759 Yeah. 131 00:06:14.800 --> 00:06:18.120 Hooks are special functions that let you hook into React features. 132 00:06:18.439 --> 00:06:20.160 U state is the main one for adding state to 133 00:06:20.199 --> 00:06:21.240 functional components. 134 00:06:21.480 --> 00:06:24.240 And what is state in this context? 135 00:06:24.519 --> 00:06:27.680 Think of state as any data within a component that, 136 00:06:27.959 --> 00:06:31.759 when it changes, should cause React to re render that 137 00:06:31.800 --> 00:06:35.480 component and update the UI. It's the memory of the component. 138 00:06:35.600 --> 00:06:37.600 Okay, so how does you state work? 139 00:06:38.040 --> 00:06:41.199 When you call U state you usually pass an initial value. 140 00:06:41.319 --> 00:06:44.600 It then returns in array with exactly two things. First, 141 00:06:45.040 --> 00:06:48.519 the current state value itself, and second a special function 142 00:06:48.560 --> 00:06:50.000 you use to update that value. 143 00:06:50.199 --> 00:06:53.199 So a value and a function to change it precisely. 144 00:06:53.480 --> 00:06:57.480 And here's the key react nose to reevaluate or rerun 145 00:06:57.600 --> 00:07:01.319 your component function only when that state updating function gets called. 146 00:07:01.519 --> 00:07:03.279 That's the trigger for UI updates. 147 00:07:03.360 --> 00:07:05.360 What if I have multiple pieces of data that need 148 00:07:05.399 --> 00:07:06.199 to change. 149 00:07:05.920 --> 00:07:08.279 Good point, you have options. You can call U state 150 00:07:08.360 --> 00:07:11.560 multiple times for each piece of state, creating multiple state slices, 151 00:07:12.199 --> 00:07:14.759 or you could manage a single larger state object with 152 00:07:14.879 --> 00:07:15.279 U state. 153 00:07:15.519 --> 00:07:18.319 Is one better than the other depends multiple use? 154 00:07:18.319 --> 00:07:21.360 State calls are often simpler for unrelated pieces of data 155 00:07:21.439 --> 00:07:23.040 if you use a single object, though, you have to 156 00:07:23.040 --> 00:07:25.480 be careful when updating. When you call the state updating 157 00:07:25.560 --> 00:07:29.000 function with a new object, it completely replaces the old one, 158 00:07:29.279 --> 00:07:31.399 so you need to make sure your new object includes 159 00:07:31.439 --> 00:07:34.879 all the properties, even the ones that didn't change. Usually 160 00:07:34.920 --> 00:07:37.800 you use the spread operator to copy the old state first. 161 00:07:37.959 --> 00:07:41.240 Ah okay, got to remember to copy the old stuck. 162 00:07:41.079 --> 00:07:44.800 Exactly And another best practice. If your new state depends 163 00:07:44.839 --> 00:07:48.839 on the previous state value like incrementing a counter, you 164 00:07:48.839 --> 00:07:51.680 should pass a function to the state setter like set 165 00:07:51.720 --> 00:07:55.079 counterpreve counterpost count plus one. This ensures you're working with 166 00:07:55.120 --> 00:07:57.839 the latest value, especially if updates happen quickly. 167 00:07:58.000 --> 00:08:00.920 Got it? Use the function form for updates based on 168 00:08:01.000 --> 00:08:03.759 previous state. What about calculating things from state? 169 00:08:04.240 --> 00:08:06.519 You can just derive values. If you have user input 170 00:08:06.639 --> 00:08:09.240 in state, you can calculate its length directly in your 171 00:08:09.240 --> 00:08:13.120 component cont snumb chars user input dot length. No need 172 00:08:13.160 --> 00:08:15.279 for separate state for that derived value. 173 00:08:15.439 --> 00:08:18.800 Okay, And what if multiple components need the same state, 174 00:08:19.360 --> 00:08:21.240 like that prop drilling problem. 175 00:08:21.319 --> 00:08:23.399 That's where the pattern of lifting state up comes in. 176 00:08:23.720 --> 00:08:26.480 You find the closest common ancestor component of all the 177 00:08:26.480 --> 00:08:29.480 components that need the state, and you manage the state there. 178 00:08:29.680 --> 00:08:32.799 So the parent component holds the state right, and. 179 00:08:32.759 --> 00:08:35.440 Then it passes the state value down as props and 180 00:08:35.519 --> 00:08:38.840 passes the state updating function down as props too, so 181 00:08:38.919 --> 00:08:42.039 the child components can still read and update the shared state. 182 00:08:42.440 --> 00:08:43.679 It centralizes control. 183 00:08:44.000 --> 00:08:48.360 Lifting state up makes sense. Okay, we have components props state. 184 00:08:48.759 --> 00:08:52.919 Now how do we handle dynamic displays showing or hiding things, 185 00:08:53.200 --> 00:08:54.200 rendering lists? 186 00:08:54.360 --> 00:08:57.879 Yeah, very common. Need for conditional content like showing an 187 00:08:57.919 --> 00:09:00.000 error message only when there's an error or a life 188 00:09:00.000 --> 00:09:02.360 oding spinner. You can just use standard JavaScript logic right 189 00:09:02.399 --> 00:09:04.039 inside your JSX. 190 00:09:03.559 --> 00:09:04.879 Like if statements yep. 191 00:09:04.960 --> 00:09:08.519 If statements work fine outside the return inside JSX. Ternary 192 00:09:08.600 --> 00:09:12.200 expressions conditioning JSX one true, JSEX one false are super common, 193 00:09:12.799 --> 00:09:15.879 or the logical A and D operator conditioned JSX one true. 194 00:09:15.919 --> 00:09:16.200 Okay. 195 00:09:16.440 --> 00:09:19.440 You can even store ENTIREJX structures and variables and render 196 00:09:19.480 --> 00:09:22.320 them conditionally, or even change the HTML tag itself based 197 00:09:22.360 --> 00:09:24.720 on a prop, like rendering a button or a tag 198 00:09:24.840 --> 00:09:26.080 dynamically flexible. 199 00:09:26.120 --> 00:09:28.519 What about lists of data like an array of items? 200 00:09:28.879 --> 00:09:33.000 For lists, you'll almost always use the JavaScript dot map method. 201 00:09:33.320 --> 00:09:35.840 You take your array of data, map over it, and 202 00:09:35.919 --> 00:09:39.360 return a JSX element for each item. Simple enough, but 203 00:09:40.600 --> 00:09:44.120 there's a very common warning. You'll hit React complaining about 204 00:09:44.159 --> 00:09:44.919 missing keys. 205 00:09:45.159 --> 00:09:46.440 Keys. What are those? 206 00:09:46.600 --> 00:09:49.720 Keys? Are special unique identifiers you need to add as 207 00:09:49.720 --> 00:09:52.279 a prop to each element you render inside a list 208 00:09:52.320 --> 00:09:54.440 map like like key, item, dot id. 209 00:09:54.639 --> 00:09:55.840 Why does React need them? 210 00:09:56.039 --> 00:09:58.919 They help React identify which items in the list have changed, 211 00:09:59.039 --> 00:10:02.559 been added, or removed. Without keys, React might have to 212 00:10:02.600 --> 00:10:05.720 re render the entire list unnecessarily. With keys, it can 213 00:10:05.759 --> 00:10:09.279 be much smarter even just rearranging existing dom elements. If 214 00:10:09.279 --> 00:10:12.639 the order changes. It's a performance optimization. 215 00:10:12.159 --> 00:10:14.120 And the key has to be unique. 216 00:10:13.799 --> 00:10:16.720 Unique among good siblings in that list. Yes, yeah, and stable. 217 00:10:16.759 --> 00:10:19.320 It shouldn't change between renders for the same item. That's 218 00:10:19.320 --> 00:10:21.320 why using the array index is a key is often 219 00:10:21.360 --> 00:10:23.759 a bad idea, especially if the list can be reordered 220 00:10:24.000 --> 00:10:27.120 or items removed from the middle. The index doesn't stick 221 00:10:27.159 --> 00:10:29.519 with the data item. Use a unique id from your 222 00:10:29.600 --> 00:10:31.279 data if possible. 223 00:10:31.080 --> 00:10:35.840 Got it? Use stable unique IDs for keys. And you 224 00:10:35.840 --> 00:10:39.080 mentioned immutability before with state objects, does that apply to 225 00:10:39.159 --> 00:10:40.360 a rays in the state too? 226 00:10:40.519 --> 00:10:42.519 Absolutely? If you have an array in state and you 227 00:10:42.559 --> 00:10:45.840 want to add an item, you must not use methods 228 00:10:45.879 --> 00:10:48.960 like dot push that modify the original array. Why not 229 00:10:49.240 --> 00:10:52.559 because React to text changes by comparing objector ray references. 230 00:10:52.759 --> 00:10:55.279 If the reference hasn't changed because you modified it in place, 231 00:10:55.559 --> 00:10:57.600 React won't see the change and won't re render. 232 00:10:57.720 --> 00:10:58.440 So what should I do? 233 00:10:58.600 --> 00:11:00.840 You need to create a new array. Use methods like 234 00:11:00.879 --> 00:11:04.159 concat or more commonly, the spread operators at my array 235 00:11:04.240 --> 00:11:06.600 dot old array new item. This creates a brand new 236 00:11:06.679 --> 00:11:09.519 array reference, signaling the change to React. 237 00:11:09.639 --> 00:11:13.159 Always immutable updates okay, immutable updates for objects and a 238 00:11:13.240 --> 00:11:16.480 raised and state crucial now styling. How do we make 239 00:11:16.519 --> 00:11:19.960 our components look good without CSS rules bleeding everywhere? 240 00:11:20.080 --> 00:11:22.600 Styling? Right, you can just in court standard CSS files 241 00:11:22.679 --> 00:11:25.320 import a component on CSS. But like you said, those 242 00:11:25.320 --> 00:11:28.519 styles are global by default, easy to get accidental clashes, 243 00:11:28.639 --> 00:11:29.919 especially in larger apps. 244 00:11:30.000 --> 00:11:31.159 So what are the alternatives? 245 00:11:31.279 --> 00:11:33.919 You can use inline styles in JSX you use the 246 00:11:33.919 --> 00:11:37.720 style prop, but it expects a JavaScript object, not a string, 247 00:11:38.080 --> 00:11:42.639 so it looks like style color red, padding top tenpx. 248 00:11:42.759 --> 00:11:44.639 Notice the cambl case for CSS. 249 00:11:44.279 --> 00:11:47.840 Properties inline styles. Okay, what about CSS classes? 250 00:11:47.960 --> 00:11:50.519 The CSS classes you use the class name prop, not 251 00:11:50.679 --> 00:11:53.759 class because class is a reserved word in JavaScript. 252 00:11:53.960 --> 00:11:55.759 Ah, class name, got it, And you. 253 00:11:55.720 --> 00:11:58.399 Can set class name dynamically based on state or props, 254 00:11:58.440 --> 00:12:00.480 which is really useful for conditionals. 255 00:12:00.519 --> 00:12:03.559 But that still doesn't solve the global clash problem if 256 00:12:03.559 --> 00:12:05.840 we import CSS files right correct? 257 00:12:06.120 --> 00:12:08.879 For that, CSS modules are a great solution. You name 258 00:12:08.919 --> 00:12:12.039 your CSS file like my component dot module dot css. 259 00:12:12.360 --> 00:12:15.480 When you import it, the build process automatically transforms your 260 00:12:15.480 --> 00:12:19.240 class names into unique strings, effectively scoping them to that component. 261 00:12:19.399 --> 00:12:22.120 So title in one component won't clash with dot title 262 00:12:22.159 --> 00:12:22.600 in another. 263 00:12:22.879 --> 00:12:25.480 Exactly, it becomes something like my component title A three 264 00:12:25.519 --> 00:12:29.360 to seven B prevents clashes entirely. Other popular options include 265 00:12:29.480 --> 00:12:33.039 CSS and JS libraries like style components, which let you 266 00:12:33.080 --> 00:12:36.960 write actual CSS inside your JavaScript files, often using tag 267 00:12:37.000 --> 00:12:41.000 template literals, and utility first libraries like Tail and thess 268 00:12:41.039 --> 00:12:44.759 are also very popular, giving you lots of small, reusable classes. 269 00:12:44.399 --> 00:12:47.480 Lots of options there. Okay, what if? What if I 270 00:12:47.559 --> 00:12:50.559 really need to directly touch a DOM element, like to 271 00:12:50.639 --> 00:12:53.879 focus an input field or measure its size. Escape reacts 272 00:12:53.879 --> 00:12:54.720 control for a moment. 273 00:12:54.840 --> 00:12:57.000 Sometimes you do need that. That's where refs come in, 274 00:12:57.120 --> 00:13:00.240 using the use ref another hook yep use ref lets 275 00:13:00.240 --> 00:13:02.440 you create a reference, a sort of pointer to a 276 00:13:02.519 --> 00:13:06.159 value that persists across renders. Commonly, you attach this ref 277 00:13:06.200 --> 00:13:08.559 to a DOM element using the ref prop like input 278 00:13:08.639 --> 00:13:12.000 ref my input ref, and then then inside your component logic, 279 00:13:12.279 --> 00:13:14.600 my input ref dot current will hold the actual DOM 280 00:13:14.679 --> 00:13:17.039 node and you can call methods on it like my 281 00:13:17.200 --> 00:13:18.919 inputref dot current dot focus. 282 00:13:19.080 --> 00:13:22.840 Does changing the ref cause a rerender like state No. 283 00:13:22.919 --> 00:13:27.240 Crucially it doesn't. Updating a ref my input ref dot 284 00:13:27.279 --> 00:13:30.480 current ocals some value does not trigger a component rerender. 285 00:13:30.720 --> 00:13:34.000 That's the key difference from state use res for values 286 00:13:34.039 --> 00:13:36.279 you need to track, but which don't directly affect the 287 00:13:36.360 --> 00:13:37.080 visual output. 288 00:13:37.200 --> 00:13:41.919 Okay. Refs for direct dom access or persistent values without rerenders. 289 00:13:42.080 --> 00:13:45.639 And this leads to the idea of controlled versus uncontrolled components, 290 00:13:45.919 --> 00:13:46.840 especially for. 291 00:13:46.639 --> 00:13:48.600 Forms control versus uncontrolled. 292 00:13:48.639 --> 00:13:51.559 A controlled input component has its value managed by React 293 00:13:51.600 --> 00:13:55.679 state use state. Every keystroke updates the state, which updates 294 00:13:55.679 --> 00:13:59.000 the input's value. Prop React is fully in control okay. 295 00:13:59.039 --> 00:14:01.639 An uncontrolled input doesn't have its value tied to state. 296 00:14:02.000 --> 00:14:04.159 You'd use a rapt to read its value only when needed, 297 00:14:04.240 --> 00:14:07.519 maybe on form submission. React doesn't manage its value moment 298 00:14:07.519 --> 00:14:07.960 to moment. 299 00:14:08.080 --> 00:14:09.039 Which one should I use? 300 00:14:09.279 --> 00:14:12.519 Generally prefer controlled components. It keeps React as the single 301 00:14:12.559 --> 00:14:16.320 source of truth. Uncontrolled can be simpler for very basic forms, 302 00:14:16.600 --> 00:14:20.159 but controlled gives you more power for validation, dynamic changes, 303 00:14:20.159 --> 00:14:20.559 et cetera. 304 00:14:20.960 --> 00:14:26.879 Got it, Prefer controlled? Now one more tricky layout thing, modals, 305 00:14:27.039 --> 00:14:30.519 pop ups, tooltips, things that need to appear on top 306 00:14:30.519 --> 00:14:33.000 but might be deep in the component tree. How does 307 00:14:33.039 --> 00:14:33.840 React handle that? 308 00:14:34.039 --> 00:14:38.360 Ah? Yes, the z index nightmare For that. React offers portals. 309 00:14:38.639 --> 00:14:41.080 You use the create portal function from React. 310 00:14:40.759 --> 00:14:43.600 Tom portals like teleporting UI. 311 00:14:43.759 --> 00:14:47.320 Kind of create portal takes two arguments the JSX you 312 00:14:47.320 --> 00:14:50.000 want to render like your modal component and a reference 313 00:14:50.000 --> 00:14:52.559 to a domnode outside your component's current place in the 314 00:14:52.600 --> 00:14:54.559 dom tree where you want to render it up inside 315 00:14:54.600 --> 00:14:57.440 where typically you'd have an empty DIV somewhere near the 316 00:14:57.480 --> 00:15:00.799 root of your index dot HTML like div ideo modal RUDDIV. 317 00:15:01.360 --> 00:15:04.080 You tell the portal to render your modal inside that div. 318 00:15:04.360 --> 00:15:06.480 So even if my button triggering the modal is nested 319 00:15:06.519 --> 00:15:07.240 deep down. 320 00:15:07.200 --> 00:15:10.120 Exactly, the modal renders visually in that top level DIV, 321 00:15:10.360 --> 00:15:13.679 avoiding CSS decking context issues and making styling much easier. 322 00:15:14.000 --> 00:15:16.320 But logically it still behaves like a child of the 323 00:15:16.360 --> 00:15:19.639 component that created the portal, regarding event bubbling in context. 324 00:15:19.919 --> 00:15:23.559 It's clever portals. Okay, that solves a common headache. Now 325 00:15:23.679 --> 00:15:28.559 let's shift gears slightly. We've talked rendering state. What about 326 00:15:28.639 --> 00:15:33.240 actions that happen besides rendering, like fetching data, setting timers, 327 00:15:33.320 --> 00:15:35.519 interacting with browser APIs. 328 00:15:35.240 --> 00:15:37.480 Right, Those are called side effects. There are actions or 329 00:15:37.519 --> 00:15:40.759 processes that happen in addition to the main rendering process. 330 00:15:41.240 --> 00:15:45.039 Sending HTTP requests, using local storage, setting up timers or 331 00:15:45.039 --> 00:15:47.480 subscriptions all side effects. 332 00:15:47.120 --> 00:15:48.559 And can they cause problems? 333 00:15:48.600 --> 00:15:51.799 Oh? Definitely. A classic newbie mistake is putting a side 334 00:15:51.799 --> 00:15:54.919 effect directly in the component body that also updates state. 335 00:15:55.639 --> 00:15:59.000 If fetching data updates state and the component rerenders, it 336 00:15:59.080 --> 00:16:02.240 might fetch data, get update state again, infinite loop. 337 00:16:02.480 --> 00:16:05.039 Yikes. How do we avoid that with another hook? 338 00:16:05.320 --> 00:16:05.919 That's effect. 339 00:16:06.120 --> 00:16:06.399 Yeah. 340 00:16:06.519 --> 00:16:09.200 Its whole purpose is to manage side effects safely within 341 00:16:09.320 --> 00:16:10.320 functional components. 342 00:16:10.559 --> 00:16:12.039 Okay, how does use effect work? 343 00:16:12.279 --> 00:16:14.399 It takes a function, your effect function, containing the side 344 00:16:14.399 --> 00:16:19.080 effect code, and crucially a second argument, a dependency's. 345 00:16:18.480 --> 00:16:19.720 Array dependencies array. 346 00:16:19.840 --> 00:16:23.919 Yes, this array tells React when to rerun your effect function. 347 00:16:24.320 --> 00:16:27.519 If you provide an empty array, the effect runs only once, 348 00:16:27.919 --> 00:16:30.919 right after the component mounts renders for the first time. 349 00:16:30.759 --> 00:16:34.279 Only once useful for initial data fetching exactly. 350 00:16:34.679 --> 00:16:37.080 If you list variables or props in the array, like 351 00:16:37.200 --> 00:16:40.000 user id, the effect will run after the first render 352 00:16:40.159 --> 00:16:43.200 and anytime the value of user ed changes between renders. 353 00:16:43.279 --> 00:16:47.120 Ah, so it reruns only if specific dependencies change. 354 00:16:47.159 --> 00:16:50.320 Precisely. If you don't provide the array at all, which 355 00:16:50.399 --> 00:16:53.840 is generally discouraged, the effect runs after every render. That's 356 00:16:53.879 --> 00:16:55.759 often how those infinite loops start. 357 00:16:55.960 --> 00:16:59.080 Okay, so always provide the dependency array mpty for once 358 00:16:59.480 --> 00:17:01.679 or list the values used inside the effect. 359 00:17:01.879 --> 00:17:06.319 That's the golden rule. Add all values props, state variables 360 00:17:06.359 --> 00:17:09.039 from the component scope that are used inside your effect 361 00:17:09.079 --> 00:17:10.599 function to the dependency's rate. 362 00:17:10.599 --> 00:17:11.880 All of them, any exceptions. 363 00:17:11.920 --> 00:17:14.880 The main exception is state updating functions the second thing 364 00:17:14.920 --> 00:17:19.519 returned by U state React guarantees these functions themselves never change, 365 00:17:19.640 --> 00:17:22.000 so you don't need to list them as dependencies. Same 366 00:17:22.079 --> 00:17:24.640 for built in APIs like fetch or refs. 367 00:17:24.799 --> 00:17:27.319 Okay, what about cleaning up like clearing a timer? 368 00:17:27.640 --> 00:17:30.640 Use effect candles that too. If your affect function returns 369 00:17:30.640 --> 00:17:34.279 another function, React will run that return function as a 370 00:17:34.319 --> 00:17:35.039 cleanup function. 371 00:17:35.319 --> 00:17:36.799 When does it run the cleanup it. 372 00:17:36.799 --> 00:17:39.680 Runs before the effect runs again if dependencies change, and 373 00:17:39.759 --> 00:17:43.039 also when the component unmounts is removed from the UI. 374 00:17:43.319 --> 00:17:47.799 Perfect for clearing timers, removing event listeners, unsubscribing from things. 375 00:17:48.079 --> 00:17:51.160 Very useful. What if a dependency is a function to 376 00:17:51.200 --> 00:17:54.759 find inside my component? Won't that cause the effect to 377 00:17:54.839 --> 00:17:55.599 run too often? 378 00:17:55.640 --> 00:17:58.599 Good catch. If you define a function inside your component, 379 00:17:58.920 --> 00:18:01.839 it gets recreated on every render. If that function is 380 00:18:01.839 --> 00:18:04.599 a dependency of use effect, the effect will run every time. 381 00:18:05.160 --> 00:18:06.279 So how do we fix that? 382 00:18:06.720 --> 00:18:10.240 We use another hook, use callback. You wrap your function 383 00:18:10.319 --> 00:18:14.319 definition and use callback and provide its dependencies. Use callback 384 00:18:14.359 --> 00:18:16.880 will then return a memoized version of your function, which 385 00:18:16.920 --> 00:18:19.000 only changes if its dependencies change. 386 00:18:19.200 --> 00:18:23.640 So use callback memois as functions preventing unnecessary effect runs exactly. 387 00:18:23.680 --> 00:18:25.799 It works hand in hand with use effect in those cases. 388 00:18:25.960 --> 00:18:31.720 Okay, effects cleanup dependencies. That covers side effects. What if 389 00:18:31.759 --> 00:18:35.640 state management gets really complex, multiple related pieces of state 390 00:18:36.079 --> 00:18:37.480 complex update logic. 391 00:18:37.640 --> 00:18:40.319 When use state starts feeling cumbersome for a related state, 392 00:18:40.720 --> 00:18:44.200 React offers an alternative, the use reducer hook. 393 00:18:44.519 --> 00:18:46.839 Use reducer sounds like redux. 394 00:18:46.599 --> 00:18:49.759 It's inspired by similar patterns. Yeah, it's better suited for 395 00:18:49.839 --> 00:18:53.680 managing complex state logic. You define a reducer function separate 396 00:18:53.720 --> 00:18:56.240 from your component. This function takes the current state and 397 00:18:56.279 --> 00:18:59.440 an action object and returns the new state actions. Yeah. 398 00:18:59.480 --> 00:19:02.680 Instead of calling a state center directly, you dispatch action 399 00:19:02.759 --> 00:19:07.759 objects to your reducer like type increment payload. The reducer 400 00:19:07.799 --> 00:19:09.359 handles the update logic based on. 401 00:19:09.319 --> 00:19:11.119