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.