WEBVTT

1
00:00:00.160 --> 00:00:02.839
<v Speaker 1>Welcome to the deep dive. We take stacks of information,

2
00:00:03.000 --> 00:00:05.679
<v Speaker 1>pull out the key nuggets and help you get informed fast.

3
00:00:06.240 --> 00:00:09.960
<v Speaker 1>Today we're plunging into a JavaScript of library. It's incredibly powerful,

4
00:00:10.000 --> 00:00:11.919
<v Speaker 1>but you know, sometimes gets this reputation for being a

5
00:00:11.960 --> 00:00:16.879
<v Speaker 1>bit intimidating. We're talking RxJS, Reactive Extensions for JavaScript, and

6
00:00:16.920 --> 00:00:19.679
<v Speaker 1>our mission for the steep dive to really unpack r XJS,

7
00:00:20.079 --> 00:00:23.000
<v Speaker 1>look at that perceived steep learning curve and show its

8
00:00:23.039 --> 00:00:26.399
<v Speaker 1>practical power. We're using insights directly from a great source,

9
00:00:26.640 --> 00:00:29.960
<v Speaker 1>the RxJS Cookbook for Reactive Programming. So you're going to

10
00:00:29.960 --> 00:00:32.679
<v Speaker 1>get a shortcut here a way to understand how RxJS

11
00:00:32.679 --> 00:00:37.000
<v Speaker 1>simplifies complex asynchronous stuff data flows, event handling. We'll go

12
00:00:37.079 --> 00:00:39.320
<v Speaker 1>beyond just listing operators and see how they build well,

13
00:00:39.359 --> 00:00:43.280
<v Speaker 1>surprisingly robust solutions for UIs, for micro services, you name it. Okay,

14
00:00:44.000 --> 00:00:47.240
<v Speaker 1>let's start the beginning. What exactly is RxJS? For anyone

15
00:00:47.240 --> 00:00:49.119
<v Speaker 1>who's heard the name, it isn't totally sure. What's the

16
00:00:49.119 --> 00:00:50.159
<v Speaker 1>core idea? Right?

17
00:00:50.479 --> 00:00:54.479
<v Speaker 2>Well, at its heart, RxJS is really a library designed

18
00:00:54.479 --> 00:00:56.960
<v Speaker 2>to make it easier to work with asynchronous data streams

19
00:00:57.439 --> 00:01:00.200
<v Speaker 2>and also orchestrating sequences of events that have up and

20
00:01:00.240 --> 00:01:03.479
<v Speaker 2>over time it gives you these powerful tools, mainly observables

21
00:01:03.479 --> 00:01:06.319
<v Speaker 2>and operators to manage that complexity, the kind they can

22
00:01:06.359 --> 00:01:08.480
<v Speaker 2>feel pretty chaotic otherwise.

23
00:01:08.120 --> 00:01:10.319
<v Speaker 1>Okay, that sounds super useful, I mean, especially with all

24
00:01:10.319 --> 00:01:12.760
<v Speaker 1>the acing stuff happening in modern web apps. But our

25
00:01:12.840 --> 00:01:15.680
<v Speaker 1>source mentions this common belief. You know that RxJS has

26
00:01:15.719 --> 00:01:19.680
<v Speaker 1>a steep learning curve even after developers learn what individual

27
00:01:19.680 --> 00:01:22.760
<v Speaker 1>operators do, What specific challenges do they run into when

28
00:01:22.799 --> 00:01:26.519
<v Speaker 1>they try to really fully adopt this reactive way of thinking.

29
00:01:26.799 --> 00:01:29.799
<v Speaker 2>Yeah, that's a really important point, because just knowing what

30
00:01:29.920 --> 00:01:32.719
<v Speaker 2>say map or filter does isn't really the whole story.

31
00:01:33.040 --> 00:01:37.200
<v Speaker 2>Developers often hit roadblocks when it comes to debugging. Debugging

32
00:01:37.280 --> 00:01:41.640
<v Speaker 2>RxJS streams can be tricky, and optimizing them, testing them effectively,

33
00:01:41.920 --> 00:01:46.359
<v Speaker 2>managing reactive state across a whole application, and maybe the

34
00:01:46.359 --> 00:01:50.319
<v Speaker 2>biggest one, figuring out the right operator or combination of

35
00:01:50.400 --> 00:01:54.920
<v Speaker 2>operators for a specific real world problem. So this deep dive,

36
00:01:55.000 --> 00:01:57.359
<v Speaker 2>we really want to focus on those practical solutions, the

37
00:01:57.400 --> 00:02:00.120
<v Speaker 2>bigger picture, beyond just the operator definition.

38
00:02:00.239 --> 00:02:02.480
<v Speaker 1>Okay, perfect, This is where it gets really interesting for me.

39
00:02:02.640 --> 00:02:05.560
<v Speaker 1>How does our XJS actually help build better web experiences

40
00:02:05.640 --> 00:02:08.599
<v Speaker 1>day to day? Let's serve something. Everyone deals with network

41
00:02:08.639 --> 00:02:11.120
<v Speaker 1>requests and inevitably network errors, right.

42
00:02:11.199 --> 00:02:15.039
<v Speaker 2>Our XAS is fantastic for building robustness resilience, especially with

43
00:02:15.120 --> 00:02:18.639
<v Speaker 2>network communication, because let's face it, networks aren't always reliable.

44
00:02:18.879 --> 00:02:21.280
<v Speaker 2>The simplest thing is using the catcher operator. It lets

45
00:02:21.319 --> 00:02:25.039
<v Speaker 2>you gracefully handle a problem. When a request fails, you

46
00:02:25.080 --> 00:02:27.960
<v Speaker 2>can maybe show a notification like oops, couldn't fetch recipes,

47
00:02:28.400 --> 00:02:31.680
<v Speaker 2>and then you either complete the stream nicely or maybe

48
00:02:31.759 --> 00:02:33.919
<v Speaker 2>rethrough the air. If something else needs to deal with.

49
00:02:33.840 --> 00:02:36.919
<v Speaker 1>That, got it, handle it or pass it on exactly.

50
00:02:37.360 --> 00:02:40.280
<v Speaker 2>Now. For those little temporary server glitches, maybe the server's

51
00:02:40.360 --> 00:02:42.800
<v Speaker 2>just busy for a second, the retry operator is your

52
00:02:42.840 --> 00:02:46.439
<v Speaker 2>go to just try again. Well, yes, but it gets smarter.

53
00:02:46.919 --> 00:02:52.120
<v Speaker 2>Our source describes using retry with a delay function. This

54
00:02:52.199 --> 00:02:56.960
<v Speaker 2>function can exponentially increase the time in between two retry attempts.

55
00:02:56.599 --> 00:02:59.319
<v Speaker 1>Ah, so it waits longer each time it fails.

56
00:02:59.080 --> 00:03:02.560
<v Speaker 2>Precisely instead just hammering the server immediately, it backs off,

57
00:03:02.960 --> 00:03:05.879
<v Speaker 2>gives the server breathing room, increases the chance of success

58
00:03:05.919 --> 00:03:08.199
<v Speaker 2>if it's just a temporary issue, reduces load.

59
00:03:08.560 --> 00:03:11.120
<v Speaker 1>That makes sense being smarter about retries. And then there's

60
00:03:11.120 --> 00:03:13.240
<v Speaker 1>this thing called the circuit breaker pattern. I like the

61
00:03:13.280 --> 00:03:14.280
<v Speaker 1>electrical analogy.

62
00:03:14.439 --> 00:03:16.960
<v Speaker 2>It's a great analogy. Just like the breaker in your

63
00:03:16.960 --> 00:03:20.439
<v Speaker 2>house trips during the surge to prevent damage. If your

64
00:03:20.439 --> 00:03:25.960
<v Speaker 2>apsees several cascading errors, maybe multiple back end services are failing,

65
00:03:25.960 --> 00:03:29.360
<v Speaker 2>the RXGS circuit breaker trips. It goes into an open

66
00:03:29.400 --> 00:03:33.199
<v Speaker 2>state for a set time, maybe fifteen seconds. It just

67
00:03:33.240 --> 00:03:36.520
<v Speaker 2>immediately rejects new requests to that failing.

68
00:03:36.240 --> 00:03:38.479
<v Speaker 1>Service, so it stops trying for a bit, right, it.

69
00:03:38.479 --> 00:03:40.840
<v Speaker 2>Says, Okay, this thing is down, let's leave it alone.

70
00:03:40.919 --> 00:03:43.439
<v Speaker 2>After the timeout, it goes half open. It allows a

71
00:03:43.439 --> 00:03:46.080
<v Speaker 2>few test requests through to see if the services.

72
00:03:45.719 --> 00:03:47.000
<v Speaker 1>Recovered, checking if it's safe.

73
00:03:47.080 --> 00:03:50.479
<v Speaker 2>Yeah, exactly if those fail, back to open. If they succeed,

74
00:03:50.560 --> 00:03:53.639
<v Speaker 2>it closes the circuit back to normal operation. It's not

75
00:03:53.719 --> 00:03:56.960
<v Speaker 2>just error handling. It's about building self healing systems, making

76
00:03:57.000 --> 00:04:00.280
<v Speaker 2>your application more resilient, more responsive even when parts of

77
00:04:00.280 --> 00:04:00.840
<v Speaker 2>it are failing.

78
00:04:00.879 --> 00:04:03.520
<v Speaker 1>Wow, that's some serious back end resilience. Okay, But what

79
00:04:03.560 --> 00:04:06.960
<v Speaker 1>about the front end, the user interface? Where does RxJS

80
00:04:06.960 --> 00:04:07.560
<v Speaker 1>shine there?

81
00:04:07.639 --> 00:04:11.439
<v Speaker 2>Oh? It absolutely shines in handling user interactions and orchestrating

82
00:04:11.479 --> 00:04:14.800
<v Speaker 2>events in the browser. You can model UI logic, which

83
00:04:14.840 --> 00:04:17.480
<v Speaker 2>can get messy as these clean streams of.

84
00:04:17.439 --> 00:04:19.160
<v Speaker 1>Events like what give me an example.

85
00:04:19.360 --> 00:04:23.600
<v Speaker 2>Okay, classic one a reactive search input. Think of a

86
00:04:23.639 --> 00:04:28.120
<v Speaker 2>recipe app search bar. You use from event to turn

87
00:04:28.199 --> 00:04:30.319
<v Speaker 2>keystrokes into an observable stream.

88
00:04:30.360 --> 00:04:33.360
<v Speaker 1>Okay, so every keypress is an event in the stream, right.

89
00:04:33.480 --> 00:04:35.560
<v Speaker 2>But you don't want to hit the server on every

90
00:04:35.600 --> 00:04:38.480
<v Speaker 2>single key stroke. That's wasteful, So you use debounced time

91
00:04:38.519 --> 00:04:41.360
<v Speaker 2>maybe five hundred milliseconds. It waits for the user to

92
00:04:41.399 --> 00:04:42.120
<v Speaker 2>pause typing.

