-
Notifications
You must be signed in to change notification settings - Fork 10.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API Proposal: AllowInteractiveRoutingAttribute for Blazor #55204
Labels
api-approved
API was approved in API review, it can be implemented
area-blazor
Includes: Blazor, Razor Components
Milestone
Comments
halter73
added
the
api-suggestion
Early API idea and discussion, it is NOT ready for implementation
label
Apr 18, 2024
dotnet-issue-labeler
bot
added
the
area-blazor
Includes: Blazor, Razor Components
label
Apr 18, 2024
halter73
added
api-ready-for-review
API is ready for formal API review - https://github.com/dotnet/apireviews
and removed
api-suggestion
Early API idea and discussion, it is NOT ready for implementation
labels
Apr 18, 2024
Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:
|
API review notes:
API Approved! // Microsoft.AspNetCore.Components.dll
namespace Microsoft.AspNetCore.Components;
+ [AttributeUsage(AttributeTargets.Class, AllowMultiple = false)]
+ public sealed class ExcludeFromInteractiveRoutingAttribute : Attribute
+ {
+ }
// Microsoft.AspNetCore.Components.Endpoints.dll
namespace Microsoft.AspNetCore.Components.Routing;
+ public static class RazorComponentsEndpointHttpContextExtensions
+ {
+ public static bool AcceptsInteractiveRouting(this HttpContext context)
+ } |
halter73
added
api-approved
API was approved in API review, it can be implemented
and removed
api-ready-for-review
API is ready for formal API review - https://github.com/dotnet/apireviews
labels
Apr 18, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
api-approved
API was approved in API review, it can be implemented
area-blazor
Includes: Blazor, Razor Components
Background and Motivation
The original feature goal was “Allow static SSR pages within a globally-interactive site” but after a lot of circling around designs, we distilled this down to just one very tiny framework feature that isn’t actually anything to do with rendermodes at all. It turns out people can already do everything they would want in user code, except for one thing: once the site is running with an interactive router, escape from the interactive routing when navigating to specific pages.
So conceptually, the new feature is: have a way for component endpoints (i.e., Blazor “@page” components in a Blazor Web app) to opt out from being seen by interactive routing. The interactive router acts as if those pages don’t exist, so if you do follow a link to them, it will behave as an external navigation and does a full-page reload.
PR: #55157
Proposed API
Behavior: the built-in component sees this and excludes any such pages from its route table, so any navigations to those URLs aren’t resolved via client-side navigation and instead fall back on a full page load.
Usage Examples
This is just a shorthand for convenience. Technically developers could already read endpoint metadata and see whether AllowInteractiveRoutingAttribute is there, but it’s several lines of messy code with lots of null-coalescing, and this reduces it to something much simpler and more convenient.
Normal usage in a statically rendered routable component:
Normal usage example in App.razor:
However that’s only one of many possibilities. Developers could write arbitrary code to select rendermodes any way they like – it could vary by the page URL or by the current browser type or anything else they like.
Alternative Designs
We could implement an end-to-end “static SSR pages in global interactivity” feature so that no App.razor logic is are required. However after a lot of design discussions we decided that’s a bad idea because it ends up being tied to particular architectural patterns instead of being a general, low-level, composable feature.
Or we could introduce a completely new “StaticSSR” rendermode, but that is massively more involved and opens up many other scenarios where people can get confused and think things will behave differently than they will (e.g., trying to use StaticSSR rendermode on things other than page components). And even if we did that it wouldn’t avoid the need to have special logic for it in App.razor equivalents, otherwise the root would already set an interactive rendermode that can’t be changed by the page.
The team has already been through quite a few iterations here so we’re reasonably confident on the conceptual approach.
Risks
It still leaves developers to copy/paste something from docs like the “PageRenderMode” expression above, as they are unlikely to figure out an end-to-end solution on their own here. However, we still prefer this because it avoids tying us to specific architectural patterns or introducing much broader new concepts.
The text was updated successfully, but these errors were encountered: