Парни, всем привет у меня вопрос по viewmodel, я делал чаще

всего так:
1 экран - 1 вью модель, но я тут подумал, можно же делать 1 модуль - 1 вью модель
(например, у меня есть чат, в котором есть данные пользователя, сообщения и мой баланс), можно юзать 1 вьюмодель, для всех запросов (сообщения, баланс, данные собеседника)

или можно юзать 2 вьюмодели
в 1 - получаются данные о пользователе и профиле (моем)
во 2 - сообщения

как лучше делать?
1 экран - 1 вьюемодель
или 1 вьюмодель для 1 модуля запросов?

Вью модель - это прослойка между твоим View и Domain, связывающая их. 1 вьюмодель на несколько экранов - это нарушение принципа единой ответственности. Если у тебя на многих экранах требуются выполнять одинаковые задачи, то можно, чтобы каждая вью модель обращалась в UseCase'ам. Тогда у нее, ВМ, будет только столько функций, сколько юзкейсов ты ей предоставил

спасибо)

Гугл рекомендует использовать общую view model для коммуникации между активити и фрагментами.

Там срп в углу повесился от таких заявлений

Необязательно

Почему же? Ты создаёшь мастер - класс для взаимодействия элементов, который, так или иначе, будет хранить бизнес - логику, которая не относится ко всем сегментам

Никто не заставляет делать монстра. Это может быть вм именно для коммуникации. Я не знаю, кто придумал правило 1 вью - 1 вм 🤷‍♂

Так вм хранит бизнес - логику. Тут либо несколько вм (что, в принципе, гугл в своей навигации и делает), либо одна отожранная, которая хранит инфу по нескольким экранам

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

Вм не обязана хранить всю бизнес -логику. Привет от срп.

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

Например, в экземпляре юзкейса, который находится в вм.

Но ведь идеалистически юзкейс должен выполнять роль интерактора, но с одним методом

Юзкейс и интерактор - синонимы

мало кто знает, но «юзкейс» — это слово «функция», написанное с шестью ошибками.

Ну не совсем, интерактор может несколько функций иметь, у юзкейса же только одна - invoke

А если юзкейс внутри вызывает другие юзкейсы, собирает их результаты и возвращает свой? Тоже запрещено? 😏

Если в файле реального кода (без импортов и заголовков функций) одна тривиалная строка то ее можно перенести вверх или в низ )

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

"Слухами слой полнится"

Бизнес топит за ххвп. Пока мне платит бизнес, а не дядя Боб, можно некоторые практики опустить)

Некоторые собирают в одном юзкейсе несколько других и называют это научным словом интерактор. Главное, чтобы не юзкейс 😏 Хотя это синонимы.

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

От оно шо! Оказывается, от догм можно отступать! Фигасе...

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

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

Третий не особо похож на юзкейс. Это похоже на функцию внутри вм/презентера, где дёргаются два вышеупомянутых юзкейса

Юзкейсы вообще-то оч похожи на функцию

Сложно поспорить. Поэтому твое заявление о том, что функция может хранить в себе другие функции выглядит странно

Функция может вызывать другие функции. Это выглядит не странно, надеюсь? 😏

Может, но с позиции юзкейса это будет значить, что тебе нужно будет внутри этого класса иметь инстансы других юзкейсов. Т.е. фактически иметь функцию внутри функции

Как вам угодно 🤷‍♂