DEV Community: Ivan Novikov

Cancelable async tasks and typed server errors with SolidJS and LazyPromise

Ivan Novikov — Thu, 04 Dec 2025 02:20:45 +0000

Cancelable async tasks

Let's begin with the question of why do we at all need to cancel async tasks. One argument is that if you've made a server request, it's already out there, and there isn't much point in aborting it. Let's take a look at a real-life example.

Suppose you have a regular OTP code authentication flow. The user starts on a page like this:

Then they enter an email, hit "Email Sign In Code", and end up on this page:

The normal flow then is the user enters the code, we send a request with that code to the server, the server responds with a Set-Cookie header, the user is now authenticated and we redirect them client-side to the app's dashboard. But what happens if while the request with the code is still in flight, the user realizes they actually want to sign in under a different email, and hit the "Go Back" button?

Well, we have here an example of when we definitely should actually abort the request at the browser level, else the user will receive the wrong cookie.

A little while ago I wrote a primitive called LazyPromise which has an api that's only superficially different from that of a native Promise, but which is cancelable. A LazyPromise has a method .subscribe(handleValue, handleError) that returns a disposal handle. Since I've recently had to port an app from React to Solid, I wrote the glue between LazyPromise and Solid, in particular a function useLazyPromise that passes the disposal handle to Solid's onCleanup, so you can write

useLazyPromise(myLazyPromise);

and be guaranteed that the async task will be canceled as soon as the Solid scope is disposed.

A good question to ask at this point is why would you do something as adventurous as a DIY promise, when you could just write a Solid-specific wrapper around the native AbortSignal that you would use like this:

useAbortablePromise(async (abortSignal) => {
  // fetch things
});

Well, the thing is that LazyPromise can be seen as simply such wrapper. There is a utility lazy that turns an async function into a LazyPromise, and you can write

useLazyPromise(lazy(async (abortSignal) => {
  // fetch things
}));

If you are using functions like async (abortSignal) => ..., you are already essentially dealing in lazy promises, and if you use actual LazyPromise objects, you get composability and a couple of benefits that I'll cover in the rest of this article.

Typed errors

In my experience, it's been extremely useful to have the type system reflect errors that a server endpoint throws, because they all throw slightly different sets of errors and it's necessary to make sure that the right errors are handled on the client side. On the server I use the regular async-await, but if there is an error (user not authenticated, not authorized, 404 etc.), I return an object {__error: ...} so the result type is Data | {__error: Error} (if you prefer you could instead return {data: Data} | {error: Error}). The client talks to the server via TRPC, and there is a wrapper that turns a TRPC response into a LazyPromise<Data, Error> (gist), so you could write something like

useLazyPromise(
  pipe(
    trpcLazyPromise(api.authn.checkOtpCode.mutate)(<params>),
    catchRejection((error) => {
      // `error` is typed.
    }),
  ),
);

You could in theory keep the return type of the server endpoint as Data | {__error: Error} and this way capture the error type without resorting to a non-native promise, but it would break things like Promise.all, make the code harder to read, and in the case when you're not doing anything with the return value (like the authentication example), TypeScript isn't going to notice if you forget to handle the errors.

There's a popular library called Effect which I haven't used, but I think typed errors is its major selling point. Here you get typed errors, but with a primitive-based approach where instead of having a whole new API to learn, you get LazyPromise API which in spirit maps one-to-one to the native Promise.

Bonus: no microtaks

We've covered above two ways a LazyPromise differs from a native Promise (laziness/cancelability and typed errors), but there is a third and final one: LazyPromise fires synchronously instead of in a microtask. That works really well with SolidJS. We've looked above at the utility useLazyPromise that just subscribes to a LazyPromise and which you'd typically use with mutations, but there's also one called createFetcher which lets you use LazyPromise with createResource:

const [accessor] = createResource(
  createFetcher(() => yourLazyPromise)
);

The fun thing is what happens when the lazy promise resolves synchronously. This:

const [accessor] = createResource(
  count,
  // `resolved` is LazyPromise equivalent of Promise.resolve.
  createFetcher((count: number) => resolved(count)),
);

behaves in the same way diamond-problem-wise as this:

const [accessor] = createResource(
  count,
  (count: number) => count,
);

as opposed to this:

const [accessor] = createResource(
  count,
  (count: number) => Promise.resolve(count),
);

Conclusion

LazyPromise is a very well unit-tested (including for memory leaks) and stable enough library available here. The SolidJS bindings are still experimental as of this writing and available here.

I've used the pipe() function 2,560 times and I can tell you it's good!

Ivan Novikov — Wed, 03 Mar 2021 20:11:42 +0000

The pipe() function that I'm talking about is the one that lets you replace b(a(x)) with pipe(x, a, b). Yes, that's how many times I've used it over the last few years, and looking back at those usages, I'd like to tell you the reasons you might find it useful too, even when you work with a codebase that doesn't stray from mainstream patterns into functional programming.

Where it's coming from

pipe takes the first argument and pipes it though each of the functions that you provide as the remaining arguments, and can be implemented as follows:

const pipe = (x, ...fns) => 
  fns.reduce((acc, el) => el(acc), x);

