* Handle links to empty-string href, resolved against base href
Needed to change the URLs used in E2E tests to be able to cover this (i.e., removed the /RouterTest prefixes so the default relative URL became an empty string)
* Change links in StandaloneApp sample to be relative
* Standardize on base URIs having trailing slash everywhere
Hence also change terminology from "base URI prefix" to simply "base URI"
* Handle link highlighting when visiting base-href-but-without-trailing-slash
* Removing leading slashes from base-relative URLs in templates
* 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
* Add camelCase utility
* Use camelCase when JSON-serializing (but not for dictionary keys)
* Make JSON deserialization treat member names case-insensitively (but retain case on dictionary keys)
* Use camelCase in JSON in the samples and templates
* Reverse the order of the params for the camelcase test because it's weird otherwise
* CR feedback
* 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.
* Upgrade to bootstrap v4
Remove redundant MIME type
* Add new styling to StandaloneApp
* Update THIRD-PARTY-NOTICES.txt
* Update version of Blazor used by templates when running from source
* Update styling on BlazorStandalone.CSharp template
* Tweak brace style
* Update styling in BlazorHosted.CSharp template
* Update E2E tests that rely on specific CSS
* Add Open Ionic fonts license to notices too
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.
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).
* 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.
* 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 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.
Steve Sanderson
Ryan Nowak
Luke Latham
Javier Calvarro Nelson
Ryan Nowak
Eugene Bekker