A modern programming language that makes developers happier.

kotlinlang

Any of you coroutine pros want to tell me everything that is wrong with this function? I’m not :100: 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>

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.

`<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.

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.

&gt;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

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?

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>