You can type it in TypeScript using overloads, and since as far back as TypeScript 3.4, type inference works perfectly:

One way to look at this function is to see it as a fill-in for the proposed pipeline operator (x |> a |> b). That proposal has been at stage 1 for years, but the good news is that pipe is not far worse — curiously, it's even better than some of the discussed flavors of the operator in one sense, namely that you don't have to enclose arrow functions in parens. If one of the flavors of the pipeline operator does reach stage 3, you won't be left out in the cold: with AST tools and Prettier, it would be easy to build a codemod that replaces pipe with the operator.

Putting aside the pipeline operator, pipe can be just seen as the first choice among different ways to do function composition. Another notable contender is a function that composes functions without applying them,

const ltrCompose = (...fns) => (x) => 
  fns.reduce((acc, el) => fn(acc), x);

so b(a(x)) is equivalent to ltrCompose(a, b)(x). It's a higher-order function though, and that's where pipe beats it: pipe is easier to read because it lets you achieve the same ends without thinking in terms of transforming functions to other functions. At first I tried using both utilities depending on the context, but I found this to be a bad violation of "only one way to do it".

It's like dot-chaining

Now to reasons for using pipe. The first thing to notice is that rather than introducing a new pattern, pipe lets you use essentially the same pattern as dot-chaining,

yourArray.filter(predicate).map(project);
yourString.trim().toLowerCase();

only without being constrained to the collection of methods defined for native objects.

One group of use-cases center around the fact that native JavaScript APIs were not designed with an eye to immutable updates that we often use today. sort method of Array and add method of Set are mutating, but with pipe, we can define their non-mutating counterparts

const sort = (compare) => (array) =>
  [...array].sort(compare);

const add = (value) => (set) => 
  new Set(set).add(value);

and use them like we use dot-chained methods:

const newArray = pipe(array, sort(compare));
const newSet = pipe(set, add(value));

Another common use-case is iterables. To take one example, if you need to filter values of a Map, you would have to write [...yourMap.values()].filter(predicate), in other words, you have to convert the iterable returned by yourMap.values to an array just to get at the filter method. It wouldn't matter that much if it was just a question of performance, but it's both inefficient and clutters up the code. pipe gives you an alternative of working with iterables in the same way that you work with arrays:

const filter = (predicate) =>
  function* (iterable) {
    for (const el of iterable) {
      if (predicate(el)) {
        yield el;
      }
    }
  };

const filteredValuesIterable = pipe(
  yourMap.values(), 
  filter(predicate)
);

It lets you create locals with expressions

Here's another reason for using pipe — and this time we're not even going to need any utility functions other than pipe itself.

Imagine that in an if clause, you need to convert a string to a number and check if that number is greater than 0.

if (parseFloat(str) > 0) { 
  // ...
}

Now suppose that we also need to check that the number is less than 1. Unless we want to duplicate parseFloat calls, we have to define a new constant in the outer scope:

const num = parseFloat(str);
if (num > 0 && num < 1) { 
  // ...
}

Wouldn't it be better if num was scoped to the expression in the if clause, which is the only place where we need it? This can be accomplished with an IIFE, but it's not pretty:

if ((() => {
  const num = parseFloat(str);
  return num > 0 && num < 1;
})()) { 
  // ...
}

pipe solves the problem:

if (pipe(str, parseFloat, (num) => num > 0 && num < 1)) { 
  // ...
}

Generally speaking, in any context where an expression is expected, whether it's a function argument, an element in an array/object literal, or an operand of a ternary operator, pipe lets you create a local without resorting to IIFE. This tends to make you rely more on expressions,

const reducer = (state, action) =>
  action.type === `incrementA`
    ? pipe(state, ({ a, ...rest }) => ({ ...rest, a: a + 1 }))
    : action.type === `incrementB`
    ? pipe(state, ({ b, ...rest }) => ({ ...rest, b: b + 1 }))
    : state;

but you don't have to use expressions all the time — pipe just lets you make the choice between expressions and statements not based on syntax limitations, but based on what's more readable in a specific situation.

The pipe function as defined here is available in fp-ts. If like me you don't need a full-blown functional programming library, you can get pipe in my own library Antiutils:

ivan7237d / pipe-function

A function to pipe a value through a number of transforms

`pipe` function

A function to pipe a value through a number of transforms.

Installation

npm install pipe-function

yarn add pipe-function

pnpm add pipe-function

Usage

import { pipe } from "pipe-function";

Takes between 1 and 20 arguments. pipe(x, a, b) is equivalent to b(a(x)), in other words, this function pipes a value through a number of functions in the order that they appear. This article talks about why this function is useful.

View on GitHub

Log and test RxJS observables with 1log

Ivan Novikov — Mon, 01 Feb 2021 15:49:27 +0000

ATTENTION: this article is now outdated, please see GitHub readme for the current version of the API.

Logging

As soon as I started building an app that uses RxJS, I realized that I needed a logging utility. First I went with a common approach of creating a custom operator like

const log = <T>(label: string): MonoTypeOperatorFunction<T> =>
  tap(
    (value) => console.log(label, value),
    (error) => console.error(label, error),
    () => console.log(label, 'complete'),
  );

