Adds support for 'Context' parameters on components
This change allows you to set the parameter name of a parameterized child content by using the `Context` attribute on the component. The `Context` attribute will be defined (and shown by completion) when the component has one or more declared parameterized (`RenderFragment<>`) child content parameters.
This is nice for cases where you are using implicit child content:
```
<ol>
<Repeater Items="People" Context="person">
<li>@person.FirstName</li>
</Repeater>
</ol>
```
or, when you have multiple child content elements and want them all to have the same parameter name:
```
<MyComponent Items="People" Context="person">
<ChildContent1><div>@person.FirstName</div></ChildContent1>
<ChildContent2><div>@person.LastName</div></ChildContent2>
</Repeater>
```
The parameter name can be overridden by using the `Context` parameter on the child content element:
```
<MyComponent Items="People" Context="person">
<ChildContent1 Context="item"><div>@item.FirstName</div></ChildContent1>
<ChildContent2><div>@person.LastName</div></ChildContent2>
</Repeater>
```
If the component defines a `Context` parameter already then we won't synthesize one - your component's parameter will work exactly as it did before this feature.
* Fix#1298
This change lifts our Razor dependencies to 2.1.1. This is needed
because by default ASP.NET Core projects will depend on 2.1.1 - which
results in a conflict trying to use the Blazor compiler. The Blazor
compiler will load the 2.1.0 msbuild tasks, which then break loading the
2.1.1 tasks.
Since this is happening in the MSBuild process, we can't really write
any code to sort this out. We have to make sure the versions match.
In general the guidance for ASP.NET Core is that projects will **compile
against** 2.1.1 so this won't be a problem in the future unless a user
project specifically lifts ASP.NET Core to a higher version. If that's
the case they will also have to live `Microsoft.AspNetCore.Razor.Design`
to match.
We weren't correctly recovering when a void element is written as a
start-end pair. This change cleans up some of the plumbing around
end-tag handling and adds recognition for this case.
Added a new bespoke diagnostic for the void element case.
This change skips our 'temp' compilation that we do to implement 2-phase
build for defining components in .cshtml when the project is not C# OR
when the project has no .cshtml files.
This should make the rest of the build-time Blazor functionality work
for non-C# projects.
This should also make the build faster when you have the Blazor targets
imported in a C# project with no .cshtml files.
This change allows you to use generic-typed components without
explicitly specify type arguments.
**Before:**
```
<Grid Items="@MyItems" TItem="Person">
...
</Grid>
```
**After:**
```
<Grid Items="@MyItems">
...
</Grid>
```
Where possible, the type of the component will be inferred based on the
values passed to component parameters. This won't work like magic, you
have to specify parameters that provide type arguments for all of the
component's type parameters.
This is a best effort system, and it's largely based on the limitations
and behaviours of generic type inference in C#. We think it will work
well with most Blazor features and for most reasonable components. You
should not forget it's easy to specify type arguments, because you may
still have to in some cases.
In particular you may notice issues if you are trying to use a generic
typed component where all of the parameters are delegates or templates.
Type inference for delegates/lambdas in C# is based on the context. Any
time you combine generics and delegates it's easy to get into a scenario
where the compiler won't infer the correct type, or will give up.
----
The type inference feature works by generating a 'thunk' method in
*caller* that can act as a site for type inference (C# does not support
inference on constructors).
For our grid example above, the non-inferenced code will look something
like:
```
builder.OpenComponent<Grid<Person>>(0);
builder.AddAttribute(1, "Items", MyItems);
builder.CloseComponent();
```
Note that we can only write the type `Grid<Person>` because you wrote
`Person` in your code. What you type in the `TItem` attribute value gets
inserted into the generated code such that it fills in the generic type
parameter.
On the other hand, if you want is to infer the type, we have to do some
compiler magic. That looks like:
```
__Blazor.(long generated name).TypeInference.CreateGrid_0();
...
// elsewhere in the file
internal static class TypeInference
{
public static void CreateGrid_0<TItem>(RenderTreeBuilder builder,
int seq, int __seq0, global::System.Collections.Generic.List<TItem>
__arg0)
{
builder.OpenComponent<Grid<TItem>>(seq);
builder.AddAttribute(__seq0, "Items", __arg0);
builder.CloseComponent();
}
}
```
This allows us to rely on the C#
compiler for itype inference.
* Fix wiping assemblies that contain references to others in same directory
* Fix generated IL for reporting calls to wiped methods
* Add E2E test for method wiping
* Add the ability to discover generic types/properties
* Add @typeparam directive
Adds the ability to declare a generic-typed component using Razor.
* Add a 'type parameter' property to generic components
* Adds the ability to consume generic-typed components
* 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.
Steve Sanderson
Nate McMaster
Ryan Nowak
KristianJakubik
Howard Richards
Suchiman
Andrii Kurdiumov
cores-system
Chris Ray
Daniel Roth
Ryan Nowak