Javascript

Going Reactive with RxJS

Published Dec 28, 2020

Updated Feb 14, 2023

4 min read

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

RxJS is the perfect tool for implementing reactive programming paradigms to your software development. In general, software development handling errors gracefully is a fundamental piece of ensuring the integrity of the application as well as ensuring the best possible user experience.

In this article, we will look at how we handle errors with RxJS and then look at how we can use RxJS to build a simple yet performant application.

Handling Errors

Our general approach to errors usually consists of us exclaiming "Oh no! What went wrong?" but it's something that is a common occurrence in all applications. The ability to manage errors well without disrupting the user's experience, while also providing accurate error logs to allow a full diagnosis of the cause of the error, is more important than ever.

RxJS gives us the tools to do this job very well! Let's take a look at some basic error handling approaches with RxJS.

Basic Error Handling

The most basic way of detecting and reacting to an error that has occurred in an Observable stream provided to us by the .subscribe() method.

obs$.subscribe(
    value => console.log("Received Value: ", value),
    error => console.error("Received Error: ", error)
)

Here we can set up two different pieces of logic—one to handle non-error emission from the Observable and one to gracefully handle errors emitted by the Observable.

We could use this to show a Notification Toast or Alert to inform the user that an error has occurred:

obs$.subscribe(
    value => console.log("Received Value: ", value),
    error => showErrorAlert(error)
)

This can help us minimize disruption for the user, giving them instant feedback that something actually hasn't worked as appropriate rather than leaving them to guess.

Composing Useful Errors

Sometimes, however, we may have situations wherein we want to throw an error ourselves. For example, some data we received isn't quite correct, or maybe some validation checks failed.

RxJS provides us with an operator that allows us to do just that. Let's take an example where we are receiving values from an API, but we encounter missing data that will cause other aspects of the app not to function correctly.

obs$
  .pipe(
    mergeMap((value) =>
      !value.id ? throwError("Data does not have an ID") : of(value)
    )
  )
  .subscribe(
    (value) => console.log(value),
    (error) => console.error("error", error)
  );

If we receive a value from the Observable that doesn't contain an ID, we throw an error that we can handle gracefully.

NOTE: Using the throwError will stop any further Observable emissions from being received.

Advanced Error Handling

We've learned that we can handle errors reactively to prevent too much disruption for the user.

But what if we want to do multiple things when we receive an error or even do a retry?

RxJS makes it super simple for us to retry errored Observables with their retry() operator.

Therefore, to create an even cleaner error handling setup in RxJS, we can set up an error management solution that will receive any errors from the Observable, retry them in the hopes of a successful emission, and, failing that, handle the error gracefully.

obs$
  .pipe(
    mergeMap((value) =>
      !value.id ? throwError("Data does not have an ID") : of(value)
    ),
    retry(2),
    catchError((error) => {
        // Handle error gracefully here
      console.error("Error: ", error);
      return EMPTY;
    })
  )
  .subscribe(
    (value) => console.log(value),
    () => console.log("completed")
  );

Once we reach an error, emitting the EMPTY observable will complete the Observable. The output of an error emission above is:

Error:  Data does not have an ID
completed

Usage in Frontend Development

RxJS can be used anywhere running JavaScript; however, I'd suggest that it's most predominately used in Angular codebases. Using RxJS correctly with Angular can massively increase the performance of your application, and also help you to maintain the Container-Presentational Component Pattern.

Let's see a super simple Todo app in Angular to see how we can use RxJS effectively.

Basic Todo App

We will have two components in this app: the AppComponent and the ToDoComponent. Let's take a look at the ToDoComponent first:

import {
  ChangeDetectionStrategy,
  Component,
  EventEmitter,
  Input,
  Output
} from "@angular/core";

export interface Todo {
  id: number;
  title: string;
}

