Prerendering

[sbwalker]

#4179 adds the ability to specify a Prerender property at the IModuleControl (component) level. This allows developers to explicitly control the prerendering behavior of their components by overriding the Site property specified in Site Settings (which defaults to True):

The problem is that in .NET 8 prerendering can cause some UX issues when you are using Static rendering with Interactive components (which is the default approach in Oqtane 5.1 and is consistent with the default Blazor app template from Microsoft). This documentation from Microsoft describes the behavior:

https://learn.microsoft.com/en-us/aspnet/core/blazor/components/prerender?view=aspnetcore-8.0

"Without persisting prerendered state, state used during prerendering is lost and must be recreated when the app is fully loaded. If any state is created asynchronously, the UI may flicker as the prerendered UI is replaced when the component is rerendered."

The documentation also talks about using the PersistentComponentState service to mitigate this "flicker" issue - however the solution is cumbersome as it needs to be implemented in every Interactive component. A much simpler solution is to disable Prerendering, which is what #4179 allows developers to do in Oqtane. However, I believe it may be possible to solve this at a higher level...

There is really only 1 scenario where you would want Prerendering to be enabled for an Interactive component - when the component is visible to anonymous users and the current user is not authenticated (ie. the content is indexable and the current user may be a bot). Note that the system does not know the difference between a real anonymous user and a bot ( and you can't trust user agent strings) so in the case where a component is intended to be visible to anonymous users, it should use the Static rendering approach (as Static rendering is indexable and does not suffer from the "flash" behavior). In all other scenarios Prerendering should be disabled.

Oqtane has all of the context needed to automatically set Prerendering based on the logic above. So it can provide the best user experience based on the configuration. And it does not require developers to hard-code the prerender behavior in their components (although they still could if they need the ultimate override).

I am not sure what to do about the Prerender property at the Site level. Could it be removed? Is there any need to set it at the Site level if there is logic to determine the appropriate setting?

[mdmontesinos]

Great insight of the prerendering issues!

As for the options you mention, I really like the possibility of Oqtane automatically determining whether to prerender or not. Perhaps you could keep the Prerender property at the Site leve with a default value of "Auto" that would use this new mode, but still allowing developers to globally enable/disable it for all modules if they need to.

Also, although I agree that prerendering could be disabled in most cases, there still should be a way to easily persist state for those who want to use it for faster initial UI response. Perhaps it could be interesting adding the PersistentComponentState service to the ModuleBase, with some wrapper functions to ease the process of loading/saving the state.

[sbwalker]

@mdmontesinos I liked your suggestion. #4243 adds support for Auto Prerendering. Basically the Prerendering option in Site Settings can be set to either Auto or Disabled (the default is Auto). Auto Prerendering takes into consideration if the user is authenticated or not. If a user is authenticated (ie. not a crawler/bot) then prerendering is disabled for Interactive components. This prevents the double-rendering issue in the majority of scenarios - improving the user experience and application performance. It is still possible to fully disable prerendering for all components in a site by setting the Site Setting to Disabled. And it is also possible to set prerendering at the component level using the IModuleControl property.

[sbwalker]

@mdmontesinos I am now having second thoughts about the above changes - mostly because they introduce "magic" behavior which may be confusing as it is not easily predictable. I believe the same goals could be achieved with the original Site Setting options simply by setting the Prerender property to False by default when the Render Mode is Static. When Prerender is false it avoid the double-render for any Interactive components and it does not affect Static components at all. In those specific cases where you are using an Interactive component in a scenario where you need the content to be indexed, you could enable Prerendering via the component-level property. And if you really want to enable Prerendering site-side you can (although I do not understand why). If you are using Interactive Render Mode it is fine to have Prerendering enabled as it does not cause any UX issues.

[sbwalker]

The one scenario which I had not considered is Static Render Mode using Client (WebAssembly) Interactivity. In this configuration, if you disable Prerendering there is a noticeable delay before an Interactive component is rendered... and if you enable Prerendering their is no delay in the initial render, however there is a double-render "flash" - so neither is truly optimal.

[mdmontesinos]

@sbwalker Perhaps for the WASM interactivity is where the use of PersistentComponentState would really shine. As I mentioned previously, it'd be interesting to integrate this functionality into ModuleBase to ease the process for devs.

[sbwalker]

@mdmontesinos I did experiment with integrating it into ModuleBase however because it relies on an event handler it has the potential to degrade performance for all other component scenarios even if it is not being used.

[mdmontesinos]

What about a PersistableModuleBase class? It could inherit from ModuleBase and add the required helper methods for this functionality.