1311:Use Compose's AndroidUiDispatcher.Main to conflate actions in runtime. #1353

steve-the-edwards · 2025-06-19T20:07:47Z

Note this also includes some adjustments to the runtime loop. After the first suspension to wait and apply an action, with CONFLATE_STALE_RENDERINGS we loop without suspending - applying any actions that are already queued up on the action queues.

If it is not being used on Android, use it for the runtime whenever on Android (requiring Compose).

As it turns out, Compose's AndroidUiDispatcher.Main and its greedy behaviour to drain all dispatches before the next Android Choreographer frame gives us exactly the behaviour we want.

In fact, CONFLATE_STALE_RENDERINGS is basically a no-op when using the AndroidUiDispatcher.Main to dispatch the runtime and consume the renderings. The greediness means that the updates all happen before the rendering can be consumed by view code (as well as all happen before the next frame). Because this is not an immediate dispatcher, when we pass a new rendering to the stateflow to be consumed by the view code, it is not immediately picked up (it has to be dispatched, even though the AndroidUiDispatcher.Main is going to do that greedily and before the next frame). This changes ordering.

On Android context where we use this dispatcher, we can likely just not use CONFLATE_STALE_RENDERINGS at all. however, for other dispatchers, it could still have an effect. We will want to be careful with how we roll out this change.

Still the code used to drain immediately available actions can be used by DRAIN_EXCLUSIVE_ACTIONS to avoid render passes.

Fixes #1311

This should also take care of #1257 if we start using the Compose AndroidUiDispatcher.

CLAassistant · 2025-06-19T20:15:53Z

All committers have signed the CLA.

…ntime If it is not being used on Android, use it for the runtime whenever on Android (requiring Compose)

zach-klippenstein · 2025-06-23T21:20:25Z

In fact, CONFLATE_STALE_RENDERINGS is basically a no-op when using the AndroidUiDispatcher.Main to dispatch the runtime and consume the renderings.
…
On Android context where we use this dispatcher, we can likely just not use CONFLATE_STALE_RENDERINGS at all. however, for other dispatchers, it could still have an effect.

Is it basically a no-op, or actually a no-op? Because if it's not identical, we shouldn't treat it as optional. We already have so many confusing workflow flags, if we start requiring various configurations with caveats about things like dispatchers, the messiness just explodes.

zach-klippenstein

Ok so after reading, I'm still not sure I fully understand what the significant behavior difference is between using Compose's main dispatcher and Main.immediate.

Numbering these assertions/questions so you can respond more easily.

When the conflation flag is off and multiple actions are available immediately – then with Compose's dispatcher they may result in multiple emissions to the UI layer with redundant updates, but all will still happen before the frame is drawn. Main.immediate will process them all immediately but also emit to the UI immediately, so effectively the same as far as the UI is concerned. But that was existing behavior.
When no actions are available, but another action is sent before the next Choreographer frame, then the action is still be guaranteed to be processed before the frame is drawn (either by Main.immediate's immediacy or by compose's pre-frame drain). Also existing behavior.
When the flag is on, then we avoid suspending when multiple actions are available, which is theoretically a performance win internally since not suspending is faster than suspending, even with Main.immediate?
1. Externally, the behavior is the same (only emit last conflated rendering to UI) even with Main.immediate because we already weren't emitting on the renderings flow until after the (previously suspending) conflation loop?
If all these are true, then this change only affects behavior for multiple immediate actions when the conflation flag is off? Otherwise the we don't suspend in the conflation loop, so the choice of dispatcher doesn't matter.

zach-klippenstein · 2025-06-23T21:25:22Z

...rc/androidTest/java/com/squareup/workflow1/android/AndroidDispatchersRenderWorkflowInTest.kt

