Adding/altering metadata properties/values to centralise shared Gnav content

[overmyheadandbody]

Based on author requirements from another thread and JIRA, we need to enable centralisation for Global Navigation content in order to keep shared resources in sync, such as the cloud menus or footer content.

Existing implementation for a similar requirement

A need for centralised 404 pages has been identified and implemented in #845. An author would need to add a new metadata field to their page(s) (or metadata.xlsx file) to specify that the 404 content should be fetched from a centralised location:

404

feds

Possible approaches for Global Navigation

We're mostly focused on centralising the footer content through a new metadata property or value, but since the logic would be almost identical for the Gnav, we'd like to future-proof it an take both use-cases into consideration.

1) The 404 way

Have a brand new metadata property specifying whether header, footer or both need to be fetched from a centralised location. Property name is TBD:

feds	header, footer

2) The #_ way

Keep the existing gnav-source and footer-source metadata properties without adding a new one, but change how their values are defined. By appending #_raw (naming TBD), we would ensure that the metadata content is not altered in any way, this might prove useful for others in the future too.

gnav-source

https://main--milo--adobecom.hlx.page/libs/feds/gnav/cc/section-menu#_raw

This will require a change in the decorateMeta method from utils.js to skip content manipulation if this hash is set.

[chrischrischris]

Method 1 seems much cleaner and author friendly. Should it instead be:

header	feds
footer	feds

or possibly still use the source properties:

gnav-source	feds

I could still see a use for a #_raw or #_unmodified property but for ease of authoring I prefer the feds strings.

[overmyheadandbody]

Unfortunately we can't rely on header and/or footer, since their values are used to init the respective block in Milo. So this would init the non-existing feds block 2 times. We could potentially have some more convoluted logic, like: "if the value is feds, then actually switch the class name to global-navigation, but keep in mind that the content should be fetched from the centralised location", but I feel this would complicate things needlessly.

gnav-source is also a no-go, just because we need the actual path from where to fetch the content from the centralised location. CC/DC/BACOM/Homepage/etc. will each fetch the dropdown content for their particular cloud, using just feds wouldn't provide enough context for that purpose.

I'm still thinking about the #_raw idea, although having feds | header, footer, 404 might be a good approach for the future for anything fetched from a centralised location (I am aware that the 404 logic is already in place and different, but maybe we could support both in the future for authoring consistency 🤷 ).

[overmyheadandbody]

I realised that having the #_raw string for metadata wouldn't solve our use-case. The idea was to not modify such a metadata field at all if that suffix were to be present. However, an author would use {{https://branch--repo--owner.hlx.page/path/to/content#_raw}} for the metadata value, which would not get updated for {{.live}} or production pages.

So I will give up on that idea for now and go on the new metadata property or updating an exiting one path.

[overmyheadandbody]

This is proving to be a no-go for now, we're looking into better centralisation options, discussion can be found under https://github.com/orgs/adobecom/discussions/1388