This change adds support for mapping DOM event handlers as tag helpers
that function in a bi-modal way.
This is a new first-class feature for DOM events, and replaces a few
workarounds like using `@onclick(...)` or `click=@{ ... }`. I haven't
removed those things yet, this is a first pass to get the new support
in, we'll remove those things when we're totally satisfied.
When used with a string like `<button onclick="foo" />` the result is
a simple HTML attribute .
But when used with an implicit expression like
`<button onclick="@Foo" />` or
`<button onclick="@(x => Clicked = true)" />` a C# function is bound to
the click event from the DOM.
This was not possible before because of the
`Microsoft.NET.Sdk.Razor/2.1.0-preview2-30230` entry in `Sdk`, which
can't be loaded from a custom restore source. But since that's on
NuGet.org now, it's no longer a problem.
Ports somee infrastructure and converts Razor code generation tests to use
it. This makes it much easier to make cross cutting changes to code
generation and see the effect.
Use build /p:GenerateBaselines=true to update all of the generated code
in place or when adding new tests. Generally if tests are failing, the
easiest thing to do is to update the baselines and do a git diff to see
what the deltas are.
The changes to the tests here are to use the new baseline infrastructure
and to rename classes/methods to result in shorter file paths.
Trying to replace the internal "." folder with the local assembly path in order to have an absolute path for the PhysicalFileStorage class at startup ("The path must be absolute" error at startup for published projects)
May resolve the issue of #376 on dev
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 should now correctly require VS 15.7-preview1 or newer with the
ASP.NET and web development tools to installed.
Removed the Razor Language Servcies dependency since it's prompting an
install of the wrong tools from the VS gallery.
Ryan Nowak
chassq
Daniel Roth
flash2048
Steve Sanderson
Guillaume ZAHRA
Austin Cummings
Olivier Lefebvre
Ryan Nowak
Grahame Horner
Luke Latham
Ryouko Konpaku
Stephen Roe
Matthew Lazarow
Benjamin
Miha Markič
Pranav K
Javier Calvarro Nelson