search

canton7 / Stylet

A very lightweight but powerful ViewModel-First MVVM framework for WPF for .NET Framework and .NET Core, inspired by Caliburn.Micro.
MIT License
994 stars 143 forks source link

Is full async support planned? #160

Closed snalesso closed 3 years ago

snalesso commented 4 years ago

Caliburn.Micro, in the "upcoming" v4, supports a full async approach, providing InitializeAsync, ActivateAsync, DeactivateAsync, CanCloseAsync, TryCloseAsync, etc.

Is anything like that planned?

canton7 commented 4 years ago

I hadn't given it any thought -- Stylet started off being inspired by Caliburn.Micro, but it's in no way a clone. Is that something you need?

snalesso commented 4 years ago

Kinda. Not in the way I can't live without it, but it would improve a lot the code quality, since it makes it easier to keep UI responsive and to interact with System.Reactive.

canton7 commented 4 years ago

Do you have examples?

For the cases of InitializeAsync/ActivateAsync/DeactivateAsync, I'm not sure what returning a Task gives you: what's the state of the Screen until that Task completes? If a Screen is deactivated, does it stay activated unless and until the Task returned from DeactivateAsync completes?

For TryCloseAsync, what's the advantage in the caller getting back a Task? Stylet currently treats this as fire-and-forget.

Stylet had CanCloseAsync before Caliburn.Micro did :)

I'm sure there are good answers to those questions, I'm just curious as to what they are.

snalesso commented 4 years ago

I guess that with ActivateAsync/DeactivateAsync you can control related I/O (e.g. state-restoring/saving) and raise corresponding events only when the awaitable work is done, and use CancellationTokens to interrupt/timout from the outside. Same for TryCloseAsync which starts the chained close procedure providing a trigger to interrupt it in case of need.

canton7 commented 4 years ago

and raise corresponding events only when the awaitable work is done

That's my point: do we want to keep the VM in the Deactivated state until it's finished activating? That seems wrong -- we're showing a VM, and it's awake and reacting to events, but it's reporting that it's deactivated. This means that if it's subsequently closed or deactivated, it won't get any notification of this, because it still claims to be deactivated.

The model in my head is that the VM itself is activated at the moment that it's displayed, and becomes available for interaction with the user. It may have some additional state which means "still loading some requirement data, hold on", but I think that falls outside of the activated/deactivated lifecycle.

and use CancellationTokens to interrupt/timout from the outside

So things like Items.Remove(someVM) from within a conductor now become async, and can accept a CancellationToken? That means wiring that all the way through BindableCollection, which as a collection is inherently non-async, which feels wrong.

canton7 commented 3 years ago

Closing as no response. Feel free to re-open if you want to continue the discussion.