почему ты второй раз мне отвечаешь, а не автору вопроса?

это из рабочего проекта?

Конкретно это нет, но я использую такой же подход в рабочих проектах

благодарствую, буду вникать

локальная вьюмодель - это вьюмодель фрагмента? как тогда активити до нее достучится?

на скриншоте вижу, что обе VM доступны внутри фрагмента, потому не вижу проблем сделать так:

val sharedViewModel = // init
val model = FragmentViewModel(sharedViewModel)

О! Одну вьюмодель передать в конструктор другой?

ага, что-то вроде того

Ни разу не встречал такого подхода... Так делают? ))))

p.s. все еще кажется, что вставить что-то такое во все заинтересованные VM лучше:

class PlaylistIdBus {
  fun observe(callback: (PlaylistId) -> Unit)
  fun dispose(callback: (PlaylistId) -> Unit)
  fun post(id: PlaylistId)
}

но вариант с прокинуть через fragment.setPlaylistId(PlaylistId) тоже имеет место быть 🤷

Ребята, а вам правда нравится шарить вьюмодели? Разве не проще и надежнее общение между экранами уровнем выше организовывать, через модель?

формально, шаренная модель и играет этой самой модели, но решение такое себе, да

Есть юскейс получения юзера с сервера и записи в БД и есть юскейс чтения юзера с БД и если он нуловый - получение юзера с сервераи собственно запись в бд.  Есть несколько юскейсов , работа которых связана с записью данных сервер и  после успешной записи снова нужно обновить юзера с сервера и записать в БД. Подскажите пожалуйста, как правильней лучше это сделать? В каждом юскейсе , где понадобится обновление юзера в БД , делать доп. метод который при успешном ответе сервера будет обновлять юзера? В некоторых примерах один юскейс инжектят в другой юскейс. Подскажите пожалуйста как правильней всего это реализовать будет

В идеале какой-то флаг сделать в юскейс получения юзера с БД , если флаг тру - сразу обновлять юзера с сервера , а не пробовать тянуть с бд. Хорошая вообще идея  один юскейс в другой инжектить ?

Когда в нескольких разных юскейсах , при выполнении определенных запросов, нужно выполнить работу, которая есть в каком-то ином юскейсе

Вот и вопрос, зачем шарить вьюмодель, если можно просто модель? Просто классов меньше?

а по делу - не приходилось шарить VM пока, все какие-то колбэки внутрь добавляю

Ребят, вы чо
Модель как раз и нужна, чтоб хранить/шарить данные, с которыми работают несколько вью моделей, сиречь бизнес логик
Исходная задача абсолютно рутинная для mvvm - 2 view (fragments), 2 view models, которые держат логику для вью, и 1 модель с данными. Вью модели общаются посредством событий типа onDataChanged, которые выбрасываются моделью, когда данные меняются, и на которые подписаны обе вью модели

Если мы имеем дело с ситуацией, когда vmodel данные не меняет, но отреагировать надо, то же самое, события в модели и подписка на них, если примитивно. Чуть посложнее - message bus в модели