.NET 8 Blazor Web App Migration

[sbwalker]

Oqtane 5.0 is already running on .NET 8... however it is still using the traditional Blazor approach in terms of hosting models ie. it supports Blazor Server and Blazor WebAssembly but it is not utilizing any of the new features introduced in .NET 8.

As discussed previously... the goal is to integrate the new Blazor features into Oqtane so that developers have the flexibility to leverage the full capabilities of Blazor. The plan is to tackle this work in few distinct phases:

Phase 1.

Make the foundational changes to the project structure to utilize the new Blazor Web App approach. Technically this means a change from using blazor.server.js/blazor.webassembly.js to using blazor.web.js (and a refactoring of a number of aspects of the Blazor application). In this initial phase the framework will only focus on Global Interactivity and ensuring all scenarios continue to function as they did previously.

Phase 2.

Implement Static Server-Side Rendering to enable modules to execute as either static or interactive components. The major challenge of this phase is expected to be dealing with state management (in a backward compatible manner).

It would be beneficial if both of these phases could be completed and included in the upcoming 5.1 release.

PLEASE NOTE... the Dev branch is expected to experience some instability while these changes are being introduced. So if you want to develop against a stable platform, you are encouraged to use the Master branch - or an official prior release.

PR #3697 is the initial commit for Phase 1 which starts moving the framework in this direction. The initial changes are largely based on the efforts which were invested over the past couple months on the Oqtane SSR POC project (https:/oqtane/OqtaneSSR) which provided a way to overcome some of the major obstacles and prove the viability of the new approach.

The current code in the Dev branch is functional - it allows you to create a new installation and navigate around the application. Currently it is hardcoded to InteractiveServer render mode. There are a number of specific features which were implemented in _Host that are commented out and will need to be refactored, including Visitor Management, Url Mapping Redirects, etc... In addition, Antiforgery is currently disabled at the application level as it is not working properly after the initial commit.

If you do any testing please log the issues under version 5.0.3 for now so that it is clear which codebase you are using.

[sbwalker]

Update 1/31/2024: all of the functionality in _Host has now been refactored... and Antiforgery is fully working once again. Hosting Model was enhanced to allow for selection of Render Mode and Interactivity:

Interactive Server and Interactive WebAssembly render modes are both functional. .NET MAUI is also functional.

[sbwalker]

One of the major benefits of using a framework as opposed to building an application from a template, is that a framework is responsible for all of the foundational run-time concerns. Basically for Oqtane this means that the migration from the traditional Blazor approach to the modern Blazor approach in .NET 8 is handled at the framework level... and custom modules get the benefit of the new approach without having to invest time or energy into complex code migrations or re-architecture.

[thabaum]

Let us know when any serious testing is needed. I am going to let the dust settle here for a few and catch up on some other projects and wait for word prior to submitting issues running the dev branch.

[sbwalker]

Update: 2/2/2024 - a lot of progress was made on Phase 1 of the migration effort this week. When using Interactive Render Mode you can install the framework. You can login/logout (using the new AddCascadingAuthenticationState service in .NET 8). You can specify Server, WebAssembly, or Auto modes. You can add new Sites with their own Render Modes.

I have moved on to Phase 2 - Static Rendering. I added the ability for Module razor components to specify a RenderMode (ie. Interactive/Static) which would then utilize the default Interactivity for the Site (ie. Server, WebAssembly, Auto). Currently I am blocked by an issue where the UI is not rendering in the browser - however no exception is being thrown and nothing is being logged which could provide a clue as to why this is happening. Note that the Oqtane POC project does not suffer from this issue, so it is something unique to the Oqtane framework code base. I have reached out to Microsoft for assistance.

I do expect there will be many issues to overcome in order to benefit from Static Rendering. For example, any functionality which relies on OnClick or OnChange events would need to change. OnAfterRender is not supported. JS Interop is not supported. Alternative approaches would need to be considered for a lot of these scenarios - but only where it makes sense. From a high level the idea is that the core framework itself should support both static and interactive scenarios - however modules will have the ability to indicate that they require interactivity which will allow them to continue to function without any code changes (Interactive will be the default render mode for modules for backward compatibility reasons).

[sbwalker]

I have now spent 2 full days on the static rendering problem and I have still not been able to resolve it - however I was able to isolate the problem to the SiteRouter. Basically what is happening, is when running the framework in Static rendering mode, as soon as a backend service is called which uses HttpClient, it results in a short circuit of component rendering.

To simplify things I created a simple component named Test.razor which displays the text [TEST]. I then modified the SiteRouter to display this component rather than ThemeBuillder (which is more complex as it loads a lot of nested child components). I modified the logic in the SiteRouter.razor Refresh() method to return at an earlier point in the processing:

        _pagestate = new PageState();
        OnStateChange?.Invoke(_pagestate);
        return;
        
        // process any sync events
        var sync = await SyncService.GetSyncEventsAsync(lastsyncdate);

Results in the [TEST] message being displayed in the browser. However, this code:

        // process any sync events
        var sync = await SyncService.GetSyncEventsAsync(lastsyncdate);

        _pagestate = new PageState();
        OnStateChange?.Invoke(_pagestate);
        return;

Results in a blank screen in the browser. Note that it does not matter which HttpClient service wrapper I reference (I have experimented with a number of them)… they all result in the component not being rendered. However, the service call does complete successfully... it calls the back-end server API method and returns the result successfully:

