Как реализовать управление сложными диалоговыми модальными окнами согласно гибкой логике

У нас на проекте используются модалки. До недавнего времени в простом обыденном контексте, но теперь, требования изменились, и нам необходимо использовать модальные окна в рамках какого-то сценария причем со сложной логикой.

Наверное, как и везде, наш модуль работы с модальными окнами имеет тривиальную структуру, не буду вдаваться в подробности, но есть провайдер Portal-компонент, который монтирует children-пропс куда-то в документ (по-умолчанию body)

<Portal name="MODAL_1">
  <SomeModalWindow>
    ...
  </SomeModalWindow>
</Portal>

и управление происходит обычным образом с помощью Redux

dispatch(actionSetPortalVisible('MODAL_1')); // для монтирования
dispatch(actionSetPortalHidden('MODAL_2')); // для размонтирования

по-сути своей все.

Но когда таких модальных окон достаточно много, и когда они переплетены логикой и принадлежностью, к примеру, из модального окна А можно открыть либо модальное окно B, либо, если пользователь авторизован модальное окно С, а из модального окна C, если пользователь подтвержден, можно открыть снова модальное окно A или модальное окно D из которого можно открыть B.

Примерно так.

По итогу, коллеги, реализовали диалог авторизации, который пестрит состояния и различными сценариями следования модальных окон, не проше, чем в примере выше. Вся логика управления размана или по внутренними компонентам модальных окон (диспатчи в эффектах, колбэка) причем совсем неявно, или вообще находится в санках (обработка различных запросов: отправили смс-код на устройство, сделали dispatch(actionSetPortalHidden('A')); dispatch(actionSetPortalVisible('B')))

по итогу, предсказать, или понять с первого взгляда в какой зависимости находятся одни модальные окна от других очень сложно.

Была поставлена задача на рефактор.

Я пересмотрел достаточно много паттернов и пытался применить их на практике: паттерн "Состояние", паттерн "Стратегия", но как-то ни один нормально не клеится к такому флоу (скорее всего по моей неопытности).

Те кто сталикавлся с такими механизмами, как решали эту проблему? Использовали ли какие-то паттерны проектирования?