Page MenuHomePhabricator

Remove data-mw-list-page-count attribute from the "Save page" bookmark button
Open, MediumPublic3 Estimated Story Points

Description

ReadingLists currently queries the database to get info about default Reading List, including the list id and the reading list size.

data-mw-list-page-count is set as a data attribute on the button and is used client-side in the readingLists.bookmark.edit hook. We listen to the hook in WikimediaEvents where we have our experiment code.

  1. Check with @jwang and @HFan-WMF if we still need to include article_count in future metrics?
  2. If we need it, then initialize the count as null and then update it as part of the API response on the first page save / unsave action.

We also use it check listPageCount === 1 when determining whether or not to show the "Saved pages" onboarding dialog, pointing users to the "Saved pages" item in the user menu. For this, we already check the readinglists-saved-pages-dialog-seen local storage key and checking page count might be redundant and this check can be removed.

We need to avoid database queries such as this when a user with ReadingLists views an article.

Event Timeline

aude set the point value for this task to 3.Feb 24 2026, 3:27 PM
aude moved this task from Needs refinement to Ready for sprint on the Reader Experience Team board.
aude moved this task from Ready for sprint to Needs refinement on the Reader Experience Team board.
aude removed the point value 3 for this task.

@aude I synced up with Jennifer today to discuss this, and she and I are in alignment that we should remove any database queries that are redundant and costly to perform.

Jennifer also mentioned that it's possible that the page count info is already stored in the below tables:

If so, that should be sufficient information to allow us to know how many items a user has saved, without having to perform this attribute query.

Per your suggestion on getting a head start on the measurement work for reading list beta, I think we should add it to this sprint (and have a little wiggle room with the point capacity to do so, I believe). Should we estimate it async?

I think we can add this to the sprint, as it blocks continuing work on https://phabricator.wikimedia.org/T417010

aude set the point value for this task to 3.Mar 4 2026, 5:41 PM

It would be best to do this task after T414368 and perhaps is not 100% necessary after we merge T417404

aude lowered the priority of this task from High to Medium.Mar 9 2026, 4:21 PM