Implement support for routable Razor Components
Figure out what if anything we want to do to align with endpoint routing
My expectation is that we create some way to define a server-side endpoint that prerenders a single specific component within a server-side (MVC-style) layout.
The server-side layout may choose to include a <script src="[...]blazor.server.js"> tag, in which case the client will open a circuit back to the server to commence interactivity, overwriting the prerendered content with live content as soon as the circuit is opened. Or the server-side layout may choose not to include that tag, in which case you have pure prerendering (non-interactive).
The typical use case would be to render a <Router> component, because that would automatically pick out and render whatever other combination of (client-side) layouts and components corresponds to your URL based on @page and @layout directives. However, developers are free to render other arbitrary Razor Components if they want, independently of <Router>.
The reason to prefer this design, rather than the more complex design of creating endpoints for each component with a @page directive, is that it cleanly replicates the same behavior whether you're executing server-side or client-side. It keeps us in a position where apps are (by default) switchable between server-side and client-side execution.
Note: #4044 has to be done before this.
What is left here is to add some sort of SPA route constraint / endpoint routing to better support client side routing.
@rynowak I think your work https://github.com/aspnet/AspNetCore/pull/8052 covers this. Doesn't it?
@rynowak, based on your last change as well as @javiercn 's comment above we believe this work is done. If this is not correct, please reopen.
Most helpful comment
My expectation is that we create some way to define a server-side endpoint that prerenders a single specific component within a server-side (MVC-style) layout.
The server-side layout may choose to include a
<script src="[...]blazor.server.js">tag, in which case the client will open a circuit back to the server to commence interactivity, overwriting the prerendered content with live content as soon as the circuit is opened. Or the server-side layout may choose not to include that tag, in which case you have pure prerendering (non-interactive).The typical use case would be to render a
<Router>component, because that would automatically pick out and render whatever other combination of (client-side) layouts and components corresponds to your URL based on@pageand@layoutdirectives. However, developers are free to render other arbitrary Razor Components if they want, independently of<Router>.The reason to prefer this design, rather than the more complex design of creating endpoints for each component with a
@pagedirective, is that it cleanly replicates the same behavior whether you're executing server-side or client-side. It keeps us in a position where apps are (by default) switchable between server-side and client-side execution.