.NET 8 Blazor Web App Migration (Continued...)

[sbwalker]

The previous thread (#3698) is getting too long, so starting a new one.

Now that most of the UI use cases are working, it is time to focus on the runtime workload characteristics...

When running on Interactive rendering, the App server component is executed once for every unique browser session. It makes a number of database calls to retrieve information so that it can populate the initial page markup. It then initiates the component rendering process which intantiates the SiteRouter. The SiteRouter makes a number of Service API calls (using HttpClient) to populate the PageState. On each subsequent user interaction the SiteRouter utilizes the existing PageState so that it does not have to reload information.

When running on Static rendering currently, the App server component is executed for every request (ie. every user interaction). It makes a number of database calls to retrieve information so that it can populate the initial page markup. It then initiates the component rendering process which intantiates the SiteRouter. The SiteRouter makes a number of Service API calls (using HttpClient) to populate the PageState. On each subsequent request (ie. user interaction) the SiteRouter has to reload the PageState.

So based on above, it is clear that when running on Static rendering the framework currently has a much higher workload than it does on Interactive rendering. In fact, on each request it is loading the same information multiple times (ie. in both the App and SiteRouter components). In addition, the SiteRouter is relying on Service API calls (using HttpClient) which is not necessary in Static rendering, as this workload is running on the server.

In order to address the runtime characteristics above, I am going to isolate the workload which is currently in SiteRouter and move it to App. App will construct the PageState and will pass it as a component parameter to Routes which will then pass it to SiteRouter. SiteRouter will then use the PageState if it is provided (which will not always be the case as if you are running on .NET MAUI then App is never executed). This will eliminate the "double workload" which currently exists for Static rendering. It will also benefit Interactive rendering (to a lesser extent as App and SiteRouter are not being executed frequently in interactive scenarios - however if you are running on Globally Interactive public site which contains a lot of content pages then this improvement will be beneficial).

I will also be implementing the approach which was demonstrated in the Oqtane SSR POC which utilizes dependency injection to vary the implementation of Service APIs based on where they are executing (ie. server or client). This will allow server-based workloads to avoid the HttpClient overhead... and client-based workloads to continue to function as they do today.

Again, I am giving a heads up about these changes because they are invasive to the framework and may result in some instability in the Dev branch for a period of time.

[sbwalker]

The changes above are mostly complete - the SiteService has been refactored to have client and server implementations, and the App component now uses the SiteService to retrieve information using the server implementation and passes the PageState to the SiteRouter - which eliminates a number of data access calls on a full page request when running on Static or Interactive render mode.

One of the challenges I am working on currently is related to the Head component. In Interactive rendering this component is responsible for injecting the favicon, page title, as well as any arbitrary head content (ie. meta, link references, etc...) based on the configuration in your site. This component is also what allows modules to dynamically set the page title, etc... It accomplishes this using the INotifyPropertyChanged concept which is part of Blazor.

Unfortunately, this approach does not seem to work in Static rendering. There are a number of issues logged in the aspnetcore repo related to HeadOutlet - which suffers from a similar problem. Basically the problem is that although the Head component receives the INotifyPropertyChanged events, it does not render the markup in the UI. This seems to be related to "mixed mode" scenarios ie. the app loads in Static render mode by default and has a few components which are Interactive. In this configuration the DOM differencing algorithm gets confused and actually removes elements from the DOM which were added during static/pre rendering (see dotnet/aspnetcore#50268). Again this is part of the Blazor "black box" which makes it difficult to diagnose and find workarounds.

This is a fairly major problem as it means that favicon, page title, as well as any arbitrary head content (ie. meta, link references, etc...) are not being injected into the page - which are some of the most critical elements you want to include in a static rendering scenario (for SEO). I initially tried implementing some logic in the App component to include elements in the page head and although it would work for configuration stored in the site, it would not support the dynamic ability for a module to set the title, etc... So more research is required. This link offers some advanced render mode concepts but I have not been able to get any of them to work for this specific scenario - https://learn.microsoft.com/en-us/aspnet/core/blazor/components/render-modes?view=aspnetcore-8.0#fine-control-of-render-modes

Another challenge is related to module and theme scripts and stylesheets. In Interactive rendering, scripts and stylesheets are handled by JS Interop in OnAfterRender() - which is implemented in ModuleBase, ThemeBase, etc... In Static rendering you can't use JS Interop and the OnAfterRender() event is not even called so a different approach is needed. Rather than having 2 totally different implementations I am hoping I can find a happy medium. I am currently experimenting with calling the JavaScript LoadJS methods in the traditional way when running on Static rendering (rather than using JS Interop). This would provide consistency on how scripts are injected into the DOM - they would just be triggered in different ways by the framework based on the render mode.

[sbwalker]

I have not been able to make any progress on the INotifyPropertyChanged issue with Static rendering. If you want to experiment with the problem yourself open the Head.razor file and put some breakpoints on the various methods.

Also put a breakpoint in ThemeBuilder,razor where it sets the page title:

        // set page title
        if (!string.IsNullOrEmpty(PageState.Page.Title))
        {
            SiteState.Properties.PageTitle = PageState.Page.Title;
        }
        else
        {
            SiteState.Properties.PageTitle = PageState.Page.Name + " - " + PageState.Site.Name;
        }

When you run the app you will see the OnInitialized() method in Head.razor get called first, registering the PropertyChanged event. Then you will see the ThemeBuilder.razor logic called where it sets the PageTitle. Then the Head.razor PropertyChanged event will fire and you can see the _title property get set with a value. This should be rendered in App.razor where the Head.razor is declared:

    <!DOCTYPE html>
    <html lang="@_language">
    <head>
        <meta charset="utf-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0">
        <base href="/" />
        <script src="js/app.js"></script>
        <script src="js/loadjs.min.js"></script>
        <link rel="stylesheet" href="css/app.css" />
        @if (!string.IsNullOrEmpty(_PWAScript))
        {
            <link id="app-manifest" rel="manifest" />
        }
        @((MarkupString)_styleSheets)
        <link id="app-stylesheet-page" />
        <link id="app-stylesheet-module" />
        @if (_renderMode == RenderModes.Static)
        {
            <Head />
        }
        else
        {
            <Head @rendermode="InteractiveRenderMode.GetInteractiveRenderMode(_runtime, _prerender)" />
        }
        @((MarkupString)_headResources)
    </head>

However the markup is never rendered into the page output:

Note that if you set the Site to use Interactive render mode, this approach works fine and includes the page title:

The strange thing is that is that this same problem exists in the Oqtane SSR POC... however I also created another Blazor Web App with per component rendering and added a service with implements INotifyPropertyChanged to it... and it renders the content to the UI as I would expect. So I am trying to determine what the difference is which is causing the problem.

NotifyProperty.cs

using System.ComponentModel;
using System.Runtime.CompilerServices;

namespace BlazorAppWithAuth.Models
{
    public class NotifyProperty : INotifyPropertyChanged
    {
        public event PropertyChangedEventHandler? PropertyChanged;

        private string _value = "";

        public string Value
        {
            get => _value;
            set
            {
                if (_value != value)
                {
                    _value = value;
                    OnPropertyChanged();
                }
            }
        }

        protected virtual void OnPropertyChanged([CallerMemberName] string? propertyName = default)
        {
            PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
        }
    }
}

Program.cs

            builder.Services.AddScoped<NotifyProperty>();

Sender.razor

@using BlazorAppWithAuth.Models
@inject NotifyProperty NotifyProperty

@code {
    [Parameter]
    public string Value { get; set; } = "";

    protected override void OnParametersSet()
    {
        NotifyProperty.Value = $"<title>{Value}</title>";
    }
}

Receiver.razor

@using System.ComponentModel
@using BlazorAppWithAuth.Models
@inject NotifyProperty NotifyProperty

@if (!string.IsNullOrEmpty(_value))
{
    @((MarkupString)_value)
}

@code {
    private string _value = "";

    protected override void OnInitialized()
    {
        ((INotifyPropertyChanged)NotifyProperty).PropertyChanged += PropertyChanged;
    }

    private void PropertyChanged(object? sender, PropertyChangedEventArgs? e)
    {
        if (NotifyProperty.Value != _value)
        {
            _value = NotifyProperty.Value;
            StateHasChanged();
        }
    }

    public void Dispose()
    {
        ((INotifyPropertyChanged)NotifyProperty).PropertyChanged -= PropertyChanged;
    }
}

App.razor

<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <base href="/" />
    <link rel="stylesheet" href="bootstrap/bootstrap.min.css" />
    <link rel="stylesheet" href="app.css" />
    <link rel="stylesheet" href="BlazorAppWithAuth.styles.css" />
    <link rel="icon" type="image/png" href="favicon.png" />
    <Receiver />
</head>
<body>
    <Routes />
    <script src="_framework/blazor.web.js"></script>
</body>
</html>

Home.razor

@page "/"

<h1>Hello, world!</h1>

Welcome to your new app.

<Sender Value="HOME" />

Counter.razor

@page "/counter"
@rendermode InteractiveServer

<h1>Counter</h1>

<p role="status">Current count: @currentCount</p>

<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>

<Sender Value="COUNTER" />

@code {
    private int currentCount = 0;

    private void IncrementCount()
    {
        currentCount++;
    }
}

Results in:

[sbwalker]

The module CSS and JS is currently not being loaded on static rendering. This is because when running on interactive rendering it is being injected dynamically using JS Interop methods in OnAfterRender. This method is not called on static rendering. Now that INotifyPropertyChanged is working I can inject the module CSS and JS using the Head component. This is one of the reasons why it was so important to resolve the issues with INotifyPropertyChanged.

[sbwalker]

@thabaum PR #3843 now injects the module JS and CSS (using the Head component and INotifyPropertyChanged).

[thabaum]

@sbwalker seems to work rendering the login page component css styles, however I have an issue accessing the control panel from the icon after logging in.

You had fixed this once before, as now the sections are not interactive either sending you back to home page when clicked on to expand in Site Settings as well.

[sbwalker]

@thabaum yes, I am working on that issue now

[sbwalker]

@thabaum PR #3847 will unblock you... but it will require more investigation to determine if it has any side effects in interactive rendering

[sbwalker]

@thabaum in regards to your earlier comment "I notice the blinking in Static Server that does not exist as much or at all in Interactive Server render mode. Like things are loading twice when visiting the interactive admin component pages. Page Management I think along with System Info seem to be the smoothest or more expected behavior." - I do have some theories about this which I will need to explore tomorrow.

Basically in interactive rendering, Oqtane is relying on custom JavaScript to efficiently manage the injection of stylesheets... there was a long discussion about this last year when we upgraded to .NET 7 because we tried to migrate to using the new Head component approach but it did not provide a good user experience we so rolled back to the custom method. In static rendering I think something similar is happening where the stylesheet references are being removed and then re-added on every page load - which is resulting in the behavior you are seeing in the browser.

[sbwalker]

@thabaum the specification of "false" in the attribute [StreamRendering(false)] indicates that StreamRendering should be disabled for the component: "a flag to indicate is this component and its descendants should stream their rendering" - it is not related to pre-rendering (which makes sense).

So basically by enabling StreamRendering in the Routes and Head components (root components) it means that all components in the entire application are using StreamRendering by default. Based on the earlier challenges encountered with content not rendering properly to the UI, it seems that StreamRendering is required in the vast majority of cases. However, in the case of interactive components (ie. Modules) it appears that disabling StreamRendering can provide a slightly better user experience in some cases, as it eliminates the "double render".

It would seem to make sense that components which are rendered interactively should disable StreamRendering by default... and components which are rendered statically should enable StreamRendering by default. This could be handled by the framework as part of the UI composition logic, and it could be easily overridden within a specific component if necessary.

Unfortunately, the StreamRendering attribute is a static and can only be specified within the component definition - it cannot be specified on the instance as a property (like rendermode) - which means that you cannot include conditional logic to control whether the attribute is enabled or disabled. The only solution would be to create 2 components - one which includes [StreamRendering(true)] and another which includes [StreamRendering(false)]... and then you can control which version of the component gets injected.

I will give this a try this morning to see how to performs.

[sbwalker]

@thabaum give PR #3858 a try... it renders interactive module components with StreamRendering disabled and it renders static module components with StreamRendering enabled.

[sbwalker]

@thabaum I just posed the question about StreamRendering usage to Microsoft: dotnet/aspnetcore#54157

[thabaum]

@sbwalker #3858 is the solution I had thought of as well minus using two components, which created that problem from it being static and unable to set on a component. Maybe Microsoft can add this ability to set on the component like render modes are as it would make it easier to do what we are doing.

This works to set this rendering setting and your overall solution using two components to wrap at that part of the pipeline seems to work great! I can't believe my eyes at how this development ride using Oqtane Framework is getting more options, faster and smoother all at the same time.

I also see you have resolved a number of other issues today and things just keep on rolling forward, awesome, thank you for this exciting journey!

🚀

[thabaum]

@sbwalker did I say wow yet?! :)

[thabaum]

@sbwalker odd behavior detected while setting themes on different pages, then navigating between the pages, you have to refresh the page each time you click on a navigation. Almost like if the page theme is different then the site theme a reload or refresh needs to happen. Only in static SSR. I suppose I will log the issue.

[sbwalker]

There are a number of places within Oqtane where a component needs to redirect to another Url. In Interactive rendering if you placed the call to NavigationManager.NavigateTo() within OnParametersSet() it would throw an exception. So the standard guidance was to include the NavigationManager.NavigateTo() logic in OnAfterRender(). On Static rendering OnAfterRender() is not a life cycle event so it will not be invoked. This means that coditional logic needs to be added in OnParametersSet():

if (PageState.RenderMode == RenderModes.Static)
{
    NavigationManager.NavigateTo(url);
}

and the traditional NavigationManager.NavigateTo() logic can be retained in OnAfterRender() for interactive scenarios (no conditional logic needed here because it is only called in interactive render mode).

I am not a big fan of having to sprinkle conditional logic around the app based on render mode but at least it is simple to handle in the cases where it is necessary because Oqtane provides the PageState - standard Blazor in .NET 8 does not provide a way to determine the render mode out of the box (it is one of the enhancement requests for .NET 9).

[sbwalker]

There are also a number of user experience behaviors in Oqtane which rely on JS Interop. For example, the Login form uses JS Interop to set the focus to the Username field when the form is loaded. These behaviors continue to function correctly because the majority of modules are using interactive rendering.

However if you created a module which needed to work in static rendering, you could not rely on JS Interop as it can only be called from OnAfterRender(). So you would need to create an alternative method. I assume that in static rendering you can just embed standard JavaScript in your components - which makes it simpler. There is nothing in Oqtane which requires this at the moment but I am sure it will come up in the near future.

[sbwalker]

Even with the improvements outlined at the top of this thread, the run-time characteristics of static rendering are much different than interactive rendering. This is because static rendering is stateless - which means methods such as SiteService GetSite() need to be called on every browser request to load the data from the server (whereas interactive rendering is stateful and can re-use data loaded previously).

Caching had been implemented in prior releases within the SiteService GetSite() method for unauthenticated users which eliminated the bulk of database calls for public-facing scenarios. This was possible because all unauthenticated users have the same set of permissions in terms of the content they are allowed to access. However, this does not provide any benefit for authenticated users.

Caching data for each authenticated user is not difficult... the challenge is dealing with cache invalidation when the site configuration changes at run-time, or when the user's permissions are updated. This required some improvements to the caching infrastructure to provide more context and control over cache items. With the latest changes, authenticated users will get the same performance benefits as unauthenticated users, and the cache will be refreshed immediately when information changes.