Page MenuHomePhabricator

Investigate coupling in the front end code
Closed, ResolvedPublic

Description

  • There's code in lib that generates HTML (Should check js and css for selectors targeting this html)
  • Actual Javascript UIs: jQuery, OOUI (and homegrown), Vue

Event Timeline

Picked this up as I wasn't sure on where to start with the other tasks, for now.

ItamarWMDE added a comment.EditedJun 19 2020, 8:23 AM

Report: JS Globals, jQuery and Selector Coupling in Wikibase

Methodology

The data for the following report was primarily gathered in two ways:

  1. An ESlint Run to Search For usage of Global Variables
  1. Using VSCode with some Regex to generate .code-search text files
Running ESLint

The ESlint and npm configuration used can be found here: https://gist.github.com/itamargiv/085299d0c12ae7c184eb7a49f9f66f96

To generate the reports:

  1. Download the files into any directory in your computer
  2. Open a terminal in the directory you downloaded the files into, and run the following to install dependencies :
npm install
  1. Run the following command (don't forget to replace the path to directory you want to analyze) :
npm run --silent report <path-to-dir>

The reports will be generated a subfolder named reports

Working with .code-search files

The VScode generated code search files are simple text files which can be analyzed with any program. While VSCode is not required to open the files, when using VSCode to open them you gain the added bonus of being able to rerun the search query (as well as fix and manipulate it).

Report

The full report including links to the report files used for it's data can be found here: https://www.notion.so/Report-JS-Globals-jQuery-and-Selector-Coupling-in-Wikibase-d3776e002ac649c49fe1f5ee6a5ed083

TL;DR

Global Variables:

  • In terms of Global Variables, WikibaseClient is the least coupled extension and can be potentially decoupled entirely
  • View and Repo are highly coupled to each other
  • View assigns a property to the mw global namespace

jQuery

  • There is relatively high usage of the jQuery Global namespace (both for use and assignment)
  • There are 53 Widgets in use out of which only 1 lives in Client
  • Most of the widgets are defined and used in the View pseudo extension.
  • Widgets defined in Lib are used in all Extensions.

Selector Coupling

  • No apparent coupling between JS files in Client and non JS files in other extensions
  • Most selectors refer to templates.php in View
  • There is potentially some coupling between Lib and View in terms of Selector usage
Conclusions
  • In terms of the Javascript codebase, it appears to be possible to completely decouple Client from Lib. This can be done in several ways:
    • Copy code over from lib to Client and let their histories diverge
    • Rewrite Client's dependencies on the global scope in a way that keeps the subset of functionality used from these global namespaces
    • Rewrite the only Client widget (wikbase.linkitem) into vue component(s).
  • It appears that it might also be feasible to try and extract additional widgets and globals from Lib and Repo directly into View
  • As Repo and View are tightly coupled, it seems as though they should be registered under one extension (while keeping the domain separation clear enough to enable us to extract view late on if need be)
SummaryClient frontend is not very coupled with other (pseudo-)extensions. Repo and View are highly coupled.
Risks, threats, challenges identifiedHigh reliance on global variables. Like in ResourceLoader investigation, there is a risk of breaking other extensions or gadgets, e. g. if we move modules from Client/Lib to View/Repo or switch from global variables to package imports/exports.
Opportunities noticedLow(er)-hanging fruit: detach Client’s linkitem from the rest.
Other remarksThere are apparently a few unused widgets in View
Ladsgroup closed this task as Resolved.Jun 24 2020, 10:11 AM