А норм ли со стороны хорошой практики пробрасывать NavController во

viewmodel?

Пробрасывание NavController в ViewModel считается нарушением принципов архитектуры MVVM (Model-View-ViewModel). Вот почему: 1. Смешение ответственностей: ViewModel должна заниматься обработкой бизнес-логики и предоставлением данных для отображения. Управление навигацией — это часть ответственности View. 2. Тестирование: ViewModel с NavController будет сложнее тестировать. Вы должны будете подменять NavController или использовать другие подходы для изоляции ViewModel в юнит-тестах. 3. Переиспользование: ViewModel с проброшенным NavController будет менее переиспользуемым, так как он привязан к конкретной навигационной логике. Похоже на правду?

Не сильно. Управлением навигацией может заниматься и бизнес-логика. Например, открыть экран по какому-то событию или при переходе по диплинку. Во многих нав-библиотеках для композа и не только так и происходит. Выносить ли стейт-объекты в композицию или хоистить их внутри компонентов бизнес-логики – зависи от конкретного юзкейса. Точно так же и стейты виджетов (LazyListState) могут хоиститься так и внутри композиции, так и внутри бизнес-логики.

Ты спрашиваешь у чата, лайк или дизлайк этому ответу поставить?)

Стикер

NavController ведь живёт в скоупе своей Composable-функции, а у ViewModel скоуп шире. Утечка же будет.

Ну я так и понял)

Как это поможет?

А, погодь, я не так тебя понял. Ты про хостинг контроллера во вью модели, которая андроидовская, и которая переживает активити

Нет

При желании можно сделать, чтобы не было утечек. У нас обертка над navcobtroller инжектится в VM. А так же инжектится в активити/фрагмент. В активити/фрагменте аттачится/детачится в onCreate/onDestroy. Утечек нет и можно дергать обертку в vm для навигации. Но с композом такой поход становится не очень. Поэтому мы по возможности от этого избавляемся. Из VM выбрасываем наверх события навигации и потом дергаем коллбеки из композаблов, которые уже выполняют навигацию.

а что за утечка

Памяти

Ну это же не сам NavController, про который шла речь. 😀 А если это VM экрана в стеке? Костыльно как-то получается.

А как?

NavController зависит от контекста

иии? как это приведет к утечке памяти?

а в чём проблема с композом при таком подходе? мы так собираемся делать как раз, так то в классическом MVVM навигацию рекомендуется как раз из viewmodel же делать