Can ObservableProperty work perfectly with aysnc method?

[ali50m]

I would like to call aysnc methond inside the generated partial void OnPropertyChanged method, could anyone kindly let me know how to perform it?

[ObservableProperty]
public partial string DbPath { get; set; } = string.Empty;

partial void OnDbPathChanged(string value)
{
    Settings.Default.DbPath = DbPath;
    Settings.Default.Save();

    // await ReloadDbUsers();
}

[bzd3y]

You should be able to just change the signature to partial async void OnDbPathChanged(string value). The async essentially just lets the compiler know that it has awaits in it and to build an async state machine to handle them. It is not really part of the method signature (this is why interface signatures don't need it, and can't have it, for example).

Since it isn't returning a Task it can't be awaited and will be truly/completely asynchronous, i.e. "fire and forget", so keep that in mind.

Generally you would not want to use async void for your own methods that you or somebody consuming your API might call. But that's only a general rule, with plenty of exceptions, no pun intended.

I realized I might not have answered your actual question about whether this can "work perfectly". A real MVVM library expert might be able to chime in and give a reason why my suggestion is a bad one in this case, but I don't know of any. Whether it works "perfectly" depends on what that means. The only thing I can think of that might cause problems, which I already mentioned above, is that it will be *actually asynchronous.

So when DbPath is set, the property setter will not wait for OnDbPathChanged to complete (well, I guess technically it does, but it doesn't wait for the async stuff inside it to complete). So any code after DbPath is set can't really rely on the code in OnDbPathChanged to have completed.

If you need it to do that, then you will probably need to use some additional concurrency mechanics, like a TaskCompletionSource, semaphore, ManualEvent(Slim), etc.

Or, alternatively, possibly ideal, refactor this so it is done with a method in the first place instead of a property. For example, invert the flow and replace OnDbPathChanged with something like UpdateDbPathAsync(string path) that has the same code, but then also sets the property.

[ali50m]

@bzd3y Thank you for your suggestion to use methods instead of properties to complete this asynchronous work.

I would like to hear the library developers' thoughts on this, or whether there is any plan to add such support? At present, this tool can help me complete most of the tedious things about mvvm.

[bzd3y]

You're welcome. What support are you wondering about? I think what you are trying to do is supported. You can use the void async like I initially suggested, IF you don't need any code after the property is set to wait for the async to complete.

If you do, then your options are:

1. Write your own concurrency mechanism using something like TaskCompletionSource. This would still require you to await some other Task, so it probably doesn't buy you anything over just setting the property and then calling ReloadDbUsers manually, although it does let you easily switch between awaiting it or not.
2. Use a method like UpdateDbPathAsync() to set the path and then call ReloadDbUsers. This is the simplest option.
3. It dawned on me that what you might want/need might already be supported with ObservableObject.TaskNotifier, so you could look into using that. It essentially allows you to bind asynchronously to the Task in your view.

Anyway, beside that, I don't think this is something they can add support for, because there is no such thing as async or awaitable properties in C# (but maybe I'm just not understanding what you are asking). And if they just made the code generator block the asynchronous calls then I think that could cause threading issues with the UI.

[ali50m]

@bzd3y Thank you very much for the detail explanation! It's because when I used AsyncRelayCommand, I felt the beauty of forwarding traditional UI events to async/await methods. So I want to ask if it is possible to elegantly connect property change events to async/await methods.

Sometimes because of the contagiousness of async/await methods, it may eventually spread to constructors/traditional UI event processing, or some designs that did not have the concept of async/await at that time. At this time, I will remember that I always hear people say not to use async void, it is a black hole...

[bzd3y]

Gotcha. You're welcome. async void is that way. That is exactly what it is there for, not specifically for properties, but just for anything that needs to be asynchronous but not awaitable.

I still don't know if you need these to be awaitable or not, but that is what it comes down to. If you don't, then async void is exactly what you want. If you do, then you need to redesign things some.

[ali50m]

@bzd3y In my app, I use to boolean IsReady to indicate the DbUser loading status, then UI use this flag to disable controls. Maybe it doesn't need awaitable at this time.

I will use fire and whencomplete to finish the property changed method. Thanks for your kind reply!

[bzd3y]

Okay, I think you can do that by binding to the IsRunning property on your command.

[ali50m]

Got it, thx!