Page MenuHomePhabricator

Build core menu API MVP
Open, MediumPublic5 Estimated Story Points

Description

Background

As one of the initial steps in T311647, we want to develop menu building capability in core to provide menu data that can be registered, used, and modified by skins, extensions, etc.

Description

Build an MVP of a core menu API.

Leveraging the refactoring of menus undertaken in MobileFrontend/Minerva, we can base the initial design of the core menu API MVP using the builder/director design pattern to deliver basic, structured menu data to templates.

Acceptance criteria
  • Menu data generation is config-driven (JSON files)
  • Menu data generation has a clear order of operations (we know which config takes precedence) << TBD
  • Menus can be readily "grouped" i.e. menu entries can be bundled together in defined groups
  • Icons, classes, attributes can be readily added/modified << descoped to Skins
  • Template data generation is backwards compatible
Developer notes

Technical requirements:

  • Settle on new data structure for menus - proposed data structure might be something like https://phabricator.wikimedia.org/F35474715
  • Director classes can be accessed via services and used to build the data in getTemplateData() methods
    • There is dependent work underway to make skin components of menus (T293289 + T302116) -- when related patches are merged, we'll want to use the menu director service to utilize the menu builder classes for data generation. Example POC patch shows how these two efforts can be wired together.
  • Generate new JSON conditionally.
  • Methods to generate data in Skin classes are removed/replaced by menu builder classes. << last step
  • Tests are added << ***

To Do:

  • If the approach proposed in POC patches (823673 + 808913 << footer menu is the 1st test case using Footer, MenuBuilder classes) is good enough to proceed, other menu classes have been stubbed out to implement MenuBuilderInterface:
  • Actions
  • AssociatedPages
  • Footer
  • Languages
  • Notifications
  • UserInterfacePreferences
  • UserMenu
  • UserPage
  • Variants
  • Views
  • Flesh out approach to read a skin's JSON file into the menu builder to conditionally show/hide menus - MenuConfig is stubbed out as the class that will read a given skin.json << needs re-working per T318757
End Q1 status
  • Follow up tasks have been outlined in T318757
  • POC can be thrown away or used as basis for encapsulating menu API code leveraged by Skin Components (example of usage - menu + footer component patch introduces menu components in conjunction with POC MVP patch which creates a default menu component to generate the data using menu api.
  • Descoping original goal in T311647 to what was able to be demo'd in POC patch.

Event Timeline

Change 823673 had a related patch set uploaded (by Clare Ming; author: Clare Ming):

[mediawiki/core@master] POC/WIP Build core menu API MVP

https://gerrit.wikimedia.org/r/823673

cjming updated the task description. (Show Details)
cjming updated the task description. (Show Details)
Jdlrobson triaged this task as Medium priority.Aug 18 2022, 5:25 PM

I fleshed out more dev notes and a tactical plan for moving forward. It could be ready for estimation which I anticipate will be an L/XL so maybe it's better as a parent task but it can be moved to Upcoming for discussion. I (or someone else next week) can break it down into more granular sub-tasks if we agree on the approach.

cjming moved this task from Doing to Code Review on the Web-Team-Backlog (Kanbanana-2022-23-Q1) board.

Setting this temporarily to code review to make sure @Mabualruz and I are on the same page re: approach -- will continue iterating after our mtg today to discuss

cjming updated the task description. (Show Details)

Submitted end of Q1 status at the bottom of the ticket description and re-assigned to @Mabualruz

If the idea is to use the POC to ship, there are clean up tasks corresponding to code review feedback - T318757

Jdlrobson subscribed.

Hey @cjming and @Mabualruz since the quarter has ended and this is not a goal for Q2 I'm moving this out of the sprint board and back into the tech backlog. I'll catch up with you both about how we can evolve this work during the quarter so we don't lose momentum and to talk about targetting a goal in Q3. If I haven't reached out to you by 19th October feel free to remind me!

This is still has low priority, and not focused on in the current team goals