fix(core): support required custom customer fields in Account Settings#3076
Open
chanceaclark wants to merge 1 commit into
Open
fix(core): support required custom customer fields in Account Settings#3076chanceaclark wants to merge 1 commit into
chanceaclark wants to merge 1 commit into
Conversation
BigCommerce revalidates required custom customer fields on every updateCustomer call, even fields that already have a stored value. Account Settings only ever submitted firstName/lastName/email/company, so any store with a merchant-defined required custom customer field (e.g. a Terms and Conditions checkbox added after accounts already existed) locked customers out of saving any change at all. This restores custom-field support (dropped in b14180c when the page was migrated to Vibes) by reusing the existing DynamicForm/ formFieldTransformer pattern already used by Register and Address, so required fields render, prefill from stored values, and get resent on every save alongside the fixed fields. Fixes #3074 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
🦋 Changeset detectedLatest commit: 0519625 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
Bundle Size ReportComparing against baseline from
Per-Route First Load JS
|
Contributor
Author
|
Proof: |
Contributor
Unlighthouse Performance Comparison — VercelComparing PR preview deployment Unlighthouse scores vs production Unlighthouse scores. Summary ScoreAggregate score across all categories as reported by Unlighthouse.
Category Scores
Core Web Vitals
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What/Why?
Fixes #3074.
The issue reports two problems with Account Settings' update-customer flow:
firstName/lastName, droppingemail/company. This turned out to be a misread of the code — the lines cited are the mutation's response selection, not the input.submission.value(validated againstupdateAccountSchema) already includesemail/company, and I confirmed via direct GraphQL calls against a test store that both persist correctly today. No fix needed for this part.updateCustomercall — even fields that already have a stored value. A customer with afirstName-only edit getsValidationError: Required account form field ID X is missingif that field isn't resent, regardless of whether it was previously set. Account Settings only ever submittedfirstName/lastName/email/company, so any store with a required custom customer field (e.g. a "Terms and Conditions" checkbox added after accounts already existed) locked customers out of saving any change at all.This is a regression: custom/dynamic form-field support existed in Account Settings since #1257 (Aug 2024) but was dropped during the Vibes migration (
b14180c4, Dec 2024) and never restored, while Register and Address kept it via the newerDynamicForm/formFieldTransformerpattern.This PR restores that support in Account Settings by reusing the same
DynamicForm/formFieldTransformerpattern already used by Register and Address:page-data.tsxnow fetches the customer's existing custom form field values (customer.formFields) alongside the field definitions it already fetched but never used.page.tsxfilters out fields already covered by the fixed inputs (email, password, name, company, phone, newsletter checkbox) and transforms the rest intoFields, pre-filled with the customer's current values.update-account-form.tsxrenders those fields in the same form as the existing firstName/lastName/email/company inputs (via the sharedDynamicFormFieldrenderer), so a single save always resubmits the full required-field state — required given BigCommerce's per-call revalidation.update-customer.tsbuilds the mutation'sformFieldsinput from whatever fields are present, following the same per-type mapping already used byregisterCustomer/updateAddress.dynamic-form/schema.ts(getFieldsShape) so Account Settings' schema can merge the fixed fields with the dynamic ones without duplicating per-field-type zod logic.Testing
email/companyalready persist correctly via the existing mutation input.updateCustomerfails withValidationError, even when the customer already has a stored value for it — confirming the bug and that the fix must always resend it./account/settingswith an authenticated session: confirmed the custom checkbox renders alongside the fixed fields, correctly prefilled from the customer's stored value (checked), and that email/company also prefill from live data.pnpm run typecheckandpnpm run lintpass.Migration
N/A — no breaking changes.
updateAccountSchemachanged from aZodObjectto a factory function; only relevant to direct importers of@/vibes/soul/sections/account-settings/schema.