* Rename Microsoft.AspNetCore.Blazor dir to .Components
* Rename Microsoft.AspNetCore.Blazor.Browser dir to .Components.Browser
* Rename Microsoft.AspNetCore.Blazor.Browser.JS dir to .Components.Browser.JS
* Rename Microsoft.AspNetCore.Blazor.TagHelperWorkaround dir to .Components.TagHelperWorkaround
* Unbreak signing
* Rename Microsoft.AspNetCore.Blazor.Analyzers dir to .Components.Analyzers
* Rename Microsoft.AspNetCore.Blazor.Server dir to .Components.Server
* Rename Microsoft.AspNetCore.Blazor.Razor.Extensions dir to .Components.Razor.Extensions
* Rename Microsoft.AspNetCore.Blazor.Build dir to .Components.Build
* Rename Microsoft.AspNetCore.Blazor.Test dir to .Components.test
* Rename Microsoft.AspNetCore.Blazor.Server.Test dir to .Components.Server.Test
* Rename Microsoft.AspNetCore.Blazor.Razor.Extensions.Test dir to .Components.Razor.Extensions.Test
* Rename Microsoft.AspNetCore.Blazor.Analyzers.Test dir to .Components.Analyzers.Test
* Rename Microsoft.AspNetCore.Blazor.Browser.Test dir to .Components.Browser.Test
* Rename Microsoft.AspNetCore.Blazor.Build.Test dir to .Components.Build.Test
* Rename Microsoft.AspNetCore.Blazor.E2ETest dir to .Components.E2ETest
* Fix typo
* Unbreak VSIX build
* Fix .Build unit tests
* Move Blazor benchmarks into blazor subdir
* Rename .Blazor.Performance dir to .Components.Performance
* Move some samples within .sln
* Move StandaloneApp sample to blazor subdir
* Move MonoSanity sample to blazor subdir
* Move HostedInAspNet sample to blazor subdir
* Update paths to samples
* Move .BuildTools and .Cli sources to blazor subdir
* Move tooling to blazor subdir
* Move templates to blazor subdir
* Restore Directory.Build.props behaviors in blazor\src
* Move mono to blazor subdir
* Update folder structure in .sln
* Fix VSIX
* Empty commit to reawaken CI
* Fix manual standalone app startup
* Marshal oninput events as UIChangeEventArgs
- Blazor does handle the oninput event, but it is marshalled as a regular UIEventArgs
- This means that we cannot access the new value of the input element from inside our oninput handler
Addresses #821
There are legitimate use cases for referencing BCL assemblies that *aren't* in the Mono WebAssembly BCL, particularly for Blazor-on-the-server which runs on CoreCLR (and hence supports a broader BCL) anyway.
* Add Provider component
* Implement discovery and matching rules for tree parameters
* Remove artificial component hierarchy unit tests now they are redundant
* Refactor: Have RenderTreeFrame point to the ComponentState instead of IComponent
... so we can more quickly find associated tree param state without having to do lookups based on the componentId.
Also rename AssignComponentId to AttachAndInitComponent to be more descriptive.
* Refactor: Add shared code path for updating parameters so there's only one place to attach tree parameters
Now framework code should no longer call IComponent.SetParameters directly, except if it knows it's definitely dealing with a root component.
* Refactor: Simplify Parameter by making it hold the name/value directly
This will be necessary for tree parameters, which don't correspond to any RenderTreeFrame
* Refactor: Wrap ParameterEnumerator logic in extra level of iterator so we can also add one for iterating tree params
* Extend ParameterEnumerator to list tree parameters too
* Include tree parameters in SetParameters calls
* Refactor: Move parameter change detection logic into separate utility class
... so we include https://github.com/dotnet/jsinterop/pull/3
* Refactor: Move tree parameter tests from RendererTest.cs their own file
* Have Provider re-render consumers when value changes. Unit tests in next
commit.
* Components that accept tree parameters need to snapshot their direct params for later replay
* Empty commit to reawaken CI
* CR: Make name matching case-insensitive
* Refactor: Rename Provider/TreeParameter to
CascadingValue/CascadingParameter
* Add dedicated [CascadingParameter] attribute. Remove FromTree flag.
* CR: CascadingParameterState cleanups
* CR: Extra unit test
* CR: arguments/parameters
* CR: Enumerator improvements
* Fix test
* remove sources.props and use NuGet.config. Source.props is only necessary for products that bulid in ProdCon, which Blazor does not
* Remove code signing glue code. This is part of KoreBuild now
* Update SDK to 2.1.400
* Update certificate names used for code-signing to use SHA2
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.
Steve Sanderson
Daniel Roth
Adrian Wright
Jeremy Hutchinson
Suchiman
Meir Blachman
Lukas Bickel
Zou Wei
alenros
simpman4
Ryan Nowak
Nate McMaster
KristianJakubik