Introduction

When people ask about createAsync with observables, the real question is usually how to expose asynchronous work as an observable stream. In reactive code, the important design choice is not the helper name itself, but whether you want a one-shot async result, a deferred async operation per subscription, or a stream that can emit multiple values over time.

Start from the Async Source

If the async work already returns a promise, the simplest observable wrapper is usually to convert that promise into an observable. In RxJS, from and defer are the common tools.

1import { defer, from } from 'rxjs';
2
3function loadUser(id: string) {
4  return defer(() => from(fetch(`/api/users/${id}`).then(r => r.json())));
5}
6
7loadUser('42').subscribe({
8  next: user => console.log(user),
9  error: err => console.error(err),
10  complete: () => console.log('done')
11});

defer matters because it creates the promise when the subscription happens, not earlier.

Use new Observable for Custom Async Behavior

If you need more control than promise conversion gives you, create the observable explicitly:

1import { Observable } from 'rxjs';
2
3function createAsyncValue() {
4  return new Observable<number>(subscriber => {
5    const timer = setTimeout(() => {
6      subscriber.next(123);
7      subscriber.complete();
8    }, 1000);
9
10    return () => clearTimeout(timer);
11  });
12}

This is the pattern to use when you need cancellation logic, multiple emissions, or precise control over when completion occurs.

Know the Difference Between One Value and a Stream

A common source of confusion is trying to model every async operation the same way. There are three very different cases:

• one eventual value, such as an HTTP response
• one value per subscription, created lazily
• many values over time, such as UI events or websocket messages

The observable abstraction can represent all three, but the implementation should match the real behavior of the source.

Prefer Existing Creation Operators When They Fit

In RxJS, you often do not need a special createAsync helper if an existing operator already describes the job clearly. from, defer, timer, and interval often express the intent better than a custom wrapper.

The less custom boilerplate you write, the easier the stream is to understand later.

One Subscription Usually Means One Async Execution

With deferred observable creation, each new subscription can trigger a fresh async operation. That behavior is often correct, but it should be explicit so callers do not accidentally assume the work is shared.

Cancellation Is Part of the Design

One reason observables are useful for async work is that they can express teardown. If a subscriber unsubscribes before the async operation finishes, the observable can stop timers, detach listeners, or cancel work where possible.

That is a practical difference from simply waiting for a promise to resolve and ignoring the result later.

Common Pitfalls

• Creating the promise too early instead of lazily at subscription time.
• Using a custom observable when from or defer would already express the intent clearly.
• Forgetting to call complete() for one-shot async work.
• Ignoring teardown logic and making unsubscription ineffective.
• Treating every async source as if it should emit many values when the real source only produces one.

Summary

• Wrapping async work in an observable is mainly about choosing the right creation pattern.
• Use from or defer for promise-based async sources.
• Use new Observable when you need custom emission or teardown behavior.
• Match the observable design to whether the source is one-shot or streaming.
• Think about cancellation and lazy execution as first-class parts of the API.