Side Effects from UI input: idioms/design choices

[sampengilly]

I've been toying around with Workflow and I find it interesting as it follows a very similar "composable state machine" to the app code I've been writing recently but does so in a more codified/standardised way and has more intentional separation of side effects.

After playing around with the core, I've run up against a question which I feel might come down to idioms/design decisions which may not be well documented and don't seem all that clear.

In my current application, I use a very "event-driven" approach to updating UI state. If the user hits a play button for example, I call a side effecting function which tells the media player to start playing. The button state subscribes to the currently playing state being emitted as a Flow from the media player. As soon as media starts playing, the flow emits and the button is updated to a pause button.

In Workflow it seems like that sequence isn't possible or may be discouraged? It feels as though it favours reacting to the button press using an action which immediately updates an internal state of the Workflow (such as changing it from Paused to Playing) and in the render function for the new state a side effect function can be run that triggers the actual playback to start.

It seems at first glance like you could achieve the first approach by just calling context::runningSideEffect from a lambda passed to the Rendering, but the docs of runningSideEffect seem to imply that may not be safe as the coroutine may be cancelled during the next render call if it isn't called again (which it wouldn't be as it was triggered by a lambda as a result of UI action). Maybe for very immediate side effects it might be ok but it gives me pause and makes me think that it's not an intended way of using the API.

Is there any idiomatic way of achieving approach 1 (Button press on UI calls lambda in Rendering, lambda triggers side effecting function on object injected into Workflow constructor without state update) or is it recommended to use approach 2 (Button press on UI calls lambda in Rendering, lambda sends an action to sink to move Workflow to new state, upon entering new state, Workflow runs side effect)