DashboardLayout offers no way to reopen the desktop sticky picker: isSidebarOpen is both 'should it exist' and 'is it showing'

[fitzergerald]

Summary

Below the md breakpoint, DashboardLayout renders sidebarContent inside a BottomSheet and pairs it with a floating action button to reopen that sheet. But WidgetPicker draws its own close control (aria-label="Close widget picker") inside that content, and that control is wired to the consumer's onClose - the same callback that clears isSidebarOpen.

So on mobile there are two close affordances in the same sheet with different and irreconcilable outcomes:

• The sheet's own close clears DashboardLayout's internal open state. isSidebarOpen stays true, so the FAB renders and the user can reopen the sheet. Correct.
• WidgetPicker's X runs the consumer's onClose, which clears isSidebarOpen. That unmounts the sheet and the FAB together, so the picker cannot be reopened at all until the consumer's own state cycles.

The second one is a dead end the user cannot get out of from the UI.

Where

DashboardLayout, mobile branch (from the built 0.22.6 bundle, names shortened):

isSidebarOpen && isMobile && (
  <>
    <BottomSheet open={internalOpen} onClose={() => setInternalOpen(false)} ...>
      {sidebarContent}
    </BottomSheet>
    {!internalOpen && <Fab onClick={() => setInternalOpen(true)} ... />}
  </>
)

Both the sheet and the FAB are gated on isSidebarOpen, so anything that clears it takes the FAB with it. WidgetPicker's X is rendered inside sidebarContent, which is exactly what the sheet is displaying.

Why the consumer cannot fix this cleanly

A consumer could make its onClose breakpoint-aware - clear isSidebarOpen on desktop, do nothing on mobile - but that requires restating Sistent's md breakpoint in the consumer, so the panel's behaviour and the component's layout decision become two values that must agree and nothing checks. That is the class of bug we were already fixing in layer5io/meshery-cloud#5992, so we declined to introduce another instance of it and left the X consistent with desktop.

Suggested fix

WidgetPicker should not render its own close control when it is being displayed inside the bottom sheet - the sheet already provides one, and the two mean different things. Options, in rough order of preference:

1. DashboardLayout tells WidgetPicker it is embedded (a context value or an internal prop), and WidgetPicker omits its X in that case.
2. WidgetPicker takes an explicit prop to suppress the close control, and DashboardLayout sets it on the mobile branch.
3. DashboardLayout gates the FAB on something other than isSidebarOpen, so a consumer clearing that prop still leaves a way back.

Either of the first two keeps the breakpoint knowledge inside the component that already owns it.

Consumer status

Not blocking. layer5io/meshery-cloud#5992 separated panel visibility from its edit-session lifetime, so the X is no longer destructive there - it closes the panel and the edit session continues with its guards armed. On mobile the picker simply cannot be reopened until edit mode cycles, which is a degraded but non-destructive state, and better than the behaviour it replaced.

Related: #1843, #1844.

[fitzergerald]

Correction: this is not mobile-specific, and mobile is the better-behaved case

I framed the original report around the mobile FAB. That framing is wrong, and it understates the problem. Re-reading the 0.22.6 bundle, DashboardLayout renders exactly three states:

children: [
  <Box sx={{flex:1, padding:0, minWidth:0}}>{children}</Box>,
  isSidebarOpen && isMobile  && <><BottomSheet open={internalOpen} …>{sidebarContent}</BottomSheet>
                                  {!internalOpen && <Fab aria-label="Open Widget Picker" …/>}</>,
  isSidebarOpen && !isMobile && <Box sx={{position:"sticky", …}}>{sidebarContent}</Box>,
]

When isSidebarOpen is false neither branch renders. So a consumer whose onClose clears that prop loses the picker at every breakpoint, with no toggle anywhere - not just below md.

Mobile is in fact the less affected case: while isSidebarOpen stays true, Sistent itself provides the "Open Widget Picker" Fab, so the sheet's own close is fully reversible. Desktop has no equivalent - the sticky panel is rendered or it is not, and the component offers nothing to bring it back.

So the accurate statement of the defect is:

WidgetPicker renders a close control whose only possible wiring is the consumer's onClose, and the only thing that callback can do to hide the panel is clear isSidebarOpen - which is also the prop that removes the sole reopen affordance Sistent provides, and on desktop there is no reopen affordance at all. The component offers a way to close itself and no way to open itself.

The suggestions in the original report still stand (have DashboardLayout tell WidgetPicker it is embedded so the X can be omitted; or gate the Fab on something other than isSidebarOpen), but one more is worth considering and is arguably the root:

• DashboardLayout should own the picker's open/closed state rather than deriving it from a single consumer-owned prop, exposing an uncontrolled default plus an optional controlled pair. Today "should this panel exist at all" and "is the panel currently showing" are the same boolean, which is exactly why the close control cannot be made reversible by any consumer.

Consumer status, updated

layer5io/meshery-cloud#5992 is adding its own reopen affordance in the dashboard's action row, so Cloud is not blocked and does not need a Sistent change to be correct. That workaround is a consumer supplying a control the component arguably ought to provide, which is the part worth fixing upstream.

Apologies for the mis-framed original - the mobile detail was real but it was a symptom, not the shape of the bug.

[fitzergerald]

Narrowing this to desktop: the mobile half is solved, and not by Sistent

The consumer (layer5io/meshery-cloud#5992) has since hidden WidgetPicker's header row below md:

containerSx={{ "& > :first-child": { display: { xs: "none", md: "flex" } } }}

That removes WidgetPicker's own close control on mobile, which means the only dismissal there is BottomSheet's own close - and that clears DashboardLayout's internal open state while leaving isSidebarOpen true, so the "Open Widget Picker" Fab renders and the sheet is reopenable. The mobile dead end is gone.

It is worth being precise about why, because it is a point in the component's favour: below md Sistent already ships a correct close/reopen pair. The defect only appeared because a second close control - WidgetPicker's own - was layered on top of it and wired to the one prop that removes the reopen affordance.

What remains, and it is only desktop

Above md, DashboardLayout renders the sticky panel and offers no reopen affordance at all. A consumer whose onClose clears isSidebarOpen loses the panel with no way back; a consumer that does nothing in onClose ships a close button that does not close. There is no third option inside the component's current API.

So the remaining question is narrower than originally filed:

Should DashboardLayout own the picker's open/closed state on desktop - an uncontrolled default plus an optional controlled pair - so the sticky panel gets the same close-and-reopen pair the bottom sheet already has?

Today "should this panel exist at all" and "is the panel currently showing" are the same boolean above md, which is why no consumer can make that close control reversible on its own.

Consumer status

Still not blocking, and now solved on both sides in the consumer: Cloud adds an Add Widgets control to its own action row, which restores reopen above md, and the contributor's mobile hide covers below md. That workaround is a consumer supplying a control the component arguably ought to provide on desktop, which is the part still worth fixing here.

Superseding my earlier framing twice over: the original report said this was mobile-specific (wrong - it was every breakpoint), and the first correction said it was every breakpoint (now true only of desktop). Apologies for the churn; the current statement is the one that holds.