Навигация во Flutter — это не просто смена виджетов, а управление стеком Navigator, где ошибка в архитектуре ведет к утечкам памяти и невозможности реализовать глубокие ссылки (Deep Linking). Правильный выбор между императивным и декларативным подходом определяет, насколько легко будет масштабировать приложение при росте количества экранов с 5 до 50.
Navigator 1.0 работает по принципу стека: push и pop. Это удобно для простых линейных переходов, но превращается в кошмар при реализации сложных сценариев, например, когда нужно вернуться на три экрана назад и обновить данные на одном из них. Основной риск здесь — потеря состояния экрана при некорректном управлении маршрутами.
Мини-кейс: в приложении интернет-магазина пользователь переходит из корзины в профиль, затем в настройки адреса. Если использовать только Navigator.push, при возврате через кнопку «Назад» на Android пользователь может оказаться в неожиданном месте или столкнуться с тем, что корзина не обновила список товаров. Решение — использование именованных маршрутов (Named Routes), но даже они не решают проблему синхронизации состояния.
Вывод: Navigator 1.0 подходит только для MVP или утилит с минимальной вложенностью экранов.
Navigator 2.0 переносит управление навигацией из методов вызова в состояние приложения. Теперь интерфейс зависит от состояния (state), а не от последовательности действий пользователя. Это позволяет синхронизировать URL в веб-версии с состоянием приложения, что критично для SEO и UX.
Практический нюанс: реализация чистого Navigator 2.0 вручную избыточна и перегружает код бойлерплейтом. Разработчики часто ошибаются, пытаясь реализовать сложную логику внутри Page-списка, что ведет к лишним перерисовкам всего дерева виджетов.
Вывод: декларативный подход необходим для многоплатформенных проектов, где важна поддержка браузерного URL и сложной иерархии страниц.
Выбор библиотеки: go_router против auto_route
Для упрощения работы с Router используют обертки. go_router (официально поддерживаемый пакет) делает упор на простоту и URL-ориентированность. auto_route использует генерацию кода, что дает строгую типизацию аргументов при переходе между экранами, исключая ошибки опечаток в строковых именах маршрутов.
Сравнение: если в проекте важна скорость разработки и поддержка Deep Linking «из коробки», выбирайте go_router. Если проект огромный, работает команда из 5+ разработчиков и важна типобезопасность каждого параметра при переходе — auto_route будет надежнее за счет генерации классов маршрутов.
Вывод: для корпоративного сектора с жестким ТЗ приоритетнее auto_route, для гибких стартапов — go_router.
Передача данных через конструктор экрана — самый простой, но опасный путь, так как он создает жесткую зависимость между экранами. Правильный подход — передача идентификатора (ID) через параметры маршрута и получение данных из репозитория или стейт-менеджера (Bloc, Riverpod) непосредственно на целевом экране.
Условный пример: вместо передачи всего объекта User в экран профиля, передавайте userId. Это гарантирует, что если данные пользователя обновятся в фоне, экран профиля отобразит актуальную информацию, а не устаревший объект, переданный при переходе.
Вывод: маршруты должны переносить только минимально необходимые ключи, а не тяжелые объекты данных.
Реализация Deep Linking требует синхронизации внешней ссылки с внутренним стеком навигации. Распространенная ошибка — попытка открыть глубокую страницу без построения «родительского» стека. В итоге, нажав «Назад», пользователь вылетает из приложения, вместо того чтобы попасть на главный экран.
Инсайт: для корректного UX необходимо настраивать иерархию маршрутов так, чтобы при переходе по ссылке /product/123 приложение автоматически создавало в стеке цепочку Home -> Catalog -> Product.
Вывод: навигация должна проектироваться как граф зависимостей, а не как набор разрозненных страниц.
Вывод
Для большинства современных проектов разработка мобильных приложений на Flutter должна базироваться на декларативном подходе. Мой экспертный выбор: использование go_router для проектов средней сложности и auto_route для крупных систем с жесткой типизацией. Избегайте Navigator 1.0 в коммерческих продуктах и никогда не передавайте сложные объекты через конструкторы экранов — используйте ID и стейт-менеджер. Начинайте с проектирования карты маршрутов (Route Map) еще до написания кода UI.