Словил интересное поведение с flattenMerge. Если мержатся больше 16 флоу, то ивенты всех начиная с 17 не доходят. Это баг или так задумано? Если изменить конкурентность на большее значение, то все начинает работать

@Test
    fun testMutableStateFlowFlatternMerge() = runBlocking {
        val flows = mutableListOf<MutableStateFlow<Int>>()
        repeat(20) {
            flows.add(MutableStateFlow(0))
        }
        val job = launch {
            flows.asFlow()
                    .flattenMerge()
                    .collect { println("received $it in ${Thread.currentThread().name}") }
        }
        delay(1000)
        flows.forEachIndexed { index, flow -> flow.value = index + 1 }
        delay(1000)
        job.cancel()
    }

Выводит

received 1 in main @coroutine#2
...
received 16 in main @coroutine#2

Потыкал немного палочкой в десктопный компоуз. Все-таки мне кажется, что использование Composable вместо ресивера (или хотя вместо того, чтобы маркировать ресивером композабли) - это ошибка. Например я не могу взять и посмотреть, какие функции доступны в данном окружении. Также нет возможности дифференцировать разные копозабл скоупу (может такое быть, что определенные наследники возможны только у определенных предков). Это все можно сделать на уровне IDE, но это какое-то "не решение". Вроде сейчас есть возможность, не ломая ничего, добавить маркетные скоупы, чтобы решить эту проблему.

Казалось бы та же проблема(ли?) есть и с suspend и вроде как на практике этот аспект вообще проблем не вызывает.

Нет, это совсем не та же проблема. Потому что суспенд не дифферинцируется по локализации применения (за исключением sequence). Мы везде можем использовать один и тот же суспенд и семантически это оправдано. Более того, мы как правило знаем какую конкретную суспенд функцию мы хотим вызвать, или как минимум в каком пространстве имен она находится. В каком-нибудь tornadoFX я не обязан знать все возможности UI, я нажимаю this. + Ctrl+space, и у меня вываливается ранжировнный список компонентов, которые я могу воткнуть в этом месте. В нынешней вариации компоуза, я должен лезть в доку/исходники, чтобы понять, а что я вообще могу сюда поставить.

Модификаторы добавляют дополнительный барьер на пути прозрачности API.

Во, я придумал, как по-умному сформулировать. suspend подразумевает открытую систему с точки зрения того, что там може быть вставлено (но мы кстати все равно любим маркировать суспенд функции ресиверами, чтобы их было проще находить). UI подразумевает динамичную, но закрытую систему. В каждой конкретной точке может быть конечное количество вариантов компонентов. И тут два выбора, или мы делаем какую-то возможность, чтобы для этого конечного множества были подсказки, или надо "учить фреймворк". Последняя стратегия мне очень сильно не нравится, потому что приводит к существованию "специалистов по определенному фреймворку" и возводит барьер на доступ в экосистему.

Не понял. Казалось бы UI максимально открыто. В любом месте втыкай любой компонент. Вопрос только в том как узнать список всех компонент. Во всяких интерактивных билдерах всегда были "палитры компонет", а те, кто писал код ручками, всегда штудировали документацию. Чего-то я даже не помню чтобы IDE в каких-либо UI системах умели сразу подсказывать какие компоненты существуют. Но в IDE можно вполне такую фичу добавить.

Скорее нет, чем да. UI открыты, когда вы сами подключаете туда компоненты. Базовые строительные блоки очень стандартны.

Опять же, опираясь на опыт tornadoFX и kotlinx.html, у нас обычной подсказки идеи достаточно. Мы просто видим все функции, доступные в данном ресивере. Я вот сейчас вижу, что частично это и в компоуз десктопе использвется к примеру с ColumnScope.

Но давайте я вот сформулирую текущие ощущения (я думаю, это полезно, посколкьу у меня нет предыдущего опыта на андроидном компоузе), они потом могут поменяться, когда попривыкну. Вот я хочу добавить Layout, скажем колоночный. В той же торнаде, я бы наше тип Layout и просто по подсказкам идеи посмотрел бы всех его наследников. Здесь наследования нет. Как мне понять, какие вообще Layout существуют? Могу ли я это сделать, не залезая в несуществующую доку. То же самое с модификаторами. Как понять, что там вообще может быть. Сейчас я ползаю по исходникам и ориентируюсь на имена файлов, другого не придумал.

Мне кажется, рассчитывать на обучение работе с UI-фреймворком без доки под рукой бессмысленно. От того, что вы название Row найдёте, вы всё равно не поймёте, как оно устроено. Всё равно придётся читать. Не говоря уже о сложных компонентах.

В принципе я за 10 минут разобрался как сделать то, что мне нужно, используя встроенную доку. Так что все не так плохо. Проблему с обнаружимостью компонентов могли бы решить namespace-ы. Можно было бы все Layout к примеру пихать в один namespace и тогда можно использовать подсказу по этому имени

Нужна общая спецификация по названиям) Что-то типа reactivex.io для рыкса. Но уже наверно поздно менять API.

from asyncio import sleep?

Could you please clarify your question? This is not a Python chat.

If you're by chance asking how to to that in Kotlin, there is Thread.sleep(...) for threads and delay(...) for coroutines.

Ну я говорю, namespace в принципе решают эту проблему. Перетаскиваем все layout в Layout и пишем Layout.Column. Причем в существующем коде только импорты поменяются. Более того, так как речь идет о функциях, там вообще можно инлайн линки делать

Согласен. Я больше про общую спецификацию для декларативных UI фреймворков. Чтобы было много общего и было легко переключаться. Как пример - RxJava, RxSwift, RxJs. Но это нереально, я понимаю. 😊

Не реально. Будет еще возня с унификация между HTML, андроидом и десктопом. Но тут опять же функциональная природа помогает, поскольку можно делать фальш-компоненты

А зачем общая спецификация? У каждого фреймворка своя модель лейаутинга, хоть они и пересекаются местами, свой набор компонентов.
С рыксом логично такое иметь, так как рыкс не о конкретной либе, а о концепте, который между языками переносится (и то там один и тот же оператор по историческим причинам порой по-разному зовётся в разных либах). Как это натягивать на зоопарк UI-фреймворков, мне непонятно.

Вакансия от JetBrains
https://www.jetbrains.com/careers/jobs/ui-framework-developer-400/