93
00:04:42.319 --> 00:04:44.279
<v Speaker 1>Smart only search when they stop.

94
00:04:44.199 --> 00:04:48.000
<v Speaker 2>Then distinctil changed. This is crucial. It only lets the

95
00:04:48.079 --> 00:04:50.519
<v Speaker 2>query through if it's actually different from the last one.

96
00:04:50.759 --> 00:04:52.720
<v Speaker 2>No point searching for chicken twice in a row.

97
00:04:52.920 --> 00:04:54.560
<v Speaker 1>Right avoids redundant requests.

98
00:04:54.600 --> 00:04:58.360
<v Speaker 2>And here's a really powerful one. Switchmap. This operator is

99
00:04:58.399 --> 00:05:02.279
<v Speaker 2>perfect for search. It has this cancelation effect. Imagine the

100
00:05:02.360 --> 00:05:05.519
<v Speaker 2>user typees chick, a request goes out, then they quickly

101
00:05:05.560 --> 00:05:06.399
<v Speaker 2>type in.

102
00:05:06.439 --> 00:05:08.160
<v Speaker 1>So now they want chicken exactly.

103
00:05:08.600 --> 00:05:12.000
<v Speaker 2>Switch map automatically cancels the pending request for chick because,

104
00:05:12.040 --> 00:05:14.560
<v Speaker 2>as the source says, we are no longer interested in

105
00:05:14.600 --> 00:05:15.439
<v Speaker 2>the previous result.

106
00:05:15.600 --> 00:05:19.480
<v Speaker 1>Ah, So it automatically cleans up the old irrelevant requests.

107
00:05:19.240 --> 00:05:22.639
<v Speaker 2>That's clever, very clever. Keeps things efficient. And if you

108
00:05:22.680 --> 00:05:26.959
<v Speaker 2>have multiple inputs, say filters plus a search term combinedly,

109
00:05:27.120 --> 00:05:28.519
<v Speaker 2>this helps manage those together.

110
00:05:28.680 --> 00:05:32.000
<v Speaker 1>Okay, that handles text input really elegantly. What about something

111
00:05:32.120 --> 00:05:36.399
<v Speaker 1>like dragging and dropping files for upload maybe multiple files?

112
00:05:36.519 --> 00:05:39.519
<v Speaker 2>Yep rxgs handles that smoothly too. You can define a

113
00:05:39.600 --> 00:05:43.560
<v Speaker 2>drop zone, use from event for the dragon draw browser events,

114
00:05:43.959 --> 00:05:47.720
<v Speaker 2>react to those events. Maybe validate the files client side first,

115
00:05:48.120 --> 00:05:52.000
<v Speaker 2>and then handle multiple uploads concurrently. Our source points out

116
00:05:52.040 --> 00:05:55.839
<v Speaker 2>using each TTP request and Angular for example with report.

117
00:05:55.519 --> 00:05:59.439
<v Speaker 1>Progress oh two, so you can show a progress bar exactly.

118
00:05:59.079 --> 00:06:02.600
<v Speaker 2>Give the user feedback. And when uploading multiple files you

119
00:06:02.680 --> 00:06:06.040
<v Speaker 2>might use merge map, but potentially with a concurrency limit

120
00:06:06.120 --> 00:06:08.519
<v Speaker 2>a limit. Why to be kind to your server dot

121
00:06:08.600 --> 00:06:11.279
<v Speaker 2>merge with a limit helps you rate limit the number

122
00:06:11.279 --> 00:06:14.160
<v Speaker 2>of requests and prevent our server from having an overwhelming

123
00:06:14.199 --> 00:06:16.959
<v Speaker 2>number of ongoing requests. Yeah, maybe only upload three falls

124
00:06:16.959 --> 00:06:17.800
<v Speaker 2>out of time for instance.

125
00:06:17.800 --> 00:06:19.040
<v Speaker 1>Okay, managing concurrency.

126
00:06:19.079 --> 00:06:21.439
<v Speaker 2>You can even build retry logic for failed uploads right

127
00:06:21.480 --> 00:06:23.759
<v Speaker 2>into that stream makes the whole process feel much more

128
00:06:23.839 --> 00:06:24.800
<v Speaker 2>robust to the user.

129
00:06:25.079 --> 00:06:28.120
<v Speaker 1>Nice and those little pop up notifications the toast messages.

130
00:06:28.199 --> 00:06:31.600
<v Speaker 2>Yeah, RXGS makes managing those surprisingly easy. You can use

131
00:06:31.600 --> 00:06:34.160
<v Speaker 2>a behavior subject to hold the current stack or list

132
00:06:34.199 --> 00:06:36.720
<v Speaker 2>of notifications, and maybe a regular subject to push new

133
00:06:36.759 --> 00:06:39.600
<v Speaker 2>notifications onto the stack or trigger removals. You can even

134
00:06:39.639 --> 00:06:43.680
<v Speaker 2>easily set up automatic notification dismissal using the timer operator,

135
00:06:43.959 --> 00:06:47.120
<v Speaker 2>so a notification piers waits five seconds and disappears keeps

136
00:06:47.120 --> 00:06:47.800
<v Speaker 2>the UI clean.

137
00:06:47.879 --> 00:06:51.560
<v Speaker 1>Okay, So, from back end resilience to smooth UI interactions,

138
00:06:51.639 --> 00:06:55.439
<v Speaker 1>even notifications, it seems OURXGS covers a lot. But what

139
00:06:55.519 --> 00:06:59.759
<v Speaker 1>about really dynamics stuff like animations or truly real time

140
00:06:59.759 --> 00:07:01.399
<v Speaker 1>fear features. Does it play a role there?

141
00:07:01.879 --> 00:07:05.000
<v Speaker 2>Oh? Absolutely. The source shows how rxjas can be used

142
00:07:05.000 --> 00:07:09.040
<v Speaker 2>to craft dynamic and interactive animations and enable seamless real

143
00:07:09.079 --> 00:07:10.319
<v Speaker 2>time features.

144
00:07:09.959 --> 00:07:12.519
<v Speaker 1>Like animating physics. That sounds complex, it.

145
00:07:12.519 --> 00:07:15.319
<v Speaker 2>Does, but URXJAS can simplify it. The source has this

146
00:07:15.399 --> 00:07:19.040
<v Speaker 2>great example simulating realistic ball bouncing physics. You can aim

147
00:07:19.079 --> 00:07:21.959
<v Speaker 2>for a smooth sixty frames per second using RXJAS as

148
00:07:22.000 --> 00:07:24.800
<v Speaker 2>animation frame scheduler. It's optimized for this kind of thing.

149
00:07:25.000 --> 00:07:28.360
<v Speaker 2>Then you use operators like scan scan lets. You accumulate

150
00:07:28.399 --> 00:07:31.279
<v Speaker 2>state over time, so on each frame you calculate the

151
00:07:31.279 --> 00:07:34.279
<v Speaker 2>ball's new position of velocity based on gravity. Maybe some

152
00:07:34.439 --> 00:07:35.600
<v Speaker 2>energy loss on the bounce.

153
00:07:35.720 --> 00:07:39.079
<v Speaker 1>Wow. Applying physics roles within the stream exactly.

154
00:07:38.879 --> 00:07:42.120
<v Speaker 2>And operators like takewhile can stop the animation when the

155
00:07:42.160 --> 00:07:45.759
<v Speaker 2>ball stops bouncing, and repeat could restart. It gives you

156
00:07:45.879 --> 00:07:46.800
<v Speaker 2>fine grain control.

157
00:07:47.040 --> 00:07:49.720
<v Speaker 1>That's really cool. Okay, forget bouncing balls for a second.

158
00:07:49.920 --> 00:07:52.439
<v Speaker 1>What about something truly interactive like a chat app.

159
00:07:52.959 --> 00:07:56.199
<v Speaker 2>Perfect example, building a modern chat app maybe like a

160
00:07:56.199 --> 00:08:00.360
<v Speaker 2>simplified Instagram clone really shows off RXJAS. You could use

161
00:08:00.399 --> 00:08:02.680
<v Speaker 2>a replay subject to store reason chat.

162
00:08:02.480 --> 00:08:03.720
<v Speaker 1>History replace subject.

163
00:08:03.800 --> 00:08:07.279
<v Speaker 2>Yeah. It replays a buffer of passed emissions to new subscribers,

164
00:08:07.639 --> 00:08:10.079
<v Speaker 2>so so when soon joins the chat, they immediately get

165
00:08:10.120 --> 00:08:11.639
<v Speaker 2>the last, say fifty messages.

166
00:08:12.040 --> 00:08:13.519
<v Speaker 1>Instant history. Nice.

167
00:08:13.759 --> 00:08:17.759
<v Speaker 2>You can track users typing indicators easily with streams, even

168
00:08:17.839 --> 00:08:21.399
<v Speaker 2>handles sending voice messages. Maybe record audio converted to base

169
00:08:21.399 --> 00:08:24.439
<v Speaker 2>sixty four and send it over the stream. And the

170
00:08:24.439 --> 00:08:28.279
<v Speaker 2>core of real time chat is often web sockets. RXGS

171
00:08:28.319 --> 00:08:30.560
<v Speaker 2>has a built in web socket function that makes connecting

172
00:08:30.560 --> 00:08:33.279
<v Speaker 2>and managing web socket communication much simpler.

173
00:08:33.360 --> 00:08:36.759
<v Speaker 1>Okay, So it handles the underlying complexity of web sockets right.

174
00:08:36.960 --> 00:08:38.919
<v Speaker 2>And if we step back from the browser, look at

175
00:08:38.919 --> 00:08:42.320
<v Speaker 2>micro services. The source talks about real time updates using

176
00:08:42.360 --> 00:08:45.440
<v Speaker 2>gRPC streaming with SJS gRPC.

177
00:08:45.759 --> 00:08:47.200
<v Speaker 1>That's the high performance thing from.

178
00:08:47.080 --> 00:08:50.919
<v Speaker 2>Google r exactly built on HPTP two. It's great for

179
00:08:51.039 --> 00:08:54.879
<v Speaker 2>high performance remote procedure calls because it allows multiple streams

180
00:08:54.919 --> 00:08:58.399
<v Speaker 2>of messages over a single long live PCP connection. Much

181
00:08:58.440 --> 00:09:02.200
<v Speaker 2>lower latency thantional HTTP one point one requests for this

182
00:09:02.320 --> 00:09:03.000
<v Speaker 2>kind of thing, so.

183
00:09:03.039 --> 00:09:05.559
<v Speaker 1>Faster communication between services much faster.

184
00:09:05.759 --> 00:09:08.120
<v Speaker 2>And with RxJS in a framework like next js, you

185
00:09:08.120 --> 00:09:11.120
<v Speaker 2>can easily stream real time updates. Think of a food

186
00:09:11.200 --> 00:09:14.840
<v Speaker 2>order stream its status from pending to accepted, preparing curry

187
00:09:14.879 --> 00:09:18.879
<v Speaker 2>on the way delivered live updates, or even dynamic curier geolocation.

