Is there a recommended way to await async work in WhenActivated?

[martinbu-tes]

Hi! We're on ReactiveUI 23.2.28 / .NET 10 (Blazor) and ran into something I'd like to understand better — quite possibly we're just holding it wrong.

Our view model base does async setup on activation:

this.WhenActivated(async d => await InitAsync(d));

Since the WhenActivated overloads take Action<…> or Func<IEnumerable>, this becomes async void, so Activate() returns before InitAsync has finished. That's reasonable in itself, but we haven't found a way to observe when activation is actually done — either from production code that wants to react once the view model is ready, or from a unit test. (The Activate() docs mention calling it from unit tests, which is what got us looking.)

We tried composing off Activator.Activated, but as far as we can tell it's hot without replay, and a chain built on it runs alongside the activation handler rather than after it — so it doesn't quite give us "activation finished".

We also noticed ReactiveComponentBase overrides OnInitialized/OnAfterRender rather than Blazor's awaitable OnInitializedAsync/OnAfterRenderAsync. Is that a deliberate choice?

A few questions:

1. Is there an established pattern for this that we've overlooked?
2. Is activation intentionally fire-and-forget?
3. If not, would an async overload — or a completion signal on ViewModelActivator — be something you'd consider? Happy to help out if so.

[Ai-Eastern]

In 23.2.28, there is no awaitable activation-completion contract. WhenActivated registers synchronous blocks; ViewModelActivator.Activate() runs those blocks, then emits Activated, then returns. It does not wait for a Task started by a block. So your reading of the async lambda and of Activated is right.

If initialization must start on each activation, keep the registered callback synchronous and expose its task explicitly:

public Task InitializationTask { get; private set; } = Task.CompletedTask;

this.WhenActivated(d =>
{
    InitializationTask = InitAsync(d); // InitAsync returns Task
});

A test can then do:

using var activation = vm.Activator.Activate();
await vm.InitializationTask;

The assignment happens while Activate() runs, so the test obtains the task for that activation; awaiting it also observes initialization failures instead of losing them in async void. If deactivation can happen before the work finishes, make InitAsync cancellable and cancel that activation's work when d is disposed. On a later activation, the property holds a new task.

For your Blazor component, ReactiveComponentBase<T> overrides the synchronous OnInitialized and OnAfterRender, but it does not prevent a derived component from overriding Blazor's OnInitializedAsync or OnAfterRenderAsync. Blazor calls OnInitialized before OnInitializedAsync; if the VM is already supplied at initialization, a derived component can await ViewModel.InitializationTask there. If this is one-time component setup rather than per-activation work, putting it directly in OnInitializedAsync is simpler.

Sources: 23.2.28 activator, WhenActivated overloads, Blazor base component, and Blazor lifecycle ordering. I cannot infer from the code whether the synchronous-only API was a deliberate product decision, or speak for the maintainers on adding an async overload.

AI-assisted — checked against the linked versioned source and framework documentation.

[martinbu-tes]

So yes I could it implement myself in a base class. But I would use a BehaviorSubject instead of a Task, as Activate / Deactivate can happen multiple times.
Is this something you would consider adding to the framework or is this something that is out of scope as other framworks supported by ReactiveUI (other than blazor) do not have async lifecycle hooks?

[Ai-Eastern]

You're right: if consumers need to observe each activation, a stream such as BehaviorSubject<Task> (or an explicit activation-state observable) is a better fit than only exposing the latest Task property. Each activation can publish its own task; deactivation should cancel or otherwise retire that activation's work, and callers should still observe failures. My example was just a way to await one specific activation, not a proposed framework API.

I should clarify that I'm a fellow community member, not a ReactiveUI maintainer. I can't say whether an async activation contract is planned or in scope for the framework; that part needs a maintainer's input.