DEV Community: Rebekah van Wyk

Reactive Programming and Observables with RxJS

Rebekah van Wyk — Mon, 08 Sep 2025 22:03:03 +0000

According to the RxJS docs, RxJS, or Reactive Extensions for JavaScript, is a library "for reactive programming using Observables, to make it easier to compose asynchronous or callback-based code”. In this article, we’ll break down the core concepts behind reactive programming and how RxJS makes it easier to work with asynchronous data.

Reactive Programming

To understand what reactive programming is, we should first understand data streams. A data stream is a flow of potentially infinite data, where the data can arrive at various points in time.

Visually, it might look something like this:

where the dotted line represents time, and our nodes A, B, and C represent data points arriving at different points in time.

Reactive programming is a paradigm that focuses on data streams and change propagation, meaning that when new data arrives, any part of our system that relies on this data automatically reacts and changes accordingly.

RxJS helps us to achieve this through Observables.

What are Observables?

Put simply, Observables are data producers that represent a data stream. They emit notifications that we can consume.

There are three types of notifications that can be emitted from an Observable:

Next notifications deliver a value emitted by the Observable
Error notifications indicate that something has gone wrong during the Observable's execution
Complete notifications indicate that the Observable has successfully finished its execution

All of these notifications are useless to us, however, if we don't have the relevant Observers and Subscriptions in place to effectively consume these notifications.

Observers and Subscriptions

Observers define how each type of notification from an Observable is handled.

A subscription is what actually connects an Observable to an observer. Without a subscription, the Observable would remain idle, and its logic would never run.

The subscribe() method of RxJS creates a subscription, and the unsubscribe() method ends a subscription. Something to note is that once a notification of type error or complete is emitted from an Observable, the subscription is automatically ended, and nothing further will be emitted by the Observable.

Overall, the relationship between Observables, Observers, and Subscriptions, looks something like this:

Why is it important to unsubscribe?

In Angular, components can live for a long time. If you forget to unsubscribe from long-running streams, you risk memory leaks, performance issues, and in the worst case scenario, your app could even crash.

Let's have a look at a very simple code example of an Observable in action.

execute() {
  // create an Observable
  const observable$ = new Observable<string>((subscriber) => {
    subscriber.next('First emission');
    setTimeout(() => subscriber.next('Second emission'), 2000);
    setTimeout(() => subscriber.complete(), 3000); // indicates that we're done and unsubscribes
    setTimeout(() => subscriber.next('Final emission'), 4000);
  });

  // define an Observer
  const observer = {
    next: (value: string) => console.log('Received: ', value),
    error: (err: any) => console.error('Error: ', err),
    complete: () => console.log('Done'),
  };

  // subscribe to start receiving values
  // pass our Observer to our subscribe function
  observable$.subscribe(observer);
}

In this example, the Observer has indeed defined how notifications from the Observable will be handled; relevant messages will be logged to the console. We'd see the following logged to the console when this execute() method is run:

the string "Received: First emission" synchronously
the string "Received: Second emission" after 2 seconds
the string "Done" after 3 seconds

Then, despite there being another next notification defined, we'd see nothing further in the console due to the complete notification ending the subscription to our Observable. In a more practical example, the number or timing of emissions from our Observable may be unknown, and we'd need to unsubscribe more explicitly. You can learn more about ways to do that in Angular here.

While this example is a valid way to work with Observables, in practice we tend to make use of functions in RxJS called operators to work with Observables more cleanly and easily.

RxJS Operators

As we've just mentioned, RxJS operators are simply functions defined by RxJS which make it easier to work with Observables. There are various types of operators, as listed here on the RxJS docs. We would typically make use of these operators to do things like transform, filter, and combine streams of data easily. Let's look at two important categories of RxJS operators: creation operators and pipeable operators.

Creation operators

Creation operators create new Observables with pre-defined behaviour, or by joining other Observables. They can be called as standalone functions.

Some popular creation operators are of(), combineLatest(), and merge(). We'll just have a brief look at the of() operator.

of()

The of() operator returns an Observable that simply emits the provided arguments synchronously and then completes.

Code snippet:

of(1, 2, 3).subscribe(value => console.log(value))

Logs:
1
2
3

Pipeable operators

Pipeable operators start with an Observable as input, transform or update the emissions of that Observable in some way, and then return the result as a new Observable. These operators are used with RxJS's pipe() method.

Let's have a look at a couple of the most commonly used pipeable operators, namely map() and filter().

map()

The map() operator applies a function to each value emitted from the Observable.

