This caught my eye. I don't fully understand it, but it has the word "search" in it, so we should probably be aware of it.
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,
Kevin Smith Agile Coach, Wikimedia Foundation
---------- Forwarded message ---------- From: Jon Robson jrobson@wikimedia.org Date: Wed, Nov 4, 2015 at 10:48 AM Subject: [Wikitech-l] Rewriting the watchstar code in OOjs UI / performance To: Wikimedia developers wikitech-l@lists.wikimedia.org
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
_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l