This change replaces the parsing of HTML that we perform during the code
generation phase, which parsing of HTML during the IR lowering phase.
The main benefit of this change is that the structure of the HTML is
reflected in the IR tree, allowing us to do more more advance
transformations.
As an example, see how the the handling of `<script>` tags is now a
separate pass.
As an aside from this I also redesigned the structure of component IR
nodes to match the new HTML element nodes. Passes are now more easily
aware of the nodes they are expected to handle and are more easily aware
of the difference between a component and element. This still isn't as
clean as I would like, but I think it's a reasonable improvement.
Another benefit of this is that the code generation is much simpler and
requires much less bookkeeping and statefulness.
* 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 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.
Ryan Nowak
Steve Sanderson