RFC: <Header /> component API

[SiAdcock]

What is the purpose of this change?

There is a plan to standardise headers across the Guardian's web products.

This proposal outlines an API that tries to capture the areas of standardisation while being as flexible as possible for end users.

See the visual designs for more context.

What does this change?

• Add RFC for the Header component API

Risks and uncertainty

• The support buttons / thank you message is delivered by Automat
  • What is the state of Automat? Will it continue to be maintained, or should we take the opportunity to simplify?
  • Currently in support-dotcom-components. Should the component code live in Source?
• Client side rendered consumers will have to ship multiple logos, or they would have to lazy load the correct SVG
• How much can we hardcode?
  • Logos
  • Editions switch
  • Support messaging
  • Masthead links
    • Do we hardcode the URLs or should platforms control the actual links?
• Should Source be aware of / managing Islands?
  • We need to avoid re-rendering the entire header on the client because Nav is pretty huge, and doesn’t need to be dynamic
  • Should we be imposing the Island architecture on all platforms?
  • Could we allow consumers to compose their own header
    • Via props
    • <EditorialHeader masthead={<Island><Masthead /></Island>} />

[changeset-bot]

⚠️ No Changeset found

Latest commit: 20a2b80

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR