WEBVTT 1 00:00:00.080 --> 00:00:03.799 Okay, let's unpack this. Welcome to the deep dive. Today's 2 00:00:03.799 --> 00:00:07.679 mission is to take a stack of sources, specifically excerpts 3 00:00:07.719 --> 00:00:12.039 from the Angular JS Web Application Development Cookbook, and really 4 00:00:12.119 --> 00:00:15.160 pull out the most important nuggets of knowledge and insight 5 00:00:15.240 --> 00:00:15.480 for you. 6 00:00:15.679 --> 00:00:18.239 Yeah, think of that as your shortcut getting you well 7 00:00:18.280 --> 00:00:21.399 informed on the practical side of Angular development. We're aiming 8 00:00:21.440 --> 00:00:25.480 to extract those useful recipes, the core techniques, and maybe 9 00:00:25.519 --> 00:00:29.079 the deeper wise behind building with this framework you straight 10 00:00:29.079 --> 00:00:30.440 from the cookbook itself exactly. 11 00:00:30.440 --> 00:00:33.159 We'll look at the foundational stuff, the building blocks, how 12 00:00:33.159 --> 00:00:36.200 to structure and test your applications properly. We'll dig into 13 00:00:36.200 --> 00:00:42.479 performance tuning, handling those tricky asynchronous operations gracefully, and even 14 00:00:42.479 --> 00:00:46.880 peak at some clever developer tools and maybe less common techniques. 15 00:00:46.920 --> 00:00:48.240 The book mentions, right, it's. 16 00:00:48.119 --> 00:00:50.679 Really about getting a guided tour through the stuff that 17 00:00:50.759 --> 00:00:54.600 actually makes a difference when you're building, you know, serious applications. 18 00:00:55.079 --> 00:00:57.079 Ready to dive in, let's do it. So. 19 00:00:57.159 --> 00:01:00.159 The book starts right at the core, talking about directives 20 00:01:00.200 --> 00:01:03.759 and filters, calls them the bread and butter of Angular. 21 00:01:03.439 --> 00:01:06.760 JS, right, and the cookbook really frames directives as these 22 00:01:06.799 --> 00:01:11.680 like incredibly powerful tools, good for architect and clean scalable apps. 23 00:01:11.959 --> 00:01:16.439 It breaks down the different ways you can declare them elements, attributes, classes, 24 00:01:16.840 --> 00:01:20.000 even comments, though it does say the comment one is 25 00:01:20.239 --> 00:01:21.480 well pretty rare. 26 00:01:21.920 --> 00:01:25.920 So they let you basically create your own custom HTML 27 00:01:26.200 --> 00:01:29.400 tags and attributes. They change how HTML behaves. 28 00:01:28.959 --> 00:01:31.519 Precisely, and the book hits on the key concepts. The 29 00:01:31.560 --> 00:01:33.959 linking function, that's where the directive actually does its work 30 00:01:34.239 --> 00:01:36.799 messing with the scope in the dom. Then there's templating, 31 00:01:36.840 --> 00:01:41.439 you know, pulling in HTML fragments, and also transclusion. 32 00:01:41.519 --> 00:01:44.319 Transclusion right, that's the one that lets you embed the 33 00:01:44.359 --> 00:01:48.040 original content inside your custom tag within the director's own template. 34 00:01:48.040 --> 00:01:48.959 That sounds pretty useful. 35 00:01:49.000 --> 00:01:51.680 Oh, it absolutely is. The insight there is that the 36 00:01:51.719 --> 00:01:53.879 original content keeps its parents scope. 37 00:01:54.040 --> 00:01:57.239 That's crucial right for keeping data binding working as expected 38 00:01:57.560 --> 00:02:01.159 and speaking of scope, directores normally inherits. But the book 39 00:02:01.239 --> 00:02:04.439 really highlights isolate scope, calls it critical. 40 00:02:04.640 --> 00:02:07.480 Ah, the isolation chamber. Why is that so important? What 41 00:02:07.599 --> 00:02:10.639 problem is it solving? Well, it stops your directive from 42 00:02:10.759 --> 00:02:13.800 accidentally messing with the parent scope or you know, being 43 00:02:13.919 --> 00:02:16.840 messed up by it unexpectedly. It makes your directive a 44 00:02:16.879 --> 00:02:20.800 truly reusable standalone thing like a black box with a 45 00:02:20.919 --> 00:02:25.159 clear API, inputs, using AT an AT and outputs. That's 46 00:02:25.240 --> 00:02:27.800 really key for bigger apps for maintainability. 47 00:02:27.919 --> 00:02:29.680 Okay, yeah, that makes a lot of sense. And the 48 00:02:29.680 --> 00:02:34.759 cookbook mentions handling complex data like nested stuff with recursive directives. 49 00:02:34.759 --> 00:02:35.479 How does that work? 50 00:02:35.759 --> 00:02:38.599 The basic idea is a directive can kind of refer 51 00:02:38.639 --> 00:02:42.039 to itself or maybe a related directive inside its own template, 52 00:02:42.319 --> 00:02:44.479 so it can break down complex data like say a 53 00:02:44.520 --> 00:02:47.680 tree structure, and render little bits of HTML for each 54 00:02:47.800 --> 00:02:51.520 nested part. The insight is using the directive structure to 55 00:02:51.639 --> 00:02:53.520 mirror your data structure. Pretty neat. 56 00:02:53.639 --> 00:02:56.800 That is a really neat pattern for hierarchical UI. Okay, 57 00:02:56.879 --> 00:02:59.319 so that's directives. What about filters filters? 58 00:02:59.439 --> 00:03:02.080 Yeah, so tools for presentation. The book calls them a 59 00:03:02.159 --> 00:03:04.599 vital pipeline between your data model and how it actually 60 00:03:04.599 --> 00:03:07.199 looks in the view. The main idea is decoupling the 61 00:03:07.319 --> 00:03:09.080 raw data from how you display. 62 00:03:08.719 --> 00:03:11.840 It, like just showing text in uppercase or lowercase right 63 00:03:11.879 --> 00:03:12.479 in the template. 64 00:03:12.719 --> 00:03:15.360 Simple stuff like that exactly, But it goes beyond that. 65 00:03:15.479 --> 00:03:19.199 It covers built ins like number and currency, and points 66 00:03:19.240 --> 00:03:21.879 out they use the local service which is super important 67 00:03:21.919 --> 00:03:25.840 for handling, you know, regional formats, currency symbols, commas versus 68 00:03:25.840 --> 00:03:28.800 periods and numbers. The date filter is another big one, 69 00:03:29.240 --> 00:03:33.560 handles all sorts of date strings. Time zones also uses 70 00:03:33.599 --> 00:03:34.680 local under the hood. 71 00:03:34.919 --> 00:03:37.520 And isn't there a debugging trick with the json filter? 72 00:03:37.719 --> 00:03:41.560 Yes, totally, just pipe any scope object through JSON right 73 00:03:41.599 --> 00:03:44.599 in your template. Bam you get a live pritified Jason 74 00:03:44.719 --> 00:03:47.120 view of it. So helpful for just seeing what's actually 75 00:03:47.199 --> 00:03:48.719 in your scope while you're developing. 76 00:03:49.000 --> 00:03:50.960 Is it only for templates though? Can you use filters 77 00:03:50.960 --> 00:03:51.919 in your controller code? 78 00:03:52.039 --> 00:03:55.400 Oh? Yeah, you definitely can. The book shows how you 79 00:03:55.439 --> 00:03:58.800 inject the filter service. It does note the syntax is 80 00:03:59.520 --> 00:04:02.520 maybe a bit awkward and verbose, but it's what you 81 00:04:02.599 --> 00:04:04.120 need if you want to use a built in filter 82 00:04:04.240 --> 00:04:07.280 or even chain them inside some custom filter logic in 83 00:04:07.280 --> 00:04:07.960 your jobscript. 84 00:04:08.080 --> 00:04:09.960 Right chaining, you can string them together with the pipe 85 00:04:10.000 --> 00:04:13.039 operator like value filter one filter too. The book really 86 00:04:13.120 --> 00:04:16.079 emphasizes that the order matters right like nested functions. 87 00:04:16.399 --> 00:04:19.360 Absolutely, filter to filter one value is totally different from 88 00:04:19.399 --> 00:04:22.360 filter onesilter to value And besides the built in ones, 89 00:04:22.399 --> 00:04:25.639 the cookbook guides you on creating your own custom filters, 90 00:04:25.920 --> 00:04:28.839 data filters for formatting, and search filters for lists. 91 00:04:28.879 --> 00:04:31.199 Search filters. Right, the built in filter is the easy one, 92 00:04:31.319 --> 00:04:35.319 just a simple case and sensitive substring match usually yeah. 93 00:04:35.120 --> 00:04:37.319 By default, but the book shows how you can give 94 00:04:37.360 --> 00:04:41.680 it a custom comparator function for say, exact matches, or 95 00:04:41.720 --> 00:04:43.680 you can go further and build a whole search filter 96 00:04:43.759 --> 00:04:47.680 from scratch, or maybe a custom search filter expression. If 97 00:04:47.720 --> 00:04:50.839 you need really complex logic like searching across multiple fields. 98 00:04:51.279 --> 00:04:54.040 The insight is you've got layers of power depending on 99 00:04:54.079 --> 00:04:54.600 what you need. 100 00:04:55.040 --> 00:04:57.800 Nice. So filters are all about keeping presentation logic out 101 00:04:57.800 --> 00:05:01.879 of your controllers and making templates cleaner. Definitely a win. Okay, 102 00:05:01.879 --> 00:05:04.319 so we've got the building blocks down, let's dive into 103 00:05:05.879 --> 00:05:09.680 structuring your application and managing the data flow. The cookbook 104 00:05:09.759 --> 00:05:12.879 really stresses this is crucial for anything non trivial. 105 00:05:12.759 --> 00:05:16.759 Absolutely, and hammers home that clean file and module organization 106 00:05:17.000 --> 00:05:20.439 is vital, especially if you're on a team or building 107 00:05:20.480 --> 00:05:23.600 something that needs to grow. It gives some clear guidelines 108 00:05:24.079 --> 00:05:27.759 one module per file. Name your files after the modules. 109 00:05:28.279 --> 00:05:31.199 Use dot notation in module names to show the hierarchy, 110 00:05:31.439 --> 00:05:35.800 like inventory dot controller dot js for the inventory dot controller. 111 00:05:35.360 --> 00:05:40.040 Module and keeping related files together, locality including the tests. 112 00:05:39.839 --> 00:05:42.720 Yes, exactly, mix navigating and just understanding the code so 113 00:05:42.800 --> 00:05:46.240 much easier. But maybe the biggest organizational insight the book 114 00:05:46.279 --> 00:05:48.720 pushes is grouping files. 115 00:05:48.560 --> 00:05:52.800 By feature feature grouping like log in, search, shopping cart, 116 00:05:52.920 --> 00:05:55.079 instead of grouping by type like all controls together, all 117 00:05:55.079 --> 00:05:55.800 directors together. 118 00:05:55.839 --> 00:05:56.360 Precisely. 119 00:05:56.439 --> 00:05:58.040 Why do they recommend that? What's the advantage? 120 00:05:58.160 --> 00:06:00.000 It just scales way better when you're working on the show, 121 00:06:00.000 --> 00:06:03.639 shopping cart. Everything you need, controller, directors, template services, even 122 00:06:03.639 --> 00:06:05.959 the tests. It's all in one place. It reflects how 123 00:06:05.959 --> 00:06:07.839 the code is actually connected in the app, you know, 124 00:06:08.439 --> 00:06:10.800 rather than just its technical type. That's a big mental 125 00:06:10.800 --> 00:06:12.000 shift for larger projects. 126 00:06:12.240 --> 00:06:14.160 Yeah, that makes a ton of sense. Now defining the 127 00:06:14.160 --> 00:06:18.000 app itself, the book mentions den app and Angular dot bootstrap. 128 00:06:18.040 --> 00:06:18.959 What's the difference there? 129 00:06:19.199 --> 00:06:21.600 Good point, that's how you kick things off and then 130 00:06:21.639 --> 00:06:23.360 an app is a simple way slap it on your 131 00:06:23.480 --> 00:06:27.800 HTML or body tag usually and Angular just automatically starts 132 00:06:27.879 --> 00:06:29.480 up for that whole part of the bomb. 133 00:06:29.959 --> 00:06:33.079 And Angular dot bootstrap when would you use that? 134 00:06:33.079 --> 00:06:35.839 That's for doing it manually in your JavaScript CLERD usually 135 00:06:35.879 --> 00:06:38.879 inside a ready handler or something. The insight is it 136 00:06:38.879 --> 00:06:41.199 gives you more control. You can bootstrap on just a 137 00:06:41.240 --> 00:06:44.399 specific element, not the whole page, or maybe do some 138 00:06:44.480 --> 00:06:48.560 setup before Angular starts compiling, like loading config data asynchronously. 139 00:06:48.879 --> 00:06:51.319 The book suggests it for more complex setups, or when 140 00:06:51.319 --> 00:06:53.560 you're integrating Angular into an existing page. 141 00:06:53.600 --> 00:06:57.439 Maybe okay, control, got it? You know, data flow, scope 142 00:06:57.480 --> 00:07:00.399 and model. The book talks about scope and here urdance 143 00:07:00.399 --> 00:07:03.000 how nested scopes inherit from parents prototypically. 144 00:07:03.160 --> 00:07:06.720 Uh huh, and this leads directly to that classic Angular jscotcha. 145 00:07:07.160 --> 00:07:10.079 The book highlights this pitfall with binding primitive types directly, 146 00:07:10.120 --> 00:07:11.759 like using in it data one two three. 147 00:07:11.959 --> 00:07:13.800 Oh yeah, I think I know this one. If you 148 00:07:13.920 --> 00:07:16.839 change data in a child's scope, it doesn't change the 149 00:07:16.879 --> 00:07:19.240 parent's data, right. It creates a new property in the 150 00:07:19.319 --> 00:07:21.680 child scope that just hides the parent one breaks the 151 00:07:21.680 --> 00:07:22.639 binding exactly. 152 00:07:22.839 --> 00:07:25.360 It looks like it should work, but no, it's a 153 00:07:25.360 --> 00:07:28.519 common source of pain. The crucial fix, as the book explains, 154 00:07:28.600 --> 00:07:32.040 is to always bind to an object property like in 155 00:07:32.120 --> 00:07:35.360 it data dot value one two three. Then changing data 156 00:07:35.439 --> 00:07:38.839 dot value in the child modifies the original object inherited 157 00:07:38.839 --> 00:07:41.920 from the parent keeps the binding intact. That little dot 158 00:07:41.959 --> 00:07:45.600 makes all the difference. It's a life saver pattern absolutely okay. 159 00:07:45.639 --> 00:07:49.720 Another scope thing, event propagation. The book covers why broadcast 160 00:07:49.800 --> 00:07:52.439 going down the scope tree and emit going up in 161 00:07:52.560 --> 00:07:54.000 one dollar for listening right. 162 00:07:54.319 --> 00:07:57.399 It does mention bardcast has some optimizations, but it also 163 00:07:57.600 --> 00:08:01.120 warns wisely that overusing it can still hurt performance because 164 00:08:01.160 --> 00:08:04.040 it has to potentially visit every child scope down the hierarchy. 165 00:08:04.199 --> 00:08:06.879 And crucially, the book talks about event cleanup. When you 166 00:08:07.000 --> 00:08:09.360 use one dollar, it gives you back a function. 167 00:08:09.399 --> 00:08:12.360 Yes, and the insight is you must call that function 168 00:08:12.480 --> 00:08:16.759 when the scope is destroyed. Otherwise memory leak especially important 169 00:08:16.800 --> 00:08:19.800 for directives that get created and destroyed a lot forgetting 170 00:08:19.839 --> 00:08:21.920 this can slowly kill your apps performance. 171 00:08:22.040 --> 00:08:25.160 Memory leaks the silent killer. The book also mentions vang 172 00:08:25.160 --> 00:08:28.199 repeat scope behavior and how track by index or some 173 00:08:28.279 --> 00:08:32.039 other unique ID is vital for performance, especially with big lists. 174 00:08:32.279 --> 00:08:35.120 Yeah, the insight there is track by tells Angular how 175 00:08:35.120 --> 00:08:37.799 to identify each item uniquely, so if the list order 176 00:08:37.879 --> 00:08:40.799 changes or items get added or removed, Angular can just 177 00:08:40.919 --> 00:08:43.639 move or update the specific dom elements it needs to. 178 00:08:43.720 --> 00:08:45.879 Without track by, it might just tear down and rebuild 179 00:08:45.960 --> 00:08:47.919 large boards of the list, which is way slower. 180 00:08:48.240 --> 00:08:51.720 Makes sense. Okay, let's look at forms and validation deeply 181 00:08:51.759 --> 00:08:52.600 tied to scope. 182 00:08:52.440 --> 00:08:55.440 Right, very much so. The book explains Angular attaches a 183 00:08:55.440 --> 00:08:58.360 form controller to your form tag an and main model 184 00:08:58.399 --> 00:09:01.679 controller to inputs using a model and the key insight 185 00:09:01.799 --> 00:09:04.320 is these controllers get exposed right on your scope, so 186 00:09:04.360 --> 00:09:06.720 you can access them like scope dot my form or 187 00:09:06.759 --> 00:09:08.000 scope dot myform dot. 188 00:09:07.879 --> 00:09:10.240 My input, And that's how you check the form state 189 00:09:10.840 --> 00:09:14.159 like pristine or dirty has the user touched it and 190 00:09:14.320 --> 00:09:16.840 valid or invalid? Does it pass the rules? And you 191 00:09:16.879 --> 00:09:20.120 get CSS classes for styling to like in dirty, in 192 00:09:20.120 --> 00:09:21.000 invalid exactly. 193 00:09:21.039 --> 00:09:24.360 You get those states automatically. Plus Angular has built in 194 00:09:24.440 --> 00:09:28.080 validators like required number email. But the cool part is 195 00:09:28.120 --> 00:09:30.960 the book shows how to create custom validators. You write 196 00:09:30.960 --> 00:09:34.120 a directive, watch the input's value, and then use the 197 00:09:34.159 --> 00:09:37.039 set validity method on that inne model controller to tell 198 00:09:37.080 --> 00:09:39.279 Angular if it's valid or not based on your own 199 00:09:39.279 --> 00:09:40.039 custom logic. 200 00:09:40.320 --> 00:09:43.559 Ah. That's super powerful for business rules that aren't just 201 00:09:43.600 --> 00:09:47.000 about basic types okay, and for select elements. The book 202 00:09:47.039 --> 00:09:48.320 dives into in options. 203 00:09:48.440 --> 00:09:51.080 Yeah. In options is way more flexible than just using 204 00:09:51.159 --> 00:09:54.120 repeat to build options. The book breaks down the different 205 00:09:54.159 --> 00:09:58.279 syntaxis simple arrays binding to object properties using track by 206 00:09:58.639 --> 00:10:01.320 using S to define the option values separately from the label, 207 00:10:01.639 --> 00:10:04.279 and it shows how each syntax affects it generated HTML 208 00:10:04.320 --> 00:10:07.679 option values and crucially what actually gets assigned to your model. 209 00:10:08.039 --> 00:10:10.480 The insight is picking the right syntax for your data 210 00:10:10.519 --> 00:10:12.240 to keep the model binding clean. 211 00:10:12.360 --> 00:10:15.360 Right structure and data flow covered time to make things 212 00:10:16.279 --> 00:10:19.360 lightning fast. The book has a chapter called Screaming Fast 213 00:10:19.440 --> 00:10:22.679 Angular JS. What's the main bottleneck get identifies. 214 00:10:23.200 --> 00:10:26.080 Unsurprisingly, it points to data binding and the whole dirty 215 00:10:26.159 --> 00:10:29.759 checking process. Every digest cycle, Angla has to check every 216 00:10:29.840 --> 00:10:32.679 binding to see if the model value changed. More bindings, 217 00:10:32.759 --> 00:10:35.960 more checks, complex checks take longer. Simple as that. 218 00:10:36.320 --> 00:10:40.320 So the main optimization principle is watch your optimization basically, 219 00:10:40.399 --> 00:10:43.919 watch less stuff and keep the watch expressions simple exactly. 220 00:10:44.000 --> 00:10:48.039 Prefer binding directly to model properties. Avoid binding to function 221 00:10:48.120 --> 00:10:51.200 calls or complex inline expressions if you can, because those 222 00:10:51.240 --> 00:10:53.399 have to be rerun all the time. And the book 223 00:10:53.440 --> 00:10:55.799 really gets into the details of the different watch types. 224 00:10:55.879 --> 00:10:58.039 This is where you can win or lose big on performance. 225 00:10:58.320 --> 00:11:00.919 There's the reference watch that's the fast does only triggers 226 00:11:00.919 --> 00:11:04.720 if the actual object reference changes or primitive value changes. 227 00:11:05.159 --> 00:11:06.840 Use this if you only care if the whole thing 228 00:11:06.840 --> 00:11:09.200 got replaced, not if something inside it changed. 229 00:11:09.559 --> 00:11:11.320 Okay, fastest what else? 230 00:11:11.639 --> 00:11:14.960 Then there's the equality watch angular dot equals. This is 231 00:11:15.000 --> 00:11:19.200 the slowest, potentially very slow. It does a deep comparison 232 00:11:19.279 --> 00:11:23.480 of the entire object, property by property recursively. Use this 233 00:11:23.639 --> 00:11:26.200 only if you absolutely have to know if anything, no 234 00:11:26.240 --> 00:11:29.840 matter how deep, has changed within a complex object. Be 235 00:11:29.960 --> 00:11:32.000 really careful with this one on large. 236 00:11:31.799 --> 00:11:34.399 Data right used with caution. Is there an in between? 237 00:11:34.720 --> 00:11:37.879 Yes? Watch collection. This is sort of the middle ground. 238 00:11:37.879 --> 00:11:39.960 It does a shallow check, looks at the top level 239 00:11:40.000 --> 00:11:42.320 properties of an object or the elements of an array. 240 00:11:42.720 --> 00:11:45.120 It schecks if items were added or removed, or if 241 00:11:45.159 --> 00:11:48.840 top level properties changed. Reference. It's faster than a full 242 00:11:48.960 --> 00:11:51.960 equality watch for big collections if you only care about 243 00:11:51.960 --> 00:11:52.919 those shallow changes. 244 00:11:53.679 --> 00:11:56.879 Okay, So the insight is really understanding those trade offs 245 00:11:56.919 --> 00:11:59.039 and picking the lightest watch that actually does what you 246 00:11:59.120 --> 00:12:03.559 need necessary. Equality watch could be a performance killer. 247 00:12:03.440 --> 00:12:06.480 Definitely, And just like with event listeners, the book stresses 248 00:12:06.519 --> 00:12:10.639 you need to de register watches manually. Scope dot watch 249 00:12:10.799 --> 00:12:13.960 returns a function, call it when the watch isn't needed anymore. 250 00:12:14.000 --> 00:12:16.759 Like when a scope is destroyed, prevents leaks, keeps things 251 00:12:16.799 --> 00:12:17.679 snappy over time. 252 00:12:17.960 --> 00:12:20.960 Makes sense for ANG repeat Again, the book circles back 253 00:12:21.000 --> 00:12:22.720 to track for optimization. 254 00:12:22.919 --> 00:12:25.960 Yeah, we mentioned it for scope, but it's absolutely critical 255 00:12:25.960 --> 00:12:29.840 for performance too, especially with large lists. It lets Angular 256 00:12:29.960 --> 00:12:32.559 be much smarter about updating the dom instead of just 257 00:12:32.600 --> 00:12:36.720 rebuilding everything. It also suggests optimizing the compile phase in 258 00:12:36.799 --> 00:12:39.120 directives that you use inside an ANG repeat. 259 00:12:39.240 --> 00:12:40.000 How does that help? 260 00:12:40.360 --> 00:12:43.240 Well? The insight is to move any heavy lifting that 261 00:12:43.279 --> 00:12:46.000 doesn't depend on the specific items data into the compile 262 00:12:46.039 --> 00:12:49.200 function of the directive. The compile function runs only once 263 00:12:49.240 --> 00:12:52.960 when Angular first encounters the directive definition. The linking function 264 00:12:53.120 --> 00:12:56.000 runs for every single item in the repeat. So do 265 00:12:56.120 --> 00:12:59.200 the heavy non item specific work once in compile, not 266 00:12:59.440 --> 00:13:00.440 end times in link. 267 00:13:00.840 --> 00:13:04.159 Do work once, not many times. Smart. The book also 268 00:13:04.159 --> 00:13:06.799 mentions trimming watched models. What's that about? 269 00:13:07.000 --> 00:13:09.600 It's basically about restructuring your data or how you watch 270 00:13:09.639 --> 00:13:12.639 it to reduce the size or complexity of objects that 271 00:13:12.720 --> 00:13:16.720 need those expensive deep watches. Maybe create smaller targeted objects 272 00:13:16.720 --> 00:13:18.600 to watch instead of one giant blob. 273 00:13:18.759 --> 00:13:21.879 Got it. The cookbook also touches on UI enhancement with 274 00:13:22.039 --> 00:13:23.279 ANG and animate right. 275 00:13:23.200 --> 00:13:26.919 The module for adding CSS or JavaScript animations. It works 276 00:13:27.000 --> 00:13:30.720 using a finite state machine idea. Angular ads and remove 277 00:13:30.799 --> 00:13:35.159 CSS classes like AANG enter, AANG, leave, AANG, interactive, etc. 278 00:13:35.799 --> 00:13:39.879 Based on animation events. You then define your CSS transitions 279 00:13:39.960 --> 00:13:42.840 or keyframe animations targeting those classes. 280 00:13:42.440 --> 00:13:45.200 And it works with ANG repeat too for animating items 281 00:13:45.200 --> 00:13:45.919 coming and going. 282 00:13:46.200 --> 00:13:49.960 YEP, handles, AD, remove, and even move events, though the 283 00:13:49.960 --> 00:13:52.919 book includes a little note that sometimes just shuffling items 284 00:13:52.919 --> 00:13:55.879 around might not trigger a move animation for the very 285 00:13:55.960 --> 00:13:59.440 last item, just based on how Angular compares the lists 286 00:14:00.000 --> 00:14:00.879 animation quirks. 287 00:14:00.960 --> 00:14:03.399 Ah the details Okay. The book also mentions some more 288 00:14:03.440 --> 00:14:06.360 modern binding techniques g Model options. 289 00:14:06.559 --> 00:14:08.840 Yeah, this is a usegittle directive. It gives you more 290 00:14:08.879 --> 00:14:11.639 control over when and how the model updates from the view. 291 00:14:11.960 --> 00:14:14.559 You can use update on to trigger updates on specific 292 00:14:14.600 --> 00:14:17.519 events like blur instead of every keystroke. You can use 293 00:14:17.600 --> 00:14:20.080 dbounds to delay the update, which is great for things 294 00:14:20.120 --> 00:14:22.559 like searches. You type inputs so you don't hammer the server, 295 00:14:23.080 --> 00:14:27.080 and getter setter lets you abstract the model access behind functions. 296 00:14:26.600 --> 00:14:28.799 And the double colon one time binding. 297 00:14:29.159 --> 00:14:35.360 Yes my value, simple but powerful insight. Here Angular evaluates 298 00:14:35.360 --> 00:14:38.559 the expression once. If it gets a defined value bam, 299 00:14:38.759 --> 00:14:41.919 the watcher for that specific binding is removed gone. This 300 00:14:42.080 --> 00:14:44.480 drastically cuts down your watch your count for data that 301 00:14:44.559 --> 00:14:47.600 you load once and don't expect to change. Huge performance 302 00:14:47.639 --> 00:14:49.240 when for relatively static content. 303 00:14:49.399 --> 00:14:53.399 Lazy binding perfect for display only data and for forms. 304 00:14:53.679 --> 00:14:55.879 It mentions NG messages for error handling. 305 00:14:56.039 --> 00:14:58.720 Yeah eang messages cleans up form air display instead of 306 00:14:58.720 --> 00:15:01.120 a messy pile of NG show to for each possible 307 00:15:01.240 --> 00:15:04.080 error required email, mid length, et cetera. You use ANG 308 00:15:04.080 --> 00:15:06.879 messages declaratively. It looks at the error object on the 309 00:15:06.879 --> 00:15:10.360 Ango model controller and shows the appropriate message. Much cleaner. 310 00:15:10.480 --> 00:15:13.799 Okay, fast apps, nice UI, But what about waiting for 311 00:15:13.840 --> 00:15:17.159 stuff asynchronous operations? The book has a key chapter on 312 00:15:17.200 --> 00:15:19.279 promises using Angular's Delilo service. 313 00:15:19.480 --> 00:15:21.840 Right, the challenge is dealing with things that don't happen 314 00:15:21.840 --> 00:15:25.320 instantly HTTT requests, timers, whatever. Trying to manage that with 315 00:15:25.360 --> 00:15:27.960 nested callbacks gets horrible fast callback. 316 00:15:27.600 --> 00:15:30.799 Hew and promises are the way to tame that piece exactly. 317 00:15:31.120 --> 00:15:35.120 Promises offer a much cleaner pattern. Dottlery is Angular's specific 318 00:15:35.159 --> 00:15:40.600 implementation the core idea. Your acinc operation immediately returns a 319 00:15:40.600 --> 00:15:43.320 promise object. Think of it as an IOU for the 320 00:15:43.360 --> 00:15:46.720 future result. You then attach handlers to this promise, dot 321 00:15:47.159 --> 00:15:51.600 then for success, dot catch for failure, finally for cleanup 322 00:15:51.600 --> 00:15:53.720 to deal with the outcome whenever it arrives. 323 00:15:54.000 --> 00:15:57.840 The book explains the pieces the deferred object, which you 324 00:15:57.960 --> 00:16:01.360 use inside your ACYNC function to control the outcome you 325 00:16:01.399 --> 00:16:03.320 call resolve or reject on it, and. 326 00:16:03.279 --> 00:16:05.159 The promise itself, which is what you return to the 327 00:16:05.159 --> 00:16:07.679 outside world, and what people attach their dot then and 328 00:16:07.759 --> 00:16:09.039 dot catch handlers to. 329 00:16:09.399 --> 00:16:12.240 And the really powerful part emphasized by the book is 330 00:16:12.320 --> 00:16:15.679 chaining promises right, Yeah, because then returns a new promise. 331 00:16:15.799 --> 00:16:19.039 Yes, that's crucial. It lets you sequence ACYNC tasks really cleanly. 332 00:16:19.480 --> 00:16:21.639 The result from one then can be passed as input 333 00:16:21.679 --> 00:16:24.039 to the next then in the chain. It makes ACYNC 334 00:16:24.120 --> 00:16:27.480 code read almost like synchronous code, avoiding that deep nesting. 335 00:16:27.279 --> 00:16:30.600 And data flows down the success chain while errors skip 336 00:16:30.639 --> 00:16:31.720 straight to the nearest. 337 00:16:31.480 --> 00:16:35.399 Dot catch precisely. Air handling becomes much more manageable. The 338 00:16:35.399 --> 00:16:38.960 book also covers promise barriers with renall. This is super useful. 339 00:16:39.080 --> 00:16:42.720 How so the insight is efficiently handling multiple ACYNC things 340 00:16:42.759 --> 00:16:45.639 happening at the same time in parallel takes an array 341 00:16:45.759 --> 00:16:48.600 or an object full of promises, it returns a single 342 00:16:48.679 --> 00:16:52.679 new promise. That single promise only resolves what all the 343 00:16:52.720 --> 00:16:55.360 promises you gave it have resolved. If any one of 344 00:16:55.360 --> 00:16:59.480 them rejects, the main galuer promise rejects immediately, perfect for say, 345 00:17:00.080 --> 00:17:02.440 loading all the data needed for a dashboard page before 346 00:17:02.480 --> 00:17:02.919 showing it. 347 00:17:03.080 --> 00:17:05.480 And you can wrap non angular promises or even just 348 00:17:05.519 --> 00:17:06.720 plain values with Reynolds. 349 00:17:06.839 --> 00:17:10.119 Yeah, that's for compatibility. The insight is making everything plain 350 00:17:10.240 --> 00:17:13.000 nicely in the Gallar world. It turns values or other 351 00:17:13.039 --> 00:17:16.400 promise types into a standard Angular JS promise you can 352 00:17:16.480 --> 00:17:17.240 use in your chains. 353 00:17:17.519 --> 00:17:20.119 How do you? Services like HTPP use promises. 354 00:17:20.640 --> 00:17:25.279 HTTP methods like http dot get return promises directly. The 355 00:17:25.319 --> 00:17:28.039 book points out a subtle difference. The older dot success 356 00:17:28.079 --> 00:17:31.920 and daughter methods return the original promise object, but the 357 00:17:31.960 --> 00:17:36.079 standard then method returns a new promise. This affects chaining, 358 00:17:36.160 --> 00:17:38.839 so it's good to be aware of other services like 359 00:17:38.920 --> 00:17:42.119 Resource and especially third party ones like Restangular, which the 360 00:17:42.119 --> 00:17:45.680 book notes is very promise centric, also rely heavily on promises. 361 00:17:45.799 --> 00:17:48.720 Okay, and a really practical use case route. 362 00:17:48.480 --> 00:17:52.640 Resolves ah yes using the resolve property in route provider 363 00:17:52.680 --> 00:17:56.440 dot when resolve dot by maydata function returning promise. The 364 00:17:56.519 --> 00:17:59.559 insight here is critical for spas. By putting promises in 365 00:17:59.599 --> 00:18:02.720 your resolve block, U tell Angular don't even finish changing 366 00:18:02.720 --> 00:18:05.400 the route or instantiate the controller for this view until 367 00:18:05.440 --> 00:18:08.319 these promises here have resolved. It ensures all the necessary 368 00:18:08.359 --> 00:18:10.839 data is loaded before the user sees the page, prevents 369 00:18:10.839 --> 00:18:13.160 those ugly flashes of empty or incomplete content. 370 00:18:13.359 --> 00:18:17.319 Yeah, promises are definitely fundamental. Okay. Shifting gears again something 371 00:18:17.440 --> 00:18:21.319 absolutely vital for real world asps testing your Angular JS application. 372 00:18:21.559 --> 00:18:24.160 The book makes it clear testing isn't just nice to have, 373 00:18:24.279 --> 00:18:28.200 it's essential. It gives you confidence your code works, verifies 374 00:18:28.240 --> 00:18:33.039 components interact correctly, and catches bugs caused by complexity. It 375 00:18:33.119 --> 00:18:36.480 highlights two main types, unit tests and end to end 376 00:18:36.599 --> 00:18:37.559 ETE tests. 377 00:18:37.759 --> 00:18:41.400 Okay, unit tests for the small isolated bits often using mocks, 378 00:18:42.000 --> 00:18:44.119 and etwo E for the whole user journey in a 379 00:18:44.119 --> 00:18:44.839 real browser. 380 00:18:45.119 --> 00:18:49.240 Why both exactly? The insight is they test different levels. 381 00:18:49.559 --> 00:18:53.240 Unit tests check if your individual functions, controllers, directives are 382 00:18:53.319 --> 00:18:56.960 correct in isolation, fast specific feedback. Etwo E tests check 383 00:18:56.960 --> 00:18:59.119 if the whole system works together from the user clicking 384 00:18:59.160 --> 00:19:01.319 buttons and the browser maybe through to the back end 385 00:19:01.319 --> 00:19:04.079 and back They test the integration you need both for 386 00:19:04.160 --> 00:19:06.400 real confidence. One tests the brix, the other test the 387 00:19:06.440 --> 00:19:07.319 wall makes sense. 388 00:19:07.599 --> 00:19:09.960 The book covers setting up the environment tools like Karma 389 00:19:10.000 --> 00:19:11.119 and Protractor. 390 00:19:10.799 --> 00:19:13.680 Yep grunt for task running, Karma as the unit test 391 00:19:13.720 --> 00:19:16.480 runner and protractor for E two E tests, which is 392 00:19:16.480 --> 00:19:20.000 built on top of Selenium webdriver specifically for Angular, and 393 00:19:20.079 --> 00:19:22.839 it shows how to write the tests for unit tests 394 00:19:23.079 --> 00:19:26.400 using things like controller to get an instance of your controller, rootscope, 395 00:19:26.440 --> 00:19:29.039 dot new to create a scope for it, and importantly 396 00:19:29.079 --> 00:19:32.440 a GTT back end to mock server responses using xpec 397 00:19:32.559 --> 00:19:35.720 jet or when get. You control the digest cycle with 398 00:19:35.759 --> 00:19:39.279 apply and trigger mock responses with HTTT backend, dot. 399 00:19:39.240 --> 00:19:42.319 Flesh and E two E tests. They use protractors features right. 400 00:19:42.680 --> 00:19:45.559 Protractor gives you global objects like browser for controlling the 401 00:19:45.599 --> 00:19:48.960