At some point though, I ran into debugging scenarios where I needed more information than nexts, errors, and completions — at a minimum,

A way to tell when an observable is created, subscribed and unsubbed.
When some observable is subscribed multiple times, a way to tell which subscription a next/error/complete/unsub originates from.

So I came up with 1log. Let's jump straight to a basic code snippet and take a look at the log messages that it produces:

import { log } from '1log';
import { timer } from 'rxjs';

timer(500).pipe(log).subscribe();

For the most part, the messages are self-explanatory, but there are a few things to note while we're at it.

Time deltas are muted if they are less than 10ms and bold if they are 1s or more. They are computed using performance.now (so the first delta is counted from the time the user started navigation that opened the page) and exclude the time spent on logging itself.

The indentation (as in the last line in the above screenshot) indicates synchronous stack level. One situation where this is handy is reentrancy-related bugs.

Colors and other styling is supported in all recent desktop browsers (where it's implemented using %c directive) and in Node/terminal (where it's implemented using ANSI escape codes).

Tip: In Chrome, you can right-click an observable or a subscriber from a "create" or "subscribe" log message and say "Store as global variable". The object will be stored with a name like temp1. It's sometimes useful to have access to this object in the console, for example to call next on a subscriber.

Library core

Now let's take a closer look at the library's API.

The logic specific to RxJS observables is in package 1log-rxjs, while the library core is in package 1log.

The core exports a function log which can be used like just like the regular console.log, but has two superpowers:

When passed a single argument, it returns that argument or a proxy that mimics it. This means that log can be inserted into any expression without changing the behavior of your program, e.g. f(log(x)).
It supports plugins. There are two ways to install a plugin: you can install a plugin locally by passing it as an argument to log, in which case log will return a function just like itself, but with the plugin installed — or you can install a plugin globally by calling installPlugin(yourPlugin) before any log calls.

The package 1log-rxjs exports a plugin called observablePlugin. It's installed globally with the default config, and affects how the log function behaves when you give it an RxJS observable, as in log(yourObservable) or equivalently yourObservable.pipe(log). Instead of passing yourObsevable through as is, log will return a proxy that's like the original, but logs everything that's happening to it.

Tip: Instances of classes like Subject that inherit from Observable will not be proxied — to log a subject, first convert it to an observable using method asObservable.

The core library has a bunch of features that you can read about in its GitHub readme: it provides plugins similar to observablePlugin, but for functions, promises and iterables; it also supports severity levels, optimized production builds and usage in libraries. What I'd like to do here though is talk about a plugin included in the core called badgePlugin, and at the same time give you another, slightly more complex example of using 1log.

As I mentioned, you can install a plugin locally by passing it to the log function. In particular, log(badgePlugin('your caption')) will return a function just like log, but which prefixes log messages with a badge. Let's see what messages are logged by the following code:

import { badgePlugin, log } from '1log';
import { fromEvent, timer } from 'rxjs';
import { switchMap } from 'rxjs/operators';

fromEvent(document, 'click')
  .pipe(
    log(badgePlugin('outer')),
    switchMap(() => timer(500).pipe(log(badgePlugin('inner')))),
  )
  .subscribe();

Two messages appear as soon as the page loads:

In this example, 2.35 seconds later I click somewhere in the page, and this immediately produces three more messages:

Notice that for the inner observable the badge says "create 1", not "create 2": that's because there are separate counters for inner and outer observables, or generally speaking, for each combination of preceding badges.

What happened so far is that my click started the 500ms timer inside switchMap — but in 157ms, before the timer has had the chance to fire, I click again, and switchMap switches to a new timer, which eventually fires:

Testing

In combination with Jest's snapshots feature, inspecting log messages is a great way to test observables.

You can configure the library in such a way that when running tests, log messages are placed in a buffer instead of writing them to the console. You can retrieve them from that buffer and clear it by calling getMessages().

Let's take a look at an example. I launch Jest in watch mode and create the following .test.ts / .test.js file:

import { getMessages, log } from '1log';
import { timer } from 'rxjs';

test('timer', () => {
  timer(500).pipe(log).subscribe();
  jest.runAllTimers();
  expect(getMessages()).toMatchInlineSnapshot();
});

Once I save this file, Jest fills in the snapshot and there you go, I have a comprehensive and easy-to-read test:

import { getMessages, log } from '1log';
import { timer } from 'rxjs';

test('timer', () => {
  timer(500).pipe(log).subscribe();
  jest.runAllTimers();
  expect(getMessages()).toMatchInlineSnapshot(`
    [create 1] +0ms [Observable]
    [create 1] [subscribe 1] +0ms [Subscriber]
    [create 1] [subscribe 1] [next] +500ms 0
    [create 1] [subscribe 1] [complete] +0ms
    · [create 1] [subscribe 1] [unsubscribe] +0ms
  `);
});

Since colors are not available in tests, badges like [create 1] are not shortened to [1] the way they are in the console.

P.S. Together with 1log I published a utilities library which I called Antiutils, and which is 1log's only dependency. Check it out if you're curious.