Update Blazor (ASP.NET Core Hosted) project template so that it is easy to toggle between client-side and server-side Blazor #6882
Assignees
Labels
area-blazor
Includes: Blazor, Razor Components
Done
This issue has been fixed
enhancement
This issue represents an ask for new feature or an enhancement to an existing one
Needs: Design
This issue requires design work before implementating.
Needs: Spec
Indicates that a spec defining user experience is required
Milestone
Comments
danroth27
added
1 - Ready
enhancement
danroth27
added
the
Needs: Design
mkArtakMSFT
added
Needs: Spec
mkArtakMSFT
assigned ryanbrandenburg and rynowak and unassigned danroth27 and ryanbrandenburg
rynowak
pushed a commit
that referenced
this issue
Apr 17, 2019
This design concept splits up UseBlazor into a usage of static files and a usage of MapFallback. --- I ignored auto-rebuild support because it's currently dead code until we have that in VS. If we add auto-rebuild to ASP.NET Core - we'd probably want to make that a separate gesture inside `IsDevelopement()` like other dev-time features anyway. --- The static-files wireup is pretty thick, and comes with some caveats. This requires you to use the StaticFiles middleware without passing in an explicit options instance. This gives us parity with what we're doing for server-side, but it still gives me a bit of pause. Note that this supports multiple calls to include multiple projects. Another approach would be to make a separate `UseClientAppFiles()` middleware. This wouldn't be quite so fragile. Basically the approach in the PR optimizes the Startup code being simpler but requiring a little more explanation. We could optimize the other way by making an explicit middleware. --- I feel pretty good about the wireup with routing to use the `index.html` from the client app. I think it's pretty to-the-point.
rynowak
pushed a commit
that referenced
this issue
Apr 18, 2019
This changes the recipe for client-side blazor to use similar primitives to server side applications. --- I ignored auto-rebuild support because it's currently dead code until we have that in VS. If we add auto-rebuild to ASP.NET Core - we'd probably want to make that a separate gesture inside `IsDevelopement()` like other dev-time features anyway. --- The static files hookup is a special thing because creating the file server for a client-side Blazor app involves some non-trivial work. We plan to make this better in the future. What's nice about this pattern is that the implementation is pretty simple and literal, and it scales fine if you have multiple Blazor client-side apps. I didn't provide a lot of options here, it's pretty much the same as UseBlazor. --- I feel pretty good about the wireup with routing to use the `index.html` from the client app. I think it's pretty to-the-point.
|
@rynowak looks like you are going this direction. (One configuration for both client and sever side) Gives the ability to select client-side or server-side Blazor at run-time without recompiling. This allows the same server to handle either type of client. The default usage is first visit the client operates server-side second-visit when all is cached it switches to client side. But all kinds of logic could be put in this to determine dynamically where is the best user experience. https://thefreezeteam.com/razor-components-dynamic-dual-mode/ This is a very nice use case that I just hope we can maintain :) |
rynowak
pushed a commit
that referenced
this issue
May 3, 2019
This changes the recipe for client-side blazor to use similar primitives to server side applications. --- I ignored auto-rebuild support because it's currently dead code until we have that in VS. If we add auto-rebuild to ASP.NET Core - we'd probably want to make that a separate gesture inside `IsDevelopement()` like other dev-time features anyway. --- The static files hookup is a special thing because creating the file server for a client-side Blazor app involves some non-trivial work. We plan to make this better in the future. What's nice about this pattern is that the implementation is pretty simple and literal, and it scales fine if you have multiple Blazor client-side apps. I didn't provide a lot of options here, it's pretty much the same as UseBlazor. --- I feel pretty good about the wireup with routing to use the `index.html` from the client app. I think it's pretty to-the-point.
rynowak
pushed a commit
that referenced
this issue
May 6, 2019
This changes the recipe for client-side blazor to use similar primitives to server side applications. --- I ignored auto-rebuild support because it's currently dead code until we have that in VS. If we add auto-rebuild to ASP.NET Core - we'd probably want to make that a separate gesture inside `IsDevelopement()` like other dev-time features anyway. --- The static files hookup is a special thing because creating the file server for a client-side Blazor app involves some non-trivial work. We plan to make this better in the future. What's nice about this pattern is that the implementation is pretty simple and literal, and it scales fine if you have multiple Blazor client-side apps. I didn't provide a lot of options here, it's pretty much the same as UseBlazor. --- I feel pretty good about the wireup with routing to use the `index.html` from the client app. I think it's pretty to-the-point.
|
Will this enable server side prerendering for Blazor Client Side app? |
mkArtakMSFT
added
Done
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
and others
The work that remains here is to break up
UseBlazorinto more parts so that it looks similar to the patterns for server-side.The text was updated successfully, but these errors were encountered: