feat: add help button to header#251
Conversation
brian-smith-tcril
force-pushed
the
help-button
branch
from
7d8fc15 to
6688abb
Compare
brian-smith-tcril
force-pushed
the
help-button
branch
from
6688abb to
3cf61c1
Compare
| import { getAppConfig, WidgetAppendOperation, WidgetOperationTypes } from '../../runtime'; | ||
| import HelpButton from './HelpButton'; | ||
|
|
||
| export const HELP_WIDGET_ID = 'org.openedx.frontend.widget.header.help.v1'; |
There was a problem hiding this comment.
I've been trying to avoid screaming snake case for new constants, specially exported ones. The name and the fact they're a const should be more than enough for readers and consumers to understand their purpose.
| export const HELP_WIDGET_ID = 'org.openedx.frontend.widget.header.help.v1'; | |
| export const helpWidgetId = 'org.openedx.frontend.widget.header.help.v1'; |
We're still going to see them in legacy configuration, but that makes for a neat indicator of what's properly typed vs a string-only MFE config var that requires casting (which is precisely what you had to do with SUPPORT_URL below).
There was a problem hiding this comment.
Fixed with https://github.com/openedx/frontend-base/compare/3cf61c1430989a016ed6110f50003ca5ad837c07..28bb5428428b2e132eb60e3334195d28d40de9f2 (amended the first commit of the two in this PR)
|
|
||
| // Secondary-nav cluster sits flush against whatever's to its left | ||
| // (notifications bell, etc.) — those neighbors bring their own padding. | ||
| .secondary-nav-links > .nav-link:first-child { |
There was a problem hiding this comment.
I realize this is extremely nitty, but do we need to limit ourselves to .nav-link?
| .secondary-nav-links > .nav-link:first-child { | |
| .secondary-nav-links > :first-child { |
There was a problem hiding this comment.
I went back and forth on this a bit. .nav-link was the only thing giving me trouble, so I figured limiting it might make sense, but it's probably better for consistency to not have it.
The only other example I've seen in here has been IconButton, which already doesn't have padding so it's a no-op for those.
Fixed.
Provides a reusable HelpButton widget and a helpButtonSlotOperation helper. Apps opt in by calling helpButtonSlotOperation with their appId and route role; the helper appends the button to the secondaryLinks slot, gated by that role. The widget reads SUPPORT_URL via getAppConfig at render time, so the value flows from runtime MFE_CONFIG / MFE_CONFIG_OVERRIDES (or any legacy fallback the backend provides) without rebuilding the apps. The widget returns null when the URL is empty so the button only appears when configured. Refs openedx#245 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
brian-smith-tcril
force-pushed
the
help-button
branch
from
3cf61c1 to
28bb542
Compare
Strips padding-left from the first .nav-link in SecondaryNavLinks so the cluster sits flush against neighboring widgets in desktopRight (e.g. the notifications bell). Inter-link padding within the cluster is preserved. Refs openedx#245 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
brian-smith-tcril
force-pushed
the
help-button
branch
from
fff5763 to
4ba1da2
Compare
| op: WidgetOperationTypes.APPEND, | ||
| element: ( | ||
| <HelpButton | ||
| getUrl={() => getAppConfig(appId).SUPPORT_URL as string | undefined} |
There was a problem hiding this comment.
for this one we will keep using as snake case or we will change in the future for supportUrl?
|
🎉 This PR is included in version 1.0.0-alpha.42 🎉 The release is available on: Your semantic-release bot 📦🚀 |
5 participants
Summary
Frontend half of #245. Adds a reusable help button widget in the header so any app can opt in with one helper call. URL flows from runtime config (
MFE_CONFIG/MFE_CONFIG_OVERRIDES, plus the help-tokens legacy fallback the backend provides for instructor-dashboard).What this PR adds:
HelpButtoncomponent (renders aLinkMenuItemwithvariant="navLink"when itsgetUrl()callback returns a truthy URL, otherwise null)helpButtonSlotOperation({ appId, role })helper that builds aWidgetOperationTypes.APPENDop forsecondaryLinks.v1, gated bycondition.active: [role]header.helpmessage.nav-linkinSecondaryNavLinksso the cluster sits flush against neighboring widgets (e.g. the notifications bell) — separate commit, can be reviewed independentlyApps opt in with one line:
Companion PRs:
SupportLinkMenuItemto the helper)commonAppConfig.SUPPORT_URLfor local verification)Backend half (already merged) provides per-app
SUPPORT_URLvia the help-tokens legacy fallback for instructor-dashboard.Test plan
cd packages/frontend-base && nvm use && npm run test— new HelpButton + helper tests, full suite greencd packages/frontend-base && nvm use && npm run lint— cleancommonAppConfig.SUPPORT_URLand verify Help renders on a learner-dashboard route, links to the URL, and disappears when SUPPORT_URL is emptyFollow-up (not in this PR)
Help button on mobile — current scope is desktop only, matching the prior learner-dashboard behavior. The non-frontend-base headers vary across apps; before adding mobile, worth deciding the intended pattern rather than literally matching any one legacy app.
🤖 Generated with Claude Code