Commit Graph

5 Commits

Author SHA1 Message Date
Steve Sanderson 18b9a70dbe Encourage encapsulation of component parameter properties (#713)
* Before refactoring ParameterCollection assignment logic, add more test coverage

* Begin caching parameter assignment info

* Factor out some reflection code to a reusable location

* Use IPropertySetter to avoid all per-property-assignment reflection

* More error cases and tests for parameter assignment

* Enable binding to nonpublic properties

* Add analyzer to warn and provide fix for public component parameters

* Unit test for analyzer

* Component tag helper now includes private properties if they have [Parameter]

* CR feedback: Remove garbage from csproj

* CR feedback: Rename .Build.Analyzers to .Analyzers

* CR feedback: Move BlazorApi.cs to shared; use it from Analyzers test

* Fix incorrect test name

* Make as many parameters private as possible. Replace ILayoutComponent with BlazorLayoutComponent.

* In component tag helper discovery, consider private members too

* Reduce the work in component parameter discovery by not inspecting the BlazorComponent base class (or System.Object)
2018-05-01 10:08:01 +01:00
Ryan Nowak c3366bc956 Add event handlers as tag helpers
This change adds support for mapping DOM event handlers as tag helpers
that function in a bi-modal way.

This is a new first-class feature for DOM events, and replaces a few
workarounds like using `@onclick(...)` or `click=@{ ... }`. I haven't
removed those things yet, this is a first pass to get the new support
in, we'll remove those things when we're totally satisfied.

When used with a string like `<button onclick="foo" />` the result is
a simple HTML attribute .

But when used with an implicit expression like
`<button onclick="@Foo" />` or
`<button onclick="@(x => Clicked = true)" />` a C# function is bound to
the click event from the DOM.
2018-04-06 13:00:04 -07:00
flash2048 3369208c28 Fix mistake in array index 2018-04-06 11:41:47 +01:00
flash2048 e696325b76 Corrects spelling of some comments 2018-04-02 12:34:08 +01:00
Ryan Nowak 5b658c80a1 Replace @bind with bind-...
This change introduces a 'tag helper' that replaces @bind with custom
code generation that accomplishes roughly the same thing.

This feature lights up by dynamically generating tag helpers that are
visible to tooling and affect the code generation based on:
- pattern recognition of component properties
- attributes that create definitions for elements
- a 'fallback' case for elements

'bind' also supports format strings (currently only for DateTime) via
a separate attribute.

This change introduces the basic framework for bind and tooling support.
We know that we'll have to do more work to define the set of default
'bind' cases for the DOM and to flesh out the conversion/formatting
infrastructure.

This change gets us far enough to replace all of the cases we currently
have tests for :) with the new features. The old @bind technique still
works for now.

Examples:

@* bind an input element to an expression *@
<input bind="@SelectedDate" format="mm/dd/yyyy" />
@functions {
    public DateTime SelectedDate { get; set; }
}

@* bind an arbitrary expression to an arbitrary set of attributes *@
<div bind-myvalue-myevent="@SomeExpression">...</div>

@* write a component that supports bind *@

@* in Counter.cshtml *@
<div>...html omitted for brevity...</div>
@functions {
    public int Value { get; set; } = 1;
    public Action<int> ValueChanged { get; set; }
}

@* in another file *@
<Counter bind-Value="@CurrentValue" />
@functions {
    public int CurrentValue { get; set; }
}
2018-03-29 22:04:24 -07:00