The reading team are keen to have watchstars in more places other than
just at the top right of the page you are viewing.
We already supporting adding things to the watchlist in search,
nearby, watchlist and gather.
We are working on a read more feature which will add a list of pages
with watchstars at the bottom of the page [1]
The code in desktop however is limited in that it is only written to
be usable by the page in question. It does various things such as use
the element id to reflect state (#ca-watch or #ca-unwatch) and runs
once on loading of the script.
We'd like to make this code more reusable so watchstars can be placed
in any interface but this comes with problems.
The model part is not too controversial but when it comes to creating
a reusable UI it becomes a little more complicated.
If we are to turn this into an OOjs UI widget, this would mean that
the OOjs UI library gets pulled in on every single page load. The OOjs
UI library, without styles or icon assets from what I can see is 226.5
kB (without gzip), (for comparisons Backbone is 69kb and React js is
559kb). This is not necessarily an issue, if all our code is built in
OOjs UI but right now we are very very far from that world, so we need
to find a strategy to getting there.
We know this is a problem. When Echo relaunched the new interface
there was a huge spike in first paint [2]. It seems the solution to
this was to render the button on the server side and defer load the
library to avoid this impact on first paint but the underlying problem
still remains - server side rendering is not an option for my team,
so to create a component the standard way we have to load this entire
library.
We have a similar problem with adopting OOJS UI in MobileFrontend. We
want to simply render/style a button on page load via JavaScript and
the library is too heavy weight for this, especially when right now we
don't have use cases for more complicated widgets such as layouts,
popups, windows, toolbars [3]... in fact we already have other
libraries that fulfill these needs that at some point will need to be
converted to oojs ui.
There's been some talk but little movement about cutting up the oojs
ui library into chunks to make it more adoptable by less complex
projects who just need buttons/inputs and other form elements. Is this
still an option? If so, how can we move this along? If not how can we
proceed?
I really think now is the time to talk about this, as adoption outside
the editing team still seems to be limited and from my point of view
this is one of the biggest barriers.
[1]
https://www.mediawiki.org/wiki/Reading/Web/Projects/Read_more
[2]
https://phabricator.wikimedia.org/T112401
[3]
https://www.mediawiki.org/wiki/OOjs_UI