Sure, for every piece of the UI that commits a change to the model, such as a save button, you need a callback to pass the updated model to.
You pass a "movie" object and a "saveMovie()" callback into a screen that allows you to edit the details of a movie. You edit the fields then click "save". The code that runs when the "save" button is clicked builds a new movie object then masses the new movie object to the the callback, like this "saveMovie(editedMovie)". The "saveMovie()" callback makes the API calls, database calls, etc, and the movie editing screen doesn't need to to anything else after that, and inside "saveMovie()" you can push a new screen, pop back to the previous one, or whatever. Does that make sense?
"Does this approach scale well?"
I don't see how it could be much worse than making API calls from UIViewControllers. If you do this, you're instantiating new UIViewControllers more often, so if you're loading a bunch of images on a certain view you may want to hang on to a reference to that particular view instead of building a new one each time. But, in my experience, the code ends up being a LOT cleaner than if you treat your UIViewControllers as mutable objects. So from an architecture and maintainability standpoint, it scales really well.
I tried this approach with my current Swift project, but I found that it doesn't scale to a certain level of complexity. A ton of the UIKit APIs are naturally stateful, so you end up having to work around them in weird ways. Animation is particularly hard when your view controllers are pure. The solution I opted for was to instead create a unidirectional data flow and just "refresh" the state of the VC every time it gets passed different data. This way, you get most of the benefits of one-way data flow and the state of your VCs is (somewhat) pure, but you can easily drop down and use the UIKit APIs as needed.
I see what you mean. I'd probably run into issues if I was doing a lot of transitions animated transitions and interactions. With my method nothing is really stopping you from creating a VC that has a public refresh function though. It would just have to break the pattern of ask the others a little bit.
At work we're at 10k loc which isn't huge but it's fairly large for a clojurescript app. Middleware on event handlers is a great abstraction. It's only been a few weeks since the refactor and there are only three of us on the team but I'm not foreseeing any scaling problems. The only changes we made are about 20 middlewares and namespacing our event keywords. We experimented with a forked version of the framework and running multiple re-frame apps nested inside each other but it wound up not being worth the effort.
The only scaling hazard I know of is that re-frame has an internal global atom so that might cause a problem if you're mixing multiple re-frame apps on a single page but it doesn't affect us and reworking the framework to not use a global isn't too difficult.
Does this approach scale well ? Have you done large apps ?
FB has an open source ComponentKit Framework.