С появлением flow всё стало гораздо проще, так как это не архитектурный компонент и может спокойно прокидываться в бизнес-слой

А если с недавним StateFlow, то прощай LiveData))

Да

Вопрос больше про подход в целом, не имеет значения, какая библиотека используется для подписок.

Как это не имеет ? Еще как имеет. А что подход ?

Имеет в том смысле, что следует избавляться от Андроид-зависимостей.

У вас одна точка для входа/выхода данных, а там хоть файл, хоть бд, хоть memory без разницы

Человек спрашивает про гонки а вы ему про андроид зависимости, он из другой дискуссии, не про вьюмодели)

Просто оборачиваете своё хранилище в flow и всё

произошли изменения в хранилище ? emit

запросили данные ? emit

и т.д.

Меня больше интересует, что emit / onNext / postValue (опять же не важно какая либа) может происходить не сразу
То есть во время выполнения UseCase`а произошла модификация хранилища - подписки получат новые данные не моментально, скорее всего в другом потоке и, скорее всего, чуть позже

Вот пока они получают свои данные юзер может накликать, в теории, много раз по старым данным на экране -> запустятся новые UseCase`ы

@alaershov , понятно, что я имею ввиду?)

я бы сказал что в любом случае обеспечение консистентности данных это задача их хранилища, будь то БД или in-memory что-то. В конечном итоге ваша корутина дойдет по цепочке вызовов до этого хранилища, и вот там уже надо будет решать, как обеспечить консистентность. К счастью корутина это всё-таки не поток, и все методы модификации данных можно сделать suspend и внутри сделать синхронизацию.

сделайте невозможным клик

Если мы говорим о том, что пользователь может на основе старых данных сделать много запросов, и после исполнения первого из них остальные станут неактуальны - опять же, задача вашего хранилища данных сделать так, чтобы остальные запросы не попортили ничего. Ну и да, можно пользователю попытаться блокировать UI, однако это уже скорее для удобства, не для защиты.

Да, вот то что я пытаюсь разобрать. Где эта защита должна быть, пока не понятно

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

В room имеется, если выполнять через транзакции

У меня был один опыт, где нужно было прям думать об этом, собственно, синхронизация с сервером локальной модели данных. И там я руками делал логику, что пока мы грузим данные на сервер, никто локальную модель не может изменять. Если запущено несколько синхронизаций для разных объектов (юзер накликал), то они клались в очередь, и исполнялись строго последовательно, и с дополнительными проверками, типа а нужно ли вообще нам это делать.