188
00:09:19.480 --> 00:09:22.080
<v Speaker 2>You could use the interval operator to send the courier's

189
00:09:22.080 --> 00:09:25.799
<v Speaker 2>location every few seconds and take until to manage the

190
00:09:25.840 --> 00:09:28.440
<v Speaker 2>life cycle of that stream, stopping it when the delivery

191
00:09:28.480 --> 00:09:32.000
<v Speaker 2>is complete. For example. It's about that constant efficient flow

192
00:09:32.000 --> 00:09:32.639
<v Speaker 2>of information.

193
00:09:32.960 --> 00:09:37.000
<v Speaker 1>Okay, this is all incredibly powerful, but with great power

194
00:09:37.320 --> 00:09:40.840
<v Speaker 1>comes the need for performance and reliability. Right, how do

195
00:09:40.879 --> 00:09:43.679
<v Speaker 1>we make sure our RxJS apps are not just cool

196
00:09:43.840 --> 00:09:46.679
<v Speaker 1>but also fast, efficient and testable?

197
00:09:46.799 --> 00:09:51.080
<v Speaker 2>Absolutely critical points. Performance optimization and solid testing are key.

198
00:09:51.559 --> 00:09:56.159
<v Speaker 2>A powerful library used carelessly can definitely create bottlenecks. For optimization,

199
00:09:56.519 --> 00:09:59.360
<v Speaker 2>a lot comes down to strategic operator selection. We've already

200
00:09:59.399 --> 00:10:02.399
<v Speaker 2>touched on some de bounced time distinct until change they

201
00:10:02.399 --> 00:10:05.600
<v Speaker 2>stop unnecessary work. Filter like checking value dot trim dot

202
00:10:05.639 --> 00:10:09.039
<v Speaker 2>length on a search avoids processing empty values, and switchmap

203
00:10:09.080 --> 00:10:12.320
<v Speaker 2>with its cancelation effect, is huge for performance in scenarios

204
00:10:12.360 --> 00:10:13.360
<v Speaker 2>like typed search.

205
00:10:13.200 --> 00:10:14.519
<v Speaker 1>Right avoiding wasted effort.

206
00:10:14.799 --> 00:10:18.120
<v Speaker 2>Another massive one is casing results. The SharePlay operator is

207
00:10:18.120 --> 00:10:21.039
<v Speaker 2>central here. Imagine you have multiple components on a page

208
00:10:21.039 --> 00:10:23.000
<v Speaker 2>that all need the same user profile data.

209
00:10:23.120 --> 00:10:25.840
<v Speaker 1>You don't want each one making a separate API call.

210
00:10:25.919 --> 00:10:28.799
<v Speaker 2>Exactly, SharePlay lets you make the call once, then it

211
00:10:28.960 --> 00:10:33.320
<v Speaker 2>multicasts the same cash value to multiple subscribers. Crucially, it

212
00:10:33.360 --> 00:10:36.440
<v Speaker 2>also ensures that late state subscribers would catch up on

213
00:10:36.480 --> 00:10:39.960
<v Speaker 2>the previously emitted values, so if a component loads later,

214
00:10:40.360 --> 00:10:42.320
<v Speaker 2>it still gets the data immediately from.

215
00:10:42.159 --> 00:10:44.559
<v Speaker 1>The cash so it broadcasts the result and remembers the

216
00:10:44.639 --> 00:10:46.759
<v Speaker 1>latest one for newcomers precisely.

217
00:10:47.240 --> 00:10:50.600
<v Speaker 2>The source recommends configuring it carefully, though often buffer size

218
00:10:50.679 --> 00:10:54.600
<v Speaker 2>one just cash the latest value and recount true proof

219
00:10:54.639 --> 00:10:55.720
<v Speaker 2>count true. What's that for?

220
00:10:56.200 --> 00:10:59.519
<v Speaker 1>That's really important for preventing memory leaks. It means the

221
00:10:59.559 --> 00:11:03.919
<v Speaker 1>underlying source subscription, like the network request, automatically tears itself

222
00:11:03.960 --> 00:11:07.399
<v Speaker 1>down when the last subscriber unsubscribes. If you don't use it,

223
00:11:07.440 --> 00:11:09.840
<v Speaker 1>the cash might hang around forever, even if nothing needs

224
00:11:09.840 --> 00:11:12.840
<v Speaker 1>it anymore. This touches on the difference between hot and

225
00:11:12.879 --> 00:11:17.919
<v Speaker 1>cold observables. Shirley helps turn a typically cold observable starts

226
00:11:17.919 --> 00:11:21.279
<v Speaker 1>on subscription into a hot one emits regardless of subscribers

227
00:11:21.279 --> 00:11:22.000
<v Speaker 1>sharing the result.

228
00:11:22.159 --> 00:11:26.120
<v Speaker 2>Got it smart caching with automatic cleanup. What other memory

229
00:11:26.200 --> 00:11:28.840
<v Speaker 2>leak pitfalls are there? The big one is just forgetting

230
00:11:28.879 --> 00:11:32.720
<v Speaker 2>to unsubscribe, especially in components that get created and destroyed

231
00:11:32.759 --> 00:11:35.919
<v Speaker 2>like an Angular or React. The take until operator is

232
00:11:36.000 --> 00:11:39.480
<v Speaker 2>highlighted as a primary way to manage the life cycle

233
00:11:39.519 --> 00:11:43.799
<v Speaker 2>of observable subscriptions gracefully. You typically create a subject that

