One use case can be seen here: https://gerrit.wikimedia.org/r/#/c/249957/
When a user interacts with the view (clicks a watchstar icon in this case) all we have to do is to update the model, and listen to model update events, and re-render the view. So, to answer your question, the model properties will change when we want to update the UI after a user input.
I also see models post the new data to the server. Maybe interact with the gateway somehow or replace it completely.
My main concern around this work is that there is a watchstar in core already. I wonder if this is an opportunity to clean up that code to be a model that can work in multiple instances on a single page and find a way for MobileFrontend to use it.
That said, rendering happens via OO.ui which is a big library to load just for three watchstars. Given the code will be loaded on demand this might not be the worst thing but...
The approach taken is not oojs ui so if we're not doing that we need to acknowledge it and why.
The reasoning behind not using OOJS UI was exactly what you said, it's big. Simple model-view separation seems to get the job done. And it's not like we're creating a full fledged framework there.
I'll have a look at the watchstar code in core. I'd love to use that instead if that's feasible.
Me too, I just need to keep us focused to actually deliver this thing.
I will plan for us to wrap this up in December when things have calmed down. Nothing wrong with working on it in the background but right now event logging and getting this feature on desktop is of greater importance.