[#104] Implement StyledGroup component to handle style loading state.

[esso23]

104

WIP

Usage:

<StyledGroup @bind-Loading="@mLoading">
    <Styled>
        ...
    </Styled>
    ...
</StyledGroup>
<Component style="@Visibility">
    ...
</Component>

private bool mLoading = true;
private string Visibility => mLoading ? "visibility: hidden" : null;

This is my proposal to solve the issue mentioned in #104. Possible improvements:

• StyledGroup could provide the visibility style directly.
• StyledGroup could be renamed to something more descriptive

[chanan]

Awesome, I will take a look at this after I fix the issues with system.text.json and the object pool extensions dll.

Regarding performance, Many of the performance gains of v3 are in parsing code which occur prior to the javascript call. What are you thoughts of v3.5 adding back the older style of writting to the head using a Blazor tag (like it was doing in v2) assuming that part is faster than the pure javascript way. You would lose some functionality but I don't think you are using those things anyway. It would take some work on my part to support both ways, but then end user can choose which way they want to use BlazorStyled. Thoughts?

[esso23]

Tested on my current project, seems to work fine.

Known issues:

• Since OnAfterRender is called many times for some reason, I still sometimes see a small (few millisecond) flicker when rendering starts. This is caused by a call to StyleGroupContext.SetRendering(false); in OnAfterRenderAsync a small delay and then registering new tasks which causes the context to switch to finalized state for a brief moment and then switch back to Loading state. I was thinking about implementing a simple debouncer for this purpose, but I don't want to overcomplicate things.

Remarks:

• I'm not sure what will happen when you use nesting of StyleGroup components.
• StyleGroup applies to all components and their children in the hierarchy, which can generate a lot of tasks. In my case, it's around 5-6 thousand tasks registered when rendering a larger component. Can be tens of thousands in some cases.

Answering your question: I think I already answered it in the issue. The difference in performance is not caused by the approach you chose in v2/v3, but in the execution. When executed in parallel and asynchronously, the performance is actually very similar, so I see no reason to revert back to the old approach.

[chanan]

@esso23 I was waiting for MS to solve: https://github.com/dotnet/aspnetcore/issues/23126 before merging this, but it seems it isn't going to be so fast, so I will merge this either over the weekend or early next week. Sorry for the delay.

[esso23]

I pushed the debouncer aswell since it was useless without it in my case. I was using timeouts between 250-500ms to eliminate flickers. Feel free to revert it if you don't want it there. The obvious downside is that loading cannot take less than the timeout (but only if the styles are not loaded yet).

[chanan]

@esso23 Sorry for the very late reply on this. I was finally able to fix the issue with BlazorStyled and system.text.json.

I put the Tag <StyledGroup> around all the cshtml in MainLayout.cs. Running the client side project worked fine. However running the ServerSideSample project exits debug mode without a lot of information:

C:\Users\cbraunstein\source\Personal\BlazorStyled\src\ServerSideSample\bin\Debug\netcoreapp3.1\ServerSideSample.exe (process 23632) exited with code -1073741819.

and in the output window:

The program '[23632] ServerSideSample.exe' has exited with code -1073741819 (0xc0000005) 'Access violation'.

[chanan]

A little more info on this, there seems to be an infinite loop in StyledGroupContext.SetRendering

[chanan]

Released 3.1.0