234
00:11:43.799 --> 00:11:47.120
<v Speaker 2>emits when the component is destroyed and pipe your subscriptions

235
00:11:47.120 --> 00:11:50.559
<v Speaker 2>through take un till doc deli dot ensures everything cleans

236
00:11:50.600 --> 00:11:51.600
<v Speaker 2>up properly.

237
00:11:51.320 --> 00:11:53.799
<v Speaker 1>Okay, a standard pattern for cleanup and for.

238
00:11:53.799 --> 00:11:57.559
<v Speaker 2>Really heavy calculations things that might freeze the browser's main thread.

239
00:11:58.159 --> 00:12:01.840
<v Speaker 2>Web workers are your friend. Offload the work. Urxgs helps

240
00:12:01.879 --> 00:12:05.480
<v Speaker 2>manage the communication stream with the web worker efficiently using

241
00:12:05.519 --> 00:12:09.240
<v Speaker 2>operators like filter map distinct until changed on the messages,

242
00:12:09.799 --> 00:12:12.039
<v Speaker 2>or even buffer count. Maybe collect a thousand events from

243
00:12:12.080 --> 00:12:14.519
<v Speaker 2>the worker before processing them on the main thread, which

244
00:12:14.559 --> 00:12:18.080
<v Speaker 2>the source notes can significantly improve memory usage or throttle time.

245
00:12:18.080 --> 00:12:21.080
<v Speaker 2>Maybe only process messages from the worker every ten milliseconds

246
00:12:21.120 --> 00:12:23.000
<v Speaker 2>to avoid overwhelming the main thread.

247
00:12:22.919 --> 00:12:26.480
<v Speaker 1>So optimizing the communication channel itself. Okay, that covers performance. Well,

248
00:12:26.480 --> 00:12:29.720
<v Speaker 1>what about testing? ACNK code is notoriously tricky?

249
00:12:30.039 --> 00:12:34.000
<v Speaker 2>It can be, but urxjs actually provides great tools. Marble

250
00:12:34.000 --> 00:12:39.200
<v Speaker 2>testing is fantastic, especially for mastering time based RxJS operators.

251
00:12:39.360 --> 00:12:41.200
<v Speaker 1>Marble testing sounds interesting.

252
00:12:41.320 --> 00:12:43.600
<v Speaker 2>It is. You use a special test schedule and that

253
00:12:43.679 --> 00:12:47.519
<v Speaker 2>creates a controlled virtual time environment. Time doesn't pass normally,

254
00:12:47.600 --> 00:12:51.320
<v Speaker 2>you control it. Then you use marble diagrams simple strings

255
00:12:51.519 --> 00:12:54.480
<v Speaker 2>to visually represent observable behavior over.

256
00:12:54.279 --> 00:12:56.200
<v Speaker 1>Time like aski art for streams.

257
00:12:56.679 --> 00:13:00.799
<v Speaker 2>Kind of a dash means one meets a virtual time. Letters,

258
00:13:00.840 --> 00:13:05.360
<v Speaker 2>az number zero nine represent emitted values, parentheses mean multiple

259
00:13:05.399 --> 00:13:08.879
<v Speaker 2>values in the same timeframe. Pipe is completion, hash, hashtag

260
00:13:08.960 --> 00:13:09.440
<v Speaker 2>is error.

261
00:13:09.559 --> 00:13:11.720
<v Speaker 1>Okay, a visual language for asynchronous events.

262
00:13:11.799 --> 00:13:14.840
<v Speaker 2>Exactly, you write tests saying given this input stream, Marble

263
00:13:14.879 --> 00:13:18.159
<v Speaker 2>diagram I expect this output stream marble diagram. It makes

264
00:13:18.200 --> 00:13:22.320
<v Speaker 2>testing complex timing logic surprisingly predictable and visual, Like testing

265
00:13:22.399 --> 00:13:24.879
<v Speaker 2>that notification system with its automatic dismissal timer.

266
00:13:25.000 --> 00:13:27.759
<v Speaker 1>That sounds incredibly useful for debugging timing issues. What about

267
00:13:27.799 --> 00:13:29.399
<v Speaker 1>testing things like API calls?

268
00:13:29.559 --> 00:13:32.960
<v Speaker 2>Mocking is key there. Angular has its HTTP testing controller,

269
00:13:33.080 --> 00:13:36.919
<v Speaker 2>but the source also highlights mock service worker or MSW. Yeah,

270
00:13:37.000 --> 00:13:40.279
<v Speaker 2>mock service worker. It's cool because it intercepts network requests

271
00:13:40.440 --> 00:13:42.559
<v Speaker 2>at the service worker level in the browser.

272
00:13:42.240 --> 00:13:44.200
<v Speaker 1>So it's like a proxy sort of.

273
00:13:44.320 --> 00:13:47.360
<v Speaker 2>Yeah. It means your application code makes real fetch calls,

274
00:13:47.440 --> 00:13:51.279
<v Speaker 2>but MSW catches them and returns your pre defined mock responses.

275
00:13:51.639 --> 00:13:55.480
<v Speaker 2>It leads to simplified integration tests because your component code

276
00:13:55.519 --> 00:13:57.159
<v Speaker 2>doesn't even know it being mocked. It looks like a

277
00:13:57.200 --> 00:13:58.240
<v Speaker 2>real API call.

278
00:13:58.399 --> 00:14:01.919
<v Speaker 1>Neat less test specific fit code and your components exactly.

279
00:14:02.240 --> 00:14:05.440
<v Speaker 2>And finally, for state management, like with NGRX, the source

