|mediawiki/extensions/Cards : master||Add watchstar|
|Declined||None||T116624 Add watchstars to uniform cards|
|Resolved||Jdforrester-WMF||T113677 Make OOjs UI in MediaWiki more lightweight, so that we can load it by default on every page without issue|
|Resolved||Legoktm||T108733 MediaWiki Widgets module loads all modules instead of the only the desired one|
|Resolved||matmarex||T112347 Split OOjs UI's distribution .css files into code required by PHP version, and required by JS only|
|Resolved||matmarex||T113681 Split oojs-ui module into smaller ones|
|Resolved||matmarex||T92464 Make it possible to generate only the distribution files that are actually wanted|
|Resolved||Peter||T127125 Create a static version of [[en:Barack Obama]] in mw-config/speedtests with OOjs UI core loaded|
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.