Is passing callbacks into rxMethod an anti-pattern? (AsyncHandler pattern)

[gjanvier]

Context

I'm using rxMethod from @ngrx/signals for async operations in my signal stores (auth, API calls, etc.).

rxMethod is fire-and-forget by design. But sometimes the caller (a component, a guard, a form) needs to know whether the operation succeeded or failed, e.g. to navigate after login, show a toast, or close a dialog.

What I came up with

I created an AsyncHandler interface that gets mixed into the rxMethod input via intersection:

export interface AsyncHandler<T = void> {
  next?: (value: T) => void;
  error?: (error: Error) => void;
}

Usage in a store:

signIn: rxMethod<{ username: string; password: string } & AsyncHandler>(
  pipe(
    tap(() => patchState(store, { isLoading: true })),
    exhaustMap(({ username, password, next, error }) =>
      from(signInWithPassword(auth, username, password)).pipe(
        tap(() => {
          patchState(store, { isLoading: false });
          next?.();
        }),
        catchError((err: Error) => {
          patchState(store, { isLoading: false });
          error?.(err);
          return of(null);
        })
      )
    )
  )
);

Calling from a component:

store.signIn({
  username: 'foo',
  password: 'bar',
  next: () => this.router.navigate(['/dashboard']),
  error: (err) => this.showError(err),
});

What I like about it

• rxMethod keeps its core strengths: flow control (exhaustMap to prevent duplicate submissions) and centralized state management (isLoading, etc.) all live in the store where they belong
• AsyncHandler just adds an optional escape hatch for the caller, without changing any of that
• Zero boilerplate on the store side: just & AsyncHandler on the type
• Callbacks are optional, so existing fire-and-forget callers are unaffected
• No extra state signals (signInError, signInSuccess) to manage for one-shot operations

What worries me

It might be fighting against the reactive philosophy of signals, rxMethod, etc. Let me explain:

My questions

1. Am I contradicting myself? I explicitly choose rxMethod to encapsulate async flows inside the store — but then I punch a hole through it with callbacks so the caller gets result feedback. It feels like I'm saying "the store owns the flow" and "but the component still needs to know what happened" at the same time. Is that a valid trade-off, or a sign that I'm using the wrong tool?
2. Is there a recommended way to get completion/error feedback from an rxMethod that I'm missing?

Alternatives I considered

Before landing on AsyncHandler, I explored other approaches:

1. Store error state (signInError signal): the store holds the error and the component reacts to it. But this requires the component to call store.clearError() on init to avoid stale errors from a previous interaction. It also gets messy when multiple operations can fail — you end up with signInError, createAccountError, etc.

2. effect() on error signals: watching an error signal with effect() to trigger side effects (toast, navigation). But effect() fires on every change, making it hard to distinguish "new error just happened" from "error is still there from last time". It also couples the component to the store's internal state shape.

3. Event emitters / Subject: exposing a Subject<Error> or similar from the store. This works but feels like reinventing callbacks with extra steps, and leaks reactive plumbing outside the store.

AsyncHandler felt like the simplest option: one-shot callbacks scoped to a single call, no cleanup needed, no stale state.

Any feedback or alternative approaches would be appreciated!

[rainerhahnekamp]

Is this what you had in mind #4980?

[gjanvier]

Well, I haven't use signal forms yet. So I couldn't tell if my need or usage is the same as this one. I just wonder if I am the only one trying to get a follow-up after an rxMethod call.

Yet, from my understanding, I guess that another helper I wrote can transform any rxMethod into a regular function returning a Promise. I use it in 1 project but I find it even more questionable in terms of anti-pattern... I hope it won't bring more confusion to my initial question.

/**
 * Converts an rxMethod with AsyncHandler callbacks into a Promise.
 *
 * Allows using async/await syntax with rxMethod calls instead of callbacks.
 *
 * @example
 * // Instead of using callbacks:
 * store.loadDevice({ deviceId: '123', next: (d) => ..., error: (e) => ... });
 *
 * // Use async/await:
 * const device = await toPromise(store.loadDevice, { deviceId: '123' });
 */
export function toPromise<T, U>(
  method: RxMethod<T & AsyncHandler<U>>,
  input: T
): Promise<U> {
  return new Promise((resolve, reject) =>
    method({ ...input, next: resolve, error: reject })
  );
}

Or even

/**
 * Creates a promisified version of an rxMethod with AsyncHandler callbacks.
 *
 * Returns a reusable function that can be called multiple times with different inputs.
 *
 * @example
 * // Create a reusable promisified function:
 * const loadDeviceAsync = promisify(store.loadDevice);
 *
 * // Use it multiple times:
 * const device1 = await loadDeviceAsync({ deviceId: '123' });
 * const device2 = await loadDeviceAsync({ deviceId: '456' });
 */
export function promisify<T, U>(
  method: RxMethod<T & AsyncHandler<U>>
): (input: T) => Promise<U> {
  return (input: T) =>
    new Promise((resolve, reject) =>
      method({ ...input, next: resolve, error: reject })
    );
}

NB: I know there could be a bug / memory leak when used with an exhaustMap() for instance... So far I don't need to manage such case.

[gjanvier]

Oh! the link that is in the issue you mention is broken so I missed most of the info (some broken markdown). My bad.

But yes, when reading the article on medium.com, I think we are close.