Improve summary details view / toolbars / navbar experience on desktop for low-vision users, as well as mobile users

[adamint]

Makes page layout / toolbars / detail views accessible to users with low viewport widths and heights (including mobile and desktop low-vision users, both of which I'll refer to as mobile), but does not yet make individual pages accessible.

This is done by

1. Standardizing pages to use AspirePageContentLayout to lay out their content
2. Add specific DesktopLayout and MobileLayout
3. Make the entire page content scrollable at very low page height for desktop users (as otherwise the page title will significantly obscure page content). In the below screen recording you can see how page scrolling works for 1) very low page height, 2) typical mobile viewports, and 3) typical desktop viewports

Screen.Recording.2024-05-28.at.12.15.12.PM.mov

4. Handle browser resizes (and block until we can initially size the viewport) with BrowserDimensionWatcher.razor.cs

5. Making toolbars appear as buttons at the bottom of the screen for mobile users

6. Expanding details views on mobile to be the full page height, minus the navbar

7. Removing the AppBar and adding a navigation menu similar to microsoft.com

Name	Desktop before	Desktop after	Low vw/vh desktop before	Low vw/vh desktop after	Mobile before	Mobile after
Resources page				video
Console logs page				video
Structured logs page
Trace details summary detail view			(unable to even get details on screen)

Microsoft Reviewers: Open in CodeFlow

[JamesNK]

On the metrics page it looks kind of odd that there are two places for filters. I wonder if graph filters should move into the view filters popup.

I don't think we have to resolve that now.

[JamesNK]

Getting close 👍

[adamint]

What do you think about moving the metrics instrument section from a tree to the filter popup? It's basically a filter, just displayed in a tree in a sidebar instead of dropdown at the top of the page.

Could be done in a follow up PR.

On the metrics page it looks kind of odd that there are two places for filters. I wonder if graph filters should move into the view filters popup.

Those are both good ideas. Modifying the metric page is out of scope of this PR, I'll include it in follow-up work on this page.

[adamint]

Metrics filters and state like showing count is being lost when switching between views.

This has been fixed by moving that state out of the chart container and into a separate service, since the chart gets re-created.

[JamesNK]

This has been fixed by moving that state out of the chart container and into a separate service, since the chart gets re-created.

@SteveSandersonMS Hi, Blazor question for you. We're adding two views to Aspire: desktop view and mobile view.

Right now, we have page content embedded in each view, which means switching view, causes by the browser window resizing, loses the current page content state. To work around this, we have to store the state somewhere externally and pass it to the page content when it's re-initialized in the new view.

Is there a way to "move" a Blazor component? We want to remove it from one place (the old view) and add it to the other place (the new view).

[SteveSandersonMS]

@JamesNK As much as possible, the web-native way to do this is with CSS - a combination of media queries and flex/grid makes it possible to have a single markup representation for very different-looking layouts on different form factors. From the animated GIFs above it looks to me like CSS would comfortably handle this (and would be a lot less code to deal with) but perhaps I'm missing something.

If you must have two physically separate components for the two cases, then you're already doing the right thing of keeping the state external. There isn't a way to move a Blazor component from one parent to another (many parts of the developer programming model, and the framework internals, assume a lifecycle in which components are attached to the hierarchy one time only).

[adamint]

@JamesNK As much as possible, the web-native way to do this is with CSS - a combination of media queries and flex/grid makes it possible to have a single markup representation for very different-looking layouts on different form factors. From the animated GIFs above it looks to me like CSS would comfortably handle this (and would be a lot less code to deal with) but perhaps I'm missing something.

If you must have two physically separate components for the two cases, then you're already doing the right thing of keeping the state external. There isn't a way to move a Blazor component from one parent to another (many parts of the developer programming model, and the framework internals, assume a lifecycle in which components are attached to the hierarchy one time only).

It is notable that this is a Blazor-specific problem, where there is no facility to avoid disposing/re-creating the main "Body" component of a page when the MainLayout is changed. Responsive component rendering is an established, working pattern in some other frameworks (such as React + Chakra UI). The Blazor behavior appears like a bug. @SteveSandersonMS

[adamint]

@JamesNK I fixed the issue of console logs not updating after layout. I don't think there were any other requested changes

[SteveSandersonMS]

Responsive component rendering is an established, working pattern in some other frameworks (such as React + Chakra UI)

Can you point to a doc showing what you mean exactly? Normally "responsive" within the context of front-end web apps refers to CSS functionality that does work equally with Blazor.

I don't know whether reparenting is really supported in React - an initial search suggests it's not a native feature as of a few years ago, and I didn't see any clear indication this has changed. But perhaps I'm missing something.

Blazor's nonsupport for reparenting is an intentional design choice, not a bug :)

[JamesNK]

@JamesNK As much as possible, the web-native way to do this is with CSS - a combination of media queries and flex/grid makes it possible to have a single markup representation for very different-looking layouts on different form factors.

