-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Remove downcasts in BlazorWebView #5984
Conversation
Instead, put "SendXyz" methods on the IBlazorWebView interface to enable the handlers to raise events on the control. The control has events for users to wire-up, or alternative systems can implement the interface with another event/command pattern if desired.
I would drop the "Send" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense and looks good!
As for whether or not to remove the Send
name prefixes, I'd be in favour of removing them.
About these names:
Do we need to say it's a BlazorWebView here? Could they be named just I mean I know it could even go as far as |
Right now it matches the event names, which I think is valuable. Or are you suggesting renaming the events, too?
I will try to see if that's possible, but it might not work because the control has concrete events X, Y, and Z, and then also interface implementations for methods named X, Y, and Z. I doubt C# allows that. |
OK, the Send prefix is gone. I guess C# is OK with having the same name on an event and an interface-implemented method! |
BTW I didn't rename the methods/event names to drop BlazorWebView. We should discuss that separately because it's a somewhat unrelated change. I think keeping the method names the same as the event names (or extremely similar) is critical. But I'd be fine if we agreed to rename all of them to some other pattern. |
Instead, put "SendXyz" methods on the IBlazorWebView interface to enable the handlers to raise events on the control. The control has events for users to wire-up, or alternative systems can implement the interface with another event/command pattern if desired.
Motivation:
BlazorWebView
is what a MAUI user will program against. As such, it has friendly "events" that they can handle and perform various customizationsIBlazorWebView
interface is the minimum set of APIs needed for a Handler to interact with a concrete usable type, such as MAUI's built-inBlazorWebView
, or perhaps some other variation that could be used in Comet or in some hypothetical future version of Hybrid Blazor Bindings. In such non-MAUI places, using events or even structuring the properties the way they are is not necessarily the best model, so they can choose to implement those features however they want (or even omit some that they don't want to use)Related: #5904, #5905