A sweet spot between signals and observables 🍬

Published in

ITNEXT

8 min readAug 18, 2023

In collaboration with Chau Tran.

The migration wave to signals is real, state management libraries have started to add support to support both observables and signals.

This is my shot together with Chau to combine observables and signals into one.

Little history

Angular has had observables since the beginning and the devs are used to it and have used it in almost every part of their apps.

Angular’s reactivity was tied to rxjs (except zone.js automagic change detection)!

Then, SIGNALS 🚦 came! They changed everything! The way we see the templates, change detection and reactivity in Angular in general!

Who would have thought Angular recommends calling functions in the template?!

@Component({
  template: `<div>Count: {{ count() }}</div>`
})
export class MyCmp {
  count = signal(0);
}

(I did LOL! More here: It’s ok to use function calls in Angular templates!)

Signals are great! But we are used to rxjs patterns in Angular, our services are tied to rxjs subjects, observables, operators and everything else!

Example scenario

I have a GalleryComponent that retrieves some data from the API and it depends on an id (retrieved from route params) and global form filters.

@Component({
    template: `
        <div *ngIf="data$ | async as data">
            {{ data | json }}
        </div>
    `
})
export class GalleryComponent {
    private route = inject(ActivatedRoute);
    private galleryService = inject(GalleryService);
    private filterService = inject(GlobalFilterService);
    
    galleryId$ = this.route.paramMap.pipe(map(p => p.get('id')!));
    
    data$ = combineLatest([
        this.filterService.filters$,
        this.galleryId$
    ]).pipe(
        switchMap(([filters, id]) => 
            this.galleryService.getGalleryItems(id, filters)
        )
    );
    
    favoritesCount$ = this.data$.pipe(map(data => getFavoritesCount(data)));
}

I want to use signals in the template for better performance, and because they are the future?! BUT, I don’t want to get rid of rxjs, I see them as complementary to each other!

Angular helper functions way

First thing I do is use toSignal to wrap my data$ observable.

data = toSignal(this.data$, { initialValue: [] });

Now I can use my data directly in the template as a signal without needing async pipe! Great!

Because favoritesCount$ depends only on data$ I can convert that one into a signal too. Computed is the perfect fit for this!

- favoritesCount$ = this.data$.pipe(map(data => getFavoritesCount(data)));
+ favoritesCount = computed(() => getFavoritesCount(this.data()));

Perfect!

I go and update my `GlobalFilterService` from `BehaviorSubjects` or `RxAngular` / `ComponentStore` to use signals!

And, now I cannot use my filters (that is now a signal) anymore in the combineLatest! Let’s convert it back to observable in order to use it inside combineLatest again!

Let’s use toObservable from Angular.

@Component()
export class GalleryComponent {
    ...
    private filterService = inject(GlobalFilterService);
    
+   filters$ = toObservable(this.filterService.filters);

    data$ = combineLatest([
-       this.filterService.filters$,
+       this.filters$,
        this.galleryId$
    ]).pipe(...);
}

Great until now! The thing is, I need to add an input to the component! This input will be used in the api call! So, I create it using a setter and a BehaviorSubject.

showStars$ = new BehaviorSubject(false);

@Input({ required: true }) set showStars(x: boolean) {
    this.showStars$.next(x);
}

We can easily use that one in the combineLatest because it’s just an observable! But I also need to use that in the template, so I use the toSignal again to convert it!

showStars = toSignal(this.showStars$);

Great again! The thing is Angular RFC showed us that a new kind of input may be coming;

So we may want to prepare when they come, to easy refactor to them, so what we may think is, let’s make the setter set the value to a signal rather than a BehaviorSubject and from there convert it to an observable.

And we get something like:

showStars = signal(false);
showStars$ = toObservable(this.showStars);

@Input({ required: true }) set showStars(x: boolean) {
    this.showStars.set(x);
}

The result of everything would look like this:

@Component()
export class GalleryComponent {
    private route = inject(ActivatedRoute);
    private galleryService = inject(GalleryService);
    private filterService = inject(GlobalFilterService);
        
    galleryId$ = this.route.paramMap.pipe(map(p => p.get('id')!));
    filters$ = toObservable(this.filterService.filters);

    showStars = signal(false);
    showStars$ = toObservable(this.showStars);
    @Input({ required: true }) set showStars(x: boolean) {
        this.showStars.set(x);
    }

    data$ = combineLatest([
        this.filters$,
        this.galleryId$,
        this.showStars$
    ]).pipe(
        switchMap(([filters, id, showStars]) => 
            this.galleryService.getGalleryItems(id, filters, showStars)
        )
    );
    
    data = toSignal(this.data$, { initialValue: [] });
    
    favoritesCount = computed(() => getFavoritesCount(this.data()));
}

All this back and forth and decision dilemma because we just need to put the value in the combineLatest and be ready for tomorrow’s Angular 🧪.

What if we had a better alternative, something that also takes signals into consideration?

Chau’s initial shot

Chau is one of the first devs who I talked to about the new Signals, and he was really hyped about it! He had been thinking about these patterns a lot! And showed me a solution he had created for combining signals with observables.

The usage (different example from the initial one) looks like this:

githubUsers = computed$(
    this.query,
    pipe(
      debounceTime(500),
      switchMap((query) => api.getUsers(query)),
      startWith([])
    )
);

// or with explicit initial value

readonly githubUsers = computed$(
    this.query,
    [], // initial value
    pipe(
      debounceTime(500),
      switchMap((query) => api.getUsers(query))
    )
);

