Explanation behind `path`

[mrlubos]

Given the example code from README...

import { createForm, Field, Form } from '@formisch/solid';
import * as v from 'valibot';

const LoginSchema = v.object({
  email: v.pipe(v.string(), v.email()),
  password: v.pipe(v.string(), v.minLength(8)),
});

export default function LoginPage() {
  const loginForm = createForm({
    schema: LoginSchema,
  });

  return (
    <Form of={loginForm} onSubmit={(output) => console.log(output)}>
      <Field
        of={loginForm}
        path={['email']}
        render={(field) => (
          <div>
            <input {...field.props} value={field.input} type="email" />
            {field.errors && <div>{field.errors[0]}</div>}
          </div>
        )}
      />
      <Field
        of={loginForm}
        path={['password']}
        render={(field) => (
          <div>
            <input {...field.props} value={field.input} type="password" />
            {field.errors && <div>{field.errors[0]}</div>}
          </div>
        )}
      />
      <button type="submit">Login</button>
    </Form>
  );
}

...I would expect input name to be 'email' and 'password' respectively. Instead, the actual names are '["email"]' and '["password"]'. Is there a reason behind this behavior?

[fabian-hiller]

Yes, there is. Using a stringified array has the advantage that we can fully restore the original path. This will be necessary to be able to support nested objects with progressive enhanced forms using server actions. Taking a look at Decode Formdata might help: https://github.com/fabian-hiller/decode-formdata

Do you see an disadvantage with this implementation?

[mrlubos]

It's definitely non-standard, hence it caught my eye. My immediate concern was around autofill functionality. I'm not sure if that's a real concern though, haven't tested it.

In fact, in my application I patched this behavior by setting name prop to field.path[0]. It seems to work? You can verify by checking any form except the login form at https://app.heyapi.dev/

ChatGPT slop

I double checked with ChatGPT just to get a temperature check and this is what it came back with.

Advantages:

• Unambiguous and lossless: No ambiguity like user[credentials][password] might cause.
• Structured deeply nested objects reliably.
• Works well with decode-formdata or similar custom parsers.
• Compatible with progressive enhancement — works with native forms + JS hydration.

Disadvantages / Caveats:

• Manual parsing required: You need custom logic (like decode-formdata) to parse the names. Browsers and standard server frameworks don’t understand JSON-in-name.
• Escaping issues: If any part of the path contains characters like ], ", or , you’ll need to handle escaping/unescaping properly.
• Less readable in devtools: Inspecting form payloads in browser or network tools is harder than with standard bracket notation.
• Tooling compatibility: Some browser extensions or form helpers may break or ignore such names (especially password managers, validation libraries, etc.).
• Edge case collisions: A name='["user"]' and name='user' are treated as two distinct keys — but someone reading the data naively might expect them to overlap.

[fabian-hiller]

Thanks! The autofill functionality is my only concern too but I haven't tested if it actually is a problem. If devs are using Formisch they probably don't deal with the name attribute themself and let the framework take care of it. I plan to provide native support for server actions for all supported frameworks at some point.

[mrlubos]

What about the fact I was able to patch this behavior myself and seemingly everything works as expected? Any concern there? I now have Formisch + pretty name attributes, win-win

<Field
  of={form}
  path={['name']}
  render={(field) => (
    <TextField>
      <TextField.Label>
        Name
      </TextField.Label>
      <TextField.Input
        {...field.props}
        id={field.path[0]}
        name={field.path[0]}
        type="text"
        value={field.input}
      />
    </TextField>
  )}
/>

[fabian-hiller]

You can do that. We are not using the name at the moment. But I would not recommend it if there is no clear reason. Users are not reading you HTML code usually. So the name shouldn't matter if the browsers are smart enough detect and apply the autofill functionality correctly.

[vincehi]

Hi, I admit I don't understand how these paths should integrate with decode and valibot. An example would be great.

[fabian-hiller]

Hey @vincehi, I will add a decode FormData function into the core package soon that will take care of it. Do you have a specific use case?

[vincehi]

hi. I don't have a specific use case. I'll try to stick to the syntax with arrays for paths to be future-proof.

[jordanw66]

I can confirm this exact format breaks at least 1 password manager extension, specifically it's the double quotes:

name="["email"]" from {...field.props} breaks autofill whereas manually setting name="['email']" doesn't or even escaping them i.e., name="[\"email\"]" or name={field.props.name.replaceAll('"', '\\"')} works as well

Is it possible to escape the double quotes or replace them to/from serializing the path in the name?

[fabian-hiller]

Thank you for sharing! I will consider all the feedback in this issue for improve our API and implementation in the long run. Right now, this is not configurable but you can overwrite the name prop when assigning it to an HTML element.