Hi all,
We've released version 0.3.0 of WVUI earlier today.
One of the agreements from Vue.js developer summit [0] organized by the
Design System team has been to start a new library and repository next with
all other technical decisions made, a.o. being based on Vue 3 or no
JavaScript only
support to IE 11. With this email we want to clarify upfront why we've
merged two more component additions (progress-bar and toggle-button)
succeeding the summit.
Reasons was mainly to finalize the already in-flight work by volunteer
DannyS712.
Additionally to this, all other components merged since v0.2.0 and before the
summit – checkbox, dropdown and options-menu – are part of this
release. Same goes
for further improvements for the most important in-production use case,
Desktop Improvements project's Typeahead Search feature [1].
We'll discontinue major additions to WVUI from this release on besides
bug fixes and
will focus our work on the coming library.
Thanks to volunteer DannyS712 for all contributions! And to Nikki
Nikkhoui for the
continued build step support and James Forrester to get release out of the door
during after hours.
Find interactive demos hosted on doc.wikimedia.org [2] and the additional
improvements since v0.2.0 in the full changelog [3].
If you have any further questions please reach out to
design-systems-team-external(a)wikimedia.org.
Best,
Volker
[0] https://www.mediawiki.org/wiki/Design_Systems_Team/Vue.js_Developer_Summit_…
[1] https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/Vue.js_case…
[2] https://doc.wikimedia.org/wvui/master/ui/
[3] https://gerrit.wikimedia.org/r/plugins/gitiles/wvui/+/refs/tags/v0.3.0/CHAN…
Hi All
There will be no deployment train the week of 2021-09-06 (Mon, 06 Sep –
Fri, 10 Sep). Release Engineering will be having a team focused work week.
Backport and config deployments should continue as planned.
There is a long-term calendar of upcoming known deployment disruptions
available on Wikitech:
https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar
Thank you!
Tyler Cipriani (he/him)
Engineering Manager, Release Engineering
Wikimedia Foundation
Hi everybody,
We've released version 0.42.0 of the OOUI library* yesterday.
It's going to rollout with normal train next Tuesday, 24 August 2021.
Highlights in this release:
- Removal of code fragments for browsers, that were taken out of basic
support, most of those affected released before 2013! [0]. Removal
will directly results in a small performance gain for all other users.
This is nominally a breaking change. If you need to continue to
support those browsers in your environment, please stick with an
earlier version.
- Upgraded underlying libraries to jQuery v3.6.0, up from v3.5.1 and
OOjs to v6.0.0, up from v5.0.0. This goes hand-in-hand with similar
upgrade in MediaWiki core. Both updates above are considered breaking
changes. Please carefully test if they affect your code.
- Two new icons, 'share' and 'ocr' have become part of the library and
the WikimediaUI design system.
- Addition of RequiredElement mixin, already added in v0.41.1
Thanks especially to Thiemo Kreuz and volunteer DannyS712 on improving
the documentation and Umherirrender for continuous code improvement
patches.
You can find details on additional new features, code-level, styling
and interaction design amendments, and all improvements since v0.41.0
in the full changelog [1].
If you have any further queries or need help dealing with breaking
changes, please reach out to me.
As always, interactive demos [2] and library documentation is
available on mediawiki.org [3], there is comprehensive generated
code-level documentation and interactive demos and tutorials hosted on
doc.wikimedia.org [4].
Best,
Volker
* Obligatory to say, no, this is not the answer to Everything. That
will probably be v42 of the future Vue.js based user-interface
components library [5].
---
OOUI version: 0.42.0
MediaWiki version: 1.37.0-wmf.20
Date of deployment to production: Regular train, starting Tuesday 24 August
[0] - https://phabricator.wikimedia.org/T266866
[1] - https://gerrit.wikimedia.org/g/oojs/ui/+/v0.42.0/History.md
[2] - https://doc.wikimedia.org/oojs-ui/master/demos/#widgets-mediawiki-vector-ltr
[3] - https://www.mediawiki.org/wiki/OOUI
[4] - https://doc.wikimedia.org/oojs-ui/master/
[5] - https://phabricator.wikimedia.org/T288980
[Moving to wikitech-l; mediawiki-l is a little off-topic.]
On Mon, 26 Jul 2021 at 21:27, Yaron Koren <yaron57(a)gmail.com> wrote:
> Hi,
>
> I've been trying to get rid of the ESLint warnings for the JavaScript code
> in some of my extensions, when they go through Jenkins validation. One
> warning that appears fairly often is this one:
>
> Where possible, maintain application state in JS to avoid slower DOM
> queries
> no-jquery/no-class-state
>
>
> I'm not sure if this is a warning that's specific to Wikimedia code, but
> doing a web search on it brings up this Wikimedia help page as the only
> real result:
>
>
> https://github.com/wikimedia/eslint-plugin-no-jquery/blob/master/docs/rules…
>
Yes, we forked the dead "jquery" upstream eslint plugin and have expanded
it significantly. In general, the plugin's purpose
<https://www.npmjs.com/package/eslint-plugin-no-jquery> is to discourage
use of jQuery functions, especially where the functions are deprecated or
have faster native equivalents. (Almost all uses of jQuery are no longer
necessary given that the vast majority of the Web only runs on
modern-enough browsers.)
This page is rather confusing. It says that the warning comes when calling
> either hasClass() or toggleClass() on a jQuery element. That part makes
> sense, but then the suggested alternatives are strange. The page says that
> the following are some examples of bad code:
>
> $( 'div' ).hasClass();
> $div.hasClass();
>
> In their place, it suggests the following:
>
> hasClass();
> [].hasClass();
> div.hasClass();
>
No, it doesn't. It says that our code is clever enough to not think that
these false positives are issues that you need to fix. It's not saying you
should use a method called hasClass(); it's saying that you should maintain
state inside JS; this is principally a performance/code smell test.
If your code is triggered from a non-JS DOM (e.g. painted from PHP), the
first time you grab state from the DOM is unavoidable (and so you'd use an
inline disable), but thereafter you should keep track of such details in
JS. An example of this is in the initialisation code for Notifications
("Echo"), where it has to grab the state from the DOM
<https://gerrit.wikimedia.org/g/mediawiki/extensions/Echo/+/HEAD/modules/ext…>
for a couple of items, but does so only once.
Sorry that this is confusing! We could put together a narrow JS tips and
tricks page and link to that from the linter, but most of these have been
fixed over the years since we introduced this in Wikimedia production code
so there's not been much call.
J.
--
*James D. Forrester* (he/him <http://pronoun.is/he> or they/themself
<http://pronoun.is/they/.../themself>)
Wikimedia Foundation <https://wikimediafoundation.org/>