Asynchronous Sources (Angular)
Tags: angular, rxjs, reactive, stateadapt
Published: 2022-07-12 08:13:02

---
title: Asynchronous Sources (Angular)
published: true
description: Easily guaranteeing consistency with asynchronous sources.
tags: angular, rxjs, reactive, stateadapt
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rlcywmsba1s2sd31epeg.png
# zoomed out: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/yg221acax49ptoldgc0n.png
series: Progressive Reactivity in Angular
---

> This series explores how we can keep our code declarative as we adapt our features to progressively higher levels of complexity.

## Level 5: Asynchronous Sources

What if our color state came from a server? Angular lets us be declarative with server data, so we could have `favoriteColors$` on a service and access it like this:

```typescript
  favoriteColors$ = this.colorService.favoriteColors$;
```

So what do we do with that now? 

If we subscribe to that observable, we need to write a callback function containing an imperative property assignment, which breaks [Rule 2](https://dev.to/this-is-angular/simple-derived-state-progressive-reactivity-in-angular-48oe). 

If that data needs to be part of the store at some point, then the observable should be part of the store's declaration. How about another parameter for `createStore`?

```typescript
export class ColorsComponent {
  // ...
  initialState = ['loading', 'loading', 'loading'];

  favoriteColors$ = this.colorService.fetch('favorite');
  favoriteStore = createStore(
    ['colors.favorite', this.initialState, this.adapter],
    this.favoriteColors$,
  );
  // ...
}
```

![Color Picker—Asynchronous Sources](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/k8bbwixuqfqaismjhywe.png)

[StackBlitz](https://stackblitz.com/edit/angular-ivy-cwnz5p?file=src%2Fapp%2F5-observable-sources.component.ts)

What if our state object was shaped like `{ loading: boolean; colors: string[] }` and we wanted our observable to dump its data into the `colors` property? If we define a `setColors` state change in our adapter, it would be nice to be able to link up that state change to our observable, like this:
```typescript
  favoriteStore = createStore(
    ['colors.favorite', this.initialState, this.adapter],
    { setColors: this.favoriteColors$ },
  );
```

Our observable is independent from the store, so theoretically  multiple stores could react to it. So it needs its own independent annotation for Devtools:

```typescript
  favoriteColors$ = this.colorService.fetch('favorite').pipe(
    toSource('[Favorite Colors] Received'),
  );
```

In Devtools that should show up as a single entry in the event log as `[Favorite Colors] Received`, and state changes from every affected store should be shown as a result of that single event.

Every time a state change happens, we want it to come from a source observable annotated like that. The one possible exception is DOM events, because they arise from user interactions, so they are very easy to keep track of as an exception. They already have to make an imperative call somewhere anyway, as we discussed before, so if it is only a single imperative call, it really does encapsulate the entire meaning of the event.

However, there is a time when DOM events should be annotated independently as well. That's the next article. 

Oh, and if you're wondering when our HTTP source observable gets subscribed to, clearly we want any subscription to the store's state to be passed along to the store's own data sources. A consumer should only have to ask for the data it wants once, _by subscribing_. That's literally the meaning of the word _subscribe_. It wants the data, it should get it. That's the beauty of RxJS, how it was designed. To dispatch an action or call something extra when it we are already asking for `store.state$` would be an unnecessary, imperative step, with implicit knowledge about where `store.state$` gets its data from. For all we know, our store's state could come from a long series of HTTP requests, but RxJS lets us declare that concern in the appropriate places only once. This should be extremely desirable to any developer who loves simplicity. And once again, StateAdapt isn't the only way to achieve this. This article I wrote in 2017 explains how to wrap data dependencies in NgRx with RxJS's `using` function: [Stop Using NgRx/Effects for That](https://medium.com/@m3po22/stop-using-ngrx-effects-for-that-a6ccfe186399). I also used the same technique in this article: [Why and How to Manage State for Angular Reactive Forms](https://dev.to/this-is-angular/why-and-how-to-manage-state-for-angular-reactive-forms-25fn). I've done the same thing in NGXS projects too.