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

refactor(account-settings): refactor formValidation, updateAccountSettings & dataProcessing #242

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

Conversation

icatalina
Copy link
Contributor

@icatalina icatalina commented Feb 5, 2025

Jira: B2B-2158

What/Why?

refactor(account-settings): reorganise account settings update

Separate payload preparation from the update process.
Purify and simplify handleGetUserExtraFields.

refactor(account-settings): separate formValidation from error notifications

The current logic conflates form validation with form error
display/translations.

We should probably include some form library, but for now we'll just
separate the methods doing the validation from the methods displaying
the errors/alerts.

refactor(account-settings): separate getAccountSettingsFields & getPasswordModifiedFields

These two methods are used at different stages of the process and for
different reasons. Separating them allows us to only execute them when
they are needed and more importantly when they are needed.

eg. the getAccountSettingFiles is not required for bc users.

Remove the configuration for the xs prop, the only use of it is 12.

Translate the passwordFields directly upon receiving them, as opposed to
doing it in the component.

Hard code the list of fields directly in the method, we had a method for
indirection that wasn't needed.

Bonus: flip all the !isBcUser ternaries

refactor(account-settings): rename isEdit to pristine in the dataProcessing methods

Current code uses isEdit, but then exposes it as !isEdit, this is
ultimately confusing. Change the flag name to pristine, and change the
method to either return the payload, if we need to save it, or undefined
if not modified.

Rollout/Rollback

Revert

Testing

Manual

…essing methods

Current code uses `isEdit`, but then exposes it as `!isEdit`, this is
ultimately confusing. Change the flag name to pristine, and change the
method to either return the payload, if we need to save it, or undefined
if not modified.

B2B-2158
…sswordModifiedFields

These two methods are used at different stages of the process and for
different reasons. Separating them allows us to only execute them when
they are needed and more importantly _when_ they are needed.

eg. the getAccountSettingFiles is not required for bc users.

Remove the configuration for the `xs` prop, the only use of it is `12`.

Translate the passwordFields directly upon receiving them, as opposed to
doing it in the component.

Hard code the list of fields directly in the method, we had a method for
indirection that wasn't needed.

Bonus: flip all the `!isBcUser` ternaries

B2B-2158
…cations

The current logic conflates form validation with form error
display/translations.

We should probably include some form library, but for now we'll just
separate the methods doing the validation from the methods displaying
the errors/alerts.

B2B-2158
Separate payload preparation from the update process.
Purify and simplify handleGetUserExtraFields.

B2B-2158
@icatalina icatalina requested review from a team as code owners February 5, 2025 12:59
@icatalina icatalina force-pushed the icatalina/B2B-2150/account-settings/1 branch from af00a9c to a933208 Compare February 5, 2025 13:00
accountB2BFormFields,
passwordModified,
};
export const getPasswordModifiedFields = (b3Lang: LangFormatFunction): GetFilterMoreListProps[] => {
Copy link
Contributor

Choose a reason for hiding this comment

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

any benefit in turning these into a hooks and getting b3Lang internally rather than by argument?

channelId,
};

const { isValid }: { isValid: boolean } = isBCUser
Copy link
Contributor

Choose a reason for hiding this comment

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

is the type definition { isValid: boolean } here because the async functions are giving back any?

If so, I'd be tempted to move it closer to the problem by adding it as a return type definition of their signatures
(rather than make this function make up for their shortcomings)

const emailFlag = emailValidation(data);

if (!emailFlag) {
Copy link
Contributor

Choose a reason for hiding this comment

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

these flag names aren't very descriptive, what do you think to turning them into something like

if (isValidEmail(data.email)) { 
    // etc

in another commit/PR/ticket?

@@ -132,6 +130,7 @@ function AccountSetting() {

const { [key]: accountSettings } = await fn(params);

const accountFormAllFields = await getB2BAccountFormFields(isBCUser ? 1 : 2);
Copy link
Contributor

Choose a reason for hiding this comment

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

"how many fields do you want? One, two..?" 😆

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.

2 participants