[Dialog] Add new component, deprecate modal component

[geospatialem]

Check existing issues

• [X] I have checked for existing issues to avoid duplicates

Description

The ModelBuider Web team is seeking a movable, non-attached component in early 2024 to support a workflow not requiring an additional click and is not restrictive for the user experience, where the use case cannot use modal as a solution.

We should identify if the new dialog component should support:

• Resizing
• Moving

Or, if not, what the recommended workflow would be for support with docking or an alternative approach.

Acceptance Criteria

1. Dependency issues
   • Panel
     • [ ] https://github.com/Esri/calcite-design-system/issues/6980
     • [x] https://github.com/Esri/calcite-design-system/issues/8979
     • [x] https://github.com/Esri/calcite-design-system/issues/8980
     • [x] https://github.com/Esri/calcite-design-system/issues/8981
   • Modal
     • [x] https://github.com/Esri/calcite-design-system/issues/7668
2. Add a new dialog component
   • "Render a panel inside" paradigm - refer to popover, sheet, and shell-panel
   • Properties
     • modal/non-modal
     • kind
     • placement
     • heading
     • description
     • scale
     • scale-width
     • fullscreen (under consideration 🚧 )
       • cc https://github.com/Esri/calcite-design-system/issues/6191
     • resizable (under consideration 🚧 )
     • draggable (under consideration 🚧 )
   • Slots
     • content
     • header
     • alerts
3. Deprecate the modal component

Relevant Info

Originally reported in https://devtopia.esri.com/WebGIS/calcite-design-system/issues/163

Which Component

New component

Example Use Case

See the internal issue for additional context.

Priority impact

impact - p3 - not time sensitive

Calcite package

• [X] @esri/calcite-components
• [ ] @esri/calcite-components-react
• [ ] @esri/eslint-plugin-calcite-components

Esri team

N/A

[driskull]

The use case cannot use modal as a solution.

Can you elaborate on this a bit? I don't see why a non blocking modal (scrim turned off) couldn't support this better.

It seems like modal would fit this use case better or if not, we need a new component that is just a dialog and can be dragged.

I could see popover supporting resizing but not being a movable draggable object. Modal would be better for that use case. The whole point of popover (and floating-ui) is to attach to another element.

[driskull]

@geospatialem can we separate resizing into their own unique issues? I do see resizing as valid requests for both modal and popover. However, the dragging is probably only valid for modal or another component that is visually equivalent to modal but non blocking.

[driskull]

I think the best solution would be to deprecate modal and add a dialog component. The dialog component could have a property for modal/non-modal as well as properties for resizing and dragging.

[ethanbdev]

Totally open to the best solution, whether its enhancing the modal or a new dialog component to meet the use case

[ethanbdev]

Hey @geospatialem - could this be assigned to a milestone for tracking? I am not sure how far out you plan

[geospatialem]

Hey @geospatialem - could this be assigned to a milestone for tracking? I am not sure how far out you plan

Hi @ethanbdev, this issue will need some design expertise prior to dev work, so there will likely be two milestones to address the effort. Design will be triaging issues late next week for consideration into an upcoming design sprint. cc @brittneytewks

[ethanbdev]

Perfect - thanks!

[macandcheese]

I think the best solution would be to deprecate modal and add a dialog component. The dialog component could have a property for modal/non-modal as well as properties for resizing and dragging.

I think this is a good idea. It would also allow the new component to follow the “slot a Panel inside” paradigm that Popover, Sheet, Shell Panel follow, instead of Modal’s current slot set up.

[mjuniper]

We have a use case for this. We want to show a non-modal privacy consent dialog positioned in the lower right of the screen like this:

[macandcheese]

@geospatialem maybe we can repurpose this issue to encompass the discussion above re: Modal -> Dialog.

[macandcheese]

If we explore Panel as the expected slotted element in this new Dialog - it would align more closely with Shell Panel / Sheet DX and UI. We'd likely want to rename "Action bar" and "Fab" slots in Panel to be more generic like Modal's "sticky top and bottom" ones.

We'd probably want to use the "placement" values from Alert as well as a "center (default)" value.

[Azadirachta]

Hello @geospatialem - Please could you suggest a possible timeline for this issue? Thank You!

Originally reported in https://devtopia.esri.com/WebGIS/calcite-design-system/issues/163

[geospatialem]

Hello @geospatialem - Please could you suggest a possible timeline for this issue? Thank You!

@Azadirachta Thanks for reaching out! The new component effort is currently in the design backlog for consideration with other high priority bug fixes and enhancements - Calcite does not have a timeline at this time, but will update the issue in the coming weeks on the design efforts (note that the dev efforts for implementation would be in addition to the design).

[github-actions[bot]]

cc @geospatialem, @brittneytewks