разве это будет работать?

положим, у меня есть:
class FooBarScreen(
 val user: User,
 val msg: Message,
 val creator: () -> Intent
)


если мне из какого-нибудь пятого в стеке презентера я хочу вернуться к FooBar и мне для этого нужно взять откуда-то пользователя и сообщение?

А разве backTo не всегда так работал? Может быть я вопрос не совсем понял

Согласен, тоже думал об этом и это действительно неудобно

БекТу всегда так работал. И поэтому обычная практика - это именно ключ. Что всегда было и есть нормальным решением.

Проблема была в другом: когда у экрана нет параметров и он сделан синглтоном, то было для многих непонятно, что для использования БекТу надо прописать ключ. Это действительно косяк. И сейчас он исправлен

Сейчас всё прозрачно: либо бери все параметры, либо используй ключ. В любом случае будет работать.

Костя, привет, обновил либу до 7.0 и стала падать ошибка, но только на старте приложения при включеном NIGHT MODE. В рантайме меняю мод на светлый и все работает, как и если запуск со светлой темой со старта. Хз как темная тема влиет на fragmentManager…

Error: FragmentManager has been destroyed
Происходит в applyCommandsSync/applyCommands

Нужен семпл

Тоже было подобное, но при смене языка. Ошибка была именно в момент смены когда пересоздавалась активити. Вылечилась тем что router.exit() с экрана выбора языка (в моем случае) нужно было сделать до вызова сомой смены, тоесть до recreate активити. На старй версии все работало и так.

После того как операции по навигации стали добавляться через handler стала происходить такая же ошибка. Я так и не смог найти почему она происходит. Просто обернул applyCommandSync в try-catch пока что

Но у меня подобная ошибка постоянно вылетает после режима откладки. Пока не переустановлю приложение, ошибка не давала запустить приложение (
Пока разбираюсь почему такое происходит

В версии 7.0 теперь сам Screen отвечает за то, будет ли навигация происходить через метод add или replace. Кажется, такой подход, менее удобный, чем передавать параметр в метод navigateTo(). Теперь, если в каких-то кейсах нужна транзакция add, а в каких-то транзакция replace, придется писать два одинаковых скрина с заменой одного лишь параметра. Вдобавок параметр неизменяемый, из-за чего хак по типу "поменять параметр в роутере при передаче флага вторым параметром" не прокатит

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

На самом деле, это архитектурное изменение позволило сильно упростить навигатор. И в целом достаточно логичное

можно же сделать так,

Спасибо. Так и сделал

А если нужно, чтобы все фрагменты открывались по умолчанию через add транзакцию, как это сделать не расширяя текущий FragmentScreen? Не нравится создавать на каждый AddableFragmentScreen, где я переопределил дефолтное значение clearContainer

создайте свой экстеншн к FragmentScreen, который будет туда передавать нужное значение

именно так и надо 👍

попробуйте в онДестрой очищать очередь
handler.removeCallbacksAndMessages(null)

если поможет, то надо добавить в навигатор