Are MobX actions allowed to show a confirm dialog, or navigate to a new screen? More generally, can actions touch ui?

[fzyzcjy]

I am refactoring MobX in large-scale applications. Since it is big, making the code clean is very important.

There is an action that does the following (simplified):

@action myAction() {
  var data = await api.getSomeDataFromServer();
  
  if (data.warnUser) {
    var userAgrees = await showConfirmDialog(
       // imagine 20 lines of UI code describing how the dialog looks like. (following is Flutter code, but for JS it should have similar spirit)
       Dialog(title: Text('Hey, are you really sure?', style: TextStyle(fontSize: 20, color: Colors.red), subtitle: Text('...', ...)),
    ); // #1
    if (!userAgrees) return;
  }

  someOperations(data);

  Navigator.push('/another_page'); // #2
}

I am worried whether the #1 and #2 are OK or not. The reason is that, IMHO mobx has a UI - action - state triad (as is seen in the figure below by the mobx book). Thus, Actions should modify the State instead of the UI directly. But in #1, the Action directly shows a dialog - which is UI; in #2, the Action directly navigates to another page - which is also UI related.

In short, can MobX's actions directly "touch" and manipulate the uis?

I have made some searches about this and is quite confused now. Thanks for any suggestions!

Remark: I tag it as both Flutter and JavaScript, because indeed I am using Flutter but this question applies to the JS version of MobX as well.

Remark: Following is the diagram from the mobx book.

[kubk]

I prefer to call navigation in actions, because "current page" is also state. Show / hide confirmation dialog is also state. There is a related article from the Mobx author: https://michel.codes/blogs/ui-as-an-afterthought

[fzyzcjy]

Thank you so much for the reply and the link!

[urugator]

All state on frontend is somehow UI related. If you won't display anything, you won't need any state.
If mobx actions wouldn't be allowed to perform UI related operations they would be pretty useless (at least on frontend).
Generally speaking action should modify only YOUR own state (observables) and you should use reaction to modify external state, eg DOM or whatever flutter uses to represent UI.
However this approach is usually only applicable if you can "map" your state to UI state (reconstruct/update). It doesn't work well if only imperative API like openDialog/closeDialog is available. It doesn't mean it should be part of action, it means mobx is useless is such case and the action doesn't matter.

[fzyzcjy]

Thank you for the reply! However I am a bit confused: How can I implement the logic mentioned in the question (you know - I cannot change the logic itself, but only change implementation details), with the best practices you suggested?