Microsoft.AspNetCore.Hosting.Diagnostics: Information: Request starting HTTP/1.1 GET http://localhost:44357/api/Sync/00010101000000000 - - -
Microsoft.AspNetCore.Routing.EndpointMiddleware: Information: Executing endpoint 'Oqtane.Controllers.SyncController.Get (Oqtane.Server)'
Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker: Information: Route matched with {action = "Get", controller = "Sync", page = ""}. Executing controller action with signature Oqtane.Models.Sync Get(System.String) on controller Oqtane.Controllers.SyncController (Oqtane.Server).
Microsoft.AspNetCore.Mvc.Infrastructure.ObjectResultExecutor: Information: Executing ObjectResult, writing value of type 'Oqtane.Models.Sync'.
Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker: Information: Executed action Oqtane.Controllers.SyncController.Get (Oqtane.Server) in 8.7785ms
Microsoft.AspNetCore.Routing.EndpointMiddleware: Information: Executed endpoint 'Oqtane.Controllers.SyncController.Get (Oqtane.Server)'
Microsoft.AspNetCore.Hosting.Diagnostics: Information: Request finished HTTP/1.1 GET http://localhost:44357/api/Sync/00010101000000000 - 200 - application/json;+charset=utf-8 24.7110ms

At this point I do not understand how component rendering could be affected by an HttpClient service call. Something strange is happening during static rendering – but there are no exceptions, errors in the browser console, etc… No clues as to why this is happening.

Note that the reason why the POC project did not experience this problem is that it does not make any HttpClient service calls in its SiteRouter.

[thabaum]

I attempted testing this however I only was able to make the component render, and could not reproduce the issue switching this code around at that point in the logic described for "// process any sync events" comment in the refresh logic.

My SSRTest.razor component renders no matter which way I set that logic.

If I take away the return a null reference exception is thrown.

However if I put those code changes as described but my component rendered both times.

I put the SSRTest.razor component in the Oqtane.Client.UI namespace and location with the following code copied from the other.

TEST COMPONENT static SSR!

This component loaded both times. Since it is not setting itself as an interactive component it should be rendering static correct? Or whatever the parent is from my understanding, what exactly that means I am still learning. Do I need to set the render mode code maybe?

I put this component in place of themebuilder.razor component and runs OK.

but if i comment out as shown here

Still the same component will render.

and if i bugger it up as follows:

I received a null reference error so I know I am hitting this logic.

I did get another error once that showed up with a white screen more or less had to do with HttpClient. I might be able to replicate it, but really I want to be up against the wall you are trying to build through.

I had this component originally in the server project which is probably where it should go and why it works is because it is in client. But Oqtane with it's API the projects seem to behave differently than other Blazor hello world apps. So I figured I would put it where the other UI controls are. So maybe I need to put this in the server project since it is static server-side to get your error? Or with Oqtane does it matter, it just needs to be in a namespace. I must have something wrong to not have similar results.

Last question relating to your setup, are you running an Oqtane VS instance that is installed with a database? For this testing I am not connecting to one? I know there are new UI options for render modes, do I need to set that up? Or are you getting the installation logic going first?

Could the installation be static SSR potentially using enhanced data?

[sbwalker]

@thabaum the PR #3739 comments out an HttpClient service call and mocks an object which allowed Oqtane to render at least some initial content rather than a blank screen. However as soon as the framework encounters another HttpClient call it encounters the same issue where content is not rendering - which is why the HtmlText modules in the default template are not displaying any content.

Note that you also need to ensure that you set the Site Settings to use Static Server Rendering or else it will render using Interactive Server Rendering by default.

[sbwalker]

I was able to reproduce the problem in the Oqtane SSR POC application:

https:/oqtane/OqtaneSSR

If I remove the service call in OqtaneSSR.Client\Components\Router\SiteRouter.razor:

private async Task Refresh()
{
    //var x = await HttpClientService.GetTextAsync(); // adding this service call prevents downstream components from rendering

    _pageState = new PageState
    {
        InteractiveRenderMode = _interactiveRenderMode,
        PagePath = new Uri(_absoluteUri).AbsolutePath,
        Modules = _modules
    };

    OnStateChange?.Invoke(_pageState);
}

The OqtaneSSR.Client\Components\Modules\Home.razor component will display “Hello World!”:

However if I include the service call in OqtaneSSR.Client\Components\Router\SiteRouter.razor:

private async Task Refresh()
{
    var x = await HttpClientService.GetTextAsync(); // adding this service call prevents downstream components from rendering

    _pageState = new PageState
    {
        InteractiveRenderMode = _interactiveRenderMode,
        PagePath = new Uri(_absoluteUri).AbsolutePath,
        Modules = _modules
    };

    OnStateChange?.Invoke(_pageState);
}

The component does not display “Hello World!”:

I am hoping that this code and repro will help identify the source of the problem.

[sbwalker]

@thabaum adding the @attribute [StreamRendering] in the Oqtane framework (and removing the hack which bypasses the InstallationService in the SiteRouter) also seems to work:

Streaming rendering is not enabled by default in SSR. It allows pages that need to execute long running requests to load quickly via an initial payload of HTML. That HTML can contains placeholders for the areas to be filled with the results of the long running call. Once that long running call completes, the remaining HTML is streamed to the browser and is seamlessly patched into the existing DOM on the client. This is all done in the same response - there are no additional calls involved.

