We are moving to Blazor .net 8 server side SSR and we may also turn on auto mode for wasm cached features.
I believe Radzen will work fine under SSR (websocket connection) or Wasm or Auto mode for .net 8 RC1? I believe the answer is yes.
On the other hand, what radzen components "require" SSR, Was or Auto? For example, RadzenGrid has some interactivity which probably needs to work, maybe tooltip service needs it or perhaps it's in the Radzen JS runtime, maybe RadzenBadge can work static.
Is there a list of required rendering modes for Radzen Components? If there isn't a list, would it be a good idea to provide that type of information on the Radzen Component documentation ... or is it a situation where once you turn on SSR or Wasm or Auto, there is no benefits isolating static control? I get a little confused when Microsoft says to build a component for static first, and turn on other rendering modes if needed...like this saves on performance for that component???
The ask here is if Radzen Components have a list of required render modes for .net 8 blazor? If not, would it be a good idea if that was documented?
thanks
Rob
Radzen Blazor Studio Professional owner
1 Like
I want to clarify that SSR was possible before .NET 8 by using this approach. We have used this with success in blazor.radzen.com and it is enabled by default for all WASM applications created with Radzen Blazor Studio. Also be aware of this PR which changes a lot of the rendermode API - it seems that the API in RC1 will not be the final one.
Every Blazor component which has any form of interactivity (fires events in response of user actions) requires a different rendering mode than static - server, wasm or auto. This includes most of of the Radzen.Blazor components. For example paging, sorting, filtering, selection, grouping are some features of RadzenDataGrid that won't work in static mode. The component will render just fine and look OK but no form of interactivity will be available. Some components that don't offer interactivity and will work without any limitations in static rendering mode are:
- RadzenCard
- RadzenRow
- RadzenColumn
- RadzenText
- RadzenBadge
- RadzenIcon
- RadzenImage
- RadzenStack
- RadzenBreadCrumb
- RadzenLink
- RadzenAlert (without the close button which requires interactivity)
- RadzenProgressBar
The simple rule of thumb is to answer the following questions:
- Is the component I plan to use interactive - does it change its state depending on user actions?
- Do I need this interactivity in my application?
If the answer to both is yes then you need to use this component with a rendering mode which is not static.
We believe it is the application developer's responsibility to decide what rendering mode they need and why. If they want interactivity they should set the render mode (and consider all limitations of doing that - for example not being able to have child content).
The simple answer is that every component that has interactivity needs a render mode which is not static. Of course if you need that interactivity - you can still render dropdowns that don't open, or buttons that do not fire click events.
3 Likes
many thanks for the response. If Radzen could support wasm caching options, I think that would be a big win because some of the reservations on our side is losing the socket connection and QA support on wasm caching. If Radzen supported wasm caching, then we are left with our own components to manage under wasm caching which need interactivity.
It's interesting how we are now viewing the world between static and interactive to increase performance.
1 Like
I don't know what wasm caching options is. Can you elaborate?
We have a scenario with Hyperscript/Htmx for static rendering, and we could have a mix of Radzen static components along with isolated islands of wasm for Radzen Listbox, DataGrid, etc... It appears the other "auto" scenario where a wasm component was used and cached is off the table. Under this new scenario, it looks like we would strictly decide what was static and Radzen static components could be used. But for interactive situations like a chart, RadzenChart would be used as a wasm component. The goal is not to have an open web socket due to the user experience of a dropped/ended web socket.
As far as I know there is never an open web socket with Blazor WASM. Even before .NET 8.
The approach currently being taken is htmx for static areas, and wasm for interactive. We are setting WebAssembly prerender to false. Our static Radzen components work anywhere, our interactive radzen components are wrapped in a wasm widget, and we are expanding our UI library to include htmx controls like for a button to allow for static support.
@attribute [RenderModeWebAssembly(prerender:false)]
In the example below, I took the code for the RadzenButton and added htmlx properties:
I think I can use a where the dictionary is the hx-get and hx-target attributes, but I got an exception...so I did a wrapper as a test.
The generated code would look something like this :
I'm not asking a question here, but I am letting you know how we are approaching a websocket issue we are having using azure frontdoor for production which creates a negative user experience when a connection gets dropped, like during an update of a release.
FYI: I am still looking for an htmx UI library that would be as robust as Radzen. This approach breaks the component model approach and all the javascript would need to be loaded on page load. It would be interesting if Radzen supported a static only solution. I may end up with two control in our UI library, one for static limited functionality, and radzen interactive wasm components.