 Courses from Andre Staltz

RxJS is a library for composing asynchronous and event-based programs by using observable sequences. 


rxjs

While there are many cases where we often believe that an RxJS Subject is necessary, there is a way of avoiding them. In this lesson we will see how to identify the underlying source of data and convert it into an Observable, essentially eliminating the use of an error-prone Subject. 

Convert an underlying source of data into an Observable

While flatMap is popular and convenient for flattening higher-order Observables, it can introduce new kinds of bugs related to subscriptions. In this lesson we will see how switchMap is a sensible default that avoids common bugs.

Use switchMap to avoid leaks when flattening

The do() operator allows us to perform side effects in the chain of operators. However, there are limited use cases for do(). We will learn what those use cases are and how to use subscribe() most of the times.

Move important side effects from do() to subscribe()

The Observable in RxJS is a JavaScript class, and can be extended. In this lesson we will learn about those cases where extending the Observable class becomes a problem, and what cases where it makes sense to extend it.

Know when to extend the Observable class

Eventually you will feel the need for pausing the observation of an Observable and resuming it later. In this lesson we will learn about use cases where pausing is possible, and what to do when pausing is impossible. 

Implement pause and resume feature correctly through RxJS

This lesson will highlight the true purpose of the zip operator, and how uncommon its use cases are. In its place, we will learn how to use the combineLatest operator.

Replace zip with combineLatest when combining sources of data

Operators like publish(), refCount(), share() make it easy to convert a cold Observable to a hot one, and are often necessary to get some feature done. In this lesson we will learn when exactly do we need to convert to hot, and when can we leave the Observable cold.

Make Observables hot only where necessary

The use of RxJS Subjects is common, but not without problems. In this lesson we will see how they can be usually safely replaced with plain Observables.

Convert RxJS Subjects to Observables

In this lesson we will learn about potential problems that may arise when using Observable.create, a low-level function for creating Observables. In its place, we will use easier helper functions that create Observables in a safe manner.

Replace Observable.create with Observable creation helpers

Manually unsubscribing from subscriptions is safe, but tedious and error-prone. This lesson will teach us about the takeUntil operator and its utility to make unsubscribing automatic. 

Use takeUntil instead of manually unsubscribing from Observables

In this lesson we will learn how to replace excessive subscribing and Subject emissions with simple uses of the map operator, simplifying our code and making it less bug-prone. 

Use the map operator instead of firing events on a Subject

We are going to see how to avoid virtually any case of a subscribe happening inside another subscribe by replacing it with a flattening operator such as flatMap or mergeAll.

Use flattening operators instead of nested subscriptions

***Note: RxJS imports have changed since the publication of this course. Operators now must be passed into `.pipe` to be applied to an observable.***

In this course we will learn to identify common mistakes with RxJS that usually make code harder to read and even introduce bugs. Most of these mistakes are related to Subject, subscribe, and subscriptions. We are going to see how to use only Observables and convenient operators made for solving those mistakes, such as fromEvent, takeUntil and switchMap. By the end of this course, you will have a more immediate intuition on what patterns are simple and safe in RxJS.

Save time avoiding common mistakes using RxJS

This lesson will show when to apply groupBy in the real world. This RxJS operator is best suited when a source observable represents many data sources, e.g. an observable for multitouch events. 

Use groupBy in Real RxJS Applications

Mapping the values of an observable to many inner observables is not the only way to create a higher order observable. RxJS also has operators that take a first order observable and return a higher order Observable. 

In this lesson we will learn about window, an operator to split an observable.

Split an RxJS Observable with Window

RxJS operators mergeMap and switchMap are useful for handling asynchronous responses from the server, but they can do much more. 

In this lesson, we will see how to use mergeMap to achieve the same functionality as map() or filter() or other custom behaviors. 

Use RxJS mergeMap for Fine-grain Custom Behavior

There are variants of the window operator that allow you to split RxJS observables in different ways. In this lesson we will explore the windowToggle variant and see one of its use cases in user interfaces. 

Split an RxJS Observable Conditionally with windowToggle

In this lesson we look at the common strategies for creating and flattening higher order observables in RxJS. In particular, we give switchMap a careful review. It is an operator that works as an "asyncMap" and is capable of solving many of our asynchronous problems in JavaScript.

Use switchMap as a Safe Default to Flatten Observables in RxJS

groupBy() is another RxJS operator to create higher order observables. In this lesson we will learn how groupBy works for routing source values into different groups according to a calculated key.

Split an RxJS Observable into Groups with groupBy

In this lesson, we will learn about switchMap, a shortcut for mapping to a higher order RxJS Observable, then flattening with switch. 

We will also see a practical example with network requests that would be used in the real world.

Use RxJS switchMap to Map and Flatten Higher Order Observables

An Observable may emit values of any JavaScript type: numbers, strings, booleans, objects, etc. This means an RxJS Observable may also happen to emit values which are themselves observables too. 

In this lesson we will learn more about this use case and begin learning about the so-called "higher order observables".

Get Started with Higher Order Observables in RxJS

