The task needs more information about the bigger plan and the reasoning to use OOJS-UI.

What does mobile.abusefilter do exactly? Does it do anything besides displaying a warning to the user? I suspect that OOJS UI might be overkill for this.

The issue is the code should not live in MobileFrontend. It should live in the AbuseFilter extension.

Oojs ui is currently the only accepted way to build frontend code without adding a new library. It may be a little heavy weight yes.

In T110741#2836829, @kaldari wrote:

What does mobile.abusefilter do exactly? Does it do anything besides displaying a warning to the user? I suspect that OOJS UI might be overkill for this.

It first shows a message at the top of the editor overlay with a link to see more info in another overlay (this time, the Abuse Filter overlay). And yes, OOJS-UI doesn't seem to be needed here. In fact, we can even remove the module and replace its functionality with a toast in MF. We may have to adjust the toast code to allow clicking of links as there maybe links to the filter that blocked the action.

@Jdlrobson can you flesh out a description for this task? Right now it is unclear if moving this code out of MobileFrontend is worth the hit of requiring OOjs-UI. The best course of action may end up being a new design for this action flow, as @bmansurov suggested.
cc @Nirzar

I've fleshed it out as best I can and tried to keep it as general as possible as I don't have the answer for how we do this. If we want to do that we'll need to invest some time in a spike.