Add Blazor component event handling to Blazor SSR

[gabephudson]

Is there an existing issue for this?

• [X] I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

While Blazor SSR is great, it is limited to form-based interactivity with very limited UI state management. It would be wonderful to supplement the framework so one can (optionally) enabled Blazor events (like OnClick) using SSR and HttpRequest to fire a SS event and stream in DOM changes. See solution suggestion

Describe the solution you'd like

I would love to see Blazor SSR to (optionally) support events. Think Blazor global interactive server without a WebSocket, but instead limited focused events and state transfer via HTTPRequest.

I was made aware (via the video below) of a very interesting open-source project called Hydro that does this with Razor Pages. It would be amazing if this type of functionality could be supported on Blazor SSR. It would, of course, be more limited than Interactive Server, but also be a sweet spot for scalability and dev productivity.

Bottom line, just want to expose the Blazor team to this project/idea, and see if in 10, we could get something similar baked in! https://www.youtube.com/watch?v=CwZjQJHwHbQ https://github.com/hydrostack/hydro/

Additional context

No response

[javiercn]

@gabephudson thanks for contacting us.

We contemplated this in the original design; however, this adds more complexity to the already complex landscape of blazor working modes.

To do this right also, it either requires that we significantly change the markup that gets generated for SSR code to introduce forms that post to the server so we handle the event (works even without JS) or that we require JS for this to work, at which point it makes sense to just rely on Blazor Server.

This likely is achievable too with a component and JS can be used if you want to extract event data and post it along the form.

[gabephudson]

@javiercn, thank you for taking a look. Reviewing the Hydro framework, they indeed use JS (httprequest) to call SS functions and fill in the DOM. As part of this, they also send the component's state as part of the request.

I LOVE Interactive Server and it's my default choice for applications that I know that don't need to scale up to a huge user count. It's a huge win for developer productivity and greatly simplifies complexity and layers needed to build a web application (thus reducing bugs). That said, as you know, it does have the following limitations when it comes to scaling...

• Shadow DOM memory for each user must be maintained on server
• A WebSocket connection per user must be maintained on server
• Because of the above, server affinity must be maintained
• Long disconnects cause the above to be recycled, impacting user experience

In my experience, it works great for all but the largest public apps that have many thousands of simultaneous users. That said, many dismiss it because they think it won't scale. ((Side note, I think there needs to be better messaging about this. Devs are throwing out the baby with the bathwater because they are scared about scaling which, in most cases, they won't ever need).

In addition. when developing Blazor, SSR and Interactive rendering are completely different beasts when it comes to any form of interactivity/events/state management. My thought is to introduce a limited form of event handling and ui state (viewstate, lol) using a methodology similar to what is being used in this Hydro framework to make SSR support common Blazor event models, allowing for better scaling and a more consistent development experience (and productivity) when using SSR.

I would love to see MS dogfood ASP.NET and Blazor more than it has been doing. I know this would result in more rapid innovation in Blazor. Because of MS scope and size, I would assume Interactive Server would never be dogfooded for a public app by MS. That said, an approach like the above may allow for rich developer experience, interactivity, and scaling (without having to go back to form submits).

Anyway, all I can do is pass this project along and ask the team to review it for inspiration and see if it makes sense. No doubt it would be an undertaking, but would bring SSR development much closer to the Interactive modes.

Again, thanks for your response and appreciate the feedback. Love Blazor and its evolution has been great. Appreciate the ASP.NET/Blazor team at MS. Lets chip away at React with the Blazor sledgehammer. ;)

[Johnhersh]

((Side note, I think there needs to be better messaging about this. Devs are throwing out the baby with the bathwater because they are scared about scaling which, in most cases, they won't ever need).

I'll note that I failed in selling my team on Blazor not because of scalability (though they added "...and who knows if it'll scale" for good measure), but the websockets were the major hangup. Seeing the disconnect message at the top is just not something anyone wants to deal with. Chrome closes the connection if the tab is in the background. Or if you're doing mobile and switch from wifi to mobile, etc. It's not even that bad honestly but just not something anyone wants to deal with. Like the idea of the circuit being server-side and even a simple UI toggle is a server round-trip is just very unappealing to people.

The upside of not having to worry about endpoints anymore is grand. I love it. But it feels like it should be doable with http requests and not have the web socket issues.