This fix adds missing line mappings for the Blazor runtime code
generation. We had the correct line mappings for design time code, but
they were missing in this case for runtime code - where they are used
for error messages and debugging (not yet supported).
Once this fix is is in the error window and output log will report the
file/line/column of the original source in .cshtml.
It looks like jumping to the code from the error window is currently not
working correctly in VS. It works from the output window.
I'm going to follow up on the VS issue in the Razor repo, since the fix
won't come from the Blazor side.
Adds conditional attributes for HTML elements.
This means that an attribute with a 'false' .NET bool value or a null
.NET value of another type will not be rendered in the HTML.
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 isn't needed anymore to support the Blazor design-time experience.
Now that it's gone, it will no longer cause conflicts with MVC's types
so we can remove the other workaround (privateassets).
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.
This reverts commit b448a5d096a27de5c8e700e43a264673de16b632.
This is because CI is currently unable to complete the signing process
so we can't upload that particular build.
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.
* Remove unnecessary <OutputType>Exe</OutputType> from templates
* Rename BlazorHosted.* projects to BlazorHosted.CSharp.(Client|Server)
* Add empty BlazorHosted.CSharp.Shared, referenced from the two other BlazorHosted.CSharp.* projects
* Have BlazorHosted.CSharp.Client fetch data from BlazorHosted.CSharp.Server
* Update templates to Blazor 0.0.5-preview1-10037
* Make date handling consistent across the templates
* Enable response compression in "hosted" template
* Enable response compression in dev server
* Simplify template app code using new namespace arrangement
* Fix project name in hosted template
MiniJSON is very small but doesn't deal with strongly-typed
deserialization by default (we can add it, but that's less
battle-tested). Also it has to allocate extra IDictionary versions of
everything before we map it to specific .NET types.
Also tried LitJSON, but has some correctness issues, e.g.,
https://github.com/LitJSON/litjson/issues/43
Also tried Json.NET but it's > 600KB
Olivier Lefebvre
Ryan Nowak
Ryan Nowak
Steve Sanderson
Grahame Horner
flash2048
Luke Latham
Ryouko Konpaku
Stephen Roe
Matthew Lazarow
Benjamin
Miha Markič
Javier Calvarro Nelson
Pranav K
Florian Dohrendorf
forest93
Daniel Roth
Alex Gavrilov