Шанс разработать уникальное флоу -- почти такой же.

Предлагаю к рассмотрению два реальных кейса, которые произошли на одном и том же проекте -- приложение NL Store 2.0

1. Когда хочется сбросить навигацию У go_router есть для этого инструменты. Он просто не дает вам ими пользоваться.

Для любого нативного разработчика вопрос программного сброса ветки даже не поднимается -- нужно просто удалить контроллер навигации. Но пользователю официально добавленного во Flutter пакета навигации это не по силам. Сброс происходит в лучшем случае для одной ветки исключительно после действия пользователя (нажатия). Воссоздадим пример:

В приложении реализована система мультиаккаунта. При выходе из текущего юзера необходимо сбросить все активные экраны в исходное положение.

Проблема: нет метода под это действие. Единственное теоретическое решение это пройтись с помощью for по всем ключам веток, взять их контекст, понадеяться на обратную совместимость пакета со стандартным Navigator и сделать .popUntill() В этом кейсе for шарашил бы на 10 веток.

На практике, конечно же, все сломалось. После такого действия приложение моментально умирает. Обойдемся без разбора stackTrace

Решение: пересоздание всего app, вместе с новым инстансом роутера через KeyedSubtree Возможно, мы бы даже оставили этот костыль -- другого решения не было. Но регресс показал, что по какой-то причине после смены ключа приложение уходит в верный экран, без шанса на восстановление. Только перезапуск Искать причину никто не стал, было ясно, нужен иной подход. И я полез смотреть, что же там под капотом в go_router

Итог: Я грубо вырезал пакет из pub кэша, закинул как есть в проект и начал его дополнять

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

Пять строчек кода, с учетом создания публичного метода для этой подмены.

Второй кейс подготовлю следующим постом. В этой небольшой серии постов хотел описать причину, по которой я начал создавать свой пакет навигации