WEBVTT

1
00:00:00.040 --> 00:00:03.919
<v Speaker 1>Okay, let's unpack this today. We're tackling something really foundational,

2
00:00:04.000 --> 00:00:05.799
<v Speaker 1>right for modern web dev.

3
00:00:06.040 --> 00:00:09.240
<v Speaker 2>Yeah, absolutely foundational things that really power the dynamic apps

4
00:00:09.240 --> 00:00:10.119
<v Speaker 2>we use every day.

5
00:00:10.279 --> 00:00:14.880
<v Speaker 1>Exactly, and we're diving deep into mastering React for advanced

6
00:00:14.960 --> 00:00:18.239
<v Speaker 1>front end development. Our mission really for this deep dive

7
00:00:18.399 --> 00:00:21.239
<v Speaker 1>is to kind of distill the core ideas that make

8
00:00:21.320 --> 00:00:25.719
<v Speaker 1>React why it's so popular, so powerful for building big,

9
00:00:25.800 --> 00:00:26.960
<v Speaker 1>scalable web apps.

10
00:00:27.120 --> 00:00:30.480
<v Speaker 2>And we're leaning heavily on Natas Shupataia's twenty twenty five

11
00:00:30.519 --> 00:00:34.119
<v Speaker 2>book Advance front End Development, which is a great job

12
00:00:34.200 --> 00:00:35.200
<v Speaker 2>laying this out right.

13
00:00:35.320 --> 00:00:37.200
<v Speaker 1>This is all about giving you that shortcut to the

14
00:00:37.200 --> 00:00:41.399
<v Speaker 1>big huh moments, you know, the core stuff without getting

15
00:00:41.399 --> 00:00:42.759
<v Speaker 1>totally swamped in details.

16
00:00:42.840 --> 00:00:44.920
<v Speaker 2>Yeah, skipping the noise and getting straight to the signal.

17
00:00:45.079 --> 00:00:48.039
<v Speaker 2>And one of the first signals the book clarifies right

18
00:00:48.079 --> 00:00:49.679
<v Speaker 2>away is what React is.

19
00:00:49.799 --> 00:00:52.840
<v Speaker 1>Oh yeah, that's crucial, the library versus framework thing exactly.

20
00:00:52.920 --> 00:00:55.679
<v Speaker 2>It's a UI library. It's not a full framework like

21
00:00:55.759 --> 00:00:57.039
<v Speaker 2>say Angular.

22
00:00:56.840 --> 00:01:00.079
<v Speaker 1>Which means it just focuses on the view, the user interface.

23
00:00:59.679 --> 00:01:03.920
<v Speaker 2>Part precisely, just the UI. So you get this huge flexibility, right,

24
00:01:04.120 --> 00:01:07.200
<v Speaker 2>you choose other bits other libraries for things like routing

25
00:01:07.359 --> 00:01:09.760
<v Speaker 2>or state management, whatever you need beyond the.

26
00:01:09.760 --> 00:01:13.480
<v Speaker 1>View that flexibility. I mean it sounds great, but couldn't

27
00:01:13.480 --> 00:01:16.359
<v Speaker 1>that also be a bit daunting for someone newer, like, oh, great,

28
00:01:16.400 --> 00:01:17.760
<v Speaker 1>now I have more choices to make.

29
00:01:18.359 --> 00:01:21.840
<v Speaker 2>It can seem that way initially, Yeah, but the book

30
00:01:21.879 --> 00:01:24.400
<v Speaker 2>points out, and I think it's true. The entry point

31
00:01:24.439 --> 00:01:26.439
<v Speaker 2>is actually quite accessible, right.

32
00:01:26.319 --> 00:01:30.400
<v Speaker 1>Just basic HTML, CSS, JavaScript knowledge needed to.

33
00:01:30.359 --> 00:01:34.239
<v Speaker 2>Start exactly you can start building UIs quickly learning which

34
00:01:34.239 --> 00:01:36.760
<v Speaker 2>other libraries to choose and how to integrate them. Well,

35
00:01:36.920 --> 00:01:39.439
<v Speaker 2>that's part of the journey, part of developing that deeper skill.

36
00:01:39.599 --> 00:01:43.719
<v Speaker 1>Okay, that makes sense. And this focused approach, this philosophy,

37
00:01:44.280 --> 00:01:46.480
<v Speaker 1>it leads straight into the first big pillar, doesn't it.

38
00:01:46.480 --> 00:01:46.840
<v Speaker 2>It does.

39
00:01:47.079 --> 00:01:50.280
<v Speaker 1>Component based architecture, the lego block analogy. I always come

40
00:01:50.319 --> 00:01:50.719
<v Speaker 1>back to that.

41
00:01:50.799 --> 00:01:52.840
<v Speaker 2>It's a good one because that's really how you should

42
00:01:52.840 --> 00:01:55.439
<v Speaker 2>think about it. Your app is built from these small,

43
00:01:55.680 --> 00:01:58.640
<v Speaker 2>reusable pieces called components.

44
00:01:58.480 --> 00:02:02.040
<v Speaker 1>And each component it is its own stuff, its own logic,

45
00:02:02.120 --> 00:02:02.840
<v Speaker 1>its own UI.

46
00:02:03.359 --> 00:02:06.400
<v Speaker 2>Yep, totally self contained. Think a button, a form, a

47
00:02:06.519 --> 00:02:09.680
<v Speaker 2>user profile card, even a whole page can be a

48
00:02:09.680 --> 00:02:12.000
<v Speaker 2>component made of smaller components.

49
00:02:11.439 --> 00:02:17.919
<v Speaker 1>And the benefits there are huge, right, especially for bigger projects, modularity, reusability, scalability,

50
00:02:18.080 --> 00:02:19.639
<v Speaker 1>It all stems from that. It just makes your code

51
00:02:19.719 --> 00:02:22.680
<v Speaker 1>so much easier to build, maintain, and well reason about.

52
00:02:22.840 --> 00:02:26.039
<v Speaker 2>Okay, so you have all these components, potentially hundreds. How

53
00:02:26.039 --> 00:02:30.000
<v Speaker 2>does React handle updating them all efficiently when things change?

54
00:02:30.039 --> 00:02:30.879
<v Speaker 2>Doesn't make it slow?

55
00:02:31.319 --> 00:02:34.680
<v Speaker 1>Ah? Good question. That leads directly to the second pillar,

56
00:02:34.759 --> 00:02:38.840
<v Speaker 1>And frankly, one of reacts kind of magic tricks the virtual.

57
00:02:38.479 --> 00:02:42.479
<v Speaker 2>Dom right, because touching the real browser dom directly that

58
00:02:42.520 --> 00:02:44.919
<v Speaker 2>could be really expensive, performance.

59
00:02:44.400 --> 00:02:49.159
<v Speaker 1>Wise, incredibly expensive, especially with complex UIs. Every little update

60
00:02:49.159 --> 00:02:52.639
<v Speaker 1>can trigger the browser to recalculate styles, repaint things, reflow

61
00:02:52.680 --> 00:02:55.520
<v Speaker 1>the layout. It adds up fast performance killer.

62
00:02:55.560 --> 00:02:58.199
<v Speaker 2>Like you said, so the virtual dom is reacts answer

63
00:02:58.240 --> 00:02:59.599
<v Speaker 2>to that bottleneck.

64
00:02:59.240 --> 00:03:03.759
<v Speaker 1>Exactly as a lightweight copy and in memory representation of

65
00:03:03.800 --> 00:03:04.560
<v Speaker 1>the actual dom.

66
00:03:04.719 --> 00:03:07.680
<v Speaker 2>Okay, so how does that work in practice? Well, when

67
00:03:07.719 --> 00:03:11.800
<v Speaker 2>something needs to change, React first updates this virtual dom

68
00:03:12.360 --> 00:03:15.840
<v Speaker 2>that's super fast because it's just a JavaScript object. Then

69
00:03:16.039 --> 00:03:19.479
<v Speaker 2>it compares this new virtual dom to the previous version

70
00:03:19.479 --> 00:03:22.280
<v Speaker 2>of the virtual dom. This comparison step is called.

71
00:03:22.199 --> 00:03:24.639
<v Speaker 1>Diffing finding the differences.

72
00:03:24.120 --> 00:03:27.520
<v Speaker 2>Right, and it's smart about it. It uses clever algorithms

73
00:03:27.520 --> 00:03:31.319
<v Speaker 2>heuristics to figure out the absolute minimum set of changes needed.

74
00:03:31.400 --> 00:03:33.240
<v Speaker 1>So it's not just comparing everything blindly.

75
00:03:33.439 --> 00:03:37.120
<v Speaker 2>No, No, it looks at component types, special key props

76
00:03:37.159 --> 00:03:41.000
<v Speaker 2>you provide on lists. It's optimized to be very efficient

77
00:03:41.280 --> 00:03:42.280
<v Speaker 2>at finding just what.

78
00:03:42.400 --> 00:03:45.280
<v Speaker 1>Change, and then it updates the real dom only.

