when using `workflow`, what’s the idiomatic / reco...

# squarelibraries

[Yang]

when using workflow, what’s the idiomatic / recommended way to handle transient events (a.ka. the single live event issue 😂)?

[Yang]

I know workflow has native backstack and dialog support, but to limit the scope of the spike I’m doing I’d like to see how far I can go with just 1 runner and 1 workflow for now and compare with previous MVI / UDF frameworks I’ve used in the past.

[Yang]

E.g. when displaying a Snackbar that’s automatically dismissed after a period, should I just have a val showSnackbar: Boolean and `val onDismissed: () -> Unit`in the Rendering and report back to the workflow by calling rendering.onDismissed() when the Snackbar has been dismissed?

[Zach Klippenstein (he/him) [MOD]]

To trigger things like snackbars/toasts, we typically use some arbitrary value that the view layer watches and triggers the event when the value changes (eg a random UUID or a monotonically-increasing int).

UI timeouts like snackbar dismissal are delivered the same way as any other events, like you were thinking.

[Yang]

Thanks. The current approach I’m using is launching a Timer worker from within the workflow and transition to the no error state after the delay. It avoids the round-tripping but requires a delay to be injected to the workflow which feels like the workflow is knowing a bit too much about the specific UI behavior it needs to support

[Zach Klippenstein (he/him) [MOD]]

If you're just showing an error, why do you need to know when the snackbar is dismissed?

[Yang]

I model “content with snackbar” as a state which trigger the layout runner to show the snackbar; if the workflow doesn’t know about the dismissal and no new states have been generated, after config change the “content with snackbar” state will show the snackbar again.

[Ray Ryan]

That’s the problem solved by the UUID or whatever. The view can keep track of if that particular error is one that it’s shown

[Zach Klippenstein (he/him) [MOD]]

If the activity is being recreated though, the view would need to persist it’s “last seen UUID” in the saved instance state to prevent showing it again – do we have a convenient way to do that with `LayerRunner`s? I can’t recall seeing logic to specifically handle this case but we must be handling it somehow internally, i haven’t seen any bug reports related to this.

[Ray Ryan]

Crud. No, we don’t, that’s custom view territory.