The nested observers/forms idea was removed since I couldn't find a good justification for it, most single root forms can do the same thing as a nested form setup with minor changes. Having said that, I may not have encountered the use case to convince me of introducing it yet.

However, there could be a place for a simpler abstraction. Like a <FormGroup /> or something that does a similar job of useForm but minus validation and form state, only aggregates state of child fields.

I can probably start working on it for 4.9 after I figure out the details, but you can do it roughly in userland by having your own custom components that can wrap this behavior with something like this:

// FormGroup.vue
const fields = ref<FieldContext[]>([]);
provide('FormGroup', fields);


// You can build other stuff similar to this
const meta = computed(() => {
  const valid = fields.value.every(f => f.meta.valid);
  const dirty = fields.value.some(f => f.meta.dirty);
  const touched = fields.value.some(f => f.meta.touched);

  return { valid, dirty, touched };
});

// InputText.vue
const field = useField(...);
const group = inject('FormGroup');
if (group) {
  group.push(field);
}

Thanks a lot for your reply.

I certainly would appreciate having this feature added.

Our use case in some more detail (to perhaps help with the convincing :):

• we have a page with multiple collapseble forms each using the same format/fields. It is intended to edit one or more items, all belonging together, in one go.
• the page has to keep track of the aggregated form states (mostly the dirty flags) to enable/disable a global submit button if anything has changed.
• we have a custom submit handler that goes over all nested dirty forms and performs the validation for them. If the validation passes, only the changed forms are gathered and submitted to the backend.

So, the formGroup would need to have a FormMeta state, aggregated from the contained forms in the same way as forms aggregate field meta states. Plus access to the contained forms, i.e. the values, validate and reset functions etc.

In the meantime I will try to implement this using your suggestions, but instead of registering FieldContexts on the FormGroup, I will register the contained FormContexts.

I may also have near exact use case that @okoell has.. thinking about how we will have a form with some top level fields but also I want to add one to many field-identical sub-forms with at least 10 different fields and their own validation rules.

I'll study the workaround a bit but given my low experience with VeeValidate it isn't immediately obvious how it wires together. Thanks!

Yep would really be helpful if we can do this.

As somebody currently migrating a Vue 2 to Vue 3 multi-step wizard form with multiple sub-components... Having this feature would make my life much easier. Not sure how feasible the proposed workaround would be until then

Yeah, we are also trying to migrate and everything went relatively smoothly so far. But not we are kinda stuck with this. Our use case is also something like sections with validation status for each of them like:

• Accordion -> section validation status
• Accordion 2 -> section 2 validation status
  and so on.

The workaround I see for now is to create custom FieldGroup component which would provide custom API for "registering" fields and custom Field component which would act as decorator over original Field ( this one would inject FieldGroup's API and register itself there which would allow to aggregate the state of fields and pass them as slot.

Do you have any other idea or maybe there is some work already done on this @logaretm ?

@logaretm I've done some testing, can be seen here:
https://stackblitz.com/edit/vue-3-veevalidate-form-validation-example-v2oddh?file=src%2FField.vue,src%2FApp.vue,src%2FFieldGroup.vue

Basically what is missing here for me is the access to the meta and eventually value from Field component's ref (it is not expose'd from it). Thus I cannot access the current state of the validation. My idea was to wrap the component since it contains all the logic for field management instead of creating my own version of Field with custom useField. Do you think it would be a good idea to expose additional refs from Field component ?

Here is an example with modified version of vee-validate:
https://stackblitz.com/edit/vue-3-veevalidate-form-validation-example-4159qg?file=src%2Fvee-validate.esm.js,src%2Fmain.js,src%2FFieldGroup.vue,package.json,src%2FField.vue,src%2FApp.vue
As you can see in this version I exposed more refs into component public API and the feature seem to work correctly. The question is if we would be able to actually do it (maybe you see some cons of this) ?

Thanks for both of your contributions. I don't know about field groups since it can be user-land and I will continue the discussion there.

For the expose one, I'm fine with it as long as we get the types corrected.

Sure, I'll look into that later. Regarding the groups I aso think we could expand this behavior to composable too. In that case we could create something like useFieldGroup which could be used in setup and aggregate the state of all fields ddclared in the component. The solution created here is not a breaking change in any way and obviously it would be nice for us to add it, but I'll honor your decision here.