@Component({
  selector: "todo",
  template: `
    <li>
      {{ item.title }} - <button (click)="delete.emit(item.id)">Delete</button>
    </li>
  `,
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class ToDoComponent {
  @Input() item: Todo;
  @Output() delete = new EventEmitter<number>();
}

Pretty simple, right? It takes an item input and outputs an event when the delete button is clicked. It performs no real logic itself other than rendering the correct HTML.

One thing to note is changeDetection: ChangeDetectionStrategy.OnPush. This tells the Angular Change Detection System that it should only attempt to re-render this component when the Input has changed.

Doing this can increase performance massively in Angular applications and should always be applicable to pure presentational components, as they should only be rendering data.

Now, let's take a look at the AppComponent.

import { Component } from "@angular/core";
import { BehaviorSubject } from "rxjs";
import { Todo } from "./todo.component";

@Component({
  selector: "my-app",
  template: `
    <div>
      <h1>
        ToDo List
      </h1>
      <div style="width: 50%;">
        <ul>
          <todo
            *ngFor="let item of (items$ | async); trackBy: trackById"
            [item]="item"
            (delete)="deleteItem($event)"
          >
          </todo>
        </ul>
        <input #todoTitle placeholder="Add item" /><br />
        <button (click)="addItem(todoTitle.value, todoTitle)">Add</button>
      </div>
    </div>
  `,
  styleUrls: ["./app.component.css"]
})
export class AppComponent {
  private items: Todo[] = [{ id: 1, title: "Learn RxJS" }];
  items$ = new BehaviorSubject<Todo[]>(this.items);

  addItem(title: string, inputEl: HTMLInputElement) {
    const item = {
      id: this.items[this.items.length - 1].id + 1,
      title,
      completed: false
    };
    this.items = [...this.items, item];
    this.items$.next(this.items);

    inputEl.value = "";
  }

  deleteItem(idToRemove: number) {
    this.items = this.items.filter(({ id }) => id !== idToRemove);
    this.items$.next(this.items);
  }

  trackById(index: number, item: Todo) {
    return item.id;
  }
}

This is a container component, and it's called this because it handles the logic relating to updating component state as well as handles or dispatches side effects.

Let's take a look at some areas of interest:

private items: Todo[] = [{ id: 1, title: "Learn RxJS" }];
items$ = new BehaviorSubject<Todo[]>(this.items);

We create a basic local store to store our ToDo items; however, this could be done via a state management system or an API.
We then set up our Observable, which will stream the value of our ToDo list to anyone who subscribes to it.

You may now look over the code and begin to wonder where we have subscribed to items$.

Angular provides a very convenient Pipe that handles this for us. We can see this in the template:

*ngFor="let item of (items$ | async); trackBy: trackById"

In particular, it's the (items$ | async) this will take the latest value emitted from the Observable and provide it to the template. It does much more than this though. It also will manage the subscription for us, meaning when we destroy this container component, it will unsubscribe automatically for us, preventing unexpected outcomes.

Using a pure pipe in Angular also has another performance benefit. It will only ever re-run the code in the Pipe if the input to the pipe changes. In our case, that would mean that item$ would need to change to a whole new Observable for the code in the async pipe to be executed again. We never have to change item$ as our values are then streamed through the Observable.

Conclusion

Hopefully, you have learned both about how to handle errors effectively as well put RxJS into practice into a real-world app that improves the overall performance of your application. You should also start to see the power that using RxJS effectively can bring!

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

About the author(s)

Colum Ferry
JavaScript Developer and Enthusiast. Really enjoy working with Angular. Married with 2 amazing kids. Powered by Coffee.
@FerryColum @https://github.com/coly010

Introduction to Zod for Data Validation

As web developers, we're often working with data from external sources like APIs we don't control or user inputs submitted to our backends. We can't always rely on this data to take the form we expect, and we can encounter unexpected errors when it deviates from expectations. But with the Zod library, we can define what our data ought to look like and parse the incoming data against those defined schemas. This lets us work with that data confidently, or to quickly throw an error when it isn't correct. Why use Zod? TypeScript is great for letting us define the shape of our data in our code. It helps us write more correct code the first time around by warning us if we are doing something we shouldn't. But TypeScript can't do everything for us. For example, we can define a variable as a string or a number, but we can't say "a string that starts with user_id_ and is 20 characters long" or "an integer between 1 and 5". There are limits to how much TypeScript can narrow down our data for us. Also, TypeScript is a tool for us developers. When we compile our code, our types are not available to the vanilla JavaScript. JavaScript can't validate that the data we actually use in our code matches what we thought we'd get when we wrote our TypeScript types unless you're willing to manually write code to perform those checks. This is where we can reach for a tool like Zod. With Zod, we can write data schemas. These schemas, in the simplest scenarios, look very much like TypeScript types. But we can do more with Zod than we can with TypeScript alone. Zod schemas let us create additional rules for data parsing and validation. A 20-character string that starts with user_id_? It's z.string().startsWith('user_id_').length(20). An integer between 1 and 5 inclusive? It's z.number().int().gte(1).lte(5). Zod's primitives give us many extra functions to be more specific about *exactly* what data we expect. Unlike TypeScript, Zod schemas aren't removed on compilation to JavaScript—we still have access to them! If our app receives some data, we can verify that it matches the expected shape by passing it to your Zod schema's parse function. You'll either get back your data in exactly the shape you defined in your schema, or Zod will give you an error to tell you what was wrong. Zod schemas aren't a replacement for TypeScript; rather, they are an excellent complement. Once we've defined our Zod schema, it's simple to derive a TypeScript type from it and to use that type as we normally would. But when we really need to be sure our data conforms to the schema, we can always parse the data with our schema for that extra confidence. Defining Data Schemas Zod schemas are the variables that define our expectations for the shape of our data, validate those expectations, and transform the data if necessary to match our desired shape. It's easy to start with simple schemas, and to add complexity as required. Zod provides different functions that represent data structures and related validation options, which can be combined to create larger schemas. In many cases, you'll probably be building a schema for a data object with properties of some primitive type. For example, here's a schema that would validate a JavaScript object representing an order for a pizza: ` Zod provides a number of primitives for defining schemas that line up with JavaScript primitives: string, number, bigint, boolean, date, symbol, undefined, and null. It also includes primitives void, any, unknown, and never for additional typing information. In addition to basic primitives, Zod can define object, array, and other native data structure schemas, as well as schemas for data structures not natively part of JavaScript like tuple and enum. The documentation contains considerable detail on the available data structures and how to use them. Parsing and Validating Data with Schemas With Zod schemas, you're not only telling your program what data should look like; you're also creating the tools to easily verify that the incoming data matches the schema definitions. This is where Zod really shines, as it greatly simplifies the process of validating data like user inputs or third party API responses. Let's say you're writing a website form to register new users. At a minimum, you'll need to make sure the new user's email address is a valid email address. For a password, we'll ask for something at least 8 characters long and including one letter, one number, and one special character. (Yes, this is not really the best way to write strong passwords; but for the sake of showing off how Zod works, we're going with it.) We'll also ask the user to confirm their password by typing it twice. First, let's create a Zod schema to model these inputs: ` So far, this schema is pretty basic. It's only making sure that whatever the user types as an email is an email, and it's checking that the password is at least 8 characters long. But it is *not* checking if password and confirmPassword match, nor checking for the complexity requirements. Let's enhance our schema to fix that! ` By adding refine with a custom validation function, we have been able to verify that the passwords match. If they don't, parsing will give us an error to let us know that the data was invalid. We can also chain refine functions to add checks for our password complexity rules: ` Here we've chained multiple refine functions. You could alternatively use superRefine, which gives you even more fine grained control. Now that we've built out our schema and added refinements for extra validation, we can parse some user inputs. Let's see two test cases: one that's bound to fail, and one that will succeed. ` There are two main ways we can use our schema to validate our data: parse and safeParse. The main difference is that parse will throw an error if validation fails, while safeParse will return an object with a success property of either true or false, and either a data property with your parsed data or an error property with the details of a ZodError explaining why the parsing failed. In the case of our example data, userInput2 will parse just fine and return the data for you to use. But userInput1 will create a ZodError listing all of the ways it has failed validation. ` ` We can use these error messages to communicate to the user how they need to fix their form inputs if validation fails. Each error in the list describes the validation failure and gives us a human readable message to go with it. You'll notice that the validation errors for checking for a valid email and for checking password length have a lot of details, but we've got three items at the end of the error list that don't really tell us anything useful: just a custom error of Invalid input. The first is from our refine checking if the passwords match, and the second two are from our refine functions checking for password complexity (numbers and special characters). Let's modify our refine functions so that these errors are useful! We'll add our own error parameters to customize the message we get back and the path to the data that failed validation. ` Now, our error messages from failures in refine are informative! You can figure out which form fields aren't validating from the path, and then display the messages next to form fields to let the user know how to remedy the error. ` By giving our refine checks a custom path and message, we can make better use of the returned errors. In this case, we can highlight specific problem form fields for the user and give them the message about what is wrong. Integrating with TypeScript Integrating Zod with TypeScript is very easy. Using z.infer<typeof YourSchema> will allow you to avoid writing extra TypeScript types that merely reflect the intent of your Zod schemas. You can create a type from any Zod schema like so: ` Using a TypeScript type derived from a Zod schema does *not* give you any extra level of data validation at the type level beyond what TypeScript is capable of. If you create a type from z.string.min(3).max(20), the TypeScript type will still just be string. And when compiled to JavaScript, even that will be gone! That's why you still need to use parse/safeParse on incoming data to validate it before proceeding as if it really does match your requirements. A common pattern with inferring types from Zod schemas is to use the same name for both. Because the schema is a variable, there's no name conflict if the type uses the same name. However, I find that this can lead to confusing situations when trying to import one or the other—my personal preference is to name the Zod schema with Schema at the end to make it clear which is which. Conclusion Zod is an excellent tool for easily and confidently asserting that the data you're working with is exactly the sort of data you were expecting. It gives us the ability to assert at runtime that we've got what we wanted, and allows us to then craft strategies to handle what happens if that data is wrong. Combined with the ability to infer TypeScript types from Zod schemas, it lets us write and run more reliable code with greater confidence....

Nov 15, 2024

7 mins

JavaScriptZod

The Journey To Making A New Framework: TanStack Start with Tanner Linsley

Danny Thompson, Director of Technology at This Dot Labs, talks with Tanner Linsley, Creator of TanStack, about his latest project, TanStack Start. They discuss the challenges of existing frameworks like Next.js and Remix, the development of TanStack Router, and the future of React Server Components. Tanner also explains how caching strategies and fine-grained invalidation can transform the user experience. Chapters - - Introduction & Tanner’s Background (00:00) - Going Full-Time on TanStack (01:00) - The Birth of TanStack Router (02:21) - Why Build Another Framework? (04:00) - React Server Components: Potential & Limitations (07:05) - Fine-Grained Cache Invalidation & UX (09:02) - Parallel Data Fetching in Routing (13:39) - TanStack Start: Alpha & Future Plans (16:41) - Where to Learn More About TanStack (18:48) Find Tanner Linsley on Social Media Twitter: https://x.com/tannerlinsley Linkedin: https://www.linkedin.com/in/tannerlinsley/ Github: https://github.com/tannerlinsley TanStack: https://tanstack.com/ Sponsored by Wix Studio...

Oct 9, 2024

1 min

TanStack QueryJavaScriptReact

NgRx Facade Pattern

NgRx Facade Pattern The NgRx Facade Pattern was first introduced by Thomas Burleson in 2018 and has drawn a lot of attention in recent years. In this article, we will discuss the pattern, how to implement it in Angular and discuss whether or not we _should_ implement it. What is NgRx? First, what is NgRx? NgRx is a state management solution for Angular built on top of RxJS which adheres to the redux pattern. It contains an immutable centralized store where the state of our application gets stored. - We select slices of state from the Store using Selectors, which we can then render in our components. - We dispatch Actions to our Store. - Our Store redirects our Action to our Reducers to recalculate our state and replaces the state within our Store. See the diagram below for an illustrated example: This provides us with a tried and tested pattern for managing the state of our application. What is the Facade Pattern? Now that we know what NgRx is, what is the Facade Pattern? Well, what _are_ Facades? Facades are a pattern that provides a simple public interface to mask more complex usage. As we use NgRx more and more in our application, we add more actions and more selectors that our components must use and track. This increases the coupling between our component and the actions and selectors themselves. The Facade pattern wants to simplify this approach by wrapping the NgRx interactions in one place, allowing the Component to only ever interact with the Facade. This means you are free to refactor the NgRx artefacts without worrying about breaking your Components. In Angular, NgRx Facades are simply services. They inject the NgRx Store allowing you to contain your interactions with the Store in the service. How do we implement it? To begin with, let's show a Component that uses NgRx directly: ` As we can see, this depends a lot on interactions with the Store and has made our component fairly complex and coupled to NgRx. Let's create a Facade that will encapsulate this interaction with NgRx: ` It's essentially everything we had in the component, except now in a service. We then inject this service into our Component: ` By implementing the Facade and using it in our Component, our component no longer depends on NgRx and we do not have to import all actions and selectors. The Facade hides those implementation details, keeping our Component cleaner and easier tested. Pros What are some advantages of using Facades? - It adds a single abstraction of a section of the Store. - This service can be used by any component that needs to interact with this section of the store. For example, if another component needs to access the TodoListState from our example above, they do not have to reimplement the action dispatch or state selector code. It's all readily available in the Facade. - Facades are scalable - As Facades are just services, we can compose them within other Facades allowing us to maintain the encapsulation and hide complex logic that interacts directly with NgRx, leaving us with an API that our developers can consume. Cons - Facades lead to reusing Actions. - Mike Ryan gave a talk at ng-conf 2018 on Good Action Hygiene which promotes creating as many actions as possible that dictate how your user is using your app and allowing NgRx to update the state of the application from your user's interactions. - Facades force actions to be reused. This becomes a problem as we no longer update state based on the user's interactions. Instead, we create a coupling between our actions and various component areas within our application. - Therefore, by changing one action and one accompanying reducer, we could be impacting a significant portion of our application. - We lose indirection - Indirection is when a portion of our app is responsible for certain logic, and the other pieces of our app (the view layer etc.) communicate with it via messages. - In NgRx, this means that our Effects or Reducers do not know what told them to work; they just know they have to. - With Facades, we hide this indirection as only the service knows about how the state is being updated. - Knowledge Cost - It becomes more difficult for junior developers to understand how to interact, update and work with NgRx if their only interactions with the state management solution are through Facades. - It also becomes more difficult for them to write new Actions, Reducers and Selectors as they may not have been exposed to them before. Conclusion Hopefully, this gives you an introduction to NgRx Facades and the pros and cons of using them. This should help you evaluate whether to use them or not....

Feb 9, 2021

4 mins

AngularNgRxJavaScriptTypeScript

Build Facial Recognition and Chatbot AIs using TypeScript with Jack Herrington

In this JS Drop, Danny Thompson is joined by YouTuber Jack Herrington to explore a unique TypeScript and AI project that lets you recognize TV show characters in real time. Just point your camera at a character, and instantly get their details or even chat with them as if they were real! Jack walks through the tech, explaining how client-side face recognition and server-side AI work together to make this possible using the Versal AI library. They discuss prompt engineering, building efficient APIs, and ensuring smooth, interactive AI responses. Jack also shares potential real-world applications, from entertainment to security. Chapters - 0:32 Project Overview – Jack explains the AI-powered character recognition project - 2:17 Setting Up the Project – Overview of how the application is structured and initial setup - 3:04 Client-Side AI – How face detection and character recognition work on the client side - 5:12 Switching to Server Side – Jack demonstrates server-side AI and setting up API endpoints - 8:20 Explaining AI Tooling – How tools and prompts are used to give context to the AI - 10:01 Detailed Prompt Structure – Breaking down the prompt and character context for AI responses - 12:40 Client-Server Interaction – Using the Versal AI library to manage streaming responses - 15:09 Handling Character Data – Training the AI on specific character images and details - 18:15 Practical Use Cases – Discussing potential real-world applications for the face recognition tool - 21:34 Challenges and Lessons Learned – Jack shares obstacles he faced and how he overcame them - 25:45 Building the API – Tips and considerations for creating reliable API endpoints - 28:40 Handling User Inputs – Testing unexpected questions and how the AI responds - 32:00 Using Advanced AI Models – Jack talks about choosing GPT-4 and issues with smaller models - 35:47 Introducing ProNextJS.dev – Jack discusses his new Next.js course, covering advanced topics - 37:20 Closing Thoughts – Danny and Jack wrap up with final thoughts and a link to the GitHub repo Follow Jack Herrington on Social Media Twitter: https://x.com/jherr Linkedin: https://www.linkedin.com/in/jherr/ YouTube: https://www.youtube.com/@jherr Sponsored by This Dot: thisdot.co...

Nov 11, 2024

2 mins

AIArtificial Intelligence

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

Going Reactive with RxJS

Handling Errors

Basic Error Handling

Composing Useful Errors

Advanced Error Handling

Usage in Frontend Development

Basic Todo App

Conclusion

Colum Ferry

You might also like

Introduction to Zod for Data Validation

The Journey To Making A New Framework: TanStack Start with Tanner Linsley

NgRx Facade Pattern

Build Facial Recognition and Chatbot AIs using TypeScript with Jack Herrington

Let's innovate together!

You might also like

Introduction to Zod for Data Validation

The Journey To Making A New Framework: TanStack Start with Tanner Linsley

NgRx Facade Pattern

Build Facial Recognition and Chatbot AIs using TypeScript with Jack Herrington