Open brian-smith-tcril opened 3 months ago
How can we help site operators that currently rely on the forking/npm install strategy move to using the frontend plugin framework plugin slot strategy?
I'd like to clarify here that we still need to support the current forking/npm install
customization strategy - but it is not a strategy we want to recommend.
This will likely impact how we need to think about
How do we handle the current LearningHeader vs StudioHeader vs DesktopHeader vs MobileHeader situation?
Anything and everything else people can think of that will impact how the header plugin slots are created!
There might still be an opportunity for frontend-component-header
to rely on Navbar
from Paragon (docs). There's has been early discussion/design work in the past within Paragon Working Group (#wg-paragon
) about how to make the Paragon Navbar
component more generic, with defined slots / permutations, such that it can be used within the platform (e.g., via frontend-component-header
). The interaction with Navbar
from Paragon might be out-of-scope for this particular bit, but I still feel this is still a direction possibly worth pursuing.
How do we handle the current LearningHeader vs StudioHeader vs DesktopHeader vs MobileHeader situation?
I think noting how headers are being used in the default enabled MFEs in tutor are using will be helpful for figuring this out:
No header
import Header from '@edx/frontend-component-header';
<Header />
import { LearningHeader as Header } from '@edx/frontend-component-header';
<Header
className="learning-header"
courseOrg={courseMetadata.org}
courseNumber={courseMetadata.number}
courseTitle={courseMetadata.title}
/>
import { StudioHeader } from '@edx/frontend-component-header';
<StudioHeader
org={org}
number={number}
title={title}
isHiddenMainMenu={isHiddenMainMenu}
mainMenuDropdowns={mainMenuDropdowns}
outlineLink={outlineLink}
searchButtonAction={meiliSearchEnabled ? openSearchModal : undefined}
/>
import { LearningHeader as Header } from '@edx/frontend-component-header';
{!enableInContextSidebar && (<Header courseOrg={org} courseNumber={courseNumber} courseTitle={courseTitle} />)}
import Header from '@edx/frontend-component-header';
<Header />
[!IMPORTANT] Assuming https://github.com/openedx/frontend-app-learner-dashboard/pull/327 lands
Import
import Header from '@edx/frontend-component-header';
Use
<Header mainMenuItems={learnerHomeHeaderMenu.mainMenu} secondaryMenuItems={learnerHomeHeaderMenu.secondaryMenu} userMenuItems={learnerHomeHeaderMenu.userMenu} />
Learning
Import (CourseAccessErrorPage)
import { LearningHeader as Header } from '@edx/frontend-component-header';
Use (CourseAccessErrorPage)
<Header />
Import (TabPage)
import { LearningHeader as Header } from '@edx/frontend-component-header';
Use (TabPage)
<Header courseOrg={org} courseNumber={number} courseTitle={title} />
Import (GoalUnsubscribe)
import { LearningHeader as Header } from '@edx/frontend-component-header';
Use (GoalUnsubscribe)
<Header showUserDropdown={false} />
ORA Grading
Import
import { LearningHeader as Header } from '@edx/frontend-component-header';
Use
<Header courseTitle={courseMetadata.title} courseNumber={courseMetadata.number} courseOrg={courseMetadata.org} data-testid="header" />
Profile
Import
import Header from '@edx/frontend-component-header';
Use
<Header />
No header
[!IMPORTANT] These screenshots are from before https://github.com/openedx/frontend-app-learner-dashboard/pull/327 landed
// todo
// todo
What are the ways in which site operators want to customize the header?
It would be really great to simply be able to add/remove/modify links in the main navigation and user menus without having to maintain an entire header component.
@asadali145 I'd love to hear your thoughts on this! In https://github.com/openedx/platform-roadmap/issues/349 you noted wanting to be able to customize the URLs for the links in the user dropdown menu - are there any other header customizations you were hoping to be able to do without forking?
Product Requirements defined here - please provide input in the wiki! https://openedx.atlassian.net/wiki/spaces/OEPM/pages/4412243977/Proposal+Customizable+Header+for+LMS
Hi @brian-smith-tcril, We are using a few customization options already provided by the header and have forked the header to add a few more customizations. Here is the complete list:
This issue sums up things nicely and identifies all our pain points.
@jmakowski1123 has added all of the customizations that we look for in the proposal. I have left a comment with a couple more suggestions.
CC: @pdpinch
It is important for site operators to be able to customize the Header. This is currently supported by having site operators fork this repository and
npm install
from their fork, however, that is a lot to ask of a site operator that just wants to make a few small changes.Now that
frontend-plugin-framework
exists, we have an opportunity to make the header customization story a better one!In this issue I would like to discuss:
npm install
strategy move to using the frontend plugin framework plugin slot strategy?LearningHeader
vsStudioHeader
vsDesktopHeader
vsMobileHeader
situation? Is there a clear path forward for consolidating those? Is consolidating those required to provide a good site operator experience for using plugin slots?