Can I run asynchronous actions sequentially in EventM?

[amano-kenji]

I could send a custom event to take care of asynchronous actions, but it will become unmanageable quickly.

I wonder whether there is something like javascript promise API for EventM.

[jtdaugherty]

I wonder whether there is something like javascript promise API for EventM.

If you're wondering whether this is provided by Brick itself, then no, there is no such API. I would not recommend attempting to orchestrate something like that from EventM. I find it actually quite manageable to use a custom event approach and have a separate thread that accepts "requests" (e.g. over a TChan), does work, and then sends "responses" back to the main event loop in the form of custom app events. That is how Brick is intended to be used, although you could certainly implement your own async scheme; it would ultimately need to use custom application events anyway since that's the only way to trigger a redraw and a staet update safely.

The CustomEventDemo program in the brick repo provides a very simple example of the custom event approach, although a much more involved implementation can be found in matterhorn where it has worked extremely well for us.

[jtdaugherty]

The way I often do this sort of thing is something like the following sketch:

-- From base:
import Control.Monad (forever)
import Control.Concurrent (forkIO)
-- From stm:
import Control.Concurrent.STM (atomically)
import Control.Concurrent.STM.TChan (newTChanIO, readTChan, writeTChan)
-- From brick:
import Brick.BChan (BChan, writeBChan)

data WorkerRequest =
    DoStuff ...
    | DoMoreStuff ...

data WorkerResponse =
    StuffReady ...
    | MoreStuffReady ...

data Worker =
    Worker { workerChan :: TChan WorkerRequest }

startWorker :: BChan WorkerResponse -> IO Worker
startWorker respChan = do
    reqChan <- newTChanIO
    void $ forkIO $ workerLoop reqChan respChan
    return $ Worker reqChan

sendWorkerRequest :: Worker -> WorkerRequest -> IO ()
sendWorkerRequest (Worker ch) req = atomically (writeTChan ch req)

workerLoop :: TChan WorkerRequest -> BChan WorkerResponse -> IO ()
workerLoop reqChan respChan = forever $ do
    req <- atomically $ readTChan reqChan
    writeBChan =<< doWork req

doWork :: WorkerRequest -> IO WorkerResponse
doWork (DoStuff ...) = return $ StuffReady ...
doWork (DoMoreStuff ...) = return $ MoreStuffReady ...

Once you have that kind of skeleton, it's very easy to add new request and response constructors, add cases to doWork, and not change any of the infrastructure. In this scenario, WorkerResponse could be your custom application event type for App, or it could be wrapped in another type (recommended) to allow room for other kinds of custom events. Then the last step is to write an event handler for each case of WorkerResponse that updates the application state as appropriate.

[jtdaugherty]

And one other detail: doing this requires using customMain so you can take responsibility for creating the BChan that brick requires, but also passing it to startWorker.

[amano-kenji]

It took some time to wrap my head around this, but when I did, I felt euphoria.

Why do you mix TChan and BChan?

[jtdaugherty]

I use TChan from stm because it's a good alternative to Chan from base. I use BChan since that is the channel type that brick requires when we want to send it custom events using customMain.

[jtdaugherty]

I have updated the code sample above with imports, too.

[jtdaugherty]

@amano-kenji another bit of context in response to your question: Brick's channel is bounded, which prevents the channel from getting too large if the UI rendering cannot keep up, whereas TChan is unbounded. I could have used BChan for the worker request queue as well. I just don't default to bounded channels unless I need to, so I reached for TChan instead.