[FRONTEND] Modal Stack Refactoring

[Jennie-Westerlund]

Issue: Refactor ModalContext to Support Multiple Simultaneous Modals

Priority

Low - Future enhancement, not required for MVP

Current State

• ModalContext manages a single modal at a time
• currentModal state is ModalType | null
• Works well for current use cases (login, register, save design)

Problem Statement

We have one specific use case where multiple modals would be beneficial: showing a delete confirmation modal on top of another modal (e.g., confirming deletion of a design while a design details modal is open).

Currently, opening a confirmation modal would close the underlying modal, requiring the user to re-open it if they cancel the deletion.

Proposed Solution

Refactor ModalContext to support a modal stack instead of a single modal.

Implementation Steps

1. Analysis Phase (30 min)

• Document all current modal usage in the application
• Identify which modals might need to show confirmation dialogs
• Decide on modal stacking behavior (LIFO vs specific priority)
• Define how backdrop clicks should behave (close top modal only vs close all)

2. Type System Updates (15 min)

• Change currentModal from single value to array/stack structure
• Consider: Should each modal have metadata (priority, canDismiss, etc.)?
• Update ModalType if new modal types are needed

3. Context Provider Refactoring (45 min)

• Replace currentModal state with modal stack state
• Update openModal to push onto stack (not replace)
• Update closeModal to handle:
  • Closing specific modal by ID/type
  • Closing top modal only (default behavior)
  • Closing all modals (escape hatch)
• Consider: Do callbacks need to be per-modal or shared?

4. Rendering Logic Updates (1 hour)

• Update modal rendering component to iterate over modal stack
• Implement z-index management (incrementing for each stacked modal)
• Handle backdrop rendering:
  • Should each modal have its own backdrop?
  • Should backdrop only show behind bottom modal?
• Ensure proper focus management for accessibility

5. Styling & UX Polish (30 min)

• Add visual indication of modal stacking (subtle shadow/offset?)
• Test backdrop opacity with multiple modals
• Ensure top modal is clearly focused
• Verify keyboard navigation (Escape key behavior)

6. Testing & Validation (2 hours)

• Test all existing modal flows to ensure no regressions
• Test new delete confirmation flow specifically
• Test edge cases:
  • Opening same modal type twice
  • Rapidly opening/closing multiple modals
  • Closing bottom modal while top modal is open
• Update any existing modal-related tests
• Add new tests for multi-modal scenarios

7. Documentation (30 min)

• Update ModalContext documentation
• Document when to use stacked modals vs single modals
• Add examples of opening confirmation modals over base modals
• Update any developer onboarding docs

Alternative Approaches to Consider

Before implementing, evaluate if simpler solutions exist:

1. Inline Confirmations: Could delete confirmation be an inline UI state change within the parent modal rather than a separate modal?

2. Modal Modes: Could the existing modal support different "modes" (view/edit/confirm-delete) without needing a stack?

3. Dedicated Confirmation Modal: Could we have a special confirmation modal that temporarily hides (not closes) the underlying modal?

Estimated Time

Total: 5-6 hours of focused development + testing

Success Criteria

• Can open delete confirmation modal over design details modal
• Clicking cancel on confirmation returns to underlying modal
• Clicking confirm closes both modals and performs deletion
• All existing modal flows work without regression
• Keyboard navigation (Escape, Tab) works correctly
• Accessible for screen readers
• No visual glitches or z-index issues

Notes

• This is not essential for launch - only implement if time allows
• Consider if the UX benefit justifies the implementation complexity
• Could be replaced with simpler confirmation patterns (inline buttons, toast notifications)

---

Before starting this work, ask: "Does this problem really require modal stacking, or could we solve it more simply?" Often the best refactoring is the one you don't have to do.