280
00:14:05.480 --> 00:14:09.440
<v Speaker 2>emphasizes testing the core pieces, effects which handle side effects,

281
00:14:09.759 --> 00:14:13.039
<v Speaker 2>and selectors which get data from the store as pure

282
00:14:13.039 --> 00:14:17.000
<v Speaker 2>functions whenever possible. Pure functions are easy to test. Given

283
00:14:17.000 --> 00:14:19.159
<v Speaker 2>input X, they always return output Y.

284
00:14:19.480 --> 00:14:22.679
<v Speaker 1>Right, test the pure logic separately. Okay, that brings us

285
00:14:22.720 --> 00:14:26.200
<v Speaker 1>nicely to state management itself. How does RXGS elevate that

286
00:14:26.240 --> 00:14:29.759
<v Speaker 1>whole area? Can you build your own state management with it?

287
00:14:29.960 --> 00:14:33.720
<v Speaker 2>Oh? Absolutely? RCJS provides the building blocks to make state

288
00:14:33.759 --> 00:14:38.720
<v Speaker 2>management more scalable, predictable, performance, and maintainable. You can build

289
00:14:38.720 --> 00:14:41.879
<v Speaker 2>your own simple reactive state manager. You typically use a

290
00:14:41.879 --> 00:14:43.960
<v Speaker 2>behavior subject to hold the current state.

291
00:14:43.759 --> 00:14:47.440
<v Speaker 1>Snapshot behavior subject because it always has a current value

292
00:14:47.440 --> 00:14:49.080
<v Speaker 1>for new subscribers.

293
00:14:48.559 --> 00:14:52.080
<v Speaker 2>Exactly, and maybe a regular subject to act as an

294
00:14:52.120 --> 00:14:57.039
<v Speaker 2>action dispatcher. Components dispatch immutable actions to this subject. Then

295
00:14:57.080 --> 00:14:59.639
<v Speaker 2>you'd have a stream that combines the actions with latest

296
00:14:59.639 --> 00:15:02.960
<v Speaker 2>state using with latest from, processes them through a pure

297
00:15:03.000 --> 00:15:06.039
<v Speaker 2>reducer function just like reducs, and emits the new state

298
00:15:06.080 --> 00:15:07.440
<v Speaker 2>back into the behavior subject.

299
00:15:07.559 --> 00:15:11.279
<v Speaker 1>So implementing the redux pattern with RXGS primitives pretty much.

300
00:15:11.399 --> 00:15:13.879
<v Speaker 2>And for side effects like making an API call when

301
00:15:13.919 --> 00:15:16.639
<v Speaker 2>an action happens, you can create an effect strain, often

302
00:15:16.720 --> 00:15:20.320
<v Speaker 2>using operators like exhaustmap to prevent firing off duplicate requests

303
00:15:20.399 --> 00:15:21.840
<v Speaker 2>if the user clicks frantically.

304
00:15:21.960 --> 00:15:24.440
<v Speaker 1>Okay, so a custom solution is feasible. But what about

305
00:15:24.519 --> 00:15:26.879
<v Speaker 1>established libraries like NGRX right.

306
00:15:27.039 --> 00:15:30.519
<v Speaker 2>NGRX is a popular choice, especially in the angular, heavily

307
00:15:30.559 --> 00:15:33.600
<v Speaker 2>inspired by reducs but built with rxgas at its core.

308
00:15:34.120 --> 00:15:37.080
<v Speaker 2>The source details how it works. Provide store sets up

309
00:15:37.080 --> 00:15:40.039
<v Speaker 2>the global state, create a reducer defines those pure state

310
00:15:40.080 --> 00:15:43.559
<v Speaker 2>transition functions, and create effect is used for side effects,

311
00:15:43.759 --> 00:15:46.759
<v Speaker 2>often combined with of type to listen for specific actions

312
00:15:46.759 --> 00:15:49.720
<v Speaker 2>and operators like exhaustmap or merge map or switch map

313
00:15:49.919 --> 00:15:52.639
<v Speaker 2>depending on the desired behavior for handling concurrent.

314
00:15:52.240 --> 00:15:55.919
<v Speaker 1>Actions, different operators for different side effect strategies exactly.

315
00:15:56.320 --> 00:16:00.679
<v Speaker 2>NGRX also has powerful selectors created with creed selects. They

316
00:16:00.720 --> 00:16:06.639
<v Speaker 2>provide regular control over accessing state slices and crucially offer memorization.

317
00:16:06.200 --> 00:16:07.759
<v Speaker 1>Memoization meaning casing.

318
00:16:07.879 --> 00:16:11.039
<v Speaker 2>Yes, if the input state pieces haven't changed, the selector

319
00:16:11.080 --> 00:16:14.960
<v Speaker 2>returns the previously computed result instantly, huge performance win for

320
00:16:15.000 --> 00:16:17.879
<v Speaker 2>derived data. You can even integrate router events into your

321
00:16:18.039 --> 00:16:21.159
<v Speaker 2>NGRX state using riter state and use meta reducers for

322
00:16:21.240 --> 00:16:23.919
<v Speaker 2>things that cut across all state changes like logging or

323
00:16:23.960 --> 00:16:25.200
<v Speaker 2>local storage persistence.

324
00:16:25.559 --> 00:16:28.919
<v Speaker 1>That's a pretty comprehensive system, but the source mentions something

325
00:16:28.960 --> 00:16:31.879
<v Speaker 1>really intriguing, building your own version of something like tanstack

326
00:16:32.000 --> 00:16:34.159
<v Speaker 1>query but just with RxJS.

