* Test namespace cleanup
* Add recognication for RenderFragment in tag helpers
* Remove dead code from node writers
* refactor type check
* Continue to treat child content as a delegate in codegen
* Add extension to enumerate child content
* Reorganize code generation tests
These were growing a bit disorganized, and weren't really result in good
code reuse.
* fix test base class
* Add some child-content tests
* Add an explicit node for ChildContent
Adds a strongly typed node to represent a 'ChildContent' and what it
contains. This allows us to simplify the code generation path,
detect/processes more issues in IR passes, and will be essential for
supporting multiple child content.
* Ignore ChildContent in components when it's just whitespace
* Add diagnostic for duplicate child content
* Add support for explicit child content elements
Precursor to support for multiple child content items
* Add support for multiple child-content elements
* Change delegate signature for RenderFragment<T>
* Clean up Tag Helper constants
* Allow RenderFragment<T> as a child content
* Allow renaming the template parameter
* Improve error message for invalid child content
* Add diagnostic for repeated child content parameter names
Adds support for Razor templates and RenderFragment<T>.
Razor templates are a little-known Razor feature that looks like:
```
@<tag>....<tag>
```
It's so little known that it's not even covered in our docs, but it's
been around for many many years. This features hasn't been implemented
until now for Blazor, and this feature brings it back as a build
building block for templated components (more to come).
In Blazor land a template like:
```
@{ RenderFragment<Person> template = @<div>@item.Name</div>; }
```
complies to code like:
```
RenderFragment<Person> template = (__builder, item) =>
{
__builder.OpenElement(...);
...
__builder.CloseElement(...);
}
```
Since the declaration always has a generic type parameter inside, it
needs to be in a context where the type is known.. ie: not with `var`.
See tests for ways to consume templates.
NOTE: There are the following caveats for templates
- Templates require a single root element.
- Templates don't work in the `@functions { }` block
These limitations are baked into the core of Razor and will take a while
for us to address (v3.0).
This change will cause the compiler to ignore <!DOCTYPE ...>
declarations in Blazor components. We don't think there's much useful
Blazor can do with doctype, since we don't generate textual output for
the browser the parse. The sanest thing to do for now is just to skip
over it.
This change introduces a mechanism for bypassing type checking and then
uses for the 'event handlers'. The event handler tag helpers have some
ideosyncratic behaviors and rely on overloading at the render tree
builder level.
Introduces a new primitive used by the compiler for type checking. Type
checking applies to component parameters when setting the value directly
and when using bind. This is nice because it also adds error checking
for bind.
The logic that binds event handlers was interfering with the code that
prevents component properties from receiving complex content.
This check was a little overzealous.
The problem is that the new HTML rewrite pass was traversing into
attributes of all kinds and would turn any HTML content inside those
attributes into elements where possible. The solution is to not do
that.
We weren't handling a few cases that can occur during typing correctly.
Our passes that look at the content of attributes need to be prepared
for it to be empty in cases where the attribute has been partially
typed in the editor.
I added a smoke test for this that attempts to simulate typing and found
another issue to fix.
The end result of this is that the design for this kind of code is
simpler and takes a more 'brute-force' approach to understanding
attributes. I think this is a good change based on the problems with how
this code has been written today, there are too many possible cases to
try and have the code express and document them all.
* In Blazor cshtml files, auto-import Microsoft.AspNetCore.Blazor and Microsoft.AspNetCore.Blazor.Components. Fixes#749
* Remove redundant @using directives from tests
* Update assertion in test
* Update all affected baselines
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.
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 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