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).
* Remove JSInterop files from this repo
* Add jsinterop submodule
* In Blazor.sln, reference jsinterop projects from submodule
* Update other references to jsinterop
* Fix TypeScript warning
* Include submodules in test/pack
* Update to newer jsinterop to fix JS pack issue
* Update to newer jsinterop to obtain strong naming
* Allow jsinterop submodule to inherit Directory.Build.props/targets
* Get latest jsinterop
* For AppVeyor builds, restore git submodules (happens automatically elsewhere)
* Update README.md with instructions to restore submodules
We recommend using this package with PrivateAssets=all everywhere to
make sure that the MSBuild files brought in by this package aren't
applied to transitively.
When that happens, the Blazor.Build MSBuild files will take over the
Razor functionality for other projects, which breaks MVC's view
compilation functionality.
This is part of a fix for #1216.
This change adds the ability to merge sibling nodes when possible during
markup block rewriting. We retain that invariant that each markup block
is a valid chunk of markup containing properly nested tags.
We still haven't done any work to remove whitespace yet, so most of the
cases where this comes into play right now will merge an element with
its surrounding whitespace.
This will make sure the build script includes the ASP.NET Core runtime
when running on local .NET. The effect of this is that our test projects
and apps will 'roll forward' unto the newest runtime without us
hardcoding it.
We can't yet rely on 2.1.3 - but we can just bump up a version number when it's available.
* Reenable HtmlBlock unit tests
* Add E2E tests for HTML Block cases
* Remove harded GenerateBaselines=true
* Fix#1193
This commit addresses the root cause of #1193. When we merge HTML
text nodes into HTML blocks we need to re-encode any HTML entities that
were encoded eariler.
I did a bit of a deep dive on how HTML encoding is handled in Blazor and
I think this is the best strategy. I think it's valuable that the
BrowserRenderer uses document.createTextNode, which will always encode
the text - this handles dynamic content. We want to keep this in place
to avoid HTML injection attacks.
* Fix#1265 Reenable MarkupBlock
* test cleanup
* Change project layout to prepare for upcoming Arcade changes
* Add signtool config file to configure OPC, NuGet, and Authenticode signing
* Fix a bug when BaseIntermediateOutputPath is set to an absolute path
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.
* 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
Steve Sanderson
cores-system
Ryan Nowak
Nate McMaster
Chris Ray
Daniel Roth
Ryan Nowak
uazo
Nate McMaster
Ryouko Konpaku