@@ -118,58 +138,69 @@ class AndroidDispatchersRenderWorkflowInTest(
      val renderings = renderWorkflowIn(
        workflow = workflow,
        scope = backgroundScope +
-          Dispatchers.Main.immediate,
+          AndroidUiDispatcher.Main,


If this is the only dispatcher we're testing, is it now a hard requirement that apps using workflow UI on Android must use Compose? If so we should probably communicate that very clearly and update the docs too. If not, then can we test both?

And furthermore, does this imply the behavior broke for other dispatchers? If not, can we just add a parameter to the parameterization that specifies the dispatcher to use, so we can continue to validate it?

zach-klippenstein · 2025-06-23T21:30:04Z

...rc/androidTest/java/com/squareup/workflow1/android/AndroidDispatchersRenderWorkflowInTest.kt

        props = props,
-        runtimeConfig = setOf(CONFLATE_STALE_RENDERINGS),
+        runtimeConfig = runtime.runtimeConfig,


Ah cool, so this change is saying that the behavior this tests validates now happens for all configs, as long as we're using that dispatcher?

zach-klippenstein · 2025-06-23T21:33:52Z

workflow-runtime-android/src/main/java/com/squareup/workflow1/android/AndroidRenderWorkflow.kt

@@ -272,9 +277,17 @@ public fun <PropsT, OutputT, RenderingT> renderWorkflowIn(
  onOutput: suspend (OutputT) -> Unit = {}
 ): StateFlow<RenderingT> {
  val restoredSnap = savedStateHandle?.get<PickledTreesnapshot>(KEY)?.snapshot
+
+  // Add in Compose's AndroidUiDispatcher.Main by default if none is specified.


Please add this new magical behavior to the kdoc as well.

zach-klippenstein · 2025-06-23T21:34:45Z

workflow-runtime/src/commonMain/kotlin/com/squareup/workflow1/RenderWorkflow.kt

-              actionResult = actionResult,
-            )
-          ) {
+          if (shouldShortCircuitForUnchangedState(actionResult = actionResult)) {


Nit: Do we really need this parameter to be named here? When the value passed in has the same name, it doesn't really add any readability.

zach-klippenstein · 2025-06-23T21:41:43Z

workflow-runtime/src/commonMain/kotlin/com/squareup/workflow1/internal/WorkflowNode.kt

+    val result = subtreeManager.applyNextAvailableChildAction()
+
+    if (result == ActionsExhausted) {
+      return eventActionsChannel.tryReceive().getOrNull()?.let { action ->


Please confirm if i understand this right: If we hit this branch, it means either no children had actions to run, or some child had an action but it didn't produce an output?

zach-klippenstein · 2025-06-23T21:46:00Z

workflow-runtime/src/commonMain/kotlin/com/squareup/workflow1/internal/WorkflowNode.kt

+  /**
+   * Will try to apply any immediately available actions in this action queue or any of our
+   * children's.
+   *


Suggested change

*

*

* Contrast this to [onNextAction], which is used to await the next action when none is available right now.

* Both call [applyAction] when one is available.

zach-klippenstein · 2025-06-23T21:47:00Z

workflow-runtime/src/commonMain/kotlin/com/squareup/workflow1/internal/WorkflowNode.kt

@@ -207,24 +206,35 @@ internal class WorkflowNode<PropsT, StateT, OutputT, RenderingT>(
   * a re-render, e.g. my state changed or a child state changed.
   *
   * It is an error to call this method after calling [cancel].


Suggested change

* It is an error to call this method after calling [cancel].

* It is an error to call this method after calling [cancel].

*

* Contrast this to [applyNextAvailableAction], which is used to check for an action

* that is already available without waiting, and then _immediately_ apply it.

* Both call [applyAction] when one is available.

zach-klippenstein · 2025-06-23T21:48:26Z

workflow-runtime/src/commonMain/kotlin/com/squareup/workflow1/internal/WorkflowRunner.kt

@@ -83,24 +80,25 @@ internal class WorkflowRunner<PropsT, OutputT, RenderingT>(
   * and resume (breaking ties with order of declaration). Guarantees only continuing on the winning
   * coroutine and no others.
   */
-  @OptIn(WorkflowExperimentalRuntime::class)
-  suspend fun processAction(waitForAnAction: Boolean = true): ActionProcessingResult {
+  suspend fun waitAndProcessAction(): ActionProcessingResult {


Nit: Since you're renaming this anyway, "await" is the more idiomatic term for "listen while suspended". In contrast, "wait" canonically implies blocking a thread.

zach-klippenstein · 2025-06-23T21:50:11Z

workflow-runtime/src/commonMain/kotlin/com/squareup/workflow1/internal/WorkflowRunner.kt

-          ActionsExhausted
-        }
-      }
+      rootNode.onNextAction(this)


(Follow-up to nit): Renaming this method would also make this code pretty much self-documenting and the above line comment redundant.

zach-klippenstein · 2025-06-23T21:52:15Z

workflow-runtime/src/commonMain/kotlin/com/squareup/workflow1/internal/WorkflowRunner.kt

+   * none immediately available.
+   */
+  fun applyNextAvailableAction(): ActionProcessingResult {
+    return rootNode.applyNextAvailableAction()


Nit: Maybe name this applyNextAvailableSubtreeAction to make it more clear when reading callsites that this actually walks the tree? It took me a few read-throughs of the subtree/WN code to remember these were actually depth-first visitors methods (this and onNextAction).

steve-the-edwards force-pushed the sedwards/compose-dispatcher branch from e6ae168 to 7f98d60 Compare June 19, 2025 20:38

steve-the-edwards marked this pull request as ready for review June 19, 2025 20:38

steve-the-edwards requested review from zach-klippenstein and a team as code owners June 19, 2025 20:38

This was referenced Jun 19, 2025

1311: Enable applying Multiple Actions on immediate dispatcher for CONFLATE_STALE_RENDERINGS #1344

Closed

#1311: Start side effects DEFAULT instead of LAZY. #1312

Closed

1311:Use Compose's AndroidUiDispatcher.Main to conflate actions in ru…

229688b

…ntime If it is not being used on Android, use it for the runtime whenever on Android (requiring Compose)

steve-the-edwards force-pushed the sedwards/compose-dispatcher branch from 3276377 to 229688b Compare June 20, 2025 18:51

zach-klippenstein reviewed Jun 23, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

1311:Use Compose's AndroidUiDispatcher.Main to conflate actions in runtime. #1353

1311:Use Compose's AndroidUiDispatcher.Main to conflate actions in runtime. #1353

Uh oh!

steve-the-edwards commented Jun 19, 2025 •

edited

Loading

Uh oh!

CLAassistant commented Jun 19, 2025 •

edited

Loading

Uh oh!

zach-klippenstein commented Jun 23, 2025

Uh oh!

zach-klippenstein left a comment •

edited

Loading

Uh oh!

zach-klippenstein Jun 23, 2025

Uh oh!

zach-klippenstein Jun 23, 2025

Uh oh!

zach-klippenstein Jun 23, 2025

Uh oh!

zach-klippenstein Jun 23, 2025

Uh oh!

zach-klippenstein Jun 23, 2025

Uh oh!

zach-klippenstein Jun 23, 2025 •

edited

Loading

Uh oh!

zach-klippenstein Jun 23, 2025

Uh oh!

zach-klippenstein Jun 23, 2025

Uh oh!

zach-klippenstein Jun 23, 2025

Uh oh!

zach-klippenstein Jun 23, 2025

Uh oh!

zach-klippenstein Jun 23, 2025

Uh oh!

Uh oh!

-   *
+   *
+   * Contrast this to [onNextAction], which is used to await the next action when none is available right now.
+   * Both call [applyAction] when one is available.

1311:Use Compose's AndroidUiDispatcher.Main to conflate actions in runtime. #1353

Are you sure you want to change the base?

1311:Use Compose's AndroidUiDispatcher.Main to conflate actions in runtime. #1353

Uh oh!

Conversation

steve-the-edwards commented Jun 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

CLAassistant commented Jun 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zach-klippenstein commented Jun 23, 2025

Uh oh!

zach-klippenstein left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zach-klippenstein Jun 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

steve-the-edwards commented Jun 19, 2025 •

edited

Loading

CLAassistant commented Jun 19, 2025 •

edited

Loading

zach-klippenstein left a comment •

edited

Loading

zach-klippenstein Jun 23, 2025 •

edited

Loading