`prefixSchemaToErrors` does not support paths for arrays of objects

[dlindahl]

Describe the bug

Given a form that represents an array of objects such as { people: [ { name: 'Alex' } ] }, the name field name would be people[0].name.

When the form is validated with a library that supports Standard Schema, the validator will return something along the lines of:

{
  issues: {
    message: 'This field is required.',
    path: ['people', '0', 'name']
  }
}

However, when prefixSchemaToErrors processes that validation value, prefixSchemaToErrors returns the path "people.0.name" and then uses that string to hold the validation message in formApi.state.errors. The field will not render the validation message because the key does not match the field name.

Your minimal, reproducible example

https://stackblitz.com/edit/tanstack-form-zzmhzozz?file=src%2Findex.tsx

Steps to reproduce

1. Go to https://stackblitz.com/edit/tanstack-form-zzmhzozz?file=src%2Findex.tsx
2. Note that there are no errors on the form
3. Click "Add Person"
4. Note that the form's validations are run on button click
5. Note that the title field has a field-specific validation message AND the validation message is present in the state.errors and state.errorMap values that are rendered at the bottom of the page.
6. Note that the people[0].name field HAS NO field-specific validation message AND the validation message is present in the state.errors and state.errorMap values that are rendered at the bottom of the page. This is due to the error path not matching the field name due to how prefixSchemaToErrors reconstitutes the path.

Expected behavior

prefixSchemaToErrors should return the path "people[0].name" to match the implied naming standard in @tanstack/form.

How often does this bug happen?

Every time

Screenshots or Videos

Platform

Version 138.0.7204.185 (Official Build) (arm64)

TanStack Form adapter

react-form

TanStack Form version

1.15.1

TypeScript version

No response

Additional context

Additionally, I'd love to see something that indicates what the expected format is for non-trivial field names to make this clearer.

[dlindahl]

Looking more at prefixSchemaToErrors, it looks like there is an issue regarding how numerical path segments are detected. It looks like it is expecting a literal Number when in reality the path segment is going to be a numerical String given a field name string of "people[0].name".

form/packages/form-core/src/standardSchemaValidator.ts

Lines 30 to 32 in fc454d4

	return typeof normalizedSegment === 'number'
	? `[${normalizedSegment}]`
	: normalizedSegment

[LeCarbonator]

That's concerning, I didn't know that standard schema spec doesn't differentiate between array access and property access. Thanks for the report!

[dlindahl]

@LeCarbonator I suppose its possible that the bug is actually in yups implementation of Standard Schema. I just tried this with Zod and it showed the expected error messages. No clue if the Standard Schema spec has a formal definition of how array accessors should be typed... 🤔

[LeCarbonator]

@dlindahl it appears that Standard Schema merely restricts what the properties must be (no symbols) and how the path must be structured, but not how arrays should be treated. It is up to the implementation of the library for that.

Part of the utils folder in the spec, there's a path generator specified. There, it doesn't differentiate between array syntax and property access, so I assume that it's not a requirement for Standard Schema to use numbers for paths.

[LeCarbonator]

Also likely related to standard-schema/standard-schema#88

[jiji-hoon96]

I found some issues related to this and tried to fix them. I would appreciate it if you could let me know your thoughts. 🙏

[LeCarbonator]

You can give it a test yourself actually.

npm i https://pkg.pr.new/@tanstack/react-form@1689

While the visual example is not correct for the provided example (checking people instead of people[0].name), the error does appear to be put there.

Keep in mind we have an error related to arrays at the moment. See #1460 and #1658 for more details.

[dlindahl]

Testing this out with the link provided. So far so good!

[dlindahl]

Any updates on when this might be merged in?