Persist resizable shell panel widths

[nwhittaker]

Check existing issues

• I have checked for existing issues to avoid duplicates

Description

The width of a resizable <calcite-shell-panel> currently resets upon refreshing the browser window. The requested enhancement is that, if the user had resized the panel manually, the panel stays that width until the user changes it again -- even after refreshing the window and possibly extending across sessions.

While it's possible for the consuming app to implement this functionality using resize observers and setting Calcite CSS variables, there is enough room for variance in the requirements that we'd likely end up with an inconsistent UX across Esri apps.

Acceptance Criteria

• The width of a manually resized shell panel is restored after refreshing the browser window.
• The width of a manually resized shell panel is restored after expiring the browser session, and starting a new session(?).
• Within a routing webapp, the width of a manually resized shell panel is restored after navigating away from, and back to, a view with the shell panel.
• If the width of the viewport changes after navigating away, the restored width takes up the same percentage of the viewport, rather than the same pixel value(?).

Relevant Info

Other components provide a storageId prop for persisting state to local storage. Something similar might work well here.

Which Component

Shell panel

Example Use Case

Field Maps Designer is interested in using the <calcite-shell> and <calcite-shell-panel> elements to create several list/detail views across several different routes. If the user decides to give the detail view a little more room by resizing the shell panel, it'd be nice to maintain that width when visiting the other related list/detail routes.

Priority impact

p3 - want for upcoming milestone

Calcite package

• @esri/calcite-components
• @esri/calcite-components-react
• @esri/calcite-design-tokens
• @esri/eslint-plugin-calcite-components

Esri team

ArcGIS Field Apps

[macandcheese]

I agree with the desired end user experience here in most cases, although there could be times it is unexpected to persist, depending on workflow.

We did have a discussion issue about re-evaluating the two instances we do provide localStorage functionality (#8029).

This is just IMO, I am not sure from a design standpoint we’d always want this behavior. Some apps may want to provide settings to configure widths, or offer a user setting to save the width or not , that could conflict with this as a default behavior.

In variable width or percentage based shell panels, the width may also change based on viewport change, not just user resize, so observing changes to width as a user is definitely not the easiest - we haven’t to this point exposed events for resize start / stop, but it has come up a lot recently.

[geospatialem]

Blocked by #8029.