Mutating fields without forms

[ashtonjurgens]

The second approach would be what you already did but with a modified version of the ValidPath type that let's you specify a datatype so that e.g. only paths to string fields can be specified.

We could also start an issue to discuss whether our field hook and component should provide a connected version of our setInput method where you directly can pass over the new value without specifying the form and path.

Originally posted by @fabian-hiller in #32

The ability to mutate a field without a reference to the form would allow me to use less code, and a more convenient API when building complex input components.

I have some thoughts on how this should work

A form is a field

I'll explain by example: I have a "user form" for getting the user data I need.

const AddressSchema = v.object({
    street: v.string(),
    city: v.string(),
    state: v.string(),
    zip: v.string()
})

const UserSchema = v.object({
    firstName: v.string(),
    lastName: v.string(),
    address: AddressSchema
})

Somewhere else, I need a form for just the address. So I create an "address form" component. The "user form" can now just use the address form, within it. This is an example of how a form can be a field, and something I keep encountering in my usage.

From another perspective, consider how a form is based on a valibot schema. In valibot, UserSchema is a schema, and AddressSchema is a schema. But on my user form, the UserSchema becomes the form, which is treated one way, and AddressSchema becomes a field, which is treated differently.

setInput

I would prefer an API like this

// No changes
const form = createForm({ schema: UserSchema })
const address = useField(form, { path: ["address"] })

// Current API still works
setInput(form, {
    path: ["firstName"],
    input: "John"
})

// Changes below
// Set input of field (without path)
setInput(address, {
    input: {
        street: "123 Main St",
        city: "Anytown",
        state: "CA",
        zip: "12345"
    }
})

// Set input of field (with path)
setInput(address, {
    path: ["street"],
    input: "456 Oak Ave"
})

useFieldArray (and FieldArray)

This primitive requires a path, so when I want to use it on an array schema I must wrap it in an object. This goes against my "a form is a field" ideal. Perhaps there are other areas where paths should not be required.

Advantages

The largest practical advantage for me, is that when I'm building and using components (#32), I only care about the field store. The form it is a part of and the path in that form are of no concern in the component (the component probably wouldn't be reusable if it were).

When using my component, I can just pass the field

{/* Current API */}
<AddressField of={form} path={["address"]}  />

{/* Preferred API */}
<Field of={form} path={["address"]}>
  {(field) => <AddressField field={field} />}
</Field>

This makes typing simple, and also works when the form was created with the AddressSchema.

{/* Just need to pass the form */}
<AddressField field={form} />

[fabian-hiller]

I apologize for not responding to this issue. I took a short break from open source work, but I am back now and will try to take a look in the next few days.

[fabian-hiller]

I think your idea is great! In simple terms:

• Allow a field to be passed whenever a form is not strictly necessary OR
• Treat the form as a field and allow fields it to be passed to other functions instead of the form

Technically, this should be possible. However, I think most functions require the form in some way. For example, the setInput method and many others need the form to run validation after a modification. Without the form, they cannot access the form's inputs, which are currently required to run the validation. Currently, we are unable to run validation on a subpart of the schema, and adding this functionality would probably result in a few edge cases.

Your approach is great! We could treat the form as a field — after all, it's already a field with a few additional properties. One possible implementation would be to store the form-specific properties in an object, with a reference to this object included in each field. This would be inexpensive and allow every field to access the form.

Do you know how other libraries are addressing this issue? I look forward to your feedback!

[ashtonjurgens]

We could treat the form as a field — after all, it's already a field with a few additional properties. One possible implementation would be to store the form-specific properties in an object, with a reference to this object included in each field. This would be inexpensive and allow every field to access the form.

These are my thoughts exactly.

I think this would be relatively easy to implement, and may even remain compatible with the current API.

Do you know how other libraries are addressing this issue?

Formisch is the first form library I've used.

Premise to Proposed Changes

The driving idea of this change is, "the user usually wants to work with a field, not a form". So to make fields more workable on their own...

Changes

1. Add useful properties from FormStore to FieldStore

• isSubmitting
• isSubmitted
• isValidating

These 3 properties apply to a field, just as well as the form itself. The user may use them to disable the input element, or display some other state.

This change depends on the following one...

2. Add a reference to the form, to FieldStore. This should be a private API. When I give a component a specific field, I don't expect it to modify other paths in the form. This leads into validation: should validation be allowed given only a field?

3. Allow the validate method on a field.
As you mentioned, validation can not be isolated to a path/subschema. I believe that, given a field, it is acceptable to trigger validation for the entire form. Speaking theoretically, a field does not relate to other fields, except for the case of validation. Based on another field, the given field may be invalid. Consider it from the another perspective; based on the given field, other fields may be invalidated. So triggering validation on the entire form, using just one field is justified, as they are connected in this way.

Although I believe this is the correct behavior, it is unintuitive, so it should be made clear in the documentation,.

4. Don't allow the submit method on a field.
Unlike validation, submission is out of the purview of a field. Submission is a concern of forms, not fields.

5. fn(form, { path: field.path }) becomes fn(field).
Anywhere you must pass the form and a path, you should be able to pass a field.

6. FormStore replaced with FieldStore.
There isn't a need to have a separate form store and field store type. The submit method can prevent "submitting a field" using FieldStore.path. Only an empty path (which is the root form) may be submitted. If there are any other form specific methods can they use this same path check.

This change would be convenient to the internal implementation, because we're just "working with a field" all the time, and if we need to require that the field is the "root-field"/form, we check field.path.length === 0.

Low Priority Changes

These are features which I noticed may be missing. I'm mentioning them here, though they aren't totally relevant.

7. Allow passing path to getAllErrors.
This function should follow the fn(form, config) pattern (which would also allow fn(field)). It would return all errors under a path, unlike getErrors which returns the errors at a path.

8. Allow passing a path to reset.
This is the same scenario as with getAllErrors. It may be convenient to reset only the fields under a path. For example, when you section a larger form by object entries, you can easily reset a section. This is especially the case with multi-step/page forms.

Edit: Looks like I missed this one, the feature already exists.

Closing thoughts

I tried to scan the whole API documentation, but I've likely missed something.

I'm willing to make code contributions, and also to do prerelease testing in my app, though I can't be relied on to touch frameworks beyond Solid JS. I'm quite busy ATM, so if you're interested in code contributions I might be a bit slow.

Looking forward to your consideration and critiquing.

[fabian-hiller]

Hey, sorry for the late reply and thank you for the additional context. This is still on my list but since it is a fundamental change it requires more time and I will probably work on other things first.