Yeah, I have a feeling that the right CSS might have gotten a lot of the way there. But this PR is pretty far advanced, and I don't think we should restart it. And server control over HTML does give ultimate control compared to CSS.

In the future we could look at whether AspirePageContentLayout.razor could be refactored to make the overall page layout changes using CSS. That would eliminate the issue with the @MainContent being thrown away and recreated, which is the source of most state issues.

[JamesNK]

@JamesNK I fixed the issue of console logs not updating after layout. I don't think there were any other requested changes

Something is wrong with console line numbers. Every time I refresh the page, it increases by about 1000.

And when switching to other resources, their logs also start from a number that is way too high instead of 1.

[adamint]

@JamesNK I fixed the issue of console logs not updating after layout. I don't think there were any other requested changes

Something is wrong with console line numbers. Every time I refresh the page, it increases by about 1000.

And when switching to other resources, their logs also start from a number that is way too high instead of 1.

Good catch but this is an issue on main, not just this branch. I'll file separately, but the incorrect line numbers originate outside of dashboard frontend, from outside the DashboardClient

  {[ { \"isStdErr\": false, \"lineNumber\": 177 }, { \"isStdErr\": false, \"lineNumber\": 178 }, { \"isStdErr\": false, \"lineNumber\": 179 }, { \"isStdErr\": false, \"lineNumber\": 180 }, { \"text\": \"2024-07-16T14:39:46.226Z d1abdbfda055238105139ff85545a67981be543d290f48269a510becc4715e39\", \"isStdErr\": false, \"lineNumber\": 181 }, { \"isStdErr\": false, \"lineNumber\": 182 }, { \"isStdErr\": false, \"lineNumber\": 183 }, { \"text\": \"2024-07-16T14:39:47.590Z d1abdbfda055238105139ff85545a67981be543d290f48269a510becc4715e39\", \"isStdErr\": false, \"lineNumber\": 184 }, { \"isStdErr\": false, \"lineNumber\": 185 }, { \"isStdErr\": false, \"lineNumber\": 186 }, { \"text\": \"2024-07-16T14:39:47.601846904Z 1:C 16 Jul 2024 14:39:47.601 * oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo\", \"isStdErr\": false, \"lineNumber\": 187 }, { \"text\": \"2024-07-16T14:39:47.601890506Z 1:C 16 Jul 2024 14:39:47.601 * Redis version=7.2.5, bits=64, commit=00000000, modified=0, pid=1, just started\", \"isStdErr\": false, \"lineNumber\": 188 }, { \"text\": \"2024-07-16T14:39:47.601895007Z 1:C 16 Jul 2024 14:39:47.601 * Configuration loaded\", \"isStdErr\": false, \"lineNumber\": 189 }, { \"text\": \"2024-07-16T14:39:47.602168319Z 1:M 16 Jul 2024 14:39:47.601 * monotonic clock: POSIX clock_gettime\", \"isStdErr\": false, \"lineNumber\": 190 }, { \"text\": \"2024-07-16T14:39:47.602779946Z 1:M 16 Jul 2024 14:39:47.602 * Running mode=standalone, port=6379.\", \"isStdErr\": false, \"lineNumber\": 191 }, { \"text\": \"2024-07-16T14:39:47.603594882Z 1:M 16 Jul 2024 14:39:47.603 * Server initialized\", \"isStdErr\": false, \"lineNumber\": 192 }, { \"text\": \"2024-07-16T14:39:47.603606283Z 1:M 16 Jul 2024 14:39:47.603 * Loading RDB produced by version 7.2.5\", \"isStdErr\": false, \"lineNumber\": 193 }, { \"text\": \"2024-07-16T14:39:47.603609583Z 1:M 16 Jul 2024 14:39:47.603 * RDB age 15 seconds\", \"isStdErr\": false, \"lineNumber\": 194 }, { \"text\": \"2024-07-16T14:39:47.603612483Z 1:M 16 Jul 2024 14:39:47.603 * RDB memory usage when created 0.92 Mb\", \"isStdErr\": false, \"lineNumber\": 195 }, { \"text\": \"2024-07-16T14:39:47.603615583Z 1:M 16 Jul 2024 14:39:47.603 * Done loading RDB, keys loaded: 1, keys expired: 0.\", \"isStdErr\": false, \"lineNumber\": 196 }, { \"text\": \"2024-07-16T14:39:47.603618783Z 1:M 16 Jul 2024 14:39:47.603 * DB loaded from disk: 0.000 seconds\", \"isStdErr\": false, \"lineNumber\": 197 }, { \"text\": \"2024-07-16T14:39:47.603621484Z 1:M 16 Jul 2024 14:39:47.603 * Ready to accept connections tcp\", \"isStdErr\": false, \"lineNumber\": 198 } ]}

^ doesn't start from 0 (DashboardClient.cs#483)

[adamint]

never mind, it's been filed already in #4893 - should be routed to AppHost