327
00:16:34.240 --> 00:16:36.559
<v Speaker 2>Yeah, isn't that cool? It's a thought experiment. Showing how

328
00:16:36.600 --> 00:16:41.360
<v Speaker 2>powerful RxJS is. The idea is to replicate core features

329
00:16:41.399 --> 00:16:46.919
<v Speaker 2>of modern acing state libraries using only RxJS operators and concepts.

330
00:16:47.320 --> 00:16:50.240
<v Speaker 1>So what would this RXGS query include?

331
00:16:50.399 --> 00:16:54.039
<v Speaker 2>Well, first, declarative queries you define and retrieve data based

332
00:16:54.039 --> 00:16:57.000
<v Speaker 2>on query keys, like an array of recipes or recipe.

333
00:16:57.039 --> 00:17:01.080
<v Speaker 2>I'd then automatic caching. You'd likely use a JavaScript map

334
00:17:01.360 --> 00:17:04.480
<v Speaker 2>to store the query keys and their corresponding observable streams

335
00:17:04.640 --> 00:17:07.799
<v Speaker 2>the ones fetching the data. You'd implement stale time, how

336
00:17:07.839 --> 00:17:10.640
<v Speaker 2>long data is considered fresh before needing a background check,

337
00:17:11.240 --> 00:17:14.480
<v Speaker 2>and g time garbage collection time for automatically removing inactive

338
00:17:14.559 --> 00:17:17.039
<v Speaker 2>queries from the cash after a while to prevent memory leaks,

339
00:17:17.440 --> 00:17:18.640
<v Speaker 2>the cash cleans itself up.

340
00:17:18.799 --> 00:17:20.559
<v Speaker 1>Okay, casing with life cycle management.

341
00:17:20.599 --> 00:17:24.119
<v Speaker 2>What else The really neat part the stale wall revalidate.

342
00:17:23.559 --> 00:17:27.119
<v Speaker 1>Mechanists stale while revalidate explain that it's a strategy to

343
00:17:27.319 --> 00:17:30.039
<v Speaker 1>always show some data to the user, even if the

344
00:17:30.119 --> 00:17:31.079
<v Speaker 1>data might be out of date.

345
00:17:31.519 --> 00:17:34.799
<v Speaker 2>So when a component needs data, if it's in the cash,

346
00:17:34.880 --> 00:17:38.319
<v Speaker 2>even it's slightly stale, it displays that cash data immediately,

347
00:17:38.599 --> 00:17:39.799
<v Speaker 2>no loading spinner.

348
00:17:39.440 --> 00:17:41.279
<v Speaker 1>Initially instant feedback right.

349
00:17:41.599 --> 00:17:44.799
<v Speaker 2>Then in the background it sends the network request and

350
00:17:44.920 --> 00:17:48.480
<v Speaker 2>refreshes the data afterward. If new data comes back, the

351
00:17:48.599 --> 00:17:52.839
<v Speaker 2>UI updates. It drastically improves the perceived performance.

352
00:17:52.359 --> 00:17:55.079
<v Speaker 1>Because the user sees something right away exactly.

353
00:17:55.599 --> 00:17:58.720
<v Speaker 2>And finally, background updates. You could use RxJS as from

354
00:17:58.720 --> 00:18:01.720
<v Speaker 2>event to listen for browser events like the window regaining

355
00:18:01.720 --> 00:18:04.920
<v Speaker 2>focus or the network connection coming back online. When those

356
00:18:04.920 --> 00:18:08.079
<v Speaker 2>events happen, you can automatically trigger background refetches for Corey's

357
00:18:08.079 --> 00:18:11.319
<v Speaker 2>mark to stale, ensuring the data stays fresh without manual intervention.

358
00:18:11.759 --> 00:18:14.880
<v Speaker 1>Wow. Building all that just with RXGS, that really shows

359
00:18:14.920 --> 00:18:19.160
<v Speaker 1>its flexibility. This has been a genuinely comprehensive deep dive

360
00:18:19.160 --> 00:18:22.960
<v Speaker 1>into rxgas. We've gone from air handling, UI design animations,

361
00:18:23.039 --> 00:18:26.759
<v Speaker 1>real time stuff all the way to performance testing and

362
00:18:26.799 --> 00:18:30.240
<v Speaker 1>advanced state management. It seems really clear that rchas you know,

363
00:18:30.279 --> 00:18:33.000
<v Speaker 1>once you get past that initial curve and apply it strategically,

364
00:18:33.240 --> 00:18:35.880
<v Speaker 1>it really can be a game changer for building modern applications.

365
00:18:36.279 --> 00:18:40.359
<v Speaker 1>It just consistently seems to simplify these really complex asynchronous

366
00:18:40.359 --> 00:18:43.480
<v Speaker 1>problems and genuinely improves the user experience. It turns that

367
00:18:43.559 --> 00:18:46.839
<v Speaker 1>learning curve into a really powerful tool set. So thinking

368
00:18:46.839 --> 00:18:50.440
<v Speaker 1>about all this power and flexibility. What's an existing non

369
00:18:50.480 --> 00:18:53.279
<v Speaker 1>reactive problem, maybe in your own work or personal project,

370
00:18:53.319 --> 00:18:55.680
<v Speaker 1>that you think could truly shine if you reimagined it

371
00:18:55.720 --> 00:18:58.839
<v Speaker 1>through this reactive RXGS lens, something to chew on. Thank

372
00:18:58.880 --> 00:19:00.920
<v Speaker 1>you for joining us for this deep Until next time,

373
00:19:01.119 --> 00:19:02.960
<v Speaker 1>keep digging for those nuggets of knowledge.