Mock Service Worker is an API mocking library that allows you to write client-agnostic mocks and reuse them across any frameworks, tools, and environments.



Mocking WebSocket APIs with Mock Service Worker


When attempting to load the same module twice in JavaScript you'll hit a cache and code won't re-run. In scenarios where you actually do want to have state in your modules, you'll have to use a cache-busting technique by passing a query parameter to a dynamic import. This lesson walks through how to add a query parameter, how to add the appropriate types for loading dynamic modules in TypeScript, and when these techniques are valuable.

Import the Same JavaScript Module Multiple Times with Cache Busting



The include keyword in GitHub Actions empowers you to add custom variables to your matrix strategy, providing flexibility beyond standard configurations. In this video, we'll explore how include allows you to define specific combinations of variables, enhancing control over your workflow runs. You'll see how this feature enables you to tailor jobs for unique environments or scenarios not covered by the default matrix options. By leveraging include, you can efficiently manage complex build processes with greater precision. This technique helps you streamline your CI/CD pipeline, making it more adaptable to your project's evolving needs.

Use GitHub Actions Matrix Include for Complex Job Configurations

While running `zod` schema validation agains domain-rich objects, the error message saying that _a string is not a number_ might not be really useful.

Especially, when you need to provide a meaningful feeback to the user, e.g. after they have submitted a form with lots of data.

`zod` allows to customize messages on a very granular level. We can also extract repeatable customization to `zod` error maps.

Finally, in order to process an error message further (e.g. display it to the user), we need to handle the `zod` validation errors effectively. Especially, when a big object validation has failed and we could receive a handful of errors.

That's what we learn in this lesson. 🔥

Customize zod Error Messages and Handle zod Errors Effectively

customize zod validation messages, customize zod schema property messages, reuse error maps across different schemas, navigate through zod error objects

You might want to run `zod` schema checks in different styles.

Sometimes you prefer to conditionally throw the error - that's what `parse` does. But another time you'd prefer to receive a `boolean` property that determines whether the validation was successful or not - and perform further actions accordingly.

Additionally, the error-throwing API of `parse` works extremely well with [TypeScript assertion functions](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html#assertion-functions). Their combination is just... perfect! 👌

That's what we learn in this lesson.

Use parse and safeParse Runtime Type-checks with zod

use zod parse function to conditionally throw ZodError, use zod safeParse to get a boolean value and run typescript type guard over success property

In this lesson we learn that TypeScript cannot guarantee correct shapes of responses. That's due to TS performing checks in compile-time, while the response will be availbale in runtime - when TS doesn't exist anymore.

In some situations, such as HTTP requests, runtime type checks such as `zod` are essential for providing quick feedback around data-related errors.

Understand where are the possible mistakes to make while using TypeScript with HTTP calls. Use `fetch` and `axios` along with `zod` schema checks.

Also, note that similar mistakes or mistakes could happen while using web storage (e.g. `localStorage`)

Validate HTTP API Response with zod, fetch and axios

use zod as an HTTP response validation tool along with fetch and axios in order to make sure that the response has expected data structure

In this lesson we learn that the `zod` schemas become the single source of truth.

We shall not update TypeScript types manually, since they are generated automatically from the schema.

Same with validation functions.

Whenever the schema changes, all the rest will update accordingly. It's an important mind shift.

Treat zod Schemas as Single Source of Truth

Zod Schemas are the single source of truth for both typescript types, and interfaces - and runtime validation functions. Schemas should be updated first.

`zod` is powerful, but writing the schemas manually for existing JSON objects, especially big ones, can be time-consuming.

But that's what `quicktype` is for! You can get 80% work done instantly! 🥳

Depending on your need - whether you want to automate the process, or do it just one time, you can:
- use an online app
- use an IDE extension
- run a CLI script
- generate a script to be executed within CI/CD environment/tooling

And this is what we learn in this lesson! 🔥🔥🔥

Get started with zod quickly!

Generate zod Schemas Automatically using Quicktype App, Extensions and Scripts

Use quicktype app, extension or scripts to automatically generate zod schemas from existing json files. Save time and get started with zod quickly!

`zod` is a powerful library allowing to run runtime type-checks.

It's complementary to TypeScript, which does type checks in compile time.

In this lesson we create few schemas that represent primitive type values, along with `zod` utilities which make these more precise. We also create object schemas and nest one inside another.

All schemas are being validated against example values. We analyze how to interpret error messages in case of failures.

Perform Runtime Type-checks on Primitives and Objects with zod

Create zod schemas to validate primitive type and object type values in runtime. Analyze the errors to see how a value doesn't correspond to schema expectations


Using Cursor Chat, you can easily reference an entire directory of files and ask it to generate anything based on those files. This opens up the possibility of using your current code as a reference guide to create new code that follows existing patterns. With this approach, the result can be a polished prompt you can use with any AI to generate consistent and reliable output.

Focus less on crafting the perfect prompt upfront - what matters most is testing and iterating based on the AI's responses. The more results you see from the prompt, the more you can reinforce the good results and prune out the bad results until your prompt is polished enough that you can rely on the prompt to give you consistent quality results.


André Staltz

Search Results