https://kotlinlang.org logo
#coroutines
Title
# coroutines
r

Ruckus

08/07/2019, 2:18 PM
Out of idle curiosity, is there any plans to expand the functionality of
kotlinx-coroutines-javafx
to provide helpers for common patterns, or is it only meant to provide a UI context?
1
👀 1
It does have the
awaitPulse
helper, so I was wondering if there were future plans for e.g. converting event handlers to idiomatic coroutine code.
a

altavir

08/07/2019, 2:22 PM
Is there actually needed? Event handlers are usually just simple callbacks. You do not need coroutines for them, especially with builders like in TornadoFX.
r

Ruckus

08/07/2019, 2:26 PM
I'm not sure. I have little experience with coroutines, so I'm not sure if I'm backwards on this, but It may be nice to have a channel/flow for events or property changes.
a

altavir

08/07/2019, 2:28 PM
Property are designed to avoid listening to change events directly. Anyway, listening with a flow, takes about three lines of code. You can probably contribute it yourself.
g

gildor

08/07/2019, 2:31 PM
I agree, it may be useful, rective source is much more powerful if you combine multiple sources, filter, share etc
3
r

Ruckus

08/07/2019, 2:32 PM
Property are designed to avoid listening to change events directly.
Could you explain what you mean by this? I'm not sure I understand what you are trying to say.
g

gildor

08/07/2019, 2:33 PM
probably Alexander means that you just pass property to some ui component and shouldn’t listen changes directly
but still sometimes it may have sense, also expose Flow as Property would be nice
a

altavir

08/07/2019, 2:35 PM
Usually, you just bind a property to another property. I worked a lot with JavaFX and It is quite rarely that I use raw events.
r

Ruckus

08/07/2019, 2:36 PM
Ah, but that only applies to situations where you want a change in property to affect the ui directly, not if you want to do anything else when a property changes. For example, when fetching new data from an API when a user changes search parameters.
a

altavir

08/07/2019, 2:36 PM
OK, I won't argue. Still it is very easy to add.
r

Ruckus

08/07/2019, 2:40 PM
I imagined it wouldn't be that hard, but that doesn't change my original question. Would such helpers belong in
kotlinx.coroutines
, or should they be part of a separate library? I'm not sure what is the intended scope of
kotlinx.coroutines
. For example, is there a clearly best way to wrap event handlers or properties in a channel or flow? If so, I'm guessing it would be a good fit. If not, I'm not sure.
a

altavir

08/07/2019, 2:43 PM
Well, it already has a module for that, so why not.
6 Views