79
00:03:45.039 --> 00:03:48.240
<v Speaker 2>Then, and it only applies those specific minimal changes it

80
00:03:48.319 --> 00:03:49.599
<v Speaker 2>identified during the diffing.

81
00:03:49.960 --> 00:03:52.719
<v Speaker 1>So instead of potentially rebuilding a big chunk of the page,

82
00:03:52.719 --> 00:03:57.319
<v Speaker 1>it might just change the text inside one specific element precisely.

83
00:03:57.599 --> 00:03:59.960
<v Speaker 2>That's why you get those blazing fast updates even in

84
00:04:00.080 --> 00:04:03.000
<v Speaker 2>really complex apps. It's incredibly efficient, and it makes life.

85
00:04:02.879 --> 00:04:05.520
<v Speaker 1>Easier for US developers too. Right, the whole declarative thing.

86
00:04:05.919 --> 00:04:08.840
<v Speaker 2>Absolutely, You just tell React what the UI should look

87
00:04:08.919 --> 00:04:11.240
<v Speaker 2>like based on the current state. You don't have to

88
00:04:11.360 --> 00:04:13.960
<v Speaker 2>manually figure out how to make the dom changes step

89
00:04:13.960 --> 00:04:15.960
<v Speaker 2>by step. React handles the how.

90
00:04:16.079 --> 00:04:18.040
<v Speaker 1>Plus it smooths over browser differences.

91
00:04:18.519 --> 00:04:21.120
<v Speaker 2>Yeah, abstracts away a lot of those inconsistencies.

92
00:04:21.240 --> 00:04:24.480
<v Speaker 1>The book had that e commerce example, right, price updating.

93
00:04:24.160 --> 00:04:28.040
<v Speaker 2>Yeah, perfect example, price changes dynamically. Maybe someone clicks a

94
00:04:28.079 --> 00:04:32.079
<v Speaker 2>button to increase quantity, React using the virtual dom just

95
00:04:32.199 --> 00:04:35.439
<v Speaker 2>surgically updates that little h one or span showing the price,

96
00:04:35.720 --> 00:04:37.839
<v Speaker 2>not the whole product card definitely not the whole.

97
00:04:37.639 --> 00:04:41.079
<v Speaker 1>Page surgical updates. I like that framing. It feels very precise.

98
00:04:41.199 --> 00:04:44.199
<v Speaker 2>It is. It keeps the UI feeling incredibly responsive.

99
00:04:44.360 --> 00:04:47.199
<v Speaker 1>Now, are there any trade offs? Does the virtual dom

100
00:04:47.319 --> 00:04:49.199
<v Speaker 1>ever add like overhead?

101
00:04:49.519 --> 00:04:53.040
<v Speaker 2>That's a fair question. For the vast majority of web apps,

102
00:04:53.279 --> 00:04:57.240
<v Speaker 2>the benefits massively outweigh any minor overhead. But yeah, if

103
00:04:57.279 --> 00:05:00.319
<v Speaker 2>you were doing something extremely low level, maybe intense Navis

104
00:05:00.360 --> 00:05:03.560
<v Speaker 2>graphics or something where every nanosecond counts, you might find

105
00:05:03.639 --> 00:05:07.240
<v Speaker 2>edge cases where direct dom manipulation is theoretically faster.

106
00:05:07.199 --> 00:05:09.120
<v Speaker 1>But those are rare exceptions.

107
00:05:09.000 --> 00:05:12.160
<v Speaker 2>Very rare in typical application development. For ninety nine percent

108
00:05:12.199 --> 00:05:15.040
<v Speaker 2>of us, the virtual dom is a huge win for

109
00:05:15.120 --> 00:05:17.920
<v Speaker 2>both performance and how easy it is to work with.

110
00:05:18.199 --> 00:05:22.600
<v Speaker 1>Got it okay, so efficient updates are handled, But managing

111
00:05:22.600 --> 00:05:26.199
<v Speaker 1>the state within those components and handling things like data

112
00:05:26.240 --> 00:05:30.560
<v Speaker 1>fetching that leads us to the third big pillar, doesn't it?

113
00:05:30.560 --> 00:05:32.839
<v Speaker 2>It does. Indeed, the revolution really of React.

114
00:05:32.560 --> 00:05:36.360
<v Speaker 1>Hooks, introduced back in sixteen point eight right around twenty nineteen,

115
00:05:36.639 --> 00:05:38.040
<v Speaker 1>changed everything fundamentally.

116
00:05:38.319 --> 00:05:41.240
<v Speaker 2>Hooks let you use state and other React features like

