This change introduces a 'tag helper' that replaces @bind with custom
code generation that accomplishes roughly the same thing.
This feature lights up by dynamically generating tag helpers that are
visible to tooling and affect the code generation based on:
- pattern recognition of component properties
- attributes that create definitions for elements
- a 'fallback' case for elements
'bind' also supports format strings (currently only for DateTime) via
a separate attribute.
This change introduces the basic framework for bind and tooling support.
We know that we'll have to do more work to define the set of default
'bind' cases for the DOM and to flesh out the conversion/formatting
infrastructure.
This change gets us far enough to replace all of the cases we currently
have tests for :) with the new features. The old @bind technique still
works for now.
Examples:
@* bind an input element to an expression *@
<input bind="@SelectedDate" format="mm/dd/yyyy" />
@functions {
public DateTime SelectedDate { get; set; }
}
@* bind an arbitrary expression to an arbitrary set of attributes *@
<div bind-myvalue-myevent="@SomeExpression">...</div>
@* write a component that supports bind *@
@* in Counter.cshtml *@
<div>...html omitted for brevity...</div>
@functions {
public int Value { get; set; } = 1;
public Action<int> ValueChanged { get; set; }
}
@* in another file *@
<Counter bind-Value="@CurrentValue" />
@functions {
public int CurrentValue { get; set; }
}
This change removes the magic 'auto-lambda' feature that has some
unconvincing UX.
Also working around a razor bug where explicit expressions are lowered
incorrectly. This should make it possible to write code like:
<Foo Bar="@(e => { OnChanged(e); })" />
* Updates the router component to scan for components within assemblies.
* Parses the templates on `[Route]` in component instances and builds a
route table that maps paths to components.
* Uses the route table to map paths to components.
* On build, drop <BlazorPackageContentFiles> items into dist\_content\(PackageName)\
* Add <script> and <link> tags to generated index.html
* Add testapp coverage of external content package. Still need to add E2E tests that uses it.
* Add missing unit test update
* Add example of packaging an entire Blazor component including CSS and images
* Add E2E test for component from NuGet package
Adds the @page directive and support for specifying routes in components
at compile time.
For now the route is required and must begin with a leading /.
* Switch the tasks used to generate the blazor output to be MSBuild based.
* Package the optimized mono runtime and the BCL inside a nuget package.
* Add opt-in support for linking the application on build.
* Make the whole build process incremental.
This removes a limitation that prevented callers from passing
attributes to a component that aren't backed by properties.
The majority of the complication here is required to deal with the more
sophisticated way that HTML attributes are represented in the Razor IR.
This builds upon existing support for UIEventHandler-typed component
properties and applies the same principle to any delegate type.
We try to help by generating the LSH of the lambda `=>` allowing you to
write `OnClick="Foo()"` rather than `OnClick="(e) => Foo()"`. You can of
course use @ as an escape.
The only rough edge here is that if the parameter names aren't memorable
for the delgate type, it's not super helpful.
Implements Component code generation and tooling support end to end
udditionally adds some default `@addTagHelper` directives to make
programming in Blazor a little nicer.
Components are discovered as Tag Helpers using Razor's extensibility
during the build/IDE process. This drives the code generation during
build and lights up a bunch of editor features.
Add
This is a working (all tests passing) implementation of the two-phase
compilation system we will need for component discovery.
This builds on top of work we've doing in Razor, including the Razor
SDK, MSBuild tasks, and CLI/server.
This currently *does* discovery components during the build process, but
it doesn't use that data for anything yet.
It works like this:
1. Generate class declarations (structure only, no method bodies)
2. Compile a 'temp' assembly using the .cs files and output of 1.
3. Do component discovery using the 'temp' assembly
4. Generate class definitions (including method bodies)
5. Compile the 'real' assembly using the .cs files and output of 4.
Adds a little more use of Razor extensibility.
Razor is a plugin model, so we can't be the 'first mover' for initiating
compilation in the build tools and IDE.
Reorganizes tests and fills out more reusable test infrastructure for
Razor-driven testing.
Adds tests for declaration-only configuration.
Steve Sanderson
Ryouko Konpaku
Stephen Roe
Ryan Nowak
flash2048
Matthew Lazarow
Benjamin
Javier Calvarro Nelson
Ryan Nowak
Florian Dohrendorf