The problem with this article is that MVP is wrong in it, and MVVM is potentially lacking some nuance. We choose architecture based on team skills and requirements and what problem we intend to solve with a particular type of abstraction, I do not like “going to the architecture shop and pick one off the shelf” anymore. What works in one project is completely unnecessary clutter in another.

Also, I don’t use Flutter. But if you want general guidance, the right way forward is to expose the View’s events via some form of contract (listener interface, stream of sealed classes, etc. idea is the same) and your “model” (thing that actually does your business logic things) receives events from the view and decides what to do with it.

If you want unit testable code, your click listeners shouldn’t know what to do, beyond propagating the event they were told about. Otherwise, you’ll need *the* button to drive your behavior, which is honestly crazy. Your doorbell’s button doesn’t know about the doorbell either :p