* Move startup action config into AddServerSideBlazor, so that UseServerSideBlazor is reduced to trivial shorthand that can become optional
* Make BlazorHub public so developers can use it with UseAzureSignalR
* Move BlazorHub to Microsoft.AspNetCore.Blazor.Server namespace for easier consumption
* Add notes
* Have E2E tests validate that devs don't have to call UseServerSideBlazor
* Add forgotten tweak
* CR: Document that BlazorHub methods are not intended for application use.
* CR: Rename extension method to UseSignalRWithBlazorHub
* CR: TryAdd
* 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
* Add "ilwipe" build command
* Perform BCL wipe as part of build
* Simplify by converting ilwipe command to process entire directories
* Clean up the build
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
Steve Sanderson
Ryan Nowak
Andrii Kurdiumov
cores-system
Nate McMaster
Chris Ray
Daniel Roth
Ryan Nowak
uazo
Nate McMaster
Ryouko Konpaku