Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for async/await handler on Register handler in Messenger #332

Closed
soroshsabz opened this issue Jul 1, 2022 · 8 comments
Closed
Labels
feature request 📬 A request for new changes to improve functionality

Comments

@soroshsabz
Copy link

Overview

ITNOA

I think it is good to can call asynchronous method on handler of Register method of Messenger and await on that without problem.

API breakdown

No API added.

Usage example

WeakReferenceMessenger.Default.Register<ContinueCallbackAnsweringRequestMessage>(this, async (r, message) =>
{
    await FooAsync();
    await BarAsync();
    message.reply(foo);
});

Breaking change?

No

Alternatives

I do not found any alternative :(

Additional context

No response

Help us help you

Yes, but only if others can assist

@soroshsabz soroshsabz added the feature request 📬 A request for new changes to improve functionality label Jul 1, 2022
@soroshsabz
Copy link
Author

related to #331

@Sergio0694
Copy link
Member

This is already supported, you're just registering the callback incorrectly. You can do this:

WeakReferenceMessenger.Default.Register<ContinueCallbackAnsweringRequestMessage>(this, (r, m) =>
{
    async Task<Foo> ReceiveAsync()
    {
        await FooAsync();
        await BarAsync();

        return foo;
    }
    
    m.Reply(ReceiveAsync());
});

I should note, you should change this to avoid creating closures, for better performance (see docs):

WeakReferenceMessenger.Default.Register<MyViewModel, ContinueCallbackAnsweringRequestMessage>(this, static (r, m) =>
{
    async Task<Foo> ReceiveAsync(MyViewModel r)
    {
        await r.FooAsync();
        await r.BarAsync();

        return r.GetSomeFoo();
    }
    
    m.Reply(ReceiveAsync(r));
});

We might consider adding some helper extensions to support this scenario in an easier way in the future I guess 🤔

@soroshsabz
Copy link
Author

@Sergio0694 very thank you for response

the minor note is I think your code is not compile, because CS0136 A local or parameter named 'r' cannot be declared in this scope because that name is used in an enclosing local scope to define a local or parameter

@Sergio0694
Copy link
Member

No that'll compile fine - the r parameter of the inner method will just shadow the outer one.
That said, it was just an example, but you can also just make the method static to make it even clearer:

image

@soroshsabz
Copy link
Author

soroshsabz commented Jul 6, 2022

I have to use C# 7.3 and cannot use static keyword, same variable name has been error

            WeakReferenceMessenger.Default.Register<Dialer, ContinueCallbackAnsweringRequestMessage>(this, (r, message) =>
            {

                async Task<Task<CancellationToken>> ReceiveAsync(Dialer r)
		{
				var continueCallbackAnsweringDialog = new ContinueCallbackAnsweringDialog();
				await continueCallbackAnsweringDialog.ShowAsync();
                                return continueCallbackAnsweringDialog.ResultAsync;
		}

		message.Reply(ReceiveAsync(r).Unwrap());
	});

@Sergio0694
Copy link
Member

Using the static keyword is just for clarity, the code still compiles even without that. I guess maybe they added support for sharing locals in a recent version of C#, I honestly don't remember. Either way, yeah then just change that name if needed 😄

@soroshsabz
Copy link
Author

After I changing my code from your suggestion, I got InvalidOperationException on Task<CancellatinToken> , this behavior is like race conditioning, Did you know or see any problem on my implementation? (My code is here)

Am I use Unwrap correctly?

thanks

@soroshsabz
Copy link
Author

I found my problem, thanks :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request 📬 A request for new changes to improve functionality
Projects
None yet
Development

No branches or pull requests

2 participants