Proposal: Application headers and footers v2.0

[davidjoy]

In 2019 we devised a system for headers and footers as part of the Arch FED team.

This involved the creation of four repositories:

https://github.com/edx/frontend-component-header
https://github.com/edx/frontend-component-footer
https://github.com/edx/frontend-component-header-edx
https://github.com/edx/frontend-component-footer-edx

The first two are generic headers and footers intended to be the defaults for any microfrontend included in Open edX. They are relatively simple and don't have a ton of content in them (especially the footer)

The second two (with the -edx suffix) are edx.org-specific versions of the header and footer. The header has an alternate set of menus and links, and includes user menu links to enterprises, for instance. The footer has a whole host of links and copyright notifications in it which make it quite different from the generic Open edX footer.

The MFEs that use these headers all have the generic versions in their package.json files, and edx.org's deployment process uses npm to install the -edx versions as aliases as shown here:

https://github.com/edx/tubular/blob/master/tubular/scripts/frontend_utils.py#L66

Problems with this approach:

1. These headers and footers are only useful for particular MFEs. As a result, we've been telling folks for a while to create their own headers in their apps in anticipation of a better solution coming down the pipe. This was to avoid a situation where we try to make these headers be All Things To All Apps, which would become unmaintainable. The system is inflexible.
2. Engineers don't really understand the existence of or approach used to substitute the -edx headers for edx.org
3. The approach we use with edx.org is not complex, but also not well documented and otherwise unsupported for Open edX installations - folks are somewhat on their own if they want to use a custom header.
4. If we keep the approach of having separate Open edX and edx.org versions of the headers and footers, and want to add more headers/footers, we're going to quickly have an unwieldy proliferation of repositories to handle.
5. We've had massive code duplication at this point, where the base code from the two -edx repositories has been copied all over the place to make custom headers.

A proposed approach:

I think in order to support both edx.org and Open edX, we need a new multi-pronged approach here.

• First, we should treat headers and footers as a collection of customizable, composable reusable components. This means an application could have a dependency on a frontend-headers repository, for instance, and pull the pieces out of it that it needs.
• The default headers and footers in applications should attempt to be configurable for 80% of use cases, ideally for edx.org as well. This requires a more robust configuration mechanism than environment variables, preferably one that would allow us to pass a JSON document into the application at build time.
• Apps should be able to use Experience Plugins to configure themselves with an alternate header or footer for the 20% of cases where an operators needs can't be fulfilled by the combination of reusable components and configuration described above.
• We need existing MFEs to be updated to use our reusable components.

Benefits:

• Two repositories total, one for headers and one for footers. Done. Combine them into frontend-organisms if we really want one.
• New MFEs would no longer copy code around, but could use a dependency on our new repository and pull our the component building blocks their app needs. The header/footer repositories could also provide common layouts.
• The npm aliasing mechanism could be eliminated and header/footer configuration could be done like any other configuration in the app, reducing the number of mechanisms that people have to learn. This should help us support Open edX more fully, rather than the current system in which we configure our headers/footers in a set of private repositories the community can't see.

[arbrandes]

This should also be discussed at the upcoming Frontend Pluggability summit.