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

pardom

02/19/2019, 4:35 PM
Any of you coroutine pros want to tell me everything that is wrong with this function? I’m not 💯 with coroutines yet and have nobody to do reviews: https://github.com/pardom/oolong/blob/effect-typealias/oolong/src/main/kotlin/oolong/Oolong.kt#L12
Thanks in advance for any reviews.
One thing to note is that I’d like to enable multiplatform in this project soon, so I’m staying away from platform specific concurrency.
d

Dico

02/19/2019, 5:12 PM
<http://Dispatchers.IO|Dispatchers.IO>
is platform specific. I would recommend that you invoke
runtimeScope.cancel()
when you want to dispose of the coroutine. Just make sure that its context contains a
Job()
or
SupervisorJob()
. Finally, I would say you should
join()
on your render coroutine before launching it again. You might be able to use a channel to communicate with a render thread.
👍 1
a conflated channel, or preferably a channel with a capacity of one, to send the render thread frames, might make sense
but, I've never seen any code attempting to make use of multiple threads for applications like this. I would call it an experimental feat, definitely interested in the results!
Finally, there's no point checking that the
channel.offer
failed, as it will not fail unless the channel is closed or cancelled. That is a property of conflated channels.
I think it might even throw an exception rather than returning false in those cases.
p

pardom

02/19/2019, 5:17 PM
there’s no point checking that the
channel.offer
failed
Cool, I was looking for other instances it might fail, but I couldn’t find any so I’m catching it to be cautious.
For context, the reason I’m using a channel here is to keep the runtime coroutine alive while waiting for next states. Also, the reason I made it conflated is so that I can send the initial state before iterating the channel.
Here are the goals: 1. Reduce states without blocking the context in which it was launched. 2. Execute side-effects without blocking the runtime or the calling context 3. Rendering is a side-effect and should not block
d

Dico

02/19/2019, 5:30 PM
I recommend a conflated channel for passing states to the renderer. you're passing
dispatch
block to both
effect
and
view
calls. Do you expect multiple updates in a single cycle?
p

pardom

02/19/2019, 5:40 PM
Effects can dispatch back to the reducer with their completed work. Views can dispatch to the reducer on user events.
For more context, this started as a port of The Elm Architecture, but now most resembles this: https://github.com/andrejewski/raj/blob/master/index.js
With the types probably most resembling this: https://github.com/p69/dartea/blob/master/lib/src/types.dart
5 Views