Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: support "address" fields in List schemas #4020

Merged
merged 9 commits into from
Jan 22, 2025

Conversation

jessicamcinchak
Copy link
Member

@jessicamcinchak jessicamcinchak commented Nov 29, 2024

Changes:

  • Building on feat(types): Stricter and more accurate Schema response types #4153, adds support for type: "address" fields in List & Page schemas,
  • "address" fields follow our AddressInput component pattern, with a mix of required and optional fields
  • Adds test coverage
  • Adds a preliminary "Owners" schema (very much anticapte content team will want to edit this!)

Testing: https://4020.planx.pizza/testing/owners-as-list

Screenshot from 2025-01-20 22-27-10

Copy link

github-actions bot commented Nov 29, 2024

Removed vultr server and associated DNS entries

@DafyddLlyr DafyddLlyr force-pushed the jess/list-address-field-owners branch from 52adff1 to 74ca0f0 Compare January 17, 2025 15:48
@DafyddLlyr DafyddLlyr force-pushed the jess/list-address-field-owners branch from f479b83 to 7219a7b Compare January 18, 2025 12:31
@DafyddLlyr DafyddLlyr force-pushed the jess/list-address-field-owners branch from 7219a7b to ad24946 Compare January 18, 2025 12:34
@DafyddLlyr DafyddLlyr force-pushed the jess/list-address-field-owners branch from ec8886f to b77f302 Compare January 20, 2025 12:22
@@ -637,6 +639,8 @@ function Page(props: ComponentProps) {
if (isTextResponse(answer)) return answer;
if (isNumberFieldResponse(answer)) return answer.toString();
if (isMapFieldResponse(answer)) return `${answer.length || 0} features`;
if (isAddressFieldResponse(answer))
return formatAsSingleLineAddress(answer);
Copy link
Member Author

@jessicamcinchak jessicamcinchak Jan 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice & tidy 👍
Screenshot from 2025-01-20 22-27-31

* Maps changes from AddressField inputs to their corresponding nested form fields
* @example
* The input for name=line1 will be mapped to the schemaData[0][yourFn]["line1"] formik field
*/
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@jessicamcinchak jessicamcinchak marked this pull request as ready for review January 20, 2025 21:38
@jessicamcinchak jessicamcinchak requested a review from a team January 20, 2025 21:38
Copy link
Contributor

@RODO94 RODO94 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested it locally and on the pizza, everything seems to be working for me as I'd expect. With all data tracking across nicely to the passport.

Only added one nit comment related to error handling and how strict to be with validating data in the components.

The current Address Component doesn't have this and it can get complex if we handle addresses outside the UK, so happy for this to be left out at your discretion.

const numberOfErrors = mockZooProps.schema.fields.length + 3;

let numberOfErrors = 0;
mockZooProps.schema.fields.forEach((field) => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this! Nice way to clearly manage the date error count

@@ -38,7 +30,7 @@ export default function AddressInputComponent(props: Props): FCReturn {
},
validateOnBlur: false,
validateOnChange: false,
validationSchema: userDataSchema,
validationSchema: addressValidationSchema,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question: significance of this switch is now the List schema now shares the same validation schema as this address input component?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thus, you gave it a more specific name

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And the list schema is now using the <AddressFields/> within the <AddressFieldsInput/>

Copy link
Contributor

@DafyddLlyr DafyddLlyr Jan 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's right - this PR imports and reuses the existing Address component's validation schema.

On the naming - specific names mean we don't have to import multiple instances of userDataSchema and cast them to a meaningful name.

This approach is quite fiddly and error prone, and you need to remember the naming convention and repeat across files 👇

import { userDataSchema as addressValidationSchema } from "@planx/components/AddressInput/model";
import { userDataSchema as textValidationSchema } from "@planx/components/TextInput/model";

This isn't actually applied consistently yet in this file - will push up a quick commit now to address this.

Copy link
Contributor

@DafyddLlyr DafyddLlyr Jan 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please see 70fc546

Comment on lines +55 to +62
export interface AddressFieldsProps {
id?: string;
values: Address;
errors: FormikErrors<Address>;
handleChange: (e: React.ChangeEvent<HTMLInputElement>) => void;
}

export function AddressFields(props: AddressFieldsProps): FCReturn {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit/personal opinion: I usually try to have one file per React component, so would prefer to see this in its own file, but that's just me!

postcode: string().required("Enter a postcode"),
country: string(),
});
export const addressValidationSchema = (): SchemaOf<Address> =>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good to have renamed this 👍

@@ -167,7 +167,7 @@ describe("Building a list", () => {
expect(addItemButton).not.toBeInTheDocument();
});

test("Adding an item", { timeout: 20000 }, async () => {
test("Adding an item", { timeout: 35000 }, async () => {
Copy link
Contributor

@jamdelion jamdelion Jan 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question: what is the timeout for? Are these tests flaky?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also nit: we can include a numeric separator to make these big numbers easier to read, e.g. 35_000

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great feedback thanks - timeouts now have numerical separators - please see 5435bf9

The tests here are pretty slow! They pass locally without timeouts as generous as this but I think that's an issue with underpowered GHA runners needing a larger timeout than my local machine.

This issue here has come up in a few other PRs and it's not flakeiness but some sort of state update interplay between vitest, formik, and React context which leads to these being slow tests. I've not go to the bottom of this and it does seem to be a test-only issue. It might be the case that we need to revisit how we're using context providers for the schema - I've had a few passes over adding useMemo()s etc here and there without any seeming effect on the test speeds.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a humungous file! Again personal preference but I'd be tempted to split this into more test files, e.g. index.validation.test.tsx, index.payloadGeneration.test.tsx so that it's easier to read/find the tests you want. 🤷

@DafyddLlyr DafyddLlyr force-pushed the jess/list-address-field-owners branch from 93edced to 5435bf9 Compare January 22, 2025 11:05
@DafyddLlyr DafyddLlyr merged commit ce1e687 into main Jan 22, 2025
12 checks passed
@DafyddLlyr DafyddLlyr deleted the jess/list-address-field-owners branch January 22, 2025 15:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants