This change makes our baseline system use CRLF for line endings end to
end. This isn't needed for correctness, but it helps with quality of
life when developing on OSX.
This will avoid churn to the baseline files related to line endings when
updating.
This might only take effect if you nuke the TestFiles directory and
check it out again.
* Factor out all DOM-structure modifying code into an abstraction. Currently, implementation is still backed by the same underlying DOM APIs
* Implement LogicalElement properly (store hierarchy in own property; use comment nodes as containers)
* In LogicalElement, be explicit about unsupported scenarios
* Update E2E tests to stop assuming existence of wrapper elements
* Where supported, store private properties using opaque symbols as keys
This change adds `Action` to the set of types that have an overload on
RenderTreeBuilder. Additionally, we special case `Action` in the runtime
because passing the event args via DynamicInvoke() would throw.
Finally, reverted some of the clutter introduced by the first pass of
the event handler feature.
* Update Mono to 078d5147836
* Update driver.c to match updated Mono version
* Rebuild Mono binaries
* Update dependency resolution baseline to match updated Mono BCL
* Add E2E test for new RuntimeInformation values
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.
* Improve support for more types of event handlers
Improves support for for other types of event handlers with eventargs
types derived from UIEventArgs. Additionally fleshes out the set of
event handler types.
This change improves support for using more specific event handler types
like:
```
<button onclick="@Clicked" />
@functions {
public void Clicked(UIMouseEventArgs e) { ... }
}
```
And:
```
builder.AddAttribute(12, "onkeypressed", KeyPressed);
...
void KeyPressed(UIKeyboardEventArgs e) { ... }
```
In particular what got better is:
- overload resolution for the AddAttribute method
- performance of different cases for AddAttribute
-----
The runtime now treats delegates as one of three types:
- arbitrary delegate: not attached to DOM events, not tracked by
renderer
- UIEventHandler: can attach to DOM events, tracked by renderer, first
class in IHandleEvents
- UIEventHandler-like: can attach to DOM events, tracked by renderer,
requires some special runtime support.
The set of overloads on AddAttribute has been tuned with a few specific
cases in mind.
Lambda expressions in an attribute will be inferred as UIEventHandler
unless the compiler does something more specific. So for instance,
passing a lambda as an attribute value for a component, where the
component doesn't define a matching attribute, will always be inferred
as UIEventHandler.
We now support method-group to delegate conversion for methods that
accept a derived UIEventArgs type. This means you can use a signature
like `void KeyPressed(UIKeyboardEventArgs e)` without any compiler
magic, and this will work in the runtime as long as the event type
produced by the runtime matches.
We also allow user-defined UIEventArgs-derived types. There's a pattern
for this and it requires defining an extension method and delegate type.
The method-group to delegate conversion part required some doing. It
doesn't play well with generics (Action<T> where T : UIEventArgs)
doesn't work at all. Adding more actual overloads (as opposed to
extensions) would cause lambda cases we want to work to be ambiguous.
----
The performance win here is to remove the need for a 'wrapper' delegate
created by the event handler tag helper code. This wrapper is now
created by the runtime, but only *after* we have checked the frame for
changes. This requires more heavy lifting in the runtime, but has the
advantage of producing no-op diffs as often as possible.
You will still get some inefficient behavior if your component uses a
capturing lambda in an event handler, so don't do that.
* Add selenium logs to test output
* Minor feedback
* WIP
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.
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 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.
Ryan Nowak
Steve Sanderson
Zachary Becknell
Ryan Nowak
flash2048
Olivier Lefebvre
Ryouko Konpaku
Stephen Roe
Matthew Lazarow
Benjamin
Javier Calvarro Nelson
Florian Dohrendorf
Eugene Bekker