117
00:05:41.279 --> 00:05:43.920
<v Speaker 2>life cycle methods effectively without writing.

118
00:05:43.560 --> 00:05:46.240
<v Speaker 1>Class components, So you can do all that powerful stuff directly,

119
00:05:46.319 --> 00:05:48.319
<v Speaker 1>and functional components.

120
00:05:47.879 --> 00:05:51.199
<v Speaker 2>Exactly, which were traditionally simpler just functions that were turned

121
00:05:51.360 --> 00:05:53.519
<v Speaker 2>UI hooks gave them superpowers.

122
00:05:53.639 --> 00:05:56.439
<v Speaker 1>And why was that so important? Less boilerplate code.

123
00:05:56.240 --> 00:05:58.480
<v Speaker 2>That's a big part of it. Yeah, class components could

124
00:05:58.480 --> 00:06:01.160
<v Speaker 2>get quite verbose, you know, with construction this binding life

125
00:06:01.240 --> 00:06:05.000
<v Speaker 2>cycle methods. Hooks streamline a lot of that makes components cleaner,

126
00:06:05.040 --> 00:06:05.720
<v Speaker 2>easier to read.

127
00:06:05.879 --> 00:06:08.000
<v Speaker 1>But it's more than just syntax, isn't it. It's about

128
00:06:08.000 --> 00:06:08.800
<v Speaker 1>reusing logic.

129
00:06:09.160 --> 00:06:12.560
<v Speaker 2>That's the real power. Especially with custom hooks. Hooks allow

130
00:06:12.600 --> 00:06:16.639
<v Speaker 2>you to extract component logic into reusable functions. Think about

131
00:06:16.639 --> 00:06:19.959
<v Speaker 2>managing state or handling side effects like talking to an API.

132
00:06:20.360 --> 00:06:22.319
<v Speaker 1>So the main ones we hear about are you state

133
00:06:22.360 --> 00:06:24.120
<v Speaker 1>and use effect the workhorses.

134
00:06:24.279 --> 00:06:27.920
<v Speaker 2>Definitely. Use state is for adding local state to your

135
00:06:28.040 --> 00:06:32.560
<v Speaker 2>functional component, like the classic counter example. You click a button,

136
00:06:32.600 --> 00:06:34.519
<v Speaker 2>a number goes up. U step manages that number.

137
00:06:34.600 --> 00:06:36.279
<v Speaker 1>Simple clear state management.

138
00:06:35.959 --> 00:06:39.639
<v Speaker 2>Right there, yep. And then use effect is for side effects.

139
00:06:39.360 --> 00:06:43.519
<v Speaker 1>Side effects meaning things outside of just rendering the.

140
00:06:43.480 --> 00:06:47.399
<v Speaker 2>Component exactly, anything that interacts the outside world, fetching data,

141
00:06:47.639 --> 00:06:51.160
<v Speaker 2>setting up subscriptions, manually changing the dom if you absolutely

142
00:06:51.160 --> 00:06:53.360
<v Speaker 2>have to. That all goes inside use effect.

143
00:06:53.519 --> 00:06:56.199
<v Speaker 1>And you mentioned custom hooks. That's where you bundle up

144
00:06:56.240 --> 00:06:57.480
<v Speaker 1>some of this logic yourself.

145
00:06:57.600 --> 00:06:59.639
<v Speaker 2>Right, Let's say you need to know the window with

146
00:07:00.040 --> 00:07:03.879
<v Speaker 2>multiple components. Instead of writing that logic everywhere, you create

147
00:07:03.959 --> 00:07:07.319
<v Speaker 2>a use window with custom huck, then any component can

148
00:07:07.399 --> 00:07:08.879
<v Speaker 2>just call us window with and get the current with

149
00:07:09.319 --> 00:07:12.199
<v Speaker 2>super reusable keeps your components focused on their main job.

150
00:07:12.399 --> 00:07:16.839
<v Speaker 1>That ability to compose behavior not just youI. That feels

151
00:07:16.879 --> 00:07:18.360
<v Speaker 1>like a really powerful concept.

152
00:07:18.519 --> 00:07:21.319
<v Speaker 2>It is. It's a paradigm shift. Mastering things like the

153
00:07:21.399 --> 00:07:25.040
<v Speaker 2>use effect dependency array. Telling React exactly when your effect

154
00:07:25.079 --> 00:07:28.720
<v Speaker 2>should rerun is key to avoiding common bugs like infinite

155
00:07:28.759 --> 00:07:32.319
<v Speaker 2>loops or stale data. That's where the real advanced understanding

