When creating a .net 8 RC1 WebApp with either server side or webassembly render mode options multiple declarations of radzen services, such as tooltip, dialog, context menu, and notification) need to be declared depending on the mix of static render mode vs "interactive" render modes (server,webassembly).
While I have a solution that is working, the solution may have unknown consequences as it doesn't work the same as Radzen documentation. Below I describe the solution:
The image below shows a normal config where MainLayout.razor has RadzenTooltip component declared.
This no longer will work in the case above because the render mode, by default is static. We want MainLayout component to stay static. Our approach is to build everything static until a child widget needs "interactivity".
The work around is for each "interactive" child widget to have RadzenTooltip component.
This solution means there would be multiple RadzenTooltip components declarations on the page instead of just one.
The question for Radzen is this : are there any issues we should be aware of when having multiple RadzenTooltip components on a page? This would also be the same for all services.
thanks
Rob
Radzen Blazor Studio Professional owner
You can try setting the rendermode attribute of those components. It should work in static layouts:
<RadzenNotification @rendermode="@RenderMode.InteractiveServer" />
<RadzenDialog @rendermode="@RenderMode.InteractiveServer" />
Or register all such components in another component which has server/wasm/auto render mode by default.
Yes, there will be issues for sure - multiple tooltips/notifications/dialogs will show. Those components are not meant to be used more than once.
1 Like
Is there a way for the tooltip service and other services to work with a page/component using StreamRendering(true) ? the weather page in the Visual Studio webapp template is an example.
If the answer is no, would Radzen have to add to their javascript library to support static/streamrendering for active components like a tooltip service, button or datagrid? This would be an important question for us to confirm the answer as we it appears our architect is leaning toward a static/streamrendering approach.
I did test <RadzenDialog @rendermode="@RenderMode.WebAssembly" /> and it worked. thanks.
Yes, just enable interactivity via @attribute [RenderModeInteractiveServer].
We don't plan to add a JS library on top of Radzen.Blazor. We prefer to keep all interactions Blazor based thus requiring interactivity.
I read the following from Microsoft about "graceful" static degrading. ASP.NET Core Blazor render modes | Microsoft Learn
Quote:
Component authors should avoid coupling a component's implementation to a specific render mode. Instead, component authors should typically design components to support any render mode or hosting model. A component's implementation should avoid assumptions on where it's running (server or client) and should degrade gracefully when rendered statically. Specifying the render mode in the component definition may be needed if the component isn't instantiated directly (such as with a routable page component) or to specify a render mode for all component instances.
For example:
For a RadzenDropdown or RadzenMenu, the dropdown button will not work in static render mode. In general, the RadzenButton will not work in static render mode. The Radzen Menu tracks an "active" state which is really nice across multiple radzen menus, but that doesn't work in static render mode. Perhaps if there were some "graceful" static render fallback options, the application would still function, but some features would not be available. If a "graceful" fallback is left to the app developer, a different UI approach is needed like htmx and hyperscript. We are building out a beta application, and some parts of the app we need a static render solution, and we are seeing mixed controls. If a component vendor could support static render mode as well as the other, that could be an important feature for adoption.
It is worth mentioning that <button @onclick="ClickHandler"> doesn't work either. This is a design choice of Blazor static rendering mode. I think you are expecting something that is beyond the component vendor scope - it is a feature of the Blazor framework.
Static rendering by design is for non-interactive parts of the UI (non-interactive means that any user interaction should be handled with JavaScript). We do not plan to implement our Blazor component library in JavaScript. I think this defeats the purpose of it being a Blazor component library. If you need a component library which works in Blazor static rendering mode you should look for a library which is not based on Blazor events.
1 Like
many thanks for your response as we figure out our approach.