Merge all the modals in a single component and functionalities

[cnotv]

Description

Create a single modal component with slots to extend current functionalities.

As outcome we want:

• A Storybook story to be added as validation of all the use cases
• Avoid QA of the 50+ cases by keeping this.$modal(componentName) function
• Have unique pattern and style

Notes

A second round research to identify all of the cases is still required! Example of cases which may still cause issues:

• Different extra markup added from initial concept, e.g. extra header using the slot
• Dialog components UI will need to be displayed after creating common component, to ensure there's no other visual issues

Context

This issues presents different challenges.

Style inconsistencies between the modals

Examples:

The standard we're initially looking at with buttons in the bottom right:

GenericPrompt

We have these other patterns, to give context about what variances we have and what we need to move from:

AddonConfigConfirmationDialog

PromptRemove

Existence of several modals components

Code-wise we have several components without a common base and sometimes in other paths: ./shell/components

Any path but found with this.$modal

./shell/dialog

Two different patterns adopted

We currently request modals in 2 different flavors: as action, with the same modal and as markup, with custom versions.

Action

In some cases the modal are requested with an action as in GenericPrompt, e.g.:

      this.$store.dispatch('management/promptModal', { // sometimes is 'cluster/promptModal', not sure why
        component:      'GenericPrompt',
        componentProps: { ... }
      });

PROS

• Avoid to load all the logic on page opened, instead of calling waiting till the modal is requested
• Unique markup placement
• Unique styling
• Unique and consistent provided options
• Possibility to display it based on logic other views/components
• Use of async/await in the logic as in confirmations

Markup

In other cases the modals/prompts are placed directly in the markup several time 🤔 (there's more than these 3 in the screenshot)

PROS

• The whole logic is contained within the component itself
• We do not have to repeat the logic twice as we do not have a common initial page, but rather 2 (default and home)

[gaktive]

Whatever we design here needs to be documented in Storybook so we ensure we have a consistent modal experience.

[cnotv]

As outcome of the conversation:

• Preferred to reuse one modal component everywhere instead of shared layout, if possible
• Update the code everywhere after identifying the modal and possibility
• QA will require to go through each case

Basic requirement for the issue is:

• Define a design
• Apply design to generic modal
• Create story for styleguide

[cnotv]

Another point which needs to be addressed, some modals allow HTML and some others not. By default for i18n we often use markup in it.

[cnotv]

@gaktive at the current state we keep creating new modal styles, e.g. inactive modal, so I'm adding more take aways.

[cnotv]

Design will be reviewed as part of the code refactoring process since we do not have a defined one and is complex for the designer to understand the current state.

[gaktive]

One of the conditions of moving to Vue 3 is tied to requiring a new modal component -- https://github.com/rancher/dashboard/issues/9537

However, we should wait to work on that once we standardize what the modals should look like so we have an easier port. We should discuss this soon so we can get off Vue 2.

[cnotv]

@gaktive this issues is on triage since long, so we omit the redesign and we'll stick to just ask how to align the buttons and that's it.

A full redesign discussion can be done later after we'll publish it in the style-guide.

[cnotv]

@richard-cox since we don't want to get stuck with this issue and we rather want to find a solution, the final goal will also be to don't actually change these 50+ use cases of this.$modal(componentName)

[gaktive]

There's a risk here of breaking extensions that consume these modals, so care needs to be taken since Epinio, Rancher Desktop, Opni, Kubewarden, etc. depend on these.

[gaktive]

Key target: use GenericPrompt as the standard pattern to use (i.e, buttons in the bottom right).

[gaktive]

As part of this work, we need to look at all the modals since it sounds like by digging into this, you almost start.

@cnotv & @richard-cox to provide input.

[cnotv]

Added notes from the remarks of @richard-cox. As I mentioned, it's impossible to foresee the outputted markup and styling by just reading the code, so it would require to actually implement an initial modal.

If we want to simplify in steps, we may starts by creating an actual component without have an actual use, then create separated migrations in chunks, although this will have to turn into an epic.

[richard-cox]

@cnotv there were some wires crossed there.

• From my understanding this.$modal relates to a dependency that we must migrate away from
• this.$modal is used in situations that cover
  • custom, location specific usage (CommunityLinks, DisableAuthProviderModal, RemoveUIPlugins, etc)
  • generic components that serve a common purpose / functionality (ModalWithCare, PromptModal, PromptRemove, etc)
• My question's regarding the scope of this ticket rather than how a new modal might look. Is it to either...?
  • Create a new root modal (containing the single this.$modal) and convert all the above cases to use it
  • Convert the custom locations to use the generic components
  • Another approach
• Given the above it feels like we need to understand how all modals are used, then understand the impact of the required changes (it may be further reaching and harder to do than just fixing the usages of this.$modal)

[cnotv]

• Given the above it feels like we need to understand how all modals are used, then understand the impact of the required changes (it may be further reaching and harder to do than just fixing the usages of this.$modal)

Technical implementation of the modal has been already described in the issue under Two different patterns adopted and used in the code as displayed in the lists Existence of several modals components.

[richard-cox]

Two different patterns adopted covers the same underlying modal. GenericPrompt referenced by actions is just a component that's shown inside of the PromptModal referenced in markup.

Would you be able to confirm

My question's regarding the scope of this ticket rather than how a new modal might look. Is it to either...?
- Create a new root modal (containing the single this.$modal) and convert all the above cases to use it
- Convert the custom locations to use the generic components
- Another approach

[cnotv]

The idea is to have a common layout, which can be used later, a single component, which allows the 2 different approaches to be requested and a way to override the default layout. There should be a common ground for all of them and provide all the possible solutions: callback, async, etc.

The technical details are obviously something which is ongoing during development. There will be a Storybook for the component and layout, plus unit tests to verify the functionalities.