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

Updated multiinput submission for ukaddressfield #377

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

SophieOHagan99
Copy link

Description

Updated how multi-input fields push ukaddress data to the database so that it's consistent with ukaddressfields outside of multi-input fields.

Type of change

Please delete options that are not relevant.

  • Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce
the testing if necessary.

Before PR's can be merged they will need to be tested by QA and approved where
applicable. To flag the change to QA assign @XGovFormBuilder/qa as one of the reviewers.

  • Test partner organisation address renders properly on assessment for submitted applications
  • Test partner organisation address renders properly in application
  • Test multi-input fields render properly in application

Checklist:

  • My changes do not introduce any new linting errors
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation and versioning
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes
  • I have rebased onto main and there are no code conflicts
  • I have checked deployments are working in all environments
  • I have updated the architecture diagrams as per Contribute.md

Comment on lines +5 to +19
function flattenMultiInput(rawValue) {
if (!rawValue) return rawValue;
rawValue.forEach((value) => {
Object.keys(value).map((key) => {
if (typeof value[key] == "object" && value[key] !== null) {
value[key] = Object.values(value[key])
.filter((p) => {
return !!p;
})
.join(", ");
}
});
});
return rawValue;
}
Copy link

Choose a reason for hiding this comment

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

Shouldn't we sort of do this the other way round? Instead of changing the structured object to a string joined by commas, change the other way so that it matches the structured object?

Just in the past seen dates stored as raw strings and then end up getting a requirement or request to re-display specific parts, which ends up in using some library (libpostal) to parse the address or some hacky regex to extract specific parts (i.e postcode) - it'd be better if we store the structured form of the address and then just on any relevant view display it as a comma separated string, or any other display that is requested

Copy link
Author

Choose a reason for hiding this comment

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

Most of the code on the assess side for rendering is already built for formatting the string that this creates and they are having errors on their side of the json object appearing in the tables so this fixes both of these issues though it may be good to have structure in the future by removing this function

Copy link

Choose a reason for hiding this comment

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

Cool - how are we handling the state already stored in the database for this component? Do we need a migration script to replicate this change for persisted data with the old structure?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants