Switch from Static render mode to Interactive when Edit mode

[mdmontesinos]

I noticied that managing pages with a lot of modules in static render mode is quite slow as it requires several enhanced navigations, which basically means all the modules are loaded again in the server and sent back as html with the overhead this supposes.

Therefore, I was wondering if it would be possible/wise to have a mechanism where static modules are made interactive when the user has logged in and has edit permission on the page/module (perhaps only in server mode, not wasm?). In this way, for example, the Action Dialog to delete modules would be interactive instead of with form submissions, and the same applies to switching to edit mode.

And also, you already have a SignalR connection opened for the interactive control panel and the site is interactive so you wouldn't be crossing any render mode boundaries anyway.

Any thoughts or comments about this idea?

[sbwalker]

@mdmontesinos have you tested this with the 5.2.0 release? One of the main areas of focus in 5.2.0 was related to performance/scalability - specifically the UI scenarios which cross render mode boundaries (ie. Module Actions Menu, Control Panel) were optimized in the release.

To elaborate on this a bit further, every single component in a page is treated as an independent UI element by Blazor. So let's say you are using static rendering for your site and you have 10 HtmlText modules on a page. By default the page will be fully rendered statically. However when you login as an Admin and enable Edit mode, all of the "interactive" features will be activated. This includes the Control Panel which is an interactive component. It also includes the Module Actions Menu which is rendered for each module instance - so 10 interactive components in this scenario. As part of the Blazor rendering process, there will be 11 different components which need to cross the render mode boundary from static to interactive. Each of these components have state which is passed as parameters. This usually includes the standard Oqtane state objects for PageState and ModuleState. In each of these cases the state which is passed as parameters to a specific interactive component will be serialized/encrypted into the page output, as this is the way that Blazor handles render mode transitions. So if the serialized/encrypted size of a PageState object is 50KB then you will have 550KB of "viewstate" injected into your page output (as you have 11 interactive components). Based on this example, you can see how this can very quickly become a major problem. In the scenario I just described there were only 10 modules on the page... however imagine a static module with a grid control where some of the elements in each grid row are interactive components (ie. ActionLink, ActionDialog) - in this case the number of individual components with render mode boundaries would be much higher resulting in massive viewstate. I actually had an example where there was 4.2MB of viewstate being injected into a page! The solution in 5.2.0 was to trim the size of the parameters as much as possible to reduce the amount of viewstate. The other solution is to try to reduce the number of render mode transitions ie. by avoiding mixing render modes, or by reviewing the functionality and if you have a lot of interactive components in your UI then make the parent component interactive as well.

[mdmontesinos]

Yes, I'm using the dev branch in its latest version.

And the situation you describe is exactly what I'm facing. Around 15 different modules in the same page, where several of them include grid items with ActionLink and ActionDialog so I assume the viewstate will be heavy.

The ActionDialog to delete the items triggers several form submissions (when opening and closing the modal) which is why I was wondering how to make it interactive so that it uses the onclick event and saves some navigations.

[sbwalker]

@mdmontesinos for modules which are primarily interactive (ie. containing grids with interactive buttons, etc...) I would suggest setting the RenderMode for the component to Interactive, as you are not getting any benefit from static rendering:

public override string RenderMode => RenderModes.Interactive; (or just remove this property assignment as the default is Interactive)

[mdmontesinos]

Sorry, I didn't explain myself properly. I meant the pager that appears only in edit mode to delete/edit items in the module. The module itself is static as it displays a carousel of images.

[sbwalker]

@mdmontesinos it sounds like you are trying to mix different use cases within the same module component. Generally it is better to separate those concerns into different components. For example your Index component would be static and display the carousal. It could contain a single Manage button which becomes visible when you go into Edit Mode. Clicking Manage will display the Manage component which is interactive and contains a grid and allows management of individual items. This clearly separates the front-end (view) from the back-end (admin) and allows you to employ the appropriate render mode for each scenario.

