Не обязательно, у вас и .map может оказаться тяжёлым.

разве map работает не как у сиквенса?

спасибо, сейчас пример сделаю для обсуждения

Как у сиквенса, да. Но его параметр -- suspend.
https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.flow/map.html

У меня довольно навороченный фронт. Карты, анимация, рюшечки хотят.

Меня как раз таки vue с openlayers спасают

А, да, логично.

Вот такой пример, нужен ли здесь suspend?                                             viewModelScope.launch {
           interactor.listenForUpdates().collect()
       }

fun listenForUpdates(): Flow<Int> {
           return repository.oneChannel.asFlow()
               .combine(twoChannel.asFlow()) { i,_ -> i}
               .map { updateUi(it) }
}

Если функция только связывает потоки данных, ей не надо быть suspend.
И как минимум ей не надо быть suspend, если компилятор не требует.

если продолжать аналогии с тасканием ящиков то получается что для выполнения работы надо
1) создать план действий, т.е. грубо говоря, кто, откуда, куда, сколько и как часто будет носить, это и есть создание Flow. Сама по себе операция вроде не тяжёлая, делать это через suspend большого смысла вроде нет.
2) непосредственная переноска тяжестей, с некоторыми преобразованиями, типа, перепаковать c одних ящиков в другие (map) и прочее. Тут необходимо понимать, что количество работников ограниченное, и на кассе ещё и людям отвечать надо что то. Поэтому всё делается через suspend внутри корутин скоупа. Грузчик как бы несёт ящик, но если надо отвлечся - отвечает людям на кассе, время от времени перекуривает, а затем продолжает выполнять перемещение тяжестей. Это наш .collect {} который запускает процесс подготовленный в первом пункте.
Т.е. если мы добавим suspend к функции что возвращает флоу мы просто сделаем неблокирующей функцию, которая создает сам флоу, сам план действий, что само по себе не должно занимать много процессорного времени.
Поправьте меня, пожалуйста, если где то ошибся.

спасибо, насчет компилятора согласен

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

Clojure/ClojureJS, последний даже вроде раньше нарисовался чем KotlinJS

Clojure/Native?

Кажись нет такого :)

там CLR зато есть, да

А как идеоматичнее сделать:
Есть класс pojo, у которого есть nullable поле isBigList:Boolean? в конструкторе.
Хочу переделать, что бы поле получалось не нулабельным при помощи экстеншена:
fun Boolean?.falseIfNull() = this ?: false
И есть 2 варианта:
1й - иметь метод fun isBigList() = isBigList.falseIfNull()
2й вариант - сделать через переменную:

val bigList: Boolean
        get() = isBigList.falseIfNull()

Какой вариант правильнее и красивее по вашему?

val bigList: Boolean
        get() = isBigList.falseIfNull()

Либо сделать неопциональным и в месте создания явно прописывать false, либо когда получаешь явно говорить какой дефолт
Оба твои экстеншена выглядят избыточно

Т.е. лучше это всё убрать что напридумывал и дёргать непосредственно nullable переменную, я правильно понял?

smthIfNull это же ?: smth