Observables and the async pipe in Angular

In my previous post about Angular subscription management we concluded that the best solution is to use the async pipe. In this post we’ll see a common problem many people ran into with the async pipe.

An observable intro

Before we dive into the details it’s important to make some observations about observables. Observables are functions that tie together a source (e.g. an HTTP request, an event stream) and an observer (your run-of-the-mill Angular component).

The most important aspect of an observable is its temperature. It can either be cold or hot. A cold observable creates its own source, while a hot observable wraps around one.

Cold observables are creating their sources

Consider the following code:

Notice how the observable is creating and dispatching the XMLHTTPRequest. Every subscriber will get a different request, resulting in multiple calls. We’ll review hot observables and then see how to avoid these issues.

Hot observables are wrapping around an existing source

Hot observables are great in the sense that they can share their results with multiple subscribers (they are multicast). However since they are not owning their source they cannot be lazy. Let’s review the same code fragment with a hot observable:

The hot observable is stored in the subject variable. Note that it wraps around our XMLHTTPRequest, which is completely independent from it. The request will always be sent with or without any subscribers.

Note that this is just for presentational purposes. There are better ways to connect subjects with observables. Also, you’d rarely send raw XMLHTTPRequests in Angular, you’d use the built-in HttpClient instead.

Smart usage of the async pipe

After some theoretical background, let’s see how this affects us and our components.

Look at the below component and template code:

callResult$ is a cold observable and we’re in big trouble. The *ngFor directive will trigger one execution, then the expression with the length below will trigger another.

We can fix this with a hot observable like this:

But this is more code, and we don’t like to write and maintain more code. Let’s try a different approach. A better solution would be this:

Using the async pipe with the async as syntax we can define a template variable. It’s called result in our case. The template then can reuse this variable without triggering the observable multiple times. We made our template code agnostic on the temperature of our observable, yayy!

Source code

I’m maintaining and developing a repo on GitHub. It contains Angular7 best practicesFollow this link to the relevant part of the code.

Execute an asynchronous query

Some ADO.NET classes supports built-in asynchronous query behavior. Some aren’t. In this post, we’ll revise the former classes, like SqlDataReader. However, if you are familiar with multithread computing (particularly, in the .NET Framework) you can easily implement asynchronous execution in classes which don’t support it, such as the TableAdapter.

Before you’d do anything, you should introduce a new name-value pair into your connection string: Async=true or Asynchronous Processing=true. Including it, you enable asynchronous queries to be executed on the database server. This was the easy part.

Writing your asynchronous data access class is a little bit more complicated. If you are familiar with delegates and the classes of System.Threading, then you are ready to go. But if you’d like to rely on built-in logic, consider using the DbCommand’s BeginExecuteReader and EndExecuteReader. First the code, then the explanation:

Continue reading “Execute an asynchronous query”

Plan for Long-running processes by using Asynchronous Pages

There may be several situations when your web pages need to handle long-running processes, for example, query information from a slow database, work with the file system, etc. In this case, you’d need to use asynchronous pages.

First you need to understand that asynchronous pages aren’t actually faster, than their synchronous counterparts. Using them won’t affect the speed of your site, just the scalability of it. The second thing to know is that you shouldn’t use the traditional multithreading ways when you are working with ASP.NET. ASP.NET serves incoming requests from its on thread pool; one thread is responsible for the whole lifetime of the request. When you use the Threading namespace, you are getting a thread from the very same thread pool ASP.NET itself uses. So you shouldn’t do it. Instead you should use asynchronous pages, which in fact gets their working threads from another thread pool, thus freeing up the ones in ASP.NET’s, which it can use to serve more requests.

Continue reading “Plan for Long-running processes by using Asynchronous Pages”