Why we split panel menus into small, named actions
A single “visit website” link in the user menu sounds trivial — until three more items arrive and the panel provider becomes a junk drawer.
Every management panel grows a user menu: profile, sign out, maybe an external link. The first version is always inline — a label, a URL, an icon, all in one place. That works until the second, third and fourth item show up.
We treat each menu entry as its own small action class, assembled in the panel provider the same way table actions are assembled in resources. The provider stays a wiring layer; labels, URLs and icons live next to the behaviour they describe.
What this buys us
- Readable providers — opening the panel configuration tells you what the menu contains without scrolling through closures.
- Consistent patterns — the same factory style we use for “edit user” and “delete contact” applies to “visit website”.
- Easier review — a new menu item is one new file and one line in the provider, not a growing block of anonymous configuration.
None of this is novel computer science. It is discipline: when a panel surface accumulates entries, we name them and give them a home before the file becomes embarrassing to open.