-
Notifications
You must be signed in to change notification settings - Fork 10.1k
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 first class support for onclick and other event handlers #16244
Comments
how would passing parameters look like? |
I guess if you use the lambda variant you can do that |
I should have been more specific. How would the eventhandler be looking like in code/@functions, are the arguments going to be added the handler, is it params argument type, etc |
Is there any specific syntax for passing the event? Like |
@awulkan just look at the first post, the example shows how to pass event (namely you don't explicitly, you always do). You currently cannot have events not receiving the event argument anymore |
This change removes support for the old syntax used for event handlers and two-way binding. See the relevant issues for details on the new features and improvements: bind https://github.com/aspnet/Blazor/issues/409 event handlers https://github.com/aspnet/Blazor/issues/503 Along with this change we've removed a few additional things Blazor could do that aren't part of Razor's usual syntax. ---- The features that was used to make something like: ``` <button @OnClick(...) /> ``` is an expression that's embedded in a an element's attribute. This feature might be useful in the future if we want to support 'splatting' arbitrary attributes into a tag, but the runtime support for this isn't accessible outside the Blazor core. ---- The features that implement: ``` <button onclick=@{ } /> ``` have been removed in favor of a better design for lambdas, method group conversions and other things for event handler attributes. use `<button onclick=@(x => ...} />` instead. We think is a better approach in general, because we want the app developer to write and see the parameter list. ---- Both syntactic features that have been removed have dedicated error messages in the compiler. If you're porting old code it should help you figure out what to do.
This change removes support for the old syntax used for event handlers and two-way binding. See the relevant issues for details on the new features and improvements: bind https://github.com/aspnet/Blazor/issues/409 event handlers https://github.com/aspnet/Blazor/issues/503 Along with this change we've removed a few additional things Blazor could do that aren't part of Razor's usual syntax. ---- The features that was used to make something like: ``` <button @OnClick(...) /> ``` is an expression that's embedded in a an element's attribute. This feature might be useful in the future if we want to support 'splatting' arbitrary attributes into a tag, but the runtime support for this isn't accessible outside the Blazor core. ---- The features that implement: ``` <button onclick=@{ } /> ``` have been removed in favor of a better design for lambdas, method group conversions and other things for event handler attributes. use `<button onclick=@(x => ...} />` instead. We think is a better approach in general, because we want the app developer to write and see the parameter list. ---- Both syntactic features that have been removed have dedicated error messages in the compiler. If you're porting old code it should help you figure out what to do.
This change removes support for the old syntax used for event handlers and two-way binding. See the relevant issues for details on the new features and improvements: bind https://github.com/aspnet/Blazor/issues/409 event handlers https://github.com/aspnet/Blazor/issues/503 Along with this change we've removed a few additional things Blazor could do that aren't part of Razor's usual syntax. ---- The features that was used to make something like: ``` <button @OnClick(...) /> ``` is an expression that's embedded in a an element's attribute. This feature might be useful in the future if we want to support 'splatting' arbitrary attributes into a tag, but the runtime support for this isn't accessible outside the Blazor core. ---- The features that implement: ``` <button onclick=@{ } /> ``` have been removed in favor of a better design for lambdas, method group conversions and other things for event handler attributes. use `<button onclick=@(x => ...} />` instead. We think is a better approach in general, because we want the app developer to write and see the parameter list. ---- Both syntactic features that have been removed have dedicated error messages in the compiler. If you're porting old code it should help you figure out what to do.
This change removes support for the old syntax used for event handlers and two-way binding. See the relevant issues for details on the new features and improvements: bind https://github.com/aspnet/Blazor/issues/409 event handlers https://github.com/aspnet/Blazor/issues/503 Along with this change we've removed a few additional things Blazor could do that aren't part of Razor's usual syntax. ---- The features that was used to make something like: ``` <button @OnClick(...) /> ``` is an expression that's embedded in a an element's attribute. This feature might be useful in the future if we want to support 'splatting' arbitrary attributes into a tag, but the runtime support for this isn't accessible outside the Blazor core. ---- The features that implement: ``` <button onclick=@{ } /> ``` have been removed in favor of a better design for lambdas, method group conversions and other things for event handler attributes. use `<button onclick=@(x => ...} />` instead. We think is a better approach in general, because we want the app developer to write and see the parameter list. ---- Both syntactic features that have been removed have dedicated error messages in the compiler. If you're porting old code it should help you figure out what to do.
Yes, it's like this: Alternative just |
This change removes support for the old syntax used for event handlers and two-way binding. See the relevant issues for details on the new features and improvements: bind https://github.com/aspnet/Blazor/issues/409 event handlers https://github.com/aspnet/Blazor/issues/503 Along with this change we've removed a few additional things Blazor could do that aren't part of Razor's usual syntax. ---- The features that was used to make something like: ``` <button @OnClick(...) /> ``` is an expression that's embedded in a an element's attribute. This feature might be useful in the future if we want to support 'splatting' arbitrary attributes into a tag, but the runtime support for this isn't accessible outside the Blazor core. ---- The features that implement: ``` <button onclick=@{ } /> ``` have been removed in favor of a better design for lambdas, method group conversions and other things for event handler attributes. use `<button onclick=@(x => ...} />` instead. We think is a better approach in general, because we want the app developer to write and see the parameter list. ---- Both syntactic features that have been removed have dedicated error messages in the compiler. If you're porting old code it should help you figure out what to do.
What is it?
We're doing some tweaks to the ways that event handlers get wired to DOM events in Blazor, and adding a lot more features and power.
Hooking up a C# function to a handle a DOM event will look like:
or if you'd prefer a lambda:
This has first class integration with the editor in Visual Studio and will include tooltips and completion.
Passing in a string like
<button onclick="foo" />
will not do any magic, and will work as if it were normal HTML.What's changing
This kind of thing has been possible today using a few temporary syntaxes that will be removed as part of 0.2. Namely
<button @onclick(Foo) />
and `<button onclick=@{ Foo(); } />. This change makes the event handler wire up look and function the same way as other Razor features.What's added
Along with this change we'll be defining more of the standard DOM events with first class completion and eventargs types.
We'll also be adding support for arbitrary event names. So
<button onfoo="@Foo" />
will bind the Foo method to be called when thefoo
DOM event is fired.TODO
onclick
andonchange
Action
in addition toUIEventHandler
The text was updated successfully, but these errors were encountered: