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

Error object types don't account for nested errors #2243

Open
bakerkretzmar opened this issue Feb 21, 2025 · 3 comments
Open

Error object types don't account for nested errors #2243

bakerkretzmar opened this issue Feb 21, 2025 · 3 comments

Comments

@bakerkretzmar
Copy link

Versions:

  • @inertiajs/vue3 version: 2.0.3

Describe the problem:

The TypeScript types for the form.errors object only allow the same keys as the form data, but if the data in the form contains nested keys then the validation errors object we get back will have additional 'dot-notation' keys that aren't in the form.

Example:

let form = useForm({
  name: '',
  items: [],
});

form.items = [{ type: 'thing', name: 'Thing 1' }, { type: 'thing' }];

form.post('/things');

console.log(form.errors)
// { 'items.1.name': 'The items.1.name is required' }

form.errors['items.1.name']; // Type error

There's a validation error for items.1.name because it's required, but if you try to access form.errors['items.1.name'] it's a TypeScript error because TypeScript thinks form.errors can only have the keys name and items.

I would guess it's relatively straightforward to fix this by just allowing keys in that object that start with known keys from the form data, but not sure if that's undesirable. I'll submit a PR.

Steps to reproduce:

See above.

@joaopalopes24
Copy link

joaopalopes24 commented Feb 21, 2025

@bakerkretzmar I created this PR

@bakerkretzmar
Copy link
Author

@joaopalopes24 cool didn't see that, thanks! I'll take a look at your approach, I forgot that it affects some methods too so maybe it's not as simple to work around as I thought.

Just speaking as a maintainer of other open source libraries, one thing that might help that PR get reviewed more quickly is if you remove all the little formatting changes in a bunch of unrelated files, so it touches as few files as possible and is small and focused just on your fix.

@joaopalopes24
Copy link

@bakerkretzmar Done!

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

No branches or pull requests

2 participants