156
00:07:32.360 --> 00:07:32.680
<v Speaker 2>comes in.

157
00:07:33.000 --> 00:07:35.439
<v Speaker 1>Okay, so we have components, the virtual down for speed

158
00:07:35.839 --> 00:07:39.879
<v Speaker 1>and hooks for state and logic and functional components. How

159
00:07:39.920 --> 00:07:43.199
<v Speaker 1>does React fit into the bigger picture compared to say

160
00:07:43.399 --> 00:07:44.560
<v Speaker 1>Angular or View.

161
00:07:44.720 --> 00:07:47.959
<v Speaker 2>Well, like we said, Angular is the full framework, very comprehensive,

162
00:07:48.120 --> 00:07:52.000
<v Speaker 2>very opinionated. Great for large enterprise teams maybe, but steeper

163
00:07:52.040 --> 00:07:55.480
<v Speaker 2>learning curve generally bigger ab size. View View is often

164
00:07:55.519 --> 00:07:58.279
<v Speaker 2>seen as maybe simpler, easier to pick up initially. It

165
00:07:58.319 --> 00:08:02.160
<v Speaker 2>also uses components and ofvirtual dom. It's fantastic, honestly, but

166
00:08:02.199 --> 00:08:05.279
<v Speaker 2>React generally has a larger community, a bigger ecosystem of

167
00:08:05.399 --> 00:08:07.160
<v Speaker 2>third party libraries, more jobs.

168
00:08:07.199 --> 00:08:10.759
<v Speaker 1>Maybe, So react sweet spot is that flexibility, the performance,

169
00:08:10.879 --> 00:08:12.319
<v Speaker 1>and the huge ecosystem.

170
00:08:12.600 --> 00:08:15.319
<v Speaker 2>I think. So it's flexibility lets you tailor your stack.

171
00:08:15.639 --> 00:08:18.560
<v Speaker 2>The virtual don keeps things fast, and the ecosystem means

172
00:08:18.600 --> 00:08:21.959
<v Speaker 2>you're rarely starting from scratch. It scales really well for

173
00:08:22.040 --> 00:08:24.360
<v Speaker 2>complex projects where you need that modularity.

174
00:08:24.800 --> 00:08:28.040
<v Speaker 1>So these three things we've unpacked, the component architecture, the

175
00:08:28.160 --> 00:08:30.959
<v Speaker 1>virtual dom, the hooks. They really are the heart of it.

176
00:08:31.000 --> 00:08:33.320
<v Speaker 2>They absolutely are. They work together to let you build

177
00:08:33.320 --> 00:08:38.200
<v Speaker 2>these really dynamic, complex yet performance UIs in a way

178
00:08:38.240 --> 00:08:42.159
<v Speaker 2>that's manageable and dare I say, often enjoyable. Right.

179
00:08:42.559 --> 00:08:45.559
<v Speaker 1>So, wrapping this up, the key takeaways for you the listener,

180
00:08:46.200 --> 00:08:49.519
<v Speaker 1>think about building with those lego blocks the components. Understand

181
00:08:49.559 --> 00:08:53.240
<v Speaker 1>how the virtual dom makes updates super efficient, and appreciate

182
00:08:53.279 --> 00:08:57.200
<v Speaker 1>how hooks simplifies state and logic within those components, making

183
00:08:57.279 --> 00:08:58.759
<v Speaker 1>them more powerful and reusable.

184
00:08:58.840 --> 00:09:00.679
<v Speaker 2>Those are the foundations, definitely, and.

185
00:09:00.639 --> 00:09:03.159
<v Speaker 1>Here's something to chew on after this. How might these

186
00:09:03.240 --> 00:09:08.279
<v Speaker 1>core react ideas modularity, efficient updates, clear state management change

187
00:09:08.320 --> 00:09:11.159
<v Speaker 1>how you think about building any kind of complex system,

188
00:09:11.200 --> 00:09:12.080
<v Speaker 1>not just websites.

189
00:09:12.159 --> 00:09:13.360
<v Speaker 2>Hmmm, good question.

190
00:09:13.679 --> 00:09:17.120
<v Speaker 1>Think about how those principles apply elsewhere. What other problems

191
00:09:17.159 --> 00:09:20.200
<v Speaker 1>could be solved more elegantly with ideas like componentization or

192
00:09:20.559 --> 00:09:24.039
<v Speaker 1>minimizing unnecessary work. What does that unlock? It's kind of

193
00:09:24.039 --> 00:09:25.600
<v Speaker 1>fascinating to consider the ripple effect.