WEBVTT 1 00:00:00.120 --> 00:00:03.000 Welcome back to the deep dive. Ever looked at a 2 00:00:03.000 --> 00:00:06.160 website and wondered, like, how did they do that? 3 00:00:06.400 --> 00:00:07.960 It's the magic of JavaScript. 4 00:00:08.439 --> 00:00:11.359 Well, today we're diving deep into that world, the world 5 00:00:11.439 --> 00:00:14.919 of JavaScript. It's the language that you know, brings websites 6 00:00:14.960 --> 00:00:19.320 to life, makes them interactive, engaging. We'll be using Kyle 7 00:00:19.359 --> 00:00:22.039 Simpson's You Don't Know js Up and Going as our guide. 8 00:00:22.120 --> 00:00:24.120 So fantastic resource it is. 9 00:00:24.199 --> 00:00:27.079 Yeah. So, if you've ever been curious about, like, you know, 10 00:00:27.120 --> 00:00:30.199 how those interactive maps work, or those cool animations or 11 00:00:30.239 --> 00:00:33.079 even those forms that pop up, get ready for some 12 00:00:33.159 --> 00:00:34.560 serious aha moments. 13 00:00:34.679 --> 00:00:38.520 Yeah. JavaScript can seem intimidating at first, all that code, right, 14 00:00:38.679 --> 00:00:41.520 but at its core, it's really just about giving instructions 15 00:00:41.520 --> 00:00:42.200 to computers. 16 00:00:42.280 --> 00:00:46.200 Okay, So like, are we basically like dog trainers for computers? 17 00:00:46.320 --> 00:00:48.560 Kind of? Yeah? Yeah, you break down a trick into steps, 18 00:00:49.119 --> 00:00:52.159 use clear signals, the dog understands, right, same with code. 19 00:00:52.320 --> 00:00:54.799 We write instructions in a language the computer gets ah. 20 00:00:54.799 --> 00:00:57.320 Okay, but computers don't speak English, do they. 21 00:00:57.439 --> 00:01:00.560 Nope, they speak binary code, all zeros in one ones. 22 00:01:00.600 --> 00:01:03.240 That's it pretty much. Thankfully we don't have to write 23 00:01:03.280 --> 00:01:03.479 in that. 24 00:01:03.600 --> 00:01:07.359 Yeah, I was gonna say. Programming languages like JavaScript, they 25 00:01:07.359 --> 00:01:12.159 act as translators. We write human readable code, and JavaScript 26 00:01:12.200 --> 00:01:15.120 converts that into the zeros and ones the computer needs. 27 00:01:15.239 --> 00:01:18.840 So JavaScript is like the Rosetta Stone of the digital world. 28 00:01:18.959 --> 00:01:22.480 I like that analogy. We write the instructions, JavaScript translates 29 00:01:22.519 --> 00:01:26.120 them for the computer. Awesome. Okay, but what do these 30 00:01:26.239 --> 00:01:28.640 instructions the code actually look like? 31 00:01:28.920 --> 00:01:32.200 Good question. The instructions are made up of statements, which 32 00:01:32.200 --> 00:01:34.159 are basically individual commands. 33 00:01:34.400 --> 00:01:34.680 Okay. 34 00:01:34.799 --> 00:01:37.359 Like, for example, a simple statement in JavaScript could be 35 00:01:37.439 --> 00:01:38.560 A equals B two. 36 00:01:38.719 --> 00:01:42.799 Okay, we're seeing letters, a number, some symbols. What's going on. 37 00:01:42.760 --> 00:01:45.079 Here, right? So those letters A and B those are 38 00:01:45.079 --> 00:01:45.760 called variables. 39 00:01:45.879 --> 00:01:46.319 Variables. 40 00:01:46.480 --> 00:01:48.480 I think of them like containers, each with a label 41 00:01:48.719 --> 00:01:51.280 for storing information. Got it, And in this case they're 42 00:01:51.280 --> 00:01:54.959 holding numbers. The two is a value that's written directly 43 00:01:55.000 --> 00:01:58.120 into the code, and those symbols those are operators. Like 44 00:01:58.480 --> 00:02:01.200 means multiply and it means a sign of value. 45 00:02:01.439 --> 00:02:04.719 Okay, So this statement saying take the value in container B, 46 00:02:05.280 --> 00:02:08.039 multiply it by two, and then stick the result into 47 00:02:08.039 --> 00:02:10.240 container A. Exactly a recipe. 48 00:02:10.479 --> 00:02:13.159 Yeah, kind of tick B. That a little spice you 49 00:02:13.199 --> 00:02:15.439 know with multiplication and voila, you get Uh. 50 00:02:15.719 --> 00:02:18.439 I like it, But why is this important? What can 51 00:02:18.439 --> 00:02:21.159 we actually deal with these statements? 52 00:02:21.840 --> 00:02:25.000 Well, by stringing these statements together, you can create programs 53 00:02:25.039 --> 00:02:28.759 that can do pretty complex stuff like calculating the total 54 00:02:28.800 --> 00:02:31.560 cost of items in a shopping cart or animating a 55 00:02:31.639 --> 00:02:32.520 character on a screen. 56 00:02:33.000 --> 00:02:36.000 So it's like building a house with lego bricks. 57 00:02:36.199 --> 00:02:38.639 Yeah, each statement's a brick, and by combining them in 58 00:02:38.680 --> 00:02:40.800 different ways we build all sorts of amazing things. 59 00:02:40.879 --> 00:02:44.680 I love that. Now, within these statements you mentioned expressions, 60 00:02:45.039 --> 00:02:46.400 What are those exactly? 61 00:02:46.960 --> 00:02:51.240 Expressions are like the ingredients and many instructions within a statement. Okay, 62 00:02:51.360 --> 00:02:54.439 in our example B two, that's an expression. It calculates 63 00:02:54.439 --> 00:02:57.840 a value. Even just B on its own, that's an expression. 64 00:02:57.840 --> 00:02:59.560 It refers to whatever is in that container. 65 00:03:00.039 --> 00:03:03.319 Expressions are like the nuts and bolts of a statement. 66 00:03:03.400 --> 00:03:05.680 You got it. And sometimes an expression can be a 67 00:03:05.680 --> 00:03:07.240 whole statement by itself. 68 00:03:07.159 --> 00:03:10.560 Like alerty, this would pop up a window on your 69 00:03:10.560 --> 00:03:13.520 screen showing you the value stored in a It's both 70 00:03:13.560 --> 00:03:17.280 an expression because it references a and a statement because 71 00:03:17.280 --> 00:03:18.479 it causes that pop up. 72 00:03:18.960 --> 00:03:22.360 Cool. So we've got programs made of statements. Statements built 73 00:03:22.400 --> 00:03:26.199 with expressions. But how does this code actually r N. 74 00:03:26.719 --> 00:03:29.840 It's not like the computer just magically understands what we've written, 75 00:03:29.960 --> 00:03:30.639 right right. 76 00:03:30.759 --> 00:03:33.520 That's where interpreters and compilers come in. Think of them 77 00:03:33.520 --> 00:03:36.439 as language translators. They take our human readable code and 78 00:03:36.479 --> 00:03:41.039 turn it into instructions the computer's processor can actually understand, so. 79 00:03:41.120 --> 00:03:44.199 Like a chef translating the recipe into a language the 80 00:03:44.280 --> 00:03:46.280 kitchen appliance can get exactly. 81 00:03:46.599 --> 00:03:50.319 Some languages are interpreted line by line as the program runs, okay, 82 00:03:50.560 --> 00:03:53.879 others are compiled all at once ahead of time. JavaScript's 83 00:03:53.879 --> 00:03:55.599 a bit unique that it does something called just in 84 00:03:55.639 --> 00:03:58.879 time compilation compiles the code right before running. 85 00:03:58.879 --> 00:04:00.000 It a very efficient show. 86 00:04:00.319 --> 00:04:01.319 Yeah you should say that. 87 00:04:01.400 --> 00:04:04.120 So sounds like JavaScript is a very adaptable language. 88 00:04:04.159 --> 00:04:05.080 It is very much so. 89 00:04:05.319 --> 00:04:08.159 Okay, So we've got the basic building blocks, but we 90 00:04:08.240 --> 00:04:13.439 deal with all sorts of data in the real world. Numbers, text, yes, no, decisions. 91 00:04:14.280 --> 00:04:16.439 How does JavaScript handle all that? 92 00:04:16.439 --> 00:04:19.079 That's where values and types come in, Just like in 93 00:04:19.120 --> 00:04:22.240 a store. Right, you have different ways of representing values, okay, 94 00:04:22.439 --> 00:04:25.680 like numbers for prices, words for descriptions, and yes or 95 00:04:25.720 --> 00:04:30.360 no for availability. JavaScript uses different types to represent various 96 00:04:30.439 --> 00:04:31.839 kinds of information. 97 00:04:31.480 --> 00:04:34.480 So it's like having the right tool for the job exactly. 98 00:04:34.600 --> 00:04:40.040 Javascripts built in types number for numerical data, string for text, 99 00:04:40.319 --> 00:04:42.519 and boolean for tru or false values. 100 00:04:42.560 --> 00:04:44.360 Okay, so if I want to store someone's age, i'd 101 00:04:44.439 --> 00:04:48.120 use a number for their name, a string, and to 102 00:04:48.279 --> 00:04:50.720 track if they're subscribed to something, a boolean. 103 00:04:51.079 --> 00:04:53.839 Got it perfect, And you can write these values directly 104 00:04:53.879 --> 00:04:56.160 into the code, like the number forty two or this 105 00:04:56.240 --> 00:04:59.639 string Hello world. These are called literals because they represent 106 00:04:59.639 --> 00:05:00.439 the value directly. 107 00:05:00.519 --> 00:05:02.600 Makes sense. But what if I need to use a number, 108 00:05:02.920 --> 00:05:05.439 say someone's age, within a sentence, do I have to 109 00:05:05.480 --> 00:05:06.759 create a separate string for it? 110 00:05:06.839 --> 00:05:10.519 Great question. JavaScript lets you convert between types. It's called coercion. 111 00:05:10.800 --> 00:05:14.319 Coercion okay, like a magic wand transforming a number into 112 00:05:14.319 --> 00:05:17.399 text and vice versa. So to combine a number and 113 00:05:17.439 --> 00:05:20.800 a string, JavaScript can automatically convert the number into its. 114 00:05:20.759 --> 00:05:23.839 String form handy. But are there any downsides to this 115 00:05:23.920 --> 00:05:24.560 magic wand? 116 00:05:25.160 --> 00:05:29.319 Well, there are actually two types of coercion, explicit and implicit. 117 00:05:29.959 --> 00:05:31.600 Okay, I'm intrigued, tell me more. 118 00:05:32.079 --> 00:05:35.879 Explicit coercion is when you intentionally tell JavaScript to convert 119 00:05:35.879 --> 00:05:40.000 a value. It's like specifically telling the chef to chop 120 00:05:40.000 --> 00:05:42.959 an onion into smaller pieces. For example, you can use 121 00:05:43.079 --> 00:05:45.079 number to turn a scring into a number. 122 00:05:45.199 --> 00:05:48.079 Okay, so that's deliberate. What about implicit. 123 00:05:47.639 --> 00:05:51.680 Coercion, ah, Implicit coercion happens behind the scenes. It's when 124 00:05:51.759 --> 00:05:55.000 JavaScript tries to make sense of operations involving different types. 125 00:05:55.199 --> 00:05:57.439 It's like letting the chef decide how to prepare the 126 00:05:57.560 --> 00:06:01.240 ingredients based on the recipe. But sometime the chef's interpretation 127 00:06:01.399 --> 00:06:02.920 might differ from what you intended. 128 00:06:03.120 --> 00:06:06.519 Ah. So implicit coercion can lead to surprises if you're 129 00:06:06.560 --> 00:06:07.839 not careful exactly. 130 00:06:08.519 --> 00:06:10.519 That's why it's important to be mindful of how you 131 00:06:10.639 --> 00:06:13.279 use different types together. Like if you try to add 132 00:06:13.319 --> 00:06:17.399 a number in a string, JavaScript might automatically convert the 133 00:06:17.399 --> 00:06:19.879 string to a number, but the result might not be 134 00:06:19.920 --> 00:06:20.720 what you expected. 135 00:06:21.160 --> 00:06:25.319 So implicit coercion is powerful but requires a good understanding 136 00:06:25.399 --> 00:06:26.040 of the rules. 137 00:06:26.199 --> 00:06:31.040 Precisely mastering coercion is key to becoming a proficient JavaScript developer. 138 00:06:32.000 --> 00:06:34.879 But we'll dig deeper into coercion in a later deep dive. 139 00:06:35.040 --> 00:06:38.360 Looking forward to that, you briefly mentioned truthy and falsey 140 00:06:38.480 --> 00:06:40.879 values before can you explain that a bit more sure? 141 00:06:41.040 --> 00:06:43.360 So, sometimes you need to check if a value is 142 00:06:43.439 --> 00:06:47.199 truth or falsey. Basically, would it be considered true or 143 00:06:47.199 --> 00:06:48.639 false in a conditional statement? 144 00:06:48.839 --> 00:06:49.199 Okay? 145 00:06:49.399 --> 00:06:52.639 In JavaScript, certain values are always considered falsey, Like an 146 00:06:52.639 --> 00:06:56.279 empty string, the number zero, or the values null and undefined. 147 00:06:56.319 --> 00:06:58.279 So those are always missing in our recipe. 148 00:06:58.279 --> 00:07:01.399 Great analogy, and anything that's not on that falsey list 149 00:07:01.439 --> 00:07:02.360 that's considered truthy. 150 00:07:02.439 --> 00:07:05.160 Okay, So a non empty string, a non zero number, 151 00:07:05.319 --> 00:07:08.360 a true boolean, those would all be truthy. 152 00:07:08.600 --> 00:07:11.759 You, got it, and JavaScript can automatically coerce those to 153 00:07:11.879 --> 00:07:14.639 true or false when needed in conditions or comparisons. 154 00:07:14.720 --> 00:07:16.920 Got it. It's like having a built in sensor that 155 00:07:16.959 --> 00:07:19.199 can tell if an ingredient is present or missing in 156 00:07:19.240 --> 00:07:19.759 our recipe. 157 00:07:19.839 --> 00:07:20.279 I like that. 158 00:07:20.480 --> 00:07:23.800 Now let's talk about comparing values. How does JavaScript know 159 00:07:23.839 --> 00:07:25.000 if two values are equal? 160 00:07:25.399 --> 00:07:29.040 JavaScript provides operators for comparing values. Yeah. The most common 161 00:07:29.079 --> 00:07:31.360 ones are double equals and triple equals. 162 00:07:31.399 --> 00:07:34.319 I've heard double equals is evil and should be avoided. 163 00:07:34.399 --> 00:07:34.920 Is that true? 164 00:07:35.240 --> 00:07:38.519 Not necessarily, It's about using the right tool for the job. 165 00:07:38.759 --> 00:07:39.120 Okay. 166 00:07:39.240 --> 00:07:43.480 Double equals allows for coercion, meaning it can compare values 167 00:07:43.519 --> 00:07:47.560 of different types. Triple equals is strict. It only considers 168 00:07:47.639 --> 00:07:50.439 values equal if they're both the same value A D 169 00:07:50.639 --> 00:07:51.360 the same type. 170 00:07:51.519 --> 00:07:54.120 So it's like having two different scales, one that can 171 00:07:54.399 --> 00:07:56.959 weigh different kinds of objects, maybe by converting them to 172 00:07:57.000 --> 00:08:00.279 a common unit, and another that requires objects to be 173 00:08:00.360 --> 00:08:02.800 of the same type for a precise measurement. 174 00:08:03.079 --> 00:08:05.480 I like that analogy. So if you're unsure about the 175 00:08:05.480 --> 00:08:09.160 types you're comparing, it's safer to use triple equals avoid 176 00:08:09.240 --> 00:08:12.879 surprises from coercion. But if you're confident and want to 177 00:08:12.959 --> 00:08:16.360 leverage coercion, double equals can be handy. The key is 178 00:08:16.439 --> 00:08:18.360 understanding its strengths and limitations. 179 00:08:18.600 --> 00:08:22.079 Got it. It's about choosing the right tool, not fearing 180 00:08:22.160 --> 00:08:25.800 one or the other. Okay, so we've got values, types, 181 00:08:25.839 --> 00:08:27.839 coercion comparisons. What's next. 182 00:08:28.240 --> 00:08:31.480 Let's talk about variables from those containers we were talking about. Yeah, 183 00:08:31.519 --> 00:08:34.759 to declare a variable, we use the var keyword. Okay, 184 00:08:35.039 --> 00:08:37.240 And a variable's name has to follow some rules. It 185 00:08:37.240 --> 00:08:39.480 has to start with a letter, a dollar sign, or 186 00:08:39.480 --> 00:08:42.279 an underscore, got it. And then it can contain letters, numbers, 187 00:08:42.320 --> 00:08:43.720 dollar signs, or underscores. 188 00:08:44.080 --> 00:08:47.799 So something like my variable or amount would be valid 189 00:08:47.879 --> 00:08:49.399 variable names exactly. 190 00:08:49.720 --> 00:08:52.799 It's super important to choose descriptive names that clearly show 191 00:08:52.799 --> 00:08:53.519 what they hold. 192 00:08:53.399 --> 00:08:55.679 Right like bank balance is much clearer than just B 193 00:08:56.080 --> 00:08:58.120 makes the code so much easier to understand. 194 00:08:58.200 --> 00:09:02.360 Absolutely clear variable names are essential for readability. Imagine trying 195 00:09:02.360 --> 00:09:05.279 to decipher a recipe where all the ingredients were labeled 196 00:09:05.320 --> 00:09:06.799 ABC and so on. 197 00:09:07.080 --> 00:09:09.799 Oh, that would be a nightmare. Now, how about where 198 00:09:09.840 --> 00:09:12.759 you can use these variables? Like, if a variable is 199 00:09:12.799 --> 00:09:17.120 declared inside a function, is it only available within that function? 200 00:09:17.679 --> 00:09:20.440 That's a great question that brings us to scope scope book. 201 00:09:20.720 --> 00:09:24.240 In JavaScript, functions create their own scopes, kind of like 202 00:09:24.320 --> 00:09:28.360 walled gardens where variables live. Okay, a variable declared inside 203 00:09:28.399 --> 00:09:32.080 a function is only accessible within that function scope, not outside. 204 00:09:32.159 --> 00:09:34.759 So it's like having separate rooms in a house, each 205 00:09:34.799 --> 00:09:37.200 with its own set of belongings that aren't visible from 206 00:09:37.200 --> 00:09:37.799 other rooms. 207 00:09:37.919 --> 00:09:41.360 Perfect analogy, And just like rooms within a house, you 208 00:09:41.399 --> 00:09:45.559 can have nested scopes in JavaScript. A function inside another 209 00:09:45.639 --> 00:09:48.840 function has access to variables from the outer function scope, 210 00:09:49.240 --> 00:09:52.000 but the outer function can't peak into the inner functions 211 00:09:52.039 --> 00:09:52.720 private space. 212 00:09:52.879 --> 00:09:55.120 So if I have a function called calculate total inside 213 00:09:55.159 --> 00:09:58.519 a function called process, order calculate total can access variables 214 00:09:58.519 --> 00:10:00.799 from process order, but not the the other way around. 215 00:10:01.000 --> 00:10:06.960 Exactly. Understanding scope is crucial for writing well organized JavaScript code. Now, 216 00:10:07.000 --> 00:10:09.879 there's this quirky thing called hoisting, which can trip up 217 00:10:09.960 --> 00:10:11.440 even experience developers. 218 00:10:11.720 --> 00:10:14.639 Hoisting sounds a bit ominous. 219 00:10:15.200 --> 00:10:18.639 Imagine a magical crane that lifts all the variable declarations 220 00:10:18.679 --> 00:10:20.519 to the top of a room, even if you wrote 221 00:10:20.559 --> 00:10:23.360 them lower down. Okay, that's kind of what hoisting does. 222 00:10:23.360 --> 00:10:27.440 In JavaScript. Variable and function declarations are conceptually moved to 223 00:10:27.480 --> 00:10:29.159 the top of their scope during compilation. 224 00:10:30.000 --> 00:10:33.480 So I could technically use a variable before declaring. 225 00:10:33.000 --> 00:10:36.320 It, you could. Yeah, hoisting can lead to confusion, especially 226 00:10:36.399 --> 00:10:39.840 in large projects. While you can technically use a variable 227 00:10:39.879 --> 00:10:43.279 before its declaration, it's way better to declare your variables 228 00:10:43.279 --> 00:10:44.320 at the top for clarity. 229 00:10:44.919 --> 00:10:47.799 Okay, so hoisting is one of those JavaScript quirks that's 230 00:10:47.879 --> 00:10:51.279 good to be aware of, but maybe not rely on exactly. Now, 231 00:10:51.320 --> 00:10:54.279 besides this function level scope, are there any other kinds 232 00:10:54.279 --> 00:10:55.399 of scope in JavaScript? 233 00:10:55.879 --> 00:10:58.799 Yes? With ES six, we got a new way to 234 00:10:58.799 --> 00:11:00.840 declare variables using let keyword. 235 00:11:01.080 --> 00:11:01.440 Okay. 236 00:11:01.639 --> 00:11:05.600 This lets you create block level scopes, meaning variables declared 237 00:11:05.679 --> 00:11:08.279 inside a block of code, like an if statement or 238 00:11:08.279 --> 00:11:10.960 a loop are only accessible within that block. 239 00:11:11.240 --> 00:11:13.919 Ah. So it's like having smaller compartments within a room 240 00:11:13.919 --> 00:11:15.159 to organize your belongings. 241 00:11:15.159 --> 00:11:19.320 Even further precisely, block level scoping gives you finer control 242 00:11:19.480 --> 00:11:20.799 over variable visibility. 243 00:11:21.120 --> 00:11:24.720 This is great. So we've got scope hoisting and block 244 00:11:24.799 --> 00:11:28.000 level scoping. What's next on our JavaScript adventure? 245 00:11:28.120 --> 00:11:31.600 Let's revisit conditional statements. It's where we make decisions in 246 00:11:31.639 --> 00:11:34.799 our code based on certain conditions. We've touched on the 247 00:11:34.840 --> 00:11:38.279 if statement, but JavaScript also has the switch statement for 248 00:11:38.360 --> 00:11:39.720 handling multiple conditions. 249 00:11:39.840 --> 00:11:41.840 Okay, remind me what does the if statement do again? 250 00:11:41.960 --> 00:11:44.919 The if statement executes a block of code only if 251 00:11:44.960 --> 00:11:48.279 a condition is true, like a gatekeeper who only allows 252 00:11:48.399 --> 00:11:50.120 entry if a certain condition is met. 253 00:11:50.240 --> 00:11:52.600 Got it? So if I want to check if a 254 00:11:52.679 --> 00:11:55.080 user is logged in before sharing their profile, I'd use 255 00:11:55.120 --> 00:11:57.120 an if statement. What about the switch statement? When wou 256 00:11:57.159 --> 00:11:57.559 I use that? 257 00:11:57.799 --> 00:12:00.559 The switch statement is like a multi way switch. It 258 00:12:00.639 --> 00:12:03.320 directs the flow of execution to different blocks of code 259 00:12:03.639 --> 00:12:06.879 based on the value of a variable or expression. It's 260 00:12:06.919 --> 00:12:09.679 more concise than a chain of if and l's if statements, 261 00:12:09.879 --> 00:12:12.000 especially when you have many conditions to check. 262 00:12:12.159 --> 00:12:14.039 So instead of having a series of if and l's 263 00:12:14.080 --> 00:12:16.840 if statements, I can use a switch statement to neatly 264 00:12:16.960 --> 00:12:19.440 organize multiple conditions exactly. 265 00:12:19.519 --> 00:12:21.360 It can make your code much easier to read. 266 00:12:21.720 --> 00:12:25.399 Makes sense, But there's a catch right You mentioned that 267 00:12:25.440 --> 00:12:28.519 sometimes code can fall through from one case to the 268 00:12:28.559 --> 00:12:29.799 next in a switch statement. 269 00:12:30.039 --> 00:12:32.960 Ah. Yes, fall through. Think of it like a secret 270 00:12:32.960 --> 00:12:36.559 passage that connects different rooms in a house. Normally, you'd 271 00:12:36.600 --> 00:12:39.320 want each case to be separate, so you use the 272 00:12:39.360 --> 00:12:43.440 break keyword to stop execution after a matching case. But 273 00:12:43.559 --> 00:12:47.320 sometimes you might intentionally want to execute multiple cases in 274 00:12:47.360 --> 00:12:50.240 a row, and that's where fall through comes in handy. 275 00:12:50.360 --> 00:12:53.000 So it's like having a shortcut that lets you access 276 00:12:53.159 --> 00:12:56.000 multiple rooms with a single key. Can you give me 277 00:12:56.039 --> 00:12:58.480 an example of when this fall through would be useful? 278 00:12:58.559 --> 00:13:03.279 Sure? Imagine building a game and different actions have the 279 00:13:03.279 --> 00:13:06.039 same outcome. You could use a switch statement with fall 280 00:13:06.080 --> 00:13:09.120 through to handle those actions together instead of repeating the 281 00:13:09.159 --> 00:13:10.759 same logic in multiple cases. 282 00:13:10.840 --> 00:13:13.279 Ah, that makes sense. So we've got if and switch 283 00:13:13.360 --> 00:13:16.080 for handling conditions. Are there any other ways to express 284 00:13:16.080 --> 00:13:17.320 conditions in JavaScript? 285 00:13:17.399 --> 00:13:22.799 Yep? There's also the conditional operator, sometimes called the ternary operator. 286 00:13:22.879 --> 00:13:25.720 It's like a compact version of the if L statement. Okay. 287 00:13:25.799 --> 00:13:29.360 It uses a question mark and a colon to represent 288 00:13:29.440 --> 00:13:30.799 the two possible outcomes. 289 00:13:30.919 --> 00:13:32.000 Can you show me an example. 290 00:13:32.039 --> 00:13:34.559 Sure. Let's say you want to display a different message 291 00:13:34.600 --> 00:13:37.279 based on whether a user is logged in. You could 292 00:13:37.320 --> 00:13:40.240 use the conditional operator like this lem a message is 293 00:13:40.279 --> 00:13:42.519 logged in, welcome back, please log in. 294 00:13:42.919 --> 00:13:44.840 Okay. So it's a shorthand way of doing that. Pretty 295 00:13:44.879 --> 00:13:48.639 neat right now. You also mentioned something about strict mode 296 00:13:48.799 --> 00:13:50.759 in JavaScript. What's that all about? 297 00:13:51.039 --> 00:13:53.960 Strict mode? It was introduced in e S five. Think 298 00:13:53.960 --> 00:13:57.279 of it as having a much stricter building inspector checking 299 00:13:57.320 --> 00:13:59.000 your code for potential hazards. 300 00:13:59.039 --> 00:14:01.799 Okay, I like that. Tell me more about these hazards. 301 00:14:01.840 --> 00:14:07.200 One example is accidental global variable creation in regular JavaScript. 302 00:14:07.440 --> 00:14:10.759 If you forget to declare a variable using var, it 303 00:14:10.840 --> 00:14:14.120 might accidentally become a global variable accessible from anywhere in 304 00:14:14.159 --> 00:14:14.600 your code. 305 00:14:14.759 --> 00:14:16.360 Oh, that sounds dangerous. 306 00:14:16.600 --> 00:14:20.240 It can be leads to unexpected behavior, hard to find bugs. 307 00:14:20.840 --> 00:14:24.559 Strict mode prevents this by throwing an error if you 308 00:14:24.679 --> 00:14:27.039 try to assign a value to an undeclared variable. 309 00:14:27.080 --> 00:14:28.840 So it's like a safety net exactly. 310 00:14:29.039 --> 00:14:32.399 You enable strict mode. By adding you strict at the 311 00:14:32.440 --> 00:14:33.799 top of a function or a file. 312 00:14:34.039 --> 00:14:35.799 Got it? Are there any other benefits? 313 00:14:36.480 --> 00:14:39.759 Yes? It also makes your code more optimizable, could lead 314 00:14:39.759 --> 00:14:44.000 to better performance, and it encourages best practices, helps you 315 00:14:44.039 --> 00:14:46.960 avoid bad habits that might not be supported in future 316 00:14:47.000 --> 00:14:48.000 JavaScript versions. 317 00:14:48.240 --> 00:14:50.919 So it's like building your house to meet the latest 318 00:14:50.919 --> 00:14:54.919 safety and efficiency standards. Good investment. Okay, we've covered a 319 00:14:54.960 --> 00:14:56.519 lot of ground here. What's next. 320 00:14:56.919 --> 00:14:59.000 Now let's move on to one of the most powerful 321 00:14:59.120 --> 00:15:04.399 and often mis understood concepts and genrefript functions as values. 322 00:15:04.600 --> 00:15:06.639 Oooh, this is where things get interesting. 323 00:15:06.799 --> 00:15:09.120 It is Remember how I said functions can be treated 324 00:15:09.200 --> 00:15:10.919 like any other value in JavaScript. 325 00:15:11.000 --> 00:15:11.120 Ye. 326 00:15:11.320 --> 00:15:14.720 Think of functions like versatile tools, usable in many different ways. 327 00:15:15.159 --> 00:15:17.639 You could assign a function to a variable, pass it 328 00:15:17.679 --> 00:15:20.360 as an argument to another function, or even return a 329 00:15:20.399 --> 00:15:21.519 function from another function. 330 00:15:21.720 --> 00:15:23.960 Wow, that's pretty flexible. Can you give me an example 331 00:15:23.960 --> 00:15:24.960 of why this is useful? 332 00:15:25.200 --> 00:15:27.960 Sure? Imagine you're building a game and you need to 333 00:15:28.000 --> 00:15:31.240 perform different actions based on user input. You could have 334 00:15:31.279 --> 00:15:34.519 a function for each action like move left, move right, jump, 335 00:15:34.559 --> 00:15:37.879 and so on. By treating these functions as values, you 336 00:15:37.879 --> 00:15:40.840 can store them in an array and then easily call 337 00:15:40.879 --> 00:15:44.480 the appropriate function based on the user's input without writing 338 00:15:44.559 --> 00:15:46.799 a bunch of repetitive if statements. 339 00:15:47.200 --> 00:15:50.759 Ah. So it's like having a toolbox with labeled compartments 340 00:15:50.759 --> 00:15:52.879 for each tool. You can grab the right tool for 341 00:15:52.919 --> 00:15:55.200 the job without having to rummage through a messy pile. 342 00:15:55.399 --> 00:15:55.960 Exactly. 343 00:15:56.080 --> 00:15:58.600 I like that. Now, how do we create a function 344 00:15:58.679 --> 00:15:59.919 as of value? 345 00:16:00.120 --> 00:16:03.200 Way is to use a function expression. It's like writing 346 00:16:03.240 --> 00:16:05.159 down the steps of a recipe on a piece of 347 00:16:05.200 --> 00:16:08.480 paper and then putting that paper into a labeled envelope. 348 00:16:08.679 --> 00:16:11.000 For example, let my function function. 349 00:16:11.080 --> 00:16:13.159 Okay, and then I can use that variable my function 350 00:16:13.240 --> 00:16:15.120 to call the function, just like I would with a 351 00:16:15.200 --> 00:16:15.799 named function. 352 00:16:15.960 --> 00:16:17.240 Precisely cool. 353 00:16:17.679 --> 00:16:19.200 Now, what if you have a function that you only 354 00:16:19.279 --> 00:16:20.039 need to use once. 355 00:16:20.399 --> 00:16:25.159 Ah, that's where immediately invote function expressions come in, or 356 00:16:25.320 --> 00:16:28.639 iafes for short. Yeah, it's like writing a recipe and 357 00:16:28.679 --> 00:16:31.480 then immediately starting to cook it without saving it for later. 358 00:16:31.600 --> 00:16:32.360 Sounds efficient. 359 00:16:32.559 --> 00:16:36.120 It is. You basically wrap the function expression in parentheses 360 00:16:36.360 --> 00:16:38.519 and then add another set of parentheses at the end 361 00:16:38.720 --> 00:16:40.799 to invoke it right away like this. 362 00:16:41.200 --> 00:16:44.080 Okay, so those extra parentheses at the end trigger the 363 00:16:44.080 --> 00:16:47.039 immediate execution. But why would we want to do this. 364 00:16:47.720 --> 00:16:51.159 One common use is to create a private scope for 365 00:16:51.320 --> 00:16:55.000 variables and functions, prevents them from cluttering up the global 366 00:16:55.039 --> 00:16:57.440 scope and potentially clashing with other code. 367 00:16:57.600 --> 00:17:00.320 Ah. So it's like having a separate workspace where you 368 00:17:00.320 --> 00:17:03.600 can experiment without messing up your main project. You got it, 369 00:17:03.759 --> 00:17:06.720 I like it. Now let's talk about closures. This is 370 00:17:06.720 --> 00:17:09.160 one of those concepts I've always found a bit mysterious. 371 00:17:09.279 --> 00:17:14.200 Closures are indeed powerful and often misunderstood. Imagine you have 372 00:17:14.240 --> 00:17:18.279 a function that returns another function okay, The inner function 373 00:17:18.599 --> 00:17:21.880 still has access to the outer function scope even after 374 00:17:21.920 --> 00:17:24.440 the outer function is finished running. That's closure. 375 00:17:24.720 --> 00:17:27.000 So it's like the inner function carries a little piece 376 00:17:27.039 --> 00:17:29.279 of its birthplace with it wherever it goes. 377 00:17:29.519 --> 00:17:32.359 That's a great way to put it. Closures are powerful 378 00:17:32.559 --> 00:17:35.640 because they let you create functions that have access to 379 00:17:35.680 --> 00:17:40.200 private data, leading to more modular and maintainable code. A 380 00:17:40.240 --> 00:17:42.720 classic example is creating a counter function. 381 00:17:43.039 --> 00:17:46.160 A counter function. How does that work with closures? 382 00:17:46.640 --> 00:17:49.400 Imagine you have a function called may counter that returns 383 00:17:49.400 --> 00:17:52.799 another function Okay. Inside make counter, you have a variable, 384 00:17:52.920 --> 00:17:56.839 let's call it count, initialized to zero. The inner function, 385 00:17:56.960 --> 00:18:01.039 when called increments count and returns its new value. Each 386 00:18:01.079 --> 00:18:03.240 time you call make counter, it creates a new closure 387 00:18:03.400 --> 00:18:05.240 with his own independent count variable. 388 00:18:05.319 --> 00:18:07.400 So I could create two counters, each with their own 389 00:18:07.480 --> 00:18:10.759 count even though they come from the same make counterfunction exactly. 390 00:18:10.920 --> 00:18:13.640 That's the magic of closures. They let you create multiple 391 00:18:13.640 --> 00:18:17.200 instances of a function, each with their own private data. 392 00:18:17.279 --> 00:18:19.720 This concept is actually a building block for something called 393 00:18:19.720 --> 00:18:22.359 the module pattern, which we'll explore more later. 394 00:18:22.720 --> 00:18:26.160 This is fascinating. It seems like closures are essential for 395 00:18:26.200 --> 00:18:27.759 a well structured JavaScript. 396 00:18:28.039 --> 00:18:29.400 They are extremely useful. 397 00:18:29.480 --> 00:18:31.160 Yes, but I have a feeling this is just the 398 00:18:31.200 --> 00:18:32.079 tip of the iceberg. 399 00:18:32.279 --> 00:18:36.480 Oh. Absolutely, closures open up a whole new dimension in JavaScript. 400 00:18:37.039 --> 00:18:40.240 But for now, let's move on to another intriguing concept. 401 00:18:41.279 --> 00:18:42.039