df13669362
* 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
|
||
|---|---|---|
| benchmarks/Microsoft.AspNetCore.Blazor.Performance | ||
| build | ||
| samples | ||
| src | ||
| test | ||
| tooling | ||
| .appveyor.yml | ||
| .gitattributes | ||
| .gitignore | ||
| .travis.yml | ||
| Blazor.sln | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| Directory.Build.props | ||
| Directory.Build.targets | ||
| LICENSE.txt | ||
| README.md | ||
| THIRD-PARTY-NOTICES.txt | ||
| build.cmd | ||
| build.sh | ||
| global.json | ||
| korebuild-lock.txt | ||
| korebuild.json | ||
| run.cmd | ||
| run.ps1 | ||
| run.sh | ||
| version.props | ||
README.md
Blazor
An experimental .NET web framework using C#/Razor and HTML that runs in the browser via WebAssembly
Blazor is a .NET web framework that runs in any browser. You author Blazor apps using C#/Razor and HTML.
Blazor uses only the latest web standards. No plugins or transpilation needed. It runs in the browser on a real .NET runtime (Mono) implemented in WebAssembly that executes normal .NET assemblies. It works in older browsers too by falling back to an asm.js based .NET runtime.
Blazor will have all the features of a modern web framework, including:
- A component model for building composable UI
- Routing
- Layouts
- Forms and validation
- Dependency injection
- JavaScript interop
- Live reloading in the browser during development
- Server-side rendering
- Full .NET debugging both in browsers and in the IDE
- Rich IntelliSense and tooling
- Ability to run on older (non-WebAssembly) browsers via asm.js
- Publishing and app size trimming
Note: Blazor is an experimental project. It's not (yet) a committed product. This is to allow time to fully investigate the technical issues associated with running .NET in the browser and to ensure we can build something that developers love and can be productive with. During this experimental phase, we expect to engage deeply with early Blazor adopters like you to hear your feedback and suggestions.
To see Blazor in action, check out Steve Sanderson's prototype demo at NDC Oslo last year. You can also try out a simple live Blazor app.
Getting Started
To get setup with Blazor:
- Install the .NET Core 2.1 Preview 1 SDK.
- Install the latest preview of Visual Studio 2017 (15.7) with the ASP.NET and web development workload.
- Note: You can install Visual Studio previews side-by-side with an existing Visual Studio installation without impacting your existing development environment.
- Install the ASP.NET Core Blazor Language Services extension from the Visual Studio Marketplace.
You're now ready to start building web apps with Blazor! To build your first Blazor web app check out our getting started guide.
Build
Prerequisites:
- Node.js (>8.3)
The build script will acquire the required version of the .NET runtime and .NET SDK on first run.
Run build.cmd or build.sh from the solution directory.
Run unit tests
Run build.cmd /t:Test or build.sh /t:Test
Run end-to-end tests
Prerequisites:
- Install selenium-standalone (requires Java 8 or later)
npm install -g selenium-standaloneselenium-standalone install
- Chrome
Run selenium-standalone start
Run build.cmd /t:Test /p:BlazorAllTests=true or build.sh /t:Test /p:BlazorAllTests=true
Opening in Visual Studio
Prerequisites:
- Visual Studio 2017 15.7 latest preview - download
We recommend getting the latest preview version of Visual Studio and updating it frequently. The Blazor editing experience in Visual Studio depends on new features of the Razor language tooling and will be updated frequently.
When installing Visual Studio choose the following workloads:
- ASP.NET and Web Development
- Visual Studio extension development features
Developing the Blazor VS Tooling
To do local development of the Blazor tooling experience in VS, select the Microsoft.VisualStudio.BlazorExtension
project and launch the debugger.
The Blazor Visual Studio tooling will build as part of the command line build when on Windows.
Contributing
There are lots of ways that you can contribute to Blazor! Read our contributing guide to learn about our development process and how to propose bug fixes and improvements.