Code snippet:

of(1, 2, 3).pipe(
  map(num => num * 10)
).subscribe(value => console.log(value));

Logs:
10
20
30

filter()

The filter() operator only passes values that match a specified predicate.

Code snippet:

of(1, 2, 3, 4, 5).pipe(
  filter(num => num % 2 === 0)
).subscribe(value => console.log(value));

Logs:
2
4

The beauty of the pipe() function is that it allows us to chain operators together to perform powerful operations. For example, we could combine the map and filter operators in the following way:

of(1, 2, 3, 4, 5).pipe(
  map(num => num * 10),     
  filter(num => num > 20)
).subscribe(value => console.log(value));

Logs:
30
40
50

Note: Marble diagrams are a great visual tool to help us understand how each RxJS operator works. RxMarbles is a website with very useful interactive marble diagrams that can be used to help deepen your understanding of various RxJS Operators. I suggest having a look to further your understanding of the above examples.

Real-world applications of Observables

Observables are most valuable in cases where code is asynchronous or event-driven in nature. Examples of such scenarios include:

Handling HTTP requests
Managing UI events such as clicks, scrolls, and key presses
Working with State Management libraries such as NgRx

Observables provide a clean way to handle data as it arrives, making it much easier to manage these kinds of scenarios.

Conclusion

This introduction to RxJS Observables highlighted how they provide a powerful way to handle asynchronous and event-driven data. We discussed how combining Observables with operators enables you to transform, filter, and combine data streams with ease, making reactive programming more intuitive and achievable. I hope this post provided some clarity around what Observables are, how they work, and why they are useful to us. Thanks for reading!

The basic components of a unit test in Angular

Rebekah van Wyk — Fri, 17 Jan 2025 11:49:48 +0000

When I hear the phrase “unit test”, my thoughts typically gravitate toward backend systems. Unit testing is common and expected in backend systems but seems to be overlooked when discussing frontend development. However, frontend unit testing is not only beneficial for many reasons, but it’s also simpler than it might at first appear. In this introduction to unit testing in Angular, we’ll discuss why unit testing is worth it and then walk through the common components typically found in an Angular test file.

What is a unit test?

Unit tests aim to test small components of an application in isolation and typically compare actual behaviour with expected behaviour in order to verify that code works correctly.

Benefits of unit testing in Angular

Unit testing can:

Aid in identifying bugs during development rather than in production
Save time and money through the aforementioned early bug detection
Help to maintain or improve code quality by encouraging developers to write more readable, maintainable, and reusable code
Give developers confidence that new code additions are not breaking existing code

Overall, unit testing is beneficial for any application. So, what does unit testing look like in Angular? Let's discuss that, starting with the files where the magic happens: spec files.

Specification (spec) files

If you use the Angular CLI to generate a new component, you will notice that four files are automatically generated: an html file, a css file, a typescript file, and lastly, a spec file. The spec file is where you’ll write the unit tests for the associated component. These tests are run using Jasmine, a JavaScript testing framework.

As I mentioned before, unit testing for frontend is often overlooked. Applications don’t need the spec file to function, and so spec files are often deleted to avoid clutter. Let’s understand the contents of these files so that we can use them to improve our applications instead!

