Комментарии 3
Была однажды подобная задачка, только по UI это выглядело не как модальное окно, а как выезжающий сбоку sidebar и в нем были табы с разным содержимым.
Мы пошли третьим путем, в сравнении с вашим.
Объявили именованный outler на странице и просто производили всю навигацию в контексте этого самого outlet:
// page.html
<router-outlet name="modal"></router-outlet>
// app-routing.module.ts
const routes = [
...
{
path: 'order',
outlet: 'modal'
component: OrderComponent,
children: [
...
]
}
];
В итоге это работало максимально нативно, но с двумя неудобствами:
URL выглядел не user friendly из-за двойной навигации в нем, что-то вроде `/foo/bar(sidebar:/baz)`, уже точно не помню как он формируется
Роуту приходило помогать - где-то сбрасывать outlet руками при навигации, если изменился именно promary route, где-то наборот делать навигацию явно указывая нужный outlet. Несколько хелперов решили все проблемы, а у вас вообще модальное окно и у пользователя не будет возможности менять primary route не закрыв outlet
Неплохая идея, единственное, следовало бы упомянуть, что после того, как диалог закроется - начинаются пляски с бубном, т.к. состояние адресной строки и того, что находится на странице больше не соответствует действительности :)
Хорошее замечание, если в диалоге есть еще какая-то кнопка закрывашка. Но закрывашка в таком диалоге работает как routerLink. Уходя с роута компонента-диалога у нас закрывается сам диалог. Рассинхрона нет.
Что-то иное тоже можно просто обработать
this._ref.afterClosed().pipe(
// топорно
this.location.back()
// кастомно
this.router.navigate([...])
).subscribe()
Роутим диалоги в Angular + Material