In T321498, we added an inline script that allowed the reading of a cookie to toggle classes on the body tag, effectively disabling a "feature".
We would like to expand this for other features, allowing anonymous users to toggle font-size, dark mode and to remember states such as sidebar / table of contents collapsed. To do this the right way, we will be engaging in a TDMP around various available options in this space here. As part of this TDMP, however, we should measure the performance of our cookie-based approach, which is what this ticket is meant to handle. Note that actually analyzing these logs is out of scope for now.
Background
Current usage is like so:
mw.cookie.set( 'mwclientprefs', 'vector-feature-limited-width' );
which results in the toggling of 'vector-feature-limited-width-enabled' to 'vector-feature-limited-width-disabled'
Proposal
It's proposed that this be expanded to allow the disabling of multiple "features" and to provide this functionality to consumers.
mw.util.setFeature('feature-1', false)
mw.util.setFeature('feature-2', false)
mw.util.setFeature('feature-3', false)
mw.util.setFeature('feature-3', true)Internally this would result in the following call:
mw.cookie.set( 'mwclientprefs', 'feature-1|feature-2' );
which would result in feature-1-enabled and feature-2-enabled class when present on the HTML tag to become feature-1-disabled and feature-2-disabled.
This would require:
- A small modification to the existing code, to introduce a delimiter and a for loop to the existing code: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/883243
- Providing a utility method to wrap the setting of the cookie and capturing these requirements in a new public and stable method disableFeature
- Constraining the utility method as necessary
TODO
- Add tests that can measure the performance impact of the change on key frontend metrics.
Separately (not as part of this ticket but adding it here for reference)
We will be going through the TDMP process via a separate ticket and proposal, here. The purpose of this proposal is to define a general problem statement that could have multiple means of being addressed. One of these is a cookie-based approach as outlined in this ticket, but there may be others.
Next steps are to discuss this problem statement together with Architecture, Performance, and other interested feature teams, and then based on the feedback we receive, we will be implementing various prototypes to address these concerns.
Sign off steps
For now, the purpose of this ticket is to add tests that measure the performance impact of the multi-preference cookie approach and that we can run at a later date to compare with other implementations (if needed). If the tests have been added, we can close out this ticket.
Going through the TDMP with the ticket that we create will be the most immediate next step, but is outside the scope of this ticket. We will then evaluate the different options on the table via prototypes. Based on the approach we identify, we will then have a new approach for setting these preferences, at which time we should do the following:
- We should implement the new API. (create a new task for doing that)
- We should document and advertise the new API. (include that as A/C)
But, notably - most of the upcoming action will take place via the to-be-created TDMP ticket.