refactor: lift default value setting to the AccountSettings page

[icatalina]

Jira: B2B-2158

What/Why?

This further separates the fetching of the field information from the data. Allowing for a cleaner API separation.

Rollout/Rollback

Revert

Testing

Manual

[leeBigCommerce]

when the order is the same, but something(s) are being omitted from the list, I quite like this pattern

const fields = [
  ...contactInformation,
  ...(isBCUser ? getAccountSettingsFields() : []),
  ...additionalInformation,
  ...getPasswordModifiedFields(),
];

we benefit from having one definition of the correct order, plus it's easier to focus on which aspect is conditional

the downside is it can look a bit new/unusual 🍹

[icatalina]

Not a huge fan of this pattern because of readability, but sure...

[leeBigCommerce]

aren't fieldIds mandatory?

[icatalina]

should be, but I don't trust anything anymore 😂

[leeBigCommerce]

I'm struggling to mentally map this one

is there a possibility of (A) multiple objects (defaultValueMap, formFields, etc) holding a value for a single item?
Or (B) would we only expect one of them to contain a value?

---

if (A) the ordering of the object look ups matters, e.g.
formFields[item.bcLabel] ?? extraFields[item.label] vs
extraFields[item.label] ?? formFields[item.bcLabel]

---

if (B) the ordering doesn't matter, as we only every expect one of them to be truth-y

---

at the moment I don't if we need to care about the ordering or not 🤔

[icatalina]

Let me see if I can clarify things without murking the waters even further.

The value for a specific field should only be held in one of the object.

• defaultValueMap holds values for all 'standard' fields (firstName, lastName, etc)
• formFields holds vales for the BC custom fields
• extraFields holds values for B2B custom fields

There's however, the possibility of clashes. If you were to label a custom field like another one or an existing default field, there will be issues with the saving of them.

The only order that matters is that last item.default, that's the actual field's default value, and should be last in preference.

[leeBigCommerce]

gotcha, I guess ideally we'd go for something that makes that clearer in code, e.g.

    const defaultValuesByType = {
      defaultValueMap,
      formFields,
      extraFields,
    };

    return accountInfoFormFields.map((item) => ({
      ...item,
      default: defaultValuesByType[item.type][item.label] ?? item.default ?? '',
     // etc etc

but these types are a long way from allowing something like that (or something better)

worth a comment to explain the mutually exclusivity in the mean time?

[icatalina]

These are responsibility of the view, we probably want all fields to look the same within one page.

[icatalina]

Let me see if I can clarify things without murking the waters even further.

The value for a specific field should only be held in one of the object.

• defaultValueMap holds values for all 'standard' fields (firstName, lastName, etc)
• formFields holds vales for the BC custom fields
• extraFields holds values for B2B custom fields

There's however, the possibility of clashes. If you were to label a custom field like another one or an existing default field, there will be issues with the saving of them.

The only order that matters is that last item.default, that's the actual field's default value, and should be last in preference.

[icatalina]

should be, but I don't trust anything anymore 😂

[icatalina]

Not a huge fan of this pattern because of readability, but sure...