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 first class support for onclick and other event handlers #16244

Closed
5 tasks done
rynowak opened this issue Apr 6, 2018 · 6 comments
Closed
5 tasks done

Add first class support for onclick and other event handlers #16244

rynowak opened this issue Apr 6, 2018 · 6 comments
Assignees
Labels
area-blazor Includes: Blazor, Razor Components

Comments

@rynowak
Copy link
Member

rynowak commented Apr 6, 2018

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:

<button onclick="@OnClick" />
@functions {
    void OnClick(UIMouseEventArgs e)
    {
        Console.WriteLine("hello, world");
    }
} 

or if you'd prefer a lambda:

<button onclick="@(e => Console.WriteLine("hello, world"))"

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 the foo DOM event is fired.

TODO

  • Add language support for onclick and onchange
  • Remove temporary workarounds
  • Support Action in addition to UIEventHandler
  • Add support for arbitrary events
  • Remove allocations for common cases
@rynowak rynowak self-assigned this Apr 6, 2018
@dlr1
Copy link

dlr1 commented Apr 6, 2018

how would passing parameters look like?
for ex; <div onclick="@OnClick(item)"/>

@yowl
Copy link

yowl commented Apr 6, 2018

I guess if you use the lambda variant you can do that
<button onclick="@(e => Console.WriteLine("hello, world " + item))"

@dlr1
Copy link

dlr1 commented Apr 6, 2018

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
update: did not try, but guess following might work, but cumbersome
<button onclick="@(e => SomeMethod(item))"

@awulkan
Copy link
Contributor

awulkan commented Apr 7, 2018

Is there any specific syntax for passing the event? Like <div onclick="@OnClick($event)"/>?

@Suchiman
Copy link
Contributor

Suchiman commented Apr 8, 2018

@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

rynowak referenced this issue in dotnet/blazor Apr 10, 2018
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.
rynowak referenced this issue in dotnet/blazor Apr 10, 2018
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.
rynowak referenced this issue in dotnet/blazor Apr 10, 2018
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.
rynowak referenced this issue in dotnet/blazor Apr 10, 2018
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.
@SteveSandersonMS
Copy link
Member

@awulkan

Yes, it's like this: onsomeevent="@(evt => MyCode(evt))", where evt is some subclass of UIEventArgs. The compiler checks you're passing a legal subclass based on the event type.

Alternative just onsomeevent="@MyMethod", where you also have void MyMethod(UIEventArgs args) { ... } (or whatever applicable subclass of UIEventArgs, such as UIChangeEventArgs).

@rynowak rynowak closed this as completed Apr 12, 2018
SteveSandersonMS referenced this issue in SteveSandersonMS/BlazorMigration Nov 27, 2018
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.
@mkArtakMSFT mkArtakMSFT transferred this issue from dotnet/blazor Oct 27, 2019
@mkArtakMSFT mkArtakMSFT added the area-blazor Includes: Blazor, Razor Components label Oct 27, 2019
@ghost ghost locked as resolved and limited conversation to collaborators Dec 4, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-blazor Includes: Blazor, Razor Components
Projects
None yet
Development

No branches or pull requests

7 participants