* Add HTML Block rewriter
* Baseline updates
* test gaps
* Update some unit tests to represent same behavior as before
* Define Markup frame type. Tests for rendering markup frames into render tree.
* Support markup frames during diffing (retain, insert, update, delete)
* Support markup blocks on WebAssembly
* Support rendering markup frames with server-side execution too
* Support markup blocks with multiple top-level nodes. Support updating markup dynamically.
* Define MarkupString type as a way to insert dynamic markup without needing custom RenderFragment code
* Remove comment
* CR: Better null value handling
... because it's important not to disclose cross-user state, such as the number of IDs that have been assigned. Plus we don't want to run out of unique IDs, which we could if it's limited by the range of an 'int'.
* 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)
This change introduces ParameterAttribute to specify a bindable
component parameter. As of the 0.3 release of Blazor we plan to make
[Parameter] required to make a property bindable by callers.
This also applies to parameters when their value is set by the
infrastructure, such as `Body` for layouts, and route paramters.
The rationale behind this change is that we think there is a need to
separate the definition of properties from their suitability for a
caller to set them through markup. We plan to introduce more features in
this area in the future such as marking parameters as required. This is
first step, and we think that this approach will scale nicely as we add
more functionaly.
The 0.3 release seems like the right time to change this behavior since
we're also introducing `ref` for captures in this release.
* Improve support for more types of event handlers
Improves support for for other types of event handlers with eventargs
types derived from UIEventArgs. Additionally fleshes out the set of
event handler types.
This change improves support for using more specific event handler types
like:
```
<button onclick="@Clicked" />
@functions {
public void Clicked(UIMouseEventArgs e) { ... }
}
```
And:
```
builder.AddAttribute(12, "onkeypressed", KeyPressed);
...
void KeyPressed(UIKeyboardEventArgs e) { ... }
```
In particular what got better is:
- overload resolution for the AddAttribute method
- performance of different cases for AddAttribute
-----
The runtime now treats delegates as one of three types:
- arbitrary delegate: not attached to DOM events, not tracked by
renderer
- UIEventHandler: can attach to DOM events, tracked by renderer, first
class in IHandleEvents
- UIEventHandler-like: can attach to DOM events, tracked by renderer,
requires some special runtime support.
The set of overloads on AddAttribute has been tuned with a few specific
cases in mind.
Lambda expressions in an attribute will be inferred as UIEventHandler
unless the compiler does something more specific. So for instance,
passing a lambda as an attribute value for a component, where the
component doesn't define a matching attribute, will always be inferred
as UIEventHandler.
We now support method-group to delegate conversion for methods that
accept a derived UIEventArgs type. This means you can use a signature
like `void KeyPressed(UIKeyboardEventArgs e)` without any compiler
magic, and this will work in the runtime as long as the event type
produced by the runtime matches.
We also allow user-defined UIEventArgs-derived types. There's a pattern
for this and it requires defining an extension method and delegate type.
The method-group to delegate conversion part required some doing. It
doesn't play well with generics (Action<T> where T : UIEventArgs)
doesn't work at all. Adding more actual overloads (as opposed to
extensions) would cause lambda cases we want to work to be ambiguous.
----
The performance win here is to remove the need for a 'wrapper' delegate
created by the event handler tag helper code. This wrapper is now
created by the runtime, but only *after* we have checked the frame for
changes. This requires more heavy lifting in the runtime, but has the
advantage of producing no-op diffs as often as possible.
You will still get some inefficient behavior if your component uses a
capturing lambda in an event handler, so don't do that.
* Add selenium logs to test output
* Minor feedback
* WIP
Adds conditional attributes for HTML elements.
This means that an attribute with a 'false' .NET bool value or a null
.NET value of another type will not be rendered in the HTML.
Steve Sanderson
Adrian Wright
Ryan Nowak
Ryan Nowak