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 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.
* In Razor compilation, trim leading and trailing whitespace
* Update all unit tests to account for whitespace trimming
* Recognize that TagHelperIntermediateNode produces output too
* Skip TrimWhitespacePass during first phase of two-phase compile
* Skip TrimWhitespacePass during design-time builds
* Update baselines after rebase
The issue here is that we were missing tests for the design time code
path. We have tests that the bind-... cases work at runtime but were
missing coverage for the editor.
I took the most relevant set of the tests for running bind-... code and
added them to the tests for codegen.
This change adds `Action` to the set of types that have an overload on
RenderTreeBuilder. Additionally, we special case `Action` in the runtime
because passing the event args via DynamicInvoke() would throw.
Finally, reverted some of the clutter introduced by the first pass of
the event handler feature.
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.
Ports somee infrastructure and converts Razor code generation tests to use
it. This makes it much easier to make cross cutting changes to code
generation and see the effect.
Use build /p:GenerateBaselines=true to update all of the generated code
in place or when adding new tests. Generally if tests are failing, the
easiest thing to do is to update the baselines and do a git diff to see
what the deltas are.
The changes to the tests here are to use the new baseline infrastructure
and to rename classes/methods to result in shorter file paths.
Ryan Nowak
Steve Sanderson
Ryan Nowak