U
При этом у вьюмодели и вьюхи есть свои скоупы для корутин, которые прекрасно справляются с управлением подписками на Flow, отменяя их в нужный момент "из коробки"
Size: a a a
2021 June 03
АЕ
Вот поэтому подписываться на вьюхи надо во вьюхе, а не в VM) изначальный вопрос звучал так, что человек хотел View передавать в VM, что, конечно, хреновая идея.
U
И я уже в голове пару вариантов прокрутил, ни в одном не понял в чём профит от предложенного. Оформление подписки на Flow от View внутри ViewModel все-равно ведь будет через какой-нибудь
view.flow().collect { viewModel.flow().emit(it) }U
Какую проблему решает и какой профит привносит передача Flow во вьюмодель я не понимаю
U
Скорее всего никакую и никакой
AO
человек хотел View передавать в VM - не, если вопрос именно в этом то это конечно так себе идеяU
Не совсем. Человек хотел передать Flow от View во ViewModel
U
Что, да, притащит ему во вьюмодель ссылку на вью
U
А запилить у View интерфейсы из Flow вместо fooBarListener - ну, почему бы и нет
AO
Я видать сразу в своей голове разложил это так что flow будет в VM а вью будет только туда значение эмитить
U
Безотносительно исходного вопроса. Как?
U
Вытащить наружу MutableFlow?
AO
ну как вариант. Но в целом реально не вижу профита)
AO
меня тут волновал вопрос почему это протечет
JF
udf/mvi?
AO
А просто дергать методы vm в таком случае чем плохо?
JF
не udf
AO
почему?
JF
нет dataflow
В
В ViewModel должен быть сам Flow. Из View можно подписываться на него и/или эмиттить данные в него(если это StateFlow/SharedFlow)