Introduces a new primitive used by the compiler for type checking. Type
checking applies to component parameters when setting the value directly
and when using bind. This is nice because it also adds error checking
for bind.
The logic that binds event handlers was interfering with the code that
prevents component properties from receiving complex content.
This check was a little overzealous.
The problem is that the new HTML rewrite pass was traversing into
attributes of all kinds and would turn any HTML content inside those
attributes into elements where possible. The solution is to not do
that.
We weren't handling a few cases that can occur during typing correctly.
Our passes that look at the content of attributes need to be prepared
for it to be empty in cases where the attribute has been partially
typed in the editor.
I added a smoke test for this that attempts to simulate typing and found
another issue to fix.
The end result of this is that the design for this kind of code is
simpler and takes a more 'brute-force' approach to understanding
attributes. I think this is a good change based on the problems with how
this code has been written today, there are too many possible cases to
try and have the code express and document them all.
* In Blazor cshtml files, auto-import Microsoft.AspNetCore.Blazor and Microsoft.AspNetCore.Blazor.Components. Fixes#749
* Remove redundant @using directives from tests
* Update assertion in test
* Update all affected baselines
This change replaces the parsing of HTML that we perform during the code
generation phase, which parsing of HTML during the IR lowering phase.
The main benefit of this change is that the structure of the HTML is
reflected in the IR tree, allowing us to do more more advance
transformations.
As an example, see how the the handling of `<script>` tags is now a
separate pass.
As an aside from this I also redesigned the structure of component IR
nodes to match the new HTML element nodes. Passes are now more easily
aware of the nodes they are expected to handle and are more easily aware
of the difference between a component and element. This still isn't as
clean as I would like, but I think it's a reasonable improvement.
Another benefit of this is that the code generation is much simpler and
requires much less bookkeeping and statefulness.
* Before refactoring ParameterCollection assignment logic, add more test coverage
* Begin caching parameter assignment info
* Factor out some reflection code to a reusable location
* Use IPropertySetter to avoid all per-property-assignment reflection
* More error cases and tests for parameter assignment
* Enable binding to nonpublic properties
* Add analyzer to warn and provide fix for public component parameters
* Unit test for analyzer
* Component tag helper now includes private properties if they have [Parameter]
* CR feedback: Remove garbage from csproj
* CR feedback: Rename .Build.Analyzers to .Analyzers
* CR feedback: Move BlazorApi.cs to shared; use it from Analyzers test
* Fix incorrect test name
* Make as many parameters private as possible. Replace ILayoutComponent with BlazorLayoutComponent.
* In component tag helper discovery, consider private members too
* Reduce the work in component parameter discovery by not inspecting the BlazorComponent base class (or System.Object)
This change introduces ParameterAttribute to specify a bindable
component parameter. As of the 0.3 release of Blazor we plan to make
[Parameter] required to make a property bindable by callers.
This also applies to parameters when their value is set by the
infrastructure, such as `Body` for layouts, and route paramters.
The rationale behind this change is that we think there is a need to
separate the definition of properties from their suitability for a
caller to set them through markup. We plan to introduce more features in
this area in the future such as marking parameters as required. This is
first step, and we think that this approach will scale nicely as we add
more functionaly.
The 0.3 release seems like the right time to change this behavior since
we're also introducing `ref` for captures in this release.
* In Razor compilation, trim leading and trailing whitespace
* Update all unit tests to account for whitespace trimming
* Recognize that TagHelperIntermediateNode produces output too
* Skip TrimWhitespacePass during first phase of two-phase compile
* Skip TrimWhitespacePass during design-time builds
* Update baselines after rebase
The issue here is that we were missing tests for the design time code
path. We have tests that the bind-... cases work at runtime but were
missing coverage for the editor.
I took the most relevant set of the tests for running bind-... code and
added them to the tests for codegen.
This change removes support for the old syntax used for event handlers
and two-way binding.
See the relevant issues for details on the new features and
improvements:
bind https://github.com/aspnet/Blazor/issues/409
event handlers https://github.com/aspnet/Blazor/issues/503
Along with this change we've removed a few additional things Blazor
could do that aren't part of Razor's usual syntax.
----
The features that was used to make something like:
```
<button @onclick(...) />
```
is an expression that's embedded in a an element's attribute. This
feature might be useful in the future if we want to support 'splatting'
arbitrary attributes into a tag, but the runtime support for this isn't
accessible outside the Blazor core.
----
The features that implement:
```
<button onclick=@{ } />
```
have been removed in favor of a better design for lambdas, method group
conversions and other things for event handler attributes.
use `<button onclick=@(x => ...} />` instead.
We think is a better approach in general, because we want the app
developer to write and see the parameter list.
----
Both syntactic features that have been removed have dedicated error
messages in the compiler. If you're porting old code it should help you
figure out what to do.
This is the *new* and most correct feed for our developer builds.
Leaving the old ones there for now because the other ASP.NET Repos also
left them there.
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.
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.
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.
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); })" />
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 /.
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.
Ryan Nowak
Nikolei, Stefan
Steve Sanderson
Ryan Nowak
Daniel Roth
flash2048