computed$ is a primitive where the first argument can be a signal, an observable or a promise, and the second arg can be either an initialValue or a pipe operator where we can pass all our rxjs operators. The operators would fire everytime the signal or observable changed!

The whole implementation here:

What does computed$ solve? Let’s re-assess what we have and what we want to achieve:

We want our githubUsers to be a Signal so we can use it on the template without AsyncPipe
We have a query which is a Signal that reacts to a search input. The query value is used to call Github API for users
We want to debounce the rate of which we call the Github API

Please don’t go and create a `debounceSignal()`. Use RxJS for asynchronous operations.

@angular/core/rxjs-interop provides two other primitives: toSignal() and toObservable() to solve this for us:

githubUsers = toSignal(
    toObservable(this.query).pipe(
        debounceTime(500),
        switchMap((query) => api.getUsers(query))
    ),
    { initialValue: [] }
);

This approach works fine but the back-and-forth between toSignal and toObservable can be messy quickly. This is where computed$ comes in. But it only works with a single source.

My shot

Because I had more than one source that were of different types (both signals and observables), I took Chau’s computed$ and converted the initial argument to be an array of sources (that could be either signals or observables). As a first time fixing Typescript types, I think it went really well! Find the implementation here.

If I take the inital example I had before, and apply the updated computed$ (now called computedFrom) approach, it would look like this:

@Component()
export class GalleryComponent {
    private route = inject(ActivatedRoute);
    private galleryService = inject(GalleryService);
    private filterService = inject(GlobalFilterService);
        
    galleryId$ = this.route.paramMap.pipe(map(p => p.get('id')!));

    showStars = signal(false);

    @Input({ required: true }) set showStars(x: boolean) {
        this.showStars.set(x);
    }
    
    data = computedFrom(
        [this.filterService.filters, this.showStars, this.galleryId$],
        [], // initial value
        pipe(
            switchMap(([filters, showStars, id]) =>
                this.galleryService.getGalleryItems(id, filters, showStars)
            )
        )
    );

        
    favoritesCount = computed(() => getFavoritesCount(this.data()));
}

As we can see, there’s no need to convert things back and forth to combine signals and observable together 🎉!

As I said before, this is fully typed. And there’s one catch, if we don’t pass an intial value our signal would be of type Signal<T | undefined> and if we pass an initial value it would be of type Signal<T>.

I think this is important (passing an initial value) in cases when we have to use this signal in the template or in other computations, because we first have to check if our signal has a value or not.

Example with favoritesCount:

favoritesCount = computed(() => {
    const data = this.data();
    if (data === undefined) return 0;
    return getFavoritesCount(data);
});

Chau’s bazooka 🔫

I go back to Chau with my solution, he initially likes it! And goes to improve it! Comes back saying that a flaw of my solution is the initialValue.

So, if I don’t provide an operator, the intial value of computedFrom will be of type any. But we don’t want that, because we have values, and at least we should get back the values of our sources inside an array.

Let’s take an example to better understand it:

const first = signal(1); // Signal with default value
const second$ = of(1); // Observable that emits first value synchronously
const third$ = timer(5000); // Observable that emits first value asynchronously

const combined = computedFrom(
    [first, second$, third$],
);

My implementation would return Signal<any> and it’s value would be undefined! Bad right? Yes, of course.

We at least want to get something like this:

const combined = computedFrom(
    [first, second$, third$],
);

// typeof combined - Signal<[number, number, number]>

While this other example would return Signal<number> and the value would be 0.

const combined = computedFrom(
    [first, second$, third$],
    0, // initial value
);

But, Chau thinks that explicit initialValue is redundant because:

Signals already have initial values
Observables can emit values synchronously

He believes only observables which emit values asynchronously should have their initial values explicitly defined. In the above example, only the third$ source needs an initial value.

const combined = computedFrom(
    [first, second$, third$.pipe(startWith(0))],
    pipe(map(([f, s, t]) => f + s + t))
);

// if we have only one operator we can write it directly like: 
const combined = computedFrom(
    [first, second$, third$.pipe(startWith(0))],
    map(([f, s, t]) => f + s + t)
);

Last but not least, Chau’s version of computedFrom() does also accept a Dictionary just like combineLatest() does. Which is a big plus in some scenarios I’d say.

const combined = computedFrom(
    {
        first: first, 
        second: second$, 
        third: third$.pipe(startWith(0))
    },
    map(({first, second, third}) => first + second + third)
);

Find Chau’s computedFrom implementation here:

To sum up

I also like Chau’s solution now! And have been using it in some places and it’s great!

You can use the computedFrom function by installing ngxtension 🪄.

Find an example here: https://stackblitz.com/edit/stackblitz-starters-ecylu8

Go give it a try and let us know in the comments or tweet about it! 🙌

For other discussions regarding signals, observables and libs also take a look at RxAngular github repo.

Thanks for reading!

I tweet and blog a lot about Angular (latest news, signals, videos, podcasts, updates, RFCs, pull requests and so much more). 💎

If you want to learn more about Modern Angular features like standalone, signals, functional guards, interceptors, ssr, hydration, new inject method, Directive Composition API, NgOptimizedImage, feel free to take a look at our Modern Angular Workshop from Push-Based.io 💎

If this article was interesting and useful to you, and you want to learn more about Angular, give me and Chau a follow at @Enea_Jahollari & @Nartc1410 or Medium. 📖

I’d appreciate it if you would support me by buying me a coffee ☕️. Thank you in advance 🙌