[mdmontesinos]

You are right that it should probably be separated into different modules. However, the Pager with the ActionLink/Dialog for each element comes from the default module template, which is static by default as well.

[sbwalker]

@mdmontesinos looping back to this item... the original thread contains a suggested solution for dealing with interactivity with Static render mode, but it never clearly outlines the actual problem and how to reproduce the issue. Based on the last post I am guessing it has something to do with the ActionDialog component in Static render mode - but it is still not clear. If you are able to elaborate it would be helpful.

[mdmontesinos]

@sbwalker Yes, let me further elaborate on what I mean with an actual example.

I have this module that, when on Edit mode, shows a pager with ActionLinks to the Edit page and ActionDialogs to Delete for each slide of the carousel (similar to the default module template):

@if (PageState.EditMode)
{
    <ActionLink Action="Add" Text="Add Video to Carousel" EditMode="true" Security="SecurityAccessLevel.Edit" />
    <br />
    <br />

    @if (_VideoCarousels.Count != 0)
    {
        <Pager Items="@_VideoCarousels">
            <Header>
                <th style="width: 1px;">&nbsp;</th>
                <th style="width: 1px;">&nbsp;</th>
                <th>Title</th>
            </Header>
            <Row>
                <td><ActionLink Action="Edit" Text="Edit Video" Parameters="@($"id=" + context.VideoCarouselId.ToString())" EditMode="true" Security="SecurityAccessLevel.Edit" /></td>
                <td><ActionDialog Action="Delete" Text="Delete Video" Id="@($"{ModuleState.ModuleId}:{context.VideoCarouselId}")" OnClick="@(async () => await Delete(context))" Header="Delete Video Carousel" Message="Are You Sure You Wish To Delete This Video of the Carousel?" Class="btn btn-danger" EditMode="true" Security="SecurityAccessLevel.Edit" /></td>
                <td>@context.Title</td>
            </Row>
        </Pager>
    }
}

As the module itself is Static, the ActionDialog to delete is rendered as a form and the click is a form submission with enhanced navigation. Therefore, everytime I open the modal to delete a slide, the page is rendered again in the server and enhanced navigation patches the differences. Now imagine a page with 10 modules where some modules can take 1 or 2 seconds to render, clicking the button to open the modal would make the user wait several seconds until it is displayed. This makes the content management process really tedious. Additionally, the scroll position always goes back to top even if you were deleting items near the bottom of the page.

The proposed solution was to move all this logic to a "Manage" component, which is of course a valid option, but prevents the content manager from having a quick way of deleting items from the main page, without having to navigate further to each module "manage" component. Also, this does not "align" with the default module template, which contains the pager with the ActionLinks to the Edit component and ActionDialogs to delete.

My suggestion was to render the ActionDialog as an interactive component instead of form submissions. When on edit mode, the site already has components with interactivity and a web socket connection is opened, so why not also render these ActionDialogs interactively?

ActionDialog already has a condition that checks if the PageState.RenderMode is interactive:

@if (PageState.RenderMode == RenderModes.Interactive || ModuleState.RenderMode == RenderModes.Interactive)

Therefore, my idea was something like making the page RenderMode be interactive when the user is logged in and in edit mode. However, as you mentioned in the first comment this could be problematic due to the "viewstate" being massive.

[sbwalker]

@mdmontesinos thank you for the more detailed explanation. Trying to mix interactive and static requirements within the same component is problematic for a number of reasons - so the recommendation to separate the concerns is the best approach.

The default module template is a very simplistic example for getting started with Oqtane module development - however it is expected that developers will need to customize the implementation to achieve their specific usage requirements.

[mdmontesinos]

@sbwalker I will take your recommendation and separate all management options into a different component. Still, I believe that having a default module template that doesn't follow best practices is a huge issue for new developers. Also, perhaps there should be different templates that implement best approaches for interactive and static modules.