Speaker 1: Welcome to the deep dive. We take stacks of information,
Speaker 1: pull out the key nuggets and help you get informed fast.
Speaker 1: Today we're plunging into a JavaScript of library. It's incredibly powerful,
Speaker 1: but you know, sometimes gets this reputation for being a
Speaker 1: bit intimidating. We're talking RxJS, Reactive Extensions for JavaScript, and
Speaker 1: our mission for the steep dive to really unpack r XJS,
Speaker 1: look at that perceived steep learning curve and show its
Speaker 1: practical power. We're using insights directly from a great source,
Speaker 1: the RxJS Cookbook for Reactive Programming. So you're going to
Speaker 1: get a shortcut here a way to understand how RxJS
Speaker 1: simplifies complex asynchronous stuff data flows, event handling. We'll go
Speaker 1: beyond just listing operators and see how they build well,
Speaker 1: surprisingly robust solutions for UIs, for micro services, you name it. Okay,
Speaker 1: let's start the beginning. What exactly is RxJS? For anyone
Speaker 1: who's heard the name, it isn't totally sure. What's the
Speaker 1: core idea? Right?
Speaker 2: Well, at its heart, RxJS is really a library designed
Speaker 2: to make it easier to work with asynchronous data streams
Speaker 2: and also orchestrating sequences of events that have up and
Speaker 2: over time it gives you these powerful tools, mainly observables
Speaker 2: and operators to manage that complexity, the kind they can
Speaker 2: feel pretty chaotic otherwise.
Speaker 1: Okay, that sounds super useful, I mean, especially with all
Speaker 1: the acing stuff happening in modern web apps. But our
Speaker 1: source mentions this common belief. You know that RxJS has
Speaker 1: a steep learning curve even after developers learn what individual
Speaker 1: operators do, What specific challenges do they run into when
Speaker 1: they try to really fully adopt this reactive way of thinking.
Speaker 2: Yeah, that's a really important point, because just knowing what
Speaker 2: say map or filter does isn't really the whole story.
Speaker 2: Developers often hit roadblocks when it comes to debugging. Debugging
Speaker 2: RxJS streams can be tricky, and optimizing them, testing them effectively,
Speaker 2: managing reactive state across a whole application, and maybe the
Speaker 2: biggest one, figuring out the right operator or combination of
Speaker 2: operators for a specific real world problem. So this deep dive,
Speaker 2: we really want to focus on those practical solutions, the
Speaker 2: bigger picture, beyond just the operator definition.
Speaker 1: Okay, perfect, This is where it gets really interesting for me.
Speaker 1: How does our XJS actually help build better web experiences
Speaker 1: day to day? Let's serve something. Everyone deals with network
Speaker 1: requests and inevitably network errors, right.
Speaker 2: Our XAS is fantastic for building robustness resilience, especially with
Speaker 2: network communication, because let's face it, networks aren't always reliable.
Speaker 2: The simplest thing is using the catcher operator. It lets
Speaker 2: you gracefully handle a problem. When a request fails, you
Speaker 2: can maybe show a notification like oops, couldn't fetch recipes,
Speaker 2: and then you either complete the stream nicely or maybe
Speaker 2: rethrough the air. If something else needs to deal with.
Speaker 1: That, got it, handle it or pass it on exactly.
Speaker 2: Now. For those little temporary server glitches, maybe the server's
Speaker 2: just busy for a second, the retry operator is your
Speaker 2: go to just try again. Well, yes, but it gets smarter.
Speaker 2: Our source describes using retry with a delay function. This
Speaker 2: function can exponentially increase the time in between two retry attempts.
Speaker 1: Ah, so it waits longer each time it fails.
Speaker 2: Precisely instead just hammering the server immediately, it backs off,
Speaker 2: gives the server breathing room, increases the chance of success
Speaker 2: if it's just a temporary issue, reduces load.
Speaker 1: That makes sense being smarter about retries. And then there's
Speaker 1: this thing called the circuit breaker pattern. I like the
Speaker 1: electrical analogy.
Speaker 2: It's a great analogy. Just like the breaker in your
Speaker 2: house trips during the surge to prevent damage. If your
Speaker 2: apsees several cascading errors, maybe multiple back end services are failing,
Speaker 2: the RXGS circuit breaker trips. It goes into an open
Speaker 2: state for a set time, maybe fifteen seconds. It just
Speaker 2: immediately rejects new requests to that failing.
Speaker 1: Service, so it stops trying for a bit, right, it.
Speaker 2: Says, Okay, this thing is down, let's leave it alone.
Speaker 2: After the timeout, it goes half open. It allows a
Speaker 2: few test requests through to see if the services.
Speaker 1: Recovered, checking if it's safe.
Speaker 2: Yeah, exactly if those fail, back to open. If they succeed,
Speaker 2: it closes the circuit back to normal operation. It's not
Speaker 2: just error handling. It's about building self healing systems, making
Speaker 2: your application more resilient, more responsive even when parts of
Speaker 2: it are failing.
Speaker 1: Wow, that's some serious back end resilience. Okay, But what
Speaker 1: about the front end, the user interface? Where does RxJS
Speaker 1: shine there?
Speaker 2: Oh? It absolutely shines in handling user interactions and orchestrating
Speaker 2: events in the browser. You can model UI logic, which
Speaker 2: can get messy as these clean streams of.
Speaker 1: Events like what give me an example.
Speaker 2: Okay, classic one a reactive search input. Think of a
Speaker 2: recipe app search bar. You use from event to turn
Speaker 2: keystrokes into an observable stream.
Speaker 1: Okay, so every keypress is an event in the stream, right.
Speaker 2: But you don't want to hit the server on every
Speaker 2: single key stroke. That's wasteful, So you use debounced time
Speaker 2: maybe five hundred milliseconds. It waits for the user to
Speaker 2: pause typing.
Speaker 1: Smart only search when they stop.
Speaker 2: Then distinctil changed. This is crucial. It only lets the
Speaker 2: query through if it's actually different from the last one.
Speaker 2: No point searching for chicken twice in a row.
Speaker 1: Right avoids redundant requests.
Speaker 2: And here's a really powerful one. Switchmap. This operator is
Speaker 2: perfect for search. It has this cancelation effect. Imagine the
Speaker 2: user typees chick, a request goes out, then they quickly
Speaker 2: type in.
Speaker 1: So now they want chicken exactly.
Speaker 2: Switch map automatically cancels the pending request for chick because,
Speaker 2: as the source says, we are no longer interested in
Speaker 2: the previous result.
Speaker 1: Ah, So it automatically cleans up the old irrelevant requests.
Speaker 2: That's clever, very clever. Keeps things efficient. And if you
Speaker 2: have multiple inputs, say filters plus a search term combinedly,
Speaker 2: this helps manage those together.
Speaker 1: Okay, that handles text input really elegantly. What about something
Speaker 1: like dragging and dropping files for upload maybe multiple files?
Speaker 2: Yep rxgs handles that smoothly too. You can define a
Speaker 2: drop zone, use from event for the dragon draw browser events,
Speaker 2: react to those events. Maybe validate the files client side first,
Speaker 2: and then handle multiple uploads concurrently. Our source points out
Speaker 2: using each TTP request and Angular for example with report.
Speaker 1: Progress oh two, so you can show a progress bar exactly.
Speaker 2: Give the user feedback. And when uploading multiple files you
Speaker 2: might use merge map, but potentially with a concurrency limit
Speaker 2: a limit. Why to be kind to your server dot
Speaker 2: merge with a limit helps you rate limit the number
Speaker 2: of requests and prevent our server from having an overwhelming
Speaker 2: number of ongoing requests. Yeah, maybe only upload three falls
Speaker 2: out of time for instance.
Speaker 1: Okay, managing concurrency.
Speaker 2: You can even build retry logic for failed uploads right
Speaker 2: into that stream makes the whole process feel much more
Speaker 2: robust to the user.
Speaker 1: Nice and those little pop up notifications the toast messages.
Speaker 2: Yeah, RXGS makes managing those surprisingly easy. You can use
Speaker 2: a behavior subject to hold the current stack or list
Speaker 2: of notifications, and maybe a regular subject to push new
Speaker 2: notifications onto the stack or trigger removals. You can even
Speaker 2: easily set up automatic notification dismissal using the timer operator,
Speaker 2: so a notification piers waits five seconds and disappears keeps
Speaker 2: the UI clean.
Speaker 1: Okay, So, from back end resilience to smooth UI interactions,
Speaker 1: even notifications, it seems OURXGS covers a lot. But what
Speaker 1: about really dynamics stuff like animations or truly real time
Speaker 1: fear features. Does it play a role there?
Speaker 2: Oh? Absolutely. The source shows how rxjas can be used
Speaker 2: to craft dynamic and interactive animations and enable seamless real
Speaker 2: time features.
Speaker 1: Like animating physics. That sounds complex, it.
Speaker 2: Does, but URXJAS can simplify it. The source has this
Speaker 2: great example simulating realistic ball bouncing physics. You can aim
Speaker 2: for a smooth sixty frames per second using RXJAS as
Speaker 2: animation frame scheduler. It's optimized for this kind of thing.
Speaker 2: Then you use operators like scan scan lets. You accumulate
Speaker 2: state over time, so on each frame you calculate the
Speaker 2: ball's new position of velocity based on gravity. Maybe some
Speaker 2: energy loss on the bounce.
Speaker 1: Wow. Applying physics roles within the stream exactly.
Speaker 2: And operators like takewhile can stop the animation when the
Speaker 2: ball stops bouncing, and repeat could restart. It gives you
Speaker 2: fine grain control.
Speaker 1: That's really cool. Okay, forget bouncing balls for a second.
Speaker 1: What about something truly interactive like a chat app.
Speaker 2: Perfect example, building a modern chat app maybe like a
Speaker 2: simplified Instagram clone really shows off RXJAS. You could use
Speaker 2: a replay subject to store reason chat.
Speaker 1: History replace subject.
Speaker 2: Yeah. It replays a buffer of passed emissions to new subscribers,
Speaker 2: so so when soon joins the chat, they immediately get
Speaker 2: the last, say fifty messages.
Speaker 1: Instant history. Nice.
Speaker 2: You can track users typing indicators easily with streams, even
Speaker 2: handles sending voice messages. Maybe record audio converted to base
Speaker 2: sixty four and send it over the stream. And the
Speaker 2: core of real time chat is often web sockets. RXGS
Speaker 2: has a built in web socket function that makes connecting
Speaker 2: and managing web socket communication much simpler.
Speaker 1: Okay, So it handles the underlying complexity of web sockets right.
Speaker 2: And if we step back from the browser, look at
Speaker 2: micro services. The source talks about real time updates using
Speaker 2: gRPC streaming with SJS gRPC.
Speaker 1: That's the high performance thing from.
Speaker 2: Google r exactly built on HPTP two. It's great for
Speaker 2: high performance remote procedure calls because it allows multiple streams
Speaker 2: of messages over a single long live PCP connection. Much
Speaker 2: lower latency thantional HTTP one point one requests for this
Speaker 2: kind of thing, so.
Speaker 1: Faster communication between services much faster.
Speaker 2: And with RxJS in a framework like next js, you
Speaker 2: can easily stream real time updates. Think of a food
Speaker 2: order stream its status from pending to accepted, preparing curry
Speaker 2: on the way delivered live updates, or even dynamic curier geolocation.
Speaker 2: You could use the interval operator to send the courier's
Speaker 2: location every few seconds and take until to manage the
Speaker 2: life cycle of that stream, stopping it when the delivery
Speaker 2: is complete. For example. It's about that constant efficient flow
Speaker 2: of information.
Speaker 1: Okay, this is all incredibly powerful, but with great power
Speaker 1: comes the need for performance and reliability. Right, how do
Speaker 1: we make sure our RxJS apps are not just cool
Speaker 1: but also fast, efficient and testable?
Speaker 2: Absolutely critical points. Performance optimization and solid testing are key.
Speaker 2: A powerful library used carelessly can definitely create bottlenecks. For optimization,
Speaker 2: a lot comes down to strategic operator selection. We've already
Speaker 2: touched on some de bounced time distinct until change they
Speaker 2: stop unnecessary work. Filter like checking value dot trim dot
Speaker 2: length on a search avoids processing empty values, and switchmap
Speaker 2: with its cancelation effect, is huge for performance in scenarios
Speaker 2: like typed search.
Speaker 1: Right avoiding wasted effort.
Speaker 2: Another massive one is casing results. The SharePlay operator is
Speaker 2: central here. Imagine you have multiple components on a page
Speaker 2: that all need the same user profile data.
Speaker 1: You don't want each one making a separate API call.
Speaker 2: Exactly, SharePlay lets you make the call once, then it
Speaker 2: multicasts the same cash value to multiple subscribers. Crucially, it
Speaker 2: also ensures that late state subscribers would catch up on
Speaker 2: the previously emitted values, so if a component loads later,
Speaker 2: it still gets the data immediately from.
Speaker 1: The cash so it broadcasts the result and remembers the
Speaker 1: latest one for newcomers precisely.
Speaker 2: The source recommends configuring it carefully, though often buffer size
Speaker 2: one just cash the latest value and recount true proof
Speaker 2: count true. What's that for?
Speaker 1: That's really important for preventing memory leaks. It means the
Speaker 1: underlying source subscription, like the network request, automatically tears itself
Speaker 1: down when the last subscriber unsubscribes. If you don't use it,
Speaker 1: the cash might hang around forever, even if nothing needs
Speaker 1: it anymore. This touches on the difference between hot and
Speaker 1: cold observables. Shirley helps turn a typically cold observable starts
Speaker 1: on subscription into a hot one emits regardless of subscribers
Speaker 1: sharing the result.
Speaker 2: Got it smart caching with automatic cleanup. What other memory
Speaker 2: leak pitfalls are there? The big one is just forgetting
Speaker 2: to unsubscribe, especially in components that get created and destroyed
Speaker 2: like an Angular or React. The take until operator is
Speaker 2: highlighted as a primary way to manage the life cycle
Speaker 2: of observable subscriptions gracefully. You typically create a subject that
Speaker 2: emits when the component is destroyed and pipe your subscriptions
Speaker 2: through take un till doc deli dot ensures everything cleans
Speaker 2: up properly.
Speaker 1: Okay, a standard pattern for cleanup and for.
Speaker 2: Really heavy calculations things that might freeze the browser's main thread.
Speaker 2: Web workers are your friend. Offload the work. Urxgs helps
Speaker 2: manage the communication stream with the web worker efficiently using
Speaker 2: operators like filter map distinct until changed on the messages,
Speaker 2: or even buffer count. Maybe collect a thousand events from
Speaker 2: the worker before processing them on the main thread, which
Speaker 2: the source notes can significantly improve memory usage or throttle time.
Speaker 2: Maybe only process messages from the worker every ten milliseconds
Speaker 2: to avoid overwhelming the main thread.
Speaker 1: So optimizing the communication channel itself. Okay, that covers performance. Well,
Speaker 1: what about testing? ACNK code is notoriously tricky?
Speaker 2: It can be, but urxjs actually provides great tools. Marble
Speaker 2: testing is fantastic, especially for mastering time based RxJS operators.
Speaker 1: Marble testing sounds interesting.
Speaker 2: It is. You use a special test schedule and that
Speaker 2: creates a controlled virtual time environment. Time doesn't pass normally,
Speaker 2: you control it. Then you use marble diagrams simple strings
Speaker 2: to visually represent observable behavior over.
Speaker 1: Time like aski art for streams.
Speaker 2: Kind of a dash means one meets a virtual time. Letters,
Speaker 2: az number zero nine represent emitted values, parentheses mean multiple
Speaker 2: values in the same timeframe. Pipe is completion, hash, hashtag
Speaker 2: is error.
Speaker 1: Okay, a visual language for asynchronous events.
Speaker 2: Exactly, you write tests saying given this input stream, Marble
Speaker 2: diagram I expect this output stream marble diagram. It makes
Speaker 2: testing complex timing logic surprisingly predictable and visual, Like testing
Speaker 2: that notification system with its automatic dismissal timer.
Speaker 1: That sounds incredibly useful for debugging timing issues. What about
Speaker 1: testing things like API calls?
Speaker 2: Mocking is key there. Angular has its HTTP testing controller,
Speaker 2: but the source also highlights mock service worker or MSW. Yeah,
Speaker 2: mock service worker. It's cool because it intercepts network requests
Speaker 2: at the service worker level in the browser.
Speaker 1: So it's like a proxy sort of.
Speaker 2: Yeah. It means your application code makes real fetch calls,
Speaker 2: but MSW catches them and returns your pre defined mock responses.
Speaker 2: It leads to simplified integration tests because your component code
Speaker 2: doesn't even know it being mocked. It looks like a
Speaker 2: real API call.
Speaker 1: Neat less test specific fit code and your components exactly.
Speaker 2: And finally, for state management, like with NGRX, the source
Speaker 2: emphasizes testing the core pieces, effects which handle side effects,
Speaker 2: and selectors which get data from the store as pure
Speaker 2: functions whenever possible. Pure functions are easy to test. Given
Speaker 2: input X, they always return output Y.
Speaker 1: Right, test the pure logic separately. Okay, that brings us
Speaker 1: nicely to state management itself. How does RXGS elevate that
Speaker 1: whole area? Can you build your own state management with it?
Speaker 2: Oh? Absolutely? RCJS provides the building blocks to make state
Speaker 2: management more scalable, predictable, performance, and maintainable. You can build
Speaker 2: your own simple reactive state manager. You typically use a
Speaker 2: behavior subject to hold the current state.
Speaker 1: Snapshot behavior subject because it always has a current value
Speaker 1: for new subscribers.
Speaker 2: Exactly, and maybe a regular subject to act as an
Speaker 2: action dispatcher. Components dispatch immutable actions to this subject. Then
Speaker 2: you'd have a stream that combines the actions with latest
Speaker 2: state using with latest from, processes them through a pure
Speaker 2: reducer function just like reducs, and emits the new state
Speaker 2: back into the behavior subject.
Speaker 1: So implementing the redux pattern with RXGS primitives pretty much.
Speaker 2: And for side effects like making an API call when
Speaker 2: an action happens, you can create an effect strain, often
Speaker 2: using operators like exhaustmap to prevent firing off duplicate requests
Speaker 2: if the user clicks frantically.
Speaker 1: Okay, so a custom solution is feasible. But what about
Speaker 1: established libraries like NGRX right.
Speaker 2: NGRX is a popular choice, especially in the angular, heavily
Speaker 2: inspired by reducs but built with rxgas at its core.
Speaker 2: The source details how it works. Provide store sets up
Speaker 2: the global state, create a reducer defines those pure state
Speaker 2: transition functions, and create effect is used for side effects,
Speaker 2: often combined with of type to listen for specific actions
Speaker 2: and operators like exhaustmap or merge map or switch map
Speaker 2: depending on the desired behavior for handling concurrent.
Speaker 1: Actions, different operators for different side effect strategies exactly.
Speaker 2: NGRX also has powerful selectors created with creed selects. They
Speaker 2: provide regular control over accessing state slices and crucially offer memorization.
Speaker 1: Memoization meaning casing.
Speaker 2: Yes, if the input state pieces haven't changed, the selector
Speaker 2: returns the previously computed result instantly, huge performance win for
Speaker 2: derived data. You can even integrate router events into your
Speaker 2: NGRX state using riter state and use meta reducers for
Speaker 2: things that cut across all state changes like logging or
Speaker 2: local storage persistence.
Speaker 1: That's a pretty comprehensive system, but the source mentions something
Speaker 1: really intriguing, building your own version of something like tanstack
Speaker 1: query but just with RxJS.
Speaker 2: Yeah, isn't that cool? It's a thought experiment. Showing how
Speaker 2: powerful RxJS is. The idea is to replicate core features
Speaker 2: of modern acing state libraries using only RxJS operators and concepts.
Speaker 1: So what would this RXGS query include?
Speaker 2: Well, first, declarative queries you define and retrieve data based
Speaker 2: on query keys, like an array of recipes or recipe.
Speaker 2: I'd then automatic caching. You'd likely use a JavaScript map
Speaker 2: to store the query keys and their corresponding observable streams
Speaker 2: the ones fetching the data. You'd implement stale time, how
Speaker 2: long data is considered fresh before needing a background check,
Speaker 2: and g time garbage collection time for automatically removing inactive
Speaker 2: queries from the cash after a while to prevent memory leaks,
Speaker 2: the cash cleans itself up.
Speaker 1: Okay, casing with life cycle management.
Speaker 2: What else The really neat part the stale wall revalidate.
Speaker 1: Mechanists stale while revalidate explain that it's a strategy to
Speaker 1: always show some data to the user, even if the
Speaker 1: data might be out of date.
Speaker 2: So when a component needs data, if it's in the cash,
Speaker 2: even it's slightly stale, it displays that cash data immediately,
Speaker 2: no loading spinner.
Speaker 1: Initially instant feedback right.
Speaker 2: Then in the background it sends the network request and
Speaker 2: refreshes the data afterward. If new data comes back, the
Speaker 2: UI updates. It drastically improves the perceived performance.
Speaker 1: Because the user sees something right away exactly.
Speaker 2: And finally, background updates. You could use RxJS as from
Speaker 2: event to listen for browser events like the window regaining
Speaker 2: focus or the network connection coming back online. When those
Speaker 2: events happen, you can automatically trigger background refetches for Corey's
Speaker 2: mark to stale, ensuring the data stays fresh without manual intervention.
Speaker 1: Wow. Building all that just with RXGS, that really shows
Speaker 1: its flexibility. This has been a genuinely comprehensive deep dive
Speaker 1: into rxgas. We've gone from air handling, UI design animations,
Speaker 1: real time stuff all the way to performance testing and
Speaker 1: advanced state management. It seems really clear that rchas you know,
Speaker 1: once you get past that initial curve and apply it strategically,
Speaker 1: it really can be a game changer for building modern applications.
Speaker 1: It just consistently seems to simplify these really complex asynchronous
Speaker 1: problems and genuinely improves the user experience. It turns that
Speaker 1: learning curve into a really powerful tool set. So thinking
Speaker 1: about all this power and flexibility. What's an existing non
Speaker 1: reactive problem, maybe in your own work or personal project,
Speaker 1: that you think could truly shine if you reimagined it
Speaker 1: through this reactive RXGS lens, something to chew on. Thank
Speaker 1: you for joining us for this deep Until next time,
Speaker 1: keep digging for those nuggets of knowledge.