Less verbose alternative to defineField!

[ttonyh]

I'd love to see a a less verbose alternative to defineField.

For a few fields, this is not too bad; but this can get repetitive pretty quick.

const [myField, myFieldProp] = defineField('myField');

I'd prefer something more like this:

const {
    useDefineFields
} = useForm();

const form = useDefineFields( /* maybe some common options */ );

Then:

<MyComponent
    v-model="form.myField.model"
    v-bind="form.myField.props"
    name="myField"
/>

I assume Vee already knows a lot about the fields, from the schema, so why all the extra work?

[logaretm]

Hey, thanks for discussing this. I have tried a lot of things to get a workable version out of this but with no avail. I will explain why.

I assume Vee already knows a lot about the fields

This is the main issue, it doesn't because the schemas describe value paths, not necessarily fields.

Consider this simple schema:

const schema = yup.object({
  emails: yup.array().of(yup.string()),
});

This could be expressed in two ways:

• Array of fields where each field represents an index in the array
• A single field that emits multiple email values or an array as a value

So it is impossible to know which one is which without having an explicit call like with defineField or useField. This is the issue of imperative declarations.

It gets harder with more complex structures or schemas for all nested values.

---

A partially working solution is to introduce schema markers:

const schema = toTypedSchema(asField => {
  return yup.object({
     // use `asField` marker to mark the path as a field
     emails: yup.array().of(asField(yup.string()))
  });
});

This has a few problems:

• It doesn't "just work" anymore, and forgetting the marker is critical failure.
• It won't work for dynamic fields, like field arrays as they are not available on setup and defineField doesn't work well with field arrays in general because of its imperative nature, field arrays are better declared declaratively.

Feel free to discuss more or shoot a few suggestions as well.

[ttonyh]

@logaretm You make some very good points and I can understand now why you implemented it the way you did. There may not be a better way at the moment, I certainly can't think of one, after your clarification.

Thanks for taking the time to discuss this.

[jsodeman]

The applications I work with have many very large forms (60+fields each). The idea of having to have 60+ lines of defineField using strings as prop names is unpleasant enough that I'm being pushed away from using vee-validate, but I really want to use it for all of the functionality that it provides. Aside from being verbose, I'm afraid that using strings for prop names will make refactoring more error prone.

I understand the ambiguity with interpretation of the schema, but I'm wondering if this could be implemented by being less flexible in the interpretation. My opinion is that if you need dynamic fields, or an array of fields in the schema then that could come at the cost of having to use the more verbose defineField statements.

In your example I think "A single field that emits multiple email values or an array as a value" is the vast majority of array usages in a form object (binding a set of checkboxes or a multi-select dropdown to a prop).

The example @ttonyh gave it what I expected to find when I looked through the useForm API documentation.