Can we undo this and use the alerts module? This is taking the imperative approach of a view instead of more declarative version: e.g., you are using business logic to determine whether to show a snackbar or not then are making an imperative API call to the snackbar. Instead, the view should react to the data change which we already have in the alerts component. Just add an alert in this case?

Done.

this is effectively creating a composite action; please do this in the alerts feature.

As per offline discussion, moved the composite action to RunsTable, and added a comment to indicate that this should be considered an exception, which goes against recommended patterns.

Just wondering, does any asynchronusity disrupt the UX? Adding what is effectively setTimeout(0) would make me feel tiny bit better about the synchronous composite action.

I manually added it to try it out, and the UX seems fine, e.g. Alert still appears and the rest of the UI is functional. Not sure how valuable it is to go add setTimeouts to all cases like these, but perhaps worth considering in a separate PR.

Just so we are 100% aligned; since the view is a representation of the state in the store, you can reason with the state in the store to know. However, it is quite cumbersome and, now, you have to ingrain presentation logic into the store which is very unpleasant.

Wow, when did we do this :(

Googlers, see original cl/330969935. Back then, it was also noted that this is kind of an anti-pattern, but a tradeoff was made for convenience. For the same reason as you mentioned, ingraining presentation logic into the store would be unpleasant, so this tradeoff still probably makes sense.