The spec file generated alongside each Angular component looks something like this at first (borrowed from this website: https://esketchers.com/angular-unit-testing-using-jasmine-and-karma/#:~:text=What%20is%20Karma%3F,devices%20like%20phones%2C%20and%20tablets ) :

import { TestBed } from '@angular/core/testing';
import { RouterTestingModule } from '@angular/router/testing';
import { AppComponent } from './app.component';

describe('AppComponent', () => {
 beforeEach(async () => {
   await TestBed.configureTestingModule({
     imports: [
       RouterTestingModule
     ],
     declarations: [
       AppComponent
     ],
   }).compileComponents();
 });

 it('should create the app', () => {
   const fixture = TestBed.createComponent(AppComponent);
   const app = fixture.componentInstance;
   expect(app).toBeTruthy();
 });

 it(`should have as title 'AngularUnitTesting'`, () => {
   const fixture = TestBed.createComponent(AppComponent);
   const app = fixture.componentInstance;
   expect(app.title).toEqual('AngularUnitTesting');
 });

});

When I first saw one of these files, I was quickly intimidated by the various blocks using keywords and function names I’d never seen before, such as ‘describe’, and ‘it’ - but things make a lot of sense when we break them down!

But first, a bit more about the Jasmine framework

If you’re looking into unit testing, there’s a good chance you’ve come across the term Test-Driven Development, or TDD. TDD involves writing tests for expected software functionality before developing said functionality and then making sure that when the functionality is implemented, the written tests (which should have been failing when first written) now pass.

Jasmine is described as a Behaviour-Driven Development (BDD) framework. BDD is an extension of TDD, so, as with TDD, when following BDD methodology tests are often written before the functionality they’re intended to test. However, BDD differs from TDD in that BDD focuses on the behaviour of the application that the user expects.

For example, say we have a method called add which adds two numbers together. A TDD-style test might ask, does add(2, 3) return 5? Whereas a BDD-style test would focus on the fact that when two numbers are added, the user should see their sum displayed. So, when writing Angular unit tests with Jasmine, we can expect to see some BDD-style traits.

Now, onto that spec file breakdown!

The basic functions and tools found in a spec file

Have a look at this code snippet from the Jasmine documentation:

describe("A suite is just a function", function() {
    let a;

    it("and so is a spec", function() {
        a = true;

        expect(a).toBe(true);
    });
});

Now let's walk through what we can see.

it is a global Jasmine function. It is used to define what are called specs (our tests). This function takes in a string and a function, where the string names the spec and the function is the spec itself.

describe

describe is used to group related specs. This group of related specs is referred to as a suite. Like the it function, describe is a function that takes in a string: here this string names the collection of specs.

When the string from the it function parameters is concatenated onto the end of the string from the describe parameters, you should be able to read it as you would an ordinary sentence. In this case, we’d read “A suite is just a function and so is a spec”. This sort of natural language definition of a test aligns with the principles of BDD, emphasizing clarity and readability.

Expectations and Matchers

As we mentioned earlier in this post, a unit test typically compares actual and expected values. In a Jasmine unit test, this comparison is achieved with the use of the expect function and what are called matcher functions.

The expect function takes in the “actual” value, and the matcher will take in the “expected” value. The matcher will use the actual and expected values to assert either true or false, and Jasmine will use this information to determine whether the spec should pass or fail.

A wide range of matchers exist to verify different things. For example, in the snippet above, the matcher “toBe” simply expects the actual value to be equal to the expected value. But say we want to compare numerical values with some leeway; we could use the "toBeCloseTo" matcher, which expects the actual value to be within a parameter-defined precision range of the expected value. Jasmine also caters for cases when a developer might like to write custom matchers for their own unique purposes.

Setup and Teardown

The last aspect of an Angular unit test that we'll be discussing are the functions made available for setup and teardown. The purpose of these functions is to prepare and clean up the environment for test execution. They help to ensure that specs are isolated, reproducible, and free from interference caused by the state left over from other specs. Jasmine provides a few functions to help developers with setup and teardown, namely:

beforeEach: called before every spec in the describe block in which it is used
afterEach: called after every spec in the describe block in which it is used
beforeAll: called once before any of the specs in the describe block are run
afterAll: called once after all of the specs in the describe block have run

Here's a code snippet to demonstrate some of beforeEach and afterEach in action (courtesy of the Jasmine documentation found at https://jasmine.github.io/archives/2.4/introduction )

describe("A spec using beforeEach and afterEach", function() {
var foo = 0;

beforeEach(function() {
  foo += 1;
});

afterEach(function() {
  foo = 0;
});

it("is just a function, so it can contain any code", function() {
  expect(foo).toEqual(1);
});

it("can have more than one expectation", function() {
  expect(foo).toEqual(1);
  expect(true).toEqual(true);
});
});

And, from the same source, beforeAll and afterAll in action:

describe("A spec using beforeAll and afterAll", function() {
var foo;

beforeAll(function() {
  foo = 1;
});

afterAll(function() {
  foo = 0;
});

it("sets the initial value of foo before specs run", function() {
  expect(foo).toEqual(1);
  foo += 1;
});

it("does not reset foo between specs", function() {
  expect(foo).toEqual(2);
});
});

Something important to note about beforeAll and afterAll is that although they may be useful to reduce the cost of setup and teardown, since they are only called once and are not reset between specs, using these functions can easily cause false positives and negatives in your specs due to state leakage from other specs.

Conclusion

This beginner's guide provided an explanation of what unit testing is and why it's just as important in frontend development as it is in backend development. We then walked through what a unit test looks like in Angular and discussed some of the common functions provided by the Jasmine framework. I hope this post has cleared up some of the confusion you might feel when encountering a spec file for the first time and inspired you to embrace thorough testing in your application!