Out of idle curiosity, is there any plans to expan...

# coroutines

[Ruckus]

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?

[Ruckus]

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.

[altavir]

Is there actually needed? Event handlers are usually just simple callbacks. You do not need coroutines for them, especially with builders like in TornadoFX.

[Ruckus]

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.

[altavir]

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.

[gildor]

I agree, it may be useful, rective source is much more powerful if you combine multiple sources, filter, share etc

[Ruckus]

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.

[gildor]

probably Alexander means that you just pass property to some ui component and shouldn’t listen changes directly

[gildor]

but still sometimes it may have sense, also expose Flow as Property would be nice

[altavir]

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.

[Ruckus]

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.

[altavir]

OK, I won't argue. Still it is very easy to add.

[Ruckus]

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.

[altavir]

Well, it already has a module for that, so why not.