[WIP][SPIKE]: Address component

[ttbarnes]

Initial setup for a new address component.

Keen to see if there is interest for this component before continuing - any help or feedback is greatly appreciated.

Why?

Currently, the only way to render address fields is to render the text input component several times. I.e one text input for each address field.

Instead, it would be very useful to have a single component that:

• Automatically renders address field text inputs, ensuring a consistent pattern.
• Consumes an object of values that pre-populate all text input values.
• Consumes an object of errors that pre-populate all text input error messages.
• Has the ability to consume custom field IDs for each field.
  • For example, data wise, one service might have a "Line 1" field named as line1, whereas in another service, it could be e.g addressLine1.
• Has the ability to render "line 1" and "line 2", with only "line 1" having a visible label. E.g "Building and street" could have 2 lines.

This should therefore handle the recommended address pattern with a single component, whilst also reducing lines of code in individual services.

Example usage

{% from "govuk/components/address/macro.njk" import govukAddress %}

{{ govukAddress({
  legend: {
    text: "What is your address?"
  },
  line1: {
    id: "line1"
  },
  line2: {
    id: "line2"
  },
  townOrCity: {
    id: "townOrCity"
  },
  county: {
    id: "county"
  },
  postcode: {
    id: "postcode"
  },
  values: {
    line1: "Line 1!",
    county: "London"
  },
  errorMessages: {
    line1: {
      text: "Address line 1 cannot contain special characters"
    },
    townOrCity: {
      text: "Enter town or city"
    },
    postcode: {
      text: "Enter postcode"
    }
  }
}) }}

Example screenshots

Rendering

Alternative rendering

Rendering with error messages and pre-populated values

TODO

• Unit tests (having some trouble understanding how to test with the nunjucks test config, doesn't seem to render anything past the 1st DOM level).
• Review examples.
• Determine if any other updates are required.

Additional information

This component idea stemmed from UKEF - Export Insurance Policies, where we were rendering several address components. We ended up creating our own address component that handles the above functionality; Instead of having to render 5x text inputs and various conditions in individual forms.

[querkmachine]

Some random, disjointed, personal thoughts about this:

I think the main reason we don't have any singular component for this is because the format of addresses is too variable. Although the format used here works for most UK addresses, it isn't necessarily suitable for overseas addresses or those from other countries (including Ireland).

As such, what formats and validations that need carried out on addresses can be heavily dependent on the audience for the service. We might risk codifying one technique as being 'the correct way' in people's minds by making it a component, when really there is no single 'correct' choice.

Even within UK addresses there is some variation as to what might be the best way of gathering this information. 'County', for example, hasn't been needed for a long time now, and a team may want to omit it. Strictly speaking, we don't need a town or city either if we ask for the postcode.

Having a dedicated address component may also open a Pandora's box of why we don't also provide components for postcode lookup, card or bank account details, or other repeatable form design patterns.

[ttbarnes]

Some random, disjointed, personal thoughts about this:

I think the main reason we don't have any singular component for this is because the format of addresses is too variable. Although the format used here works for most UK addresses, it isn't necessarily suitable for overseas addresses or those from other countries (including Ireland).

As such, what formats and validations that need carried out on addresses can be heavily dependent on the audience for the service. We might risk codifying one technique as being 'the correct way' in people's minds by making it a component, when really there is no single 'correct' choice.

Even within UK addresses there is some variation as to what might be the best way of gathering this information. 'County', for example, hasn't been needed for a long time now, and a team may want to omit it. Strictly speaking, we don't need a town or city either if we ask for the postcode.

Having a dedicated address component may also open a Pandora's box of why we don't also provide components for postcode lookup, card or bank account details, or other repeatable form design patterns.

Thank you, all understood and makes sense. What would your thoughts be on a UK Address component with all fields being optional?

For example, address fields could only render if they are passed to the component. The following example would only render 2x inputs:

{{ govukAddressUk({
  legend: {
    text: "What is your address?"
  },
  line1: {
    id: "line1"
  },
  townOrCity: {
    id: "townOrCity"
  },
  values: {
    line1: "Line 1!",
    townOrCity: "London"
  },
  errorMessages: {
    line1: {
      text: "Address line 1 cannot contain special characters"
    },
    townOrCity: {
      text: "Enter town or city"
    },
  }
}) }}

I appreciate there are many variants and this could potentially open a pandora's box, however this could allow for multiple configurations for a UK address - in theory, I imagine, all combinations. For example, if only "line 1" is desired, it would be supported in the component by only passing line1.