Bad idea to update initialValues based on { values } = useForm()?

[9mm]

I want to store input state for all fields in Pinia store, in a format that is easily accessible/modifiable to other components.

I noticed there is a Pinia/vee integration method to do this, but I like the fact that Vee keeps its own internal state in values to contain things like touched, etc. Otherwise my other components modifying the inputState would need to understand that structure of Vee to update a value.

I was thinking of doing this... is this a huge no no or will it cause problems given that initialValues will be re-propagating every single value change?

It seems to work perfect I am just concerned about weird edge cases, as I don't know how this reactive recursive loop will play out in different scenarios

    const store = useStore();
    const { inputState } = storeToRefs(store);

    const {
      values,
    } = useForm({
      initialValues: inputState,
    });

    watch(values, state => {
      // 🛑 bad idea?
      store.setInputState(state);
    });

[logaretm]

It should be fine unless you change the values inside that watcher or something else does. Generally, form state should not be used in a store but in some cases it is viable.

But no, this is not a bad idea. You just need to be careful about what setInputState does and if it changes the values somehow via another watcher. If not then all good.

[9mm]

EDIT There might be too many edge cases because of this below, see my next comment for my actual use case if you dont have time to read the following:

---

@logaretm I just had a thought that might throw a wrench in this :/ I forgot to mention that there are many forms in my wizard (one per page) that are all wired into the same state object.

I believe all the watchers are conflicting and now sending outdated values, etc.

Multiple step-form components:

    <template v-for="step in store.steps" :key="step.id">
      <step-form
        v-show="store.currentStep.id === step.id"
        @step-complete="onStepComplete"
        :step="step"
      />

step-form component:

    <form @submit.prevent="onSubmit">
      <step-form-input v-for="input in step.inputs" :input="input" :key="input.id" />
    </form>

  setup(props, { emit }) {
    const store = useStore();
    const { inputState } = storeToRefs(store);

    const {
      meta,
      handleSubmit,
      values,
    } = useForm({
      initialValues: inputState,
    });

    watch(values, state => {
      store.setInputState(state);
    });

    const onSubmit = handleSubmit(fields => {
      emit('step-complete', fields);
    });

    return {
      meta,
      onSubmit,
    };
  },

and step-form-input is just a very simple useField that seems to work great.

[9mm]

I see this is causing a lot of problems doing it this way. These are my constraints which is why I'm doing this weird method

1. It's a large complex form, where a single input control is not tied to a single value. Instead, a single input may trigger multiple "actions" which can change the values of other inputs. These actions occur when an input is blurred AND the input is valid
2. The form is a multi-step form, which should support animation (v-show transitions to next page).
3. I liked the idea of Global Validations due to their string format/simplicity (i can send from server easily on each input)
4. I wanted a simple state object in the format of {input_0_0: 'val', input_0_1: 'val', ...}. I DID like the idea of having it in Pinia store. This way, when the actions of the other inputs can run, its very simple to modify the "form state" using a store action and it propagates to all pages/steps, even if its the current step their on.
5. I also liked a global store because invalid values need to persist across pages, exactly like they left that page, it should be like that when they return (including validation messages)

I can foresee the problem with multiple useForm with multiple watchers. So I can think of 2 ways of doing this:

Method 1: 1 single useForm. Instead of the actions modifying the store, every field when running actions emit an event to update multiple names/values. Unfortunately there are many nested components for this event to travel through to get all the way to the form and that seems like a headache.
I also know this also requires a dynamically changing schema... I don't know if there are edge cases to that.

• one problem might be the validation errors are lost when they go back and forward again (ideally the form stays perfectly the same)

Method 2: a useForm for every step, and it somehow feeds into a global state of all inputs. This has a few issues I noticed

• all the meta information for a field is reset every time initialValues changes
• if there are multiple watchers, they all try to update with their own (out of date) version
• when the component unmounts, it seems to be clearing out some values. ultimately it should memorize answers across pages, even if the page is invalid/complete, when they return it should still be there

[logaretm]

To me method 1 sounds like the better one here. While form state should be local, it is up to you to determine how local it is.

In the multistep forms I built, usually it is the same useForm for all the steps, not multiple ones. However, for the error/value persistence across steps it gets slightly tricky. While you can configure keepValuesOnUnmount on the form level, it will still remove the errors.

So, you could accumulate the errors prior to moving in either direction. And restore them with setErrors whenever the step is mounted again.

I'm thinking about building a useFormWizard helper that offers these behaviors on top of useForm. However, I have yet to think about how it works with the various features currently present.

[9mm]

@logaretm ok thanks for replying! That makes sense. I actually decided on method 1... I only have 1 "todo" before I get that method working, perhaps you have quick 5 second answers on:

1. I created a global required_unless:<input_name> validation that works, but how would I get the other input to validate once the first input is valid? The other input still shows as invalid, even though if you submit the form its technically valid

[9mm]

actually ill make a sandbox for #1 as its a bit hard to explain, it works until you hit the back button and it re-mounts

[9mm]

@logaretm instead of saving errors, is there a way I can do a simpler way and just validate again on useField mount if there are existing values in the useForm?

The values are already stored in the parent state, and i wouldnt want every field to be validated on mount (for the multi-step form), only those which have already have input values

[9mm]

to anyone seeing this,t eh answer is validateOnMount: true