So I am guessing that an HttpClient loopback call on the server when running in Static RenderMode is considered to be a "long running process". Which is probably why StreamRendering seems to resolve the issue. This is essentially the "higher level orchestration for HttpClient and component rendering across the framework" which I mentioned earlier in this thread.

However I do recall watching a session by Steve Sanderson where he said that it would NOT be appropriate to enable Streaming Rendering for your entire application (which is essentially what we are doing by adding the attribute to Routes.razor). So more investigation is probably required.

However, since the UI rendering is now functioning reliably - it means that we are no longer blocked. This means that I can begin to refactor the other functionality which needs to be changed in order to support Static RenderMode.

[thabaum]

@sbwalker I see you applied stream rendering as a possible solution or workaround until we can find out a better solution. This may help discover why it does not work as you are discussing. I had put the stream rendering on both the Router and SiteRouter, I put on the SiteRouter trying to limit it's scope. I was trying on all the components there after as well but it really boiled down to fixing that issue in the router itself.

On another note: I was wondering if putting in that bypass hack along with stream rendering on the HTML module would fix the HTML content issue. And where exactly that could be enabled to do so, for the event of when we are able to fix the other issue if possible.

One last note, is being able to set a site to stream rendering, if functions disabled, to set it back to normal rendering to allow modifying what pages have, then set it back to static. We could use a "host" set of features for managing sites without loading the site settings page for that static site itself. Then you can host a static site and be able to turn on/off interactivity to allow editing. But really it looks like it boils down to rebuilding things to work in both.

[sbwalker]

@thabaum I am not sure what "other issue" you are referring to? The UI is now fully rendering with the addition of the [StreamRendering] attribute (and with the "hack" logic removed)

[thabaum]

@sbwalker My guess is the issue is as soon as static SSR component is consumed it is disposed of at the same time. Oqtane loses all memory of it, then tries to handle the request, and doesn't remember what the request was even for.

[thabaum]

@sbwalker the other issue is not using stream rendering to get the values to run the site you had "hacked" in. If this is fixed with that attribute, moving on.

Thing is I fixed it without using stream rendering in the POC, and I am wondering why I cannot in Oqtane. There maybe a clue for MS to look at if this is unexpected behavior.

Last thing is I always see in both the POC and Oqtane a failed websocket request, which maybe VS but was alarmed by it when running sSSR

And I want to know if we can somehow run some iSSR (interactive) components inside, as in turn the HTML module interactive for example with Stream Rendering turned on for the entire app. Or the login control and page components. I had a tough time making that happen but once that is figured out, eureka!

I am just putting a small character i or s in front of the SSR to indicate which I am talking about since it is very confusing to me otherwise. I think of it like the iPhone, the iSSR... or the sSSR. In MS docs it is stated as "static SSR" or "static Server-Side Rendering".

Just so you all know what I am trying to say.

[thabaum]

@sbwalker Microsoft I believe says in documentation that for component library authors to set components to use stream rendering as it will work with all. If you think about it Oqtane Framework is like a massive library that gets extended.

There is a slow feeling clicking between pages waiting for them each to render currently with static SSR and Oqtane. I expected more blink of the eye but it takes a moment to process a page. But I understand this should be expected behavior. Maybe production page loads will run quicker.

The HTTPCLient issue was leading me here thinking maybe it was a cache issue or header issue, or maybe one of those would help.

Then I read up some more on some static server-side rendering best practices.

I would like to be sure to review all the security precautions while making adjustments as there are some things to investigate further still.
This is the area that concerns me the most going forward I would like for us to put some extra love into reviewing while making changes:

https://learn.microsoft.com/en-us/aspnet/core/blazor/security/server/static-server-side-rendering?view=aspnetcore-8.0

There can be a switch to set which types of forms to be used, ie. if sSSR is enabled run different UI logic to make it interactive as needed. This would limit breaking changes, however it would be nice to try to ensure skins flow between the two with minimal additions. May need an ssr class or an id for a CSS selector for styles. Just thinking out loud here sorry getting excited to see this all pull together.

Thank you 🚀

---

Edited note:
@sbwalker when you have time, one more question. Are we going to add the server project services in this same push to 5.1? Or will this be more geared for 5.2?

I can most likely, definitely help here I believe I just would like to see one example first to be sure I follow patterns. For example if you do a larger one, I could work on the less difficult conversions and by the second or third PR start rolling them out the PR line. I have done a lot of them in the past in practice, but it has been a while. However, I have done it for a variety of services for both client and server using different structures from the courses I took. So once you start putting these out I guess I am warning you I may attempt doing a few myself. Not trying to take this topic off coarse, If you can please start another topic relating to this end note. Thanks again!

[sbwalker]

@thabaum I believe a server-side services layer should be done for 5.1.... however there is some basic functionality which we need to get working before going down this path. Making too many unrelated changes in parallel makes it very difficult to determine a root cause when issues arise, so it would be best to tackle things in a methodical manner. This is the main reason I broke the migration into 2 phases - Interactive and then Static.

This being said, the introduction of a server-side services layer will be important for a number of reasons. It will allow server-side workloads to execute without the latency of an HttpClient - which should improve performance. It will also provide a consistent API on the client and server for developers to utilize (currently there is a Service API on the client and a Repository on the server with no consistency). Once we get further with the Static render mode I should be able to provide some examples on how to create the server-side service layer.

[sbwalker]

@thabaum I just noticed that .NET MAUI is no longer working. I know it was working when I completed Phase 1 (Interactive) last week... so it was something related to the recent Static Rendering changes which .NET MAUI does not like :(

[sbwalker]

@thabaum in order to allow the Logout button to function in both Static and Interactive render modes, I had to get rid of the onclick event handler on the button and use a standard form post instead:

Oqtane.Client\Themes\Controls\Theme\Login.razor

Replace:

                <button type="button" class="btn btn-primary" @onclick="LogoutUser">@Localizer["Logout"]</button>

With:

                <form method="post" action="@logouturl" @formname="LogoutForm">
                    <input type="hidden" name="__RequestVerificationToken" value="@SiteState.AntiForgeryToken" />
                    <input type="hidden" name="returnurl" value="@returnurl" />
                    <button type="submit" class="btn btn-primary">@Localizer["Logout"]</button>
                </form>

This is working fine - however it causes a cosmetic styling issue:

I am not sure why the button within a form is behaving completely different than a standalone button - perhaps its a Bootstrap issue. If you have time to explore this, it would be helpful as there will be many places where buttons will need to be replaced with forms.

[sbwalker]

From the Bootstrap site:

"Every group of form fields should reside in a

element. Bootstrap provides no default styling for the element, but there are some powerful browser features that are provided by default.

s within a default to type="submit", so strive to be specific and always include a type.

Since Bootstrap applies display: block and width: 100% to almost all our form controls, forms will by default stack vertically. Additional classes can be used to vary this layout on a per-form basis."

So is it the button element which is causing the UI issue?

[thabaum]

@sbwalker correct, it was an <a> element and now it's a <button> so the css will need updated to reflect this.

a.login, button.login {
    /* styles for both <a> and <button> elements with class "login" */
}

or

a.login {
    /* styles for <a> elements with class "login" */
}

button.login {
    /* styles for <button> elements with class "login" */
}

The login UI could need a "login" or "login-nav-button" class if it does not have one to more easily select it.

However I do not see these being selected in the current Theme.css or App.css so these UI styling updates will need to be applied via the Theme.css.

Looks like you are adding the btn btn-primary class.

One thing you can test is wrapping it in a <div class="container">

From reviewing the code in source: class="controls ms-auto" inside the nav element wraps around these items in a div.

Also for another place to select would be controls-group so .controls-group.button would select all the buttons.

Last thing I would like to point out is the use of <span> element.

This is probably the issue as it will generally put each item in it's own row.

As you can see "app-login" and "app-profile" may get set in either the App.css or Theme.css. I would expect anything with an "app" selector should be focused on the App.css file to easily locate these and then modified as needed in Theme.css. Anyone creating themes might want to use class selectors that have a theme-name-object and the same with module-name-object in order avoid collisions with other vendor themes. It should be a best practice note made in documentation that can help so many trouble tickets for vendors in the future. It helps limit the use of !important with venders fighting for priority.

I would use general html elements and allow bootstrap classes to work as much as possible with anything special to be styled in a module with effort to keep things from fighting the different CSS code provided by modules and themes on the same page. If you want to make a more generic module that works with all default themes it should not be necessary to even style a module much... let the app and theme loaded do most all the work.

[thabaum]

@sbwalker I had an idea that you can try wrapping all the controls into one span. Instead of 2 spans with a button each plus 2 toggle buttons after, put all 4 into one span element with a class="app-controls" and then give each button an ID id="logout" to each button accordingly. Then these can be selected span .app-controls. and span .app-controls .logout or even also select the nav element to select that more specifically ensuring it is only here a style may apply.

However, trying not to break things here too much, Selecting nav .controls-group and/or nav .controls and adding something like display:flex; flex-direction:row; justify-content: flex-end; may be the solution. I will try to replicate what you have, or if you can add to the dev branch I can play with this more.

I should have some time this weekend to work on the Maui app issue and any styling issues that are reproduce-able.

[sbwalker]

@thabaum I am still a bit confused by the difference in display...

Prior to the recent changes for static rendering the Logout button markup was:

<span class="app-login">
    <button type="button" class="btn btn-primary" @onclick="LogoutUser">@Localizer["Logout"]</button>
</span>

and with the recent changes it is:

<span class="app-login">
    <form method="post" action="@logouturl" @formname="LogoutForm">
        <input type="hidden" name="__RequestVerificationToken" value="@SiteState.AntiForgeryToken" />
        <input type="hidden" name="returnurl" value="@returnurl" />
        <button type="submit" class="btn btn-primary">@Localizer["Logout"]</button>
    </form>
</span>

so there was always a span... and it is still using a button... and there is no different CSS being applied by Oqtane to these elements.

[sbwalker]

Changing an interactive button to a static form button is going to be a common scenario for developers in module components which are mainly static and do not require full interactivity. So it's important to have a styling solution which works consistently for both scenarios and displays the buttons inline with an identical appearance. So we need to think about this from a perspective which is broader than just the Logout button in a theme.

[ADefWebserver]

Also VS2022 is having strange behavior for me - the intellisense, etc... is busted

I had that problem with https:/AIStoryBuilders/AIStoryBuilders. It is a MAUI program and the solution for me was to enable Android builds.

[thabaum]

I get that on components such as with it not recognized as well in Visual Studio, my guess is it looked like a namespace conflict issue that confuses intellisense. Although all compiles and works fine, intellisense bugs out like this when using some components in Oqtane.

[sbwalker]

I deleted the .vs folder and opened the solution again... and the problem is gone :)

[sbwalker]

