Simplify template logic for header component

[paulrobertlloyd]

Description

Prior to any work on adding account links to the header, or refining its design, this PR aims to reduce the complexity of the component template, and remove repetition of navigation and search markup.

This PR:

• Shows or hides navigation and search markup by querying the presence of values for params.primaryLinks and params.search respectively
• Removes repetition of navigation and search markup thanks to simplified logic and fewer variables
• Uses the default filter for values as opposed to longer if/else tags
• Adds an option to set the (visually hidden) label for the search input
• Allows a transactional service name to be used alongside navigation and/or search
• Changes the default search query param from search-field to q, to match that used by the NHS.UK website (all the other fallback values do this, so this should as well)

As this PR stands, this is a breaking change, although only in terms of the Nunjucks macro options. Here are the changes:

Option	Change	Note
showNav	Removed	Navigation shown if primaryLinks option provided
showSearch	Removed	Search shown if search option provided
transactional	Removed	Transactional header used if transactionService option provided
search	New option	Used to collate all search related options
search.visuallyHiddenLabel	New option	Change the (visually hidden) search label. Defaults to ‘Search the NHS website’
searchAction	Renamed	Becomes search.action
searchInputName	Renamed	Becomes search.name

It should be noted that the service manual website, as just one example, currently has the label ‘Search the NHS website’, when in fact you can only search the service manual website. The new search{}.visuallyHiddenLabel option would make it possible to use a correct label.

If this PR is accepted, a separate PR can be made against the service manual to update these options.

There’s a whole load of other refinements that could be made in terms of markup, styles and the different options provided, but I’ve tried to keep this change tightly scoped to focus only on reducing the complexity of this component’s templating logic, with the side effect being a reduction in the number of interconnected macro options provided to authors.

Why remove showNav, showSearch and transactional options?

While it could be suggested that these options make it easy to show/hide parts of the header, this can be achieved with Nunjucks in other ways. For example, currently you might do the following:

{# If `user.loggedIn` is `true`, navigation is shown #}
{{ header({
  service: {
    name: "Example"
  },
  showNav: user.loggedIn,
  primaryLinks: [{
    url : "#",
    label : "Item one"
  }, {
    url : "#",
    label : "Item two"
  }]
}) }}

This could be written thus:

{# When `user.loggedIn` is `true`, navigation is shown #}
{{ header({
  service: {
    name: "Example"
  },
  primaryLinks: [{
    url : "#",
    label : "Item one"
  }, {
    url : "#",
    label : "Item two"
  }] if user.loggedIn
}) }}

It can also get tricky and complex if you have to manage the state of the header across multiple options. The changes in this PR hopefully make it easier to manage this.

Checklist

• Tested against our testing policy (Resolution, Browser & Accessibility)
• Follows our coding standards and style guide
• CHANGELOG entry

[paulrobertlloyd]

All checks now pass; I hadn’t updated the header/index.njk example ☺️

[frankieroberto]

Looks great. Think it just needs an entry in the CHANGELOG, and an update to packages/components/header/README.md.

There's also a couple of uses of showNav and showSearch within app/ to update.

Not sure when the next breaking change release is planned for? @anandamaryon1

[paulrobertlloyd]

Updated the component README.md, added a line to the CHANGELOG.md, and updated the reaming examples.

Not sure this should be part of this PR, but I’d love to simplify the component API further by renaming primaryLinks to navigation, and merging service and transactionService options. Interested to hear what people think to making a bunch of breaking changes to the header component in the next major release?

I can create the corresponding PR on the service manual when we are happy with the shape of this PR, and if there any other changes we want to make to the header component at the same time.

[frankieroberto]

Looks good to me. I'm not sure what our merge strategy should be here, as this would have to go into a breaking change release. @anandamaryon1?

Given this is already a breaking change, I'd be up for renaming primaryLinks to navigation and merging service and transactionService options as part of a follow-up PR targeting the same release?