Closed anorborg closed 11 months ago
Check this repository description
@Hellevar, looks interesting, though you'd still be making the decision based on your first request. Perhaps you could wrap the logic a bit, but I'm not sure you could start the app running server side and simultaneously prepare and switch over to wasm when ready.
I don't personally have much interest in the client-side mode (doesn't seem like a good fit for enterprise dev, which is where I live now, and I'm not a fan of the slower pace of Xamarin), but it seems to me this could only work if the server side ran wasm, which might make it easier to transfer state to the client when your code decides to switch.
Otherwise what you propose would seem to require the ability to transfer state from the completely-different .NET Core-based runtime to the Xamarian runtime, which sounds unlikely.
Also bear in mind there are three more Blazor rendering models already in the pipeline (Electron, PWA, full-native)...
We've moved this issue to the Backlog milestone. This means that it is not going to happen for the coming release. We will reassess the backlog following the current release and consider this item at that time. However, keep in mind that there are many other high priority features with which it will be competing for resources.
This goes much further than the OPs request.
We need single deployments that can contain BOTH Blazor client side and server-side.
For example, recently ran into an issue in Bazlor WASM, so I need to change this component from client side to server side until I can work out a resolution. It is ridiculous to have to have two separate projects and have to move the component between the two!
We live in a production environment here not a test one. Options to move things around easily are VITAL for keeping a production system running.
There is NOTHING technically stopping both models from being supported in the same project. Please allow it urgently.
We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.
I'm building a solution that uses server-side blazor at first while loading wasm blazor in the background, and when wasm resources are ready, switch the server-side blazor to wasm blazor at the runtime. I can already achieve switching hosting model at the runtime, but I am struggling with keeping the previous states (both the application states and render tree) after switching. I hope blazor can add support for passing states and render tree from server to client and applying them to the client.
Thanks for your patience, everyone. I assume the new Auto render mode is exactly what you were looking for, isn't it, @anorborg: https://learn.microsoft.com/aspnet/core/blazor/components/render-modes?view=aspnetcore-8.0
Closing this as completed then. Please feel free to open a new issue if I've missed something.
Is your feature request related to a problem?
I would like to host my blazor application differently depending on client attributes and needs, but it appears I must choose between server or client.
Describe the solution you'd like
Ideally it would be interesting to have a bootstrap step on the initial load that can decide whether to run the application in server-side mode or wasm mode from the client. For instance, perhaps I check a
localstorage
variable to see if I have already loaded the version of the wasm bundle I need. If so, I'll go ahead and run as wasm, otherwise I can choose to run as server-side for a quicker startup.In addition, if I choose to run server-side, I can also choose to request the wasm hosting bundle in the background. The idea being, while the client is up and running on the server-side hosting, the application is preparing itself to be able to switch to wasm mode once all the resources are downloaded.
The end result is an attempt for a best-of-both-worlds scenario. You get the speed of a quick server-side startup and the flexibility of a full wasm hosted application without changing the experience for the user.