Update 2/9/2024: You can install Oqtane, login, and go into Site Settings and scroll to Hosting Model and change the Render Mode to Static Server Rendering and Interactivity to Server. In this configuration the theme, containers, and Html/Text module will all render statically. If you click on the "host" link to access the User Profile it will be displayed and it will indicate Render Mode: Interactive. However if you click the Save button nothing will happen because it is in fact in static render mode. I have spent the past day trying to determine why this is not working as expected - as it is working in the Oqtane SSR POC project which emulates the same nesting of components and uses the same technique for setting the render mode.

[thabaum]

@sbwalker very odd behavior on the navigation menu "Login" button does not take you to the login page in the menu so this is probably set to interactive not interactive or working. It worked/works most the time but I did get it to not work... click and it does nothing, but right now it works... maybe related to the issue.

So if this login button is "interactive" it seems to work sometimes but then forgets the login page and just redirects. This could be a place to investigate a bug breaking the rest of the interactivity?

In fact, it works the first time you render the page and fire up Oqtane on VS, click on the button it takes you to the login page, once on the login page it takes you back to homepage with return url missing the login component route in the address.

It only bugs out when it generates a return url, maybe a bug I will report as an issue.

---

Issue I see is just making "Interactive" components when we can set "InteractiveWebAssembly" or "InteractiveServer" "InteractiveAuto" component render modes along with static should be an option I would be guessing for 4 rendermodes total for components, setting no rendermode inherits parent component, so maybe even 5 total settings are possible. It looks like there is only 2 "static" and "interactive". I understand we are probably focusing on just server-side for now.

I did a lot of reading on this topic today and found out some things about passing parameters or state to child components I will try to review more tonight as I look at the current code base.

We have these modes, but I believe a static site can use all 3 plus static for component render modes (not the runtime). This should not matter if you have "Interactive SSR" for the runtime if I am not mistaken you can still set a component to use webassembly or auto from within any component mixing them up as you feel fits the bill so to speak when dealing with client vs server resources and security.

---

for a quick reference this is the docs from MS I have been reviewing:
https://learn.microsoft.com/en-us/aspnet/core/blazor/components/render-modes?view=aspnetcore-8.0#apply-a-render-mode-programatically
https://learn.microsoft.com/en-us/aspnet/core/blazor/components/render-modes?view=aspnetcore-8.0#static-server-side-rendering-static-ssr
https://learn.microsoft.com/en-us/aspnet/core/blazor/components/render-modes?view=aspnetcore-8.0#child-component-with-a-different-render-mode-than-its-parent

[sbwalker]

@thabaum have you tried the Oqtane SSR POC? It demonstrates the expected functionality.

A Site in an install can specify a default render mode - Static Server Rendering or Global Interactivity. If the render mode is Interactive it means that all components in the site will be fully interactive. If the render mode is Static it means the default page, theme, containers, etc... will be static - however some modules may still require interactivity based on their functionality.
(ie. if they use traditional Blazor concepts like onclick, etc...). For this reason a Site must also specify it's default Interactivity - Server, WebAssembly, or Auto. Modules which have components which are interactive (specified via the RenderMode property on the IModuleControl interface in the component) will use this Interactivity setting when they are dynamically instantiated.

This is what the POC demonstrates - and it works as expected.

I explained in my post yesterday that the equivalent functionality is not currently working in the Oqtane framework. I outlined the specific steps to reproduce the problem above ie. the Site Settings and expected behavior. Note that state management works in the POC and it has been implemented in the framework as well.

I am not focused on the Login button or HTML/Text module - I need to figure out why modules which are supposed to render interactively (ie. Login module, User Profile module, etc... ) are behaving as static. The Html/Text module Index component has RenderMode = Static specified so it will always render statically - so it should not be used for testing interactivity.

[thabaum]

@sbwalker the issue i noticed was this error:

Maybe relating to the passing of parameters from ModuleInstance to child components. I read about adding [Serialization] to the model class, which I did but made no difference.

Once I got deeper into what was added to show the different modes I now understand more about the recent updates. I also have the POC running.

The odd thing, and maybe I am breaking static and it goes dynamic is that one issue in the POC where you can move the http client service below OnStateChange and it renders the Hello World without stream rendering.

Why it works like this here, and then I look at Oqtane things are so much more complex to even test there without some real deep thinking.

I am confident if we can resolve that error mentioned at top I think it will all work as intended.

Something is breaking the circuit which could be the parameters potentially, but interactivity is null. I also paid attention to the prerender defaults to true, thinking maybe that might have something to do with it.

Not sure if you noticed the toggle button I do not believe is working on static mode.

I have had my focus on the login so we can ... login :)

Would there be a better way to test how components render without going so deep into the code base? Some way we can simplify everything from ModuleInstance > RenderModeBoundary and then a basic component to test like just the login button similar to the POC?

One other thing is I put the login button from the POC into Oqtane to do some testing putting a <Login2 @rendermode="InteractiveServer"/> and I have it rendering all over the place, in the themes Default.razor, everywhere and no interactivity.

@namespace Oqtane.Themes.Controls

<button type="button" class="btn btn-primary ms-2" @onclick="LoginUser">@((_authenticated ? "Logout" : "Login"))</button>

@code
{
	private bool _authenticated = false;
	protected void LoginUser()
	{
		_authenticated = !_authenticated;
		StateHasChanged();
	}
}

This is way before any parameters are passed, and dont have any since just a boolean expression. This is useless all over the place, and should render.

I believe fixing that error is key if we can find out what is making it happen while stream rendering attribute is added...

In the end I created Login2 with render mode set on the component and Login3 setting it inside the component just to see if that has any affect. so far static SSR does not allow interactive anywhere...

I will continue to strip Oqtane down until I find what is causing that error or something more to chew on here tomorrow. I don't think it has anything to do with when the module renders or logic to get the modules set with different modes, something is bugging out the interactive rendering internally.

Could be a program.cs/startup.cs issue or something with how the site router logic that handles pages.

Maybe something can help you get started here with a new direction worth following.

[sbwalker]

@thabaum I am able to reproduce the same browser console error based on the specific use case I described above.

And since the POC does not have this error, it hopefully provides a clue in regards to why components are not becoming interactive.

One difference between the POC and the full Oqtane framework is that the SiteState, PageState, and ModuleState classes have many more properties in the full framework than they do in the POC. So perhaps one of these classes contains a property which is not serializable.

[thabaum]

@sbwalker I see a couple differences between POC and Oqtane 5.0.3 logic, but not sure it's causing anything.

For example in Oqtane:

@if (PageState.Site.RenderMode == RenderModes.Interactive || ModuleState.RenderMode == RenderModes.Static)
{
    <div>Render Mode: @PageState.Site.RenderMode</div><br />
	<RenderModeBoundary ModuleState="@ModuleState" PageState="@PageState" SiteState="@SiteState"  />
}
else
{
    <div>Render Mode: @ModuleState.RenderMode</div><br />
    <RenderModeBoundary ModuleState="@ModuleState" PageState="@PageState" SiteState="@SiteState" @rendermode="@RenderMode.GetInteractiveRenderMode(PageState.Site.Runtime, PageState.Site.Prerender)" />
}

RenderMode.cs

        public static IComponentRenderMode GetInteractiveRenderMode(string runtime, bool prerender)
        {
            switch (runtime)
            {
                case Runtimes.Server:
                    return new InteractiveServerRenderMode(prerender);
                case Runtimes.WebAssembly:
                    return new InteractiveWebAssemblyRenderMode(prerender);
                case Runtimes.Auto:
                    return new InteractiveAutoRenderMode(prerender);
            }
            return new InteractiveServerRenderMode(prerender); // default to interactiver server
        }

vs POC

	@if (ModuleState.RenderMode == "Interactive")
	{
		<DynamicRenderMode ModuleState="@ModuleState" PageState="@PageState" SiteState="@SiteState" @rendermode="@Utilities.GetRenderMode(PageState.InteractiveRenderMode)"></DynamicRenderMode>
	}
	else
	{
		<DynamicRenderMode ModuleState="@ModuleState" PageState="@PageState" SiteState="@SiteState"></DynamicRenderMode>
	}

Utilities.cs

        public static IComponentRenderMode GetRenderMode(string renderMode)
        {
            switch (renderMode)
            {
                case "InteractiveServer":
                    return RenderMode.InteractiveServer;
                case "InteractiveWebAssembly":
                    return RenderMode.InteractiveWebAssembly;
                case "InteractiveAuto":
                    return RenderMode.InteractiveAuto;
            }
            return null;

Which looks like was changed to add prerendering

---

Now for a potentially exciting update if we can figure out why I can now make it this simple login button from the POC work...

Those login buttons now work on the login page... but the login page component itself is not working. I will probably need to get a fresh start at this now to dig deeper. My best explanation is the way render modes are being set within Oqtane Framework vs the POC.

Difference i see is I am using @rendermode="InteractiveServer" and so does the POC, but in Oqtane we are using the prerender.

I read somewhere this needs to be false or true for prerendering, I also read that the @key will help retain element, component, and model relationships in ASP.NET Core Blazor.

From themebuilder.razor on I was able to interact with the buttons, but only on the page with interactivity enabled on the login form.

I believe one is a "Page" level render mode and the other works as a child of the page component level potentially.

This is my new error.
Screenshot of the buttons working:

And these buttons do not work on the home page some odd reason, only the login page. I get the error shown above and the one from before still showing up:

And currently my navigation menu isn't working possibly due to the login2 button included. I need a fresh start.

So maybe a page level and a module level are two different types of render mode settings that work in Blazor potentially is my guess... which I am naturally not 100% on :)

But if you step back and think about it, the Login page component is maybe getting more information than it can handle? Or your guess is better than mine here, but this is a difference in Logic which maybe the reason for the issue? I am setting all of login2 and login3 components@rendermode="InteractiveServer", they seem to work.

I will keep this copy of the dev branch as is since it seems to be displaying the proper behavior and start fresh with a new copy to dig into more details on the error and get this to more easily be reproduced without so many buttons all over... it kind of makes sense to me, which is why I was confused a bit earlier as I am still learning this at a more advanced level.

One other thing I want to play with more to see behaviors is the stream rendering attribute, @attribute [StreamRendering(true)] and @attribute [StreamRendering(false)] as of now we are using @attribute [StreamRendering]

And to show the screenshot one more time, the Head.razor login controls don't seem to render each time from looking at previous screenshot, but I do have those components there as well, and they are NOT interactive while the ThemeBuilder.Razor and on become interactive.

No solution yet, but some clues!

[thabaum]

@sbwalker

One difference between the POC and the full Oqtane framework is that the SiteState, PageState, and ModuleState classes have many more properties in the full framework than they do in the POC. So perhaps one of these classes contains a property which is not serializable.

This was my first guess, and I tried to work on this and maybe the problem is within this issue described about serialization of a parameter earlier produced from that error.

However from my last notes I show the Login page Login2 and Login3 buttons working, on homepage they are not.

To summarize, I believe that there are two ways to set render modes, and one works for the pages which would be site level for Oqtane and the other for components. The previous post explains why I believe this to be the case. I am still learning here so not 100% sure how to come up with a solution other than separation of concerns using the current logic for site level, and introducing logic that replicates the POC for module level.

I am on idle for working on it today, but I will continue to think about it and test a thing or two throughout the day/night. I will be more active on this tomorrow.

---

Quick links to related areas of interest for render mode, parameters and prerendering settings:

Page level or app level prerendering:

• Prerendering
• Prerender ASP.NET Core Razor components
• Components embedded into pages and views (Razor Pages/MVC)
• Interactive Routing and Prerendering
• Prerendering Guidance

Component Render Modes:

• Set the render mode by component definition
• Apply a render mode to a component instance
• Fine control of render modes

Serializable parameters:

• Child component with a serializable parameter
• Render mode propagation

I believe Microsoft documentation could clarify this better if it is the case. So much is scattered all over the place, a clue here, a clue there type of coding treasure hunt.

[sbwalker]

Update 2/12/2024: I was finally able to identify the interactive rendering issue. The obscure JavaScript error ("The list of component operations is not valid") from the browser console which @thabaum posted on the weekend provided a clue. This led me to Stack Overflow which suggested that it could be caused by parameter serialization. So I concluded that one difference between the POC and the full Oqtane framework is that the SiteState, PageState, and ModuleState classes have many more properties in the full framework than they do in the POC. So perhaps one of these classes contained a property which was not serializable. So I added some debugging logic to ModuleInstance.razor to attempt to serialize and then deserialize each parameter value which needed to be passed to the RenderModeBoundary.razor component (using the JsonSerializer):

As you can see it identified an error deserializing the PageState value. This is due to the Route property which is based on a class that only has a single constructor which requires parameters. Obviously .NET does not know how to handle this constructor - so it throws a deserialization exception. Adding a parameterless constructor resolves this issue:

        /// <summary>
        /// parameterless constructor to prevent deserialization exceptions
        /// </summary>
        public Route() { }

And with this tiny change (#3768), interactive rendering is now working as expected for modules.

NOTE: although this resolves the fundamental issue for allowing module components to render interactively, there are MANY scenarios which are incomplete. Specifically, any UI scenario which is expected to support static rendering (ie. is not a module component) will need to be refactored to support the static methodology.

[sbwalker]

The next major area I need to tackle is resource management ie. CSS and JS references. In static rendering, OnAfterRenderAsync() is not called... so there is no JS Interop support... which means that the techniques being used to inject resources dynamically in interactive render mode do not work in static render mode. As a result, JS and CSS resources are not being loaded which results in broken functionality throughout the framework when running in static render mode. This area was not implemented in the POC so it will require new logic.

[sbwalker]

Found another inconsistent behavior which seems like a bug in Blazor itself. Here is an example of a form with multiple buttons (a common scenario):

<form method="post" @onsubmit="Submit" @formname="MyUniqueFormName">
    <AntiforgeryToken />
    <button type="submit" class="btn btn-primary" name="Action" value="Action1">Action1</button>
    <button type="submit" class="btn btn-primary" name="Action" value="Action2">Action2</button>
</form>

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

@code {
    [SupplyParameterFromForm] public string Action { get; set; }

    private string _message;

    private void Submit()
    {
        _message = $"<br /><p>";
        _message += "Action: " + ((Action != null) ? Action : "NULL");
        _message += "</p>";
    }
}

When I run this using Static rendering it displays an action of “Action1” or “Action2” depending on which button I click (which is correct).

However, when I run this on Interactive rendering, the action always returns NULL (which is incorrect).

This makes it difficult to support complex forms.

Another issue I noticed is that when using forms, you often need to a redirect to a different Url – which is what NavigationManager.NavigateUrl() is intended for. However, when calling this method in Static rendering it throws an unhandled exception. The guidance from Microsoft is to adjust the Exception settings in Visual Studio to ignore this error – but for the majority of developers, they will assume this is a problem in the application code. Definitely some rough edges around this static rendering capability in .NET 8.

[thabaum]

@sbwalker are you talking about errors thrown due to navigation exceptions that are safe to ignore for an example would this issue of typing in a url like localhost:44357/dog that does not exist and throws an error trying to display the 404 page in place of the one that does not exist?

After you step through this error it navigates to the 404 page as expected.

[sbwalker]

@thabaum exactly... and there are many other scenarios in static rendering where the framework uses NavigationManager.NavigateTo(). See this issue and the recommendation from Microsoft on Github: dotnet/aspnetcore#13582 (comment) . One possible option is to create a wrapper method for NavigationManager.NavigateTo which ignores the exception - but this whole scenario seems really kludgy.

[thabaum]

@sbwalker we should be sure include some documentation on this as well to help provide this support as a known issue under our upcoming Oqtane static SSR component developer section once we settle in on our path going forward with this issue. I will comb through this discussion here when we are finished for these types of notes to review.

[sbwalker]

Update 2/13/2024: I have migrated a number of UI use cases to use the Static approach. In particular I have been focusing on the Control Panel as it is a central UI feature in Oqtane - and it needs to support both Static and Interactive render modes. One use case which was never explored in the POC was related to @onchange event handlers.

In Interactive rendering it is very easy to wire up an @onchange event handler:

<select name="category" class="form-select mt-1" @onchange="(e => CategoryChanged(e))">

However this event is not supported in Static rendering (neither is @onclick). However I have not been able to find any .NET 8 examples online which demonstrate how you would replicate the @onchange functionality using static techniques. So if anyone is able to find a functional example, it would be very appreciated.

The only examples are for onclick - https://learn.microsoft.com/en-us/aspnet/core/blazor/forms/?view=aspnetcore-8.0

[leigh-pointer]

@sbwalker does this help

<input type="number" @bind-value:event="onchange" @oninput="DoAnInputMethod" @bind-value="Model.MyProperty" />

Use different events for binding and handling. You can bind the value of your input element to a property using the @bind-value:event=“onchange” attribute, and then handle the input event separately using the @oninput attribute. For example:

[sbwalker]

@thabaum so based on the response to this issue: dotnet/aspnetcore#54018 it appears that the recommended way to handle onchange events is to use JavaScript.

However, if you are trying to build a component which supports both interactive and static render modes, this is problematic because interactive render mode only supports JavaScript through JS Interop - whereas static render mode does not support OnAfterRender/JS Interop. So you would need to include different implementations and utilize conditional logic based on render mode. This is a not optimal from a code complexity/maintainability perspective - so I consider this to be a show stopper.

This means that the alternative solution of forcing the Control Panel to be an interactive component and including a "shim" component to marshal state across the render mode boundary is the better approach. PR #3786 includes the changes to make this functional.

[thabaum]

@sbwalker this is exactly what I was trying to get everyone to be aware of say and I as a I recalled from past videos or information consumed related. I just could not find a quick source to present this to you. Thanks for the link.

I think we should focus on how we can introduce static SSR without breaking much if anything for the current Global Interactivity option. This way people can test adopting it.

I really think mission accomplished here for static SSR. We need to review things closer make sure we are 100% happy with the results being as expected and move forward with the Interactive Auto features test with it pushing the DLL information securely from within Oqtane to clients and ensure everything is very secured and documented how to produce different results.

Also any work needed for making the server-side services. As far as static SSR goes, I think we just need to demonstrate it works... the html module and theme accomplishes this by showcasing you can develop a static module with dynamic components for the editor for example. The login and administration features shows interactivity. This is very powerful option and exciting to see we made it here as we all had our concerns going forward worth noting.

I don't believe anything that is a huge expense is worth moving away from our next steps towards the goal of converting Oqtane to full blown .NET 8 compatibility for additional developer flexibility. At the same time if it is to show a POC maybe it is worth it. These choices are above my pay grade :)

Awesome to see the control panel component and all the administration working interactively in static SSR mode enabled. We should be able to mix SSR and CSR along with AUTO interactive components on top of the static.

Something like the control panel could possibly be an interactive CSR/WebAssembly component that may get some good use out of the auto feature since I don't believe holds any sensitive information. This is kind of what my mind is trying to wrap around, how flexible is Oqtane going to be and where do we draw the lines for interactivity options.

This is why I felt maybe an option to override a component by a host or administrator maybe an option. But I suppose this can be set in the module settings at time of development to hand that power off to an admin or not if the component can handle it.

Thanks for taking time with all the clarifications.

To The Moon and Beyond! 🚀

[sbwalker]

@thabaum the link I shared above (dotnet/aspnetcore#54018) is an Issue I just created yesterday in the aspnetcore repo... to determine if there is any support for onchange in static rendering (because I could not find any examples).

As far as "mission accomplished" there are still a number of critical pieces of functionality which do not work in static render mode. The main one is module level resources (ie. stylesheets and JavaScript). You can see this problem in action if you set your Site to Static Rendering and go into Edit Mode and click Edit on one of the Html/Text modules. The RichTextEditor is broken because the module-level resources are not being loaded. Note that in this scenario the Edit.razor is rendered Interactively however the static resources are managed by ThemeBuilder.razor which is rendered statically. I am still trying to resolve this issue.

[sbwalker]

Actually... on a related note, the Page Title is also not being set properly when using static rendering - which is a fairly critical functionality. This issue in the aspnetcore repo dotnet/aspnetcore#50268 refers to issues with the HeadOutlet component not working - which is what the Oqtane Head component is based on. This comment:

"The problem is that the title gets removed when the render mode kicks in on a SSR page where PageTitle is not interactive."

describes the problem I am seeing.

EDIT: It looks like this never worked in the POC either :(

[thabaum]

I am noticing more of these odd behaviors. Between these and now the Maui app is working again we are having static render mode issues. (works with global interactivity). I was able to get the login button to work once without an error, but the login page component didnt render. I believe that the button is static but being rendered interactively possible due to the if/else render mode logic when hybrid is enabled in ModuleInstance.razor. I am also reviewing Head.Razor and Main.razor in the Oqtane.Maui project itself for ideas and clues for this relating issue I reported #3793.

[thabaum]

@sbwalker I am seeing two uses of getting the page render mode: PageState.RenderMode and PageState.Site.RenderMode in recent commits and logic.

One was just shortened it looks like intentionally here: https:/oqtane/oqtane.framework/pull/3797/files 2
Oqtane.Client/Themes/Controls/Container/ModuleActions.razor||

Are these two different render mode classes that Oqtane will support. If this is being moved would it be helpful for me to or will you update them all to the new namespace?

[sbwalker]

@thabaum the difference is explained here: #3793 (comment) I don't believe anything needs to be modified.