Validations Setting Dirty with Identical Path Names Incorrectly

I’m using Alpha-6 and Alpha-4 of the libraries.

Nested Validations (a single, large object graph with validations) seems to mark similar paths as ‘dirty’. I suspect it’s the way that you’re building the cached keys but I can’t seem to debug the libraries. I’ve attached this reproduction of the issue (too complex for a jsfiddle):

repro-dup-keys.zip

Here is the scenario:

I have a model class that represents an address:

export default class AddressModel {

  constructor() { }

  address1 = "";
  address2 = "";
  cityTown = "";
  stateProvince = "";
  postalCode = "";

  static rules() {
    return {
      address1: { required, minLength: minLength(5) },
      address2: {},
      cityTown: { required },
      stateProvince: { required },
      postalCode: { required, minLength: minLength(5) }
    };
  };
}

When I use them in subsequent classes (e.g.):

export default class BillingAddressModel 
{
  company = "";
  address = new AddressModel();

  static rules() {
    return {
      company: { required}, 
      address: AddressModel.rules()
    };
  }
}

In the main vue file, I create a high-level object (reactive) to hold the two classes which contain the common class (AddressModel):

    const company = reactive({
      name: "",
      shippingAddress: new ShippingAddressModel(),
      billingAddress: new BillingAddressModel()
    });

    const rules = {
      name: { required },
      shippingAddress: ShippingAddressModel.rules(),
      billingAddress: BillingAddressModel.rules()
    };

The addresses (of the Shipping and Billing addresses) are passed into the components like so:

    <ChildView :address="model.shippingAddress.address" />
    <ChildView :address="model.billingAddress.address" />

In the component, I just show one field (address1) and show validation:

<input type="text" v-model="address.address1.$model" />
<div v-if="address.$invalid" class="text-danger">
  <ul class="list-unstyled">
    <li v-for="e in address.address1.$errors" :key="e">{{ e.$message }}</li>
  </ul>
</div>

Realize that i’m purposely creating the rules so that they are not the same rules. It effectively forces validation rules to show for both components when I touch the first component.

I know this isn’t trivial, but I’m hoping that you can help me find the bug (even if that’s hand-holding a bit to get the code debugging on my machine so I can dig it into it.

[aethr]

Hey @shawnwildermuth, I cloned the vuelidate repo to my local machine and checked out the next branch, then used npm link so that I can substitute the local version of vuelidate for some of the projects I’m working on. Something like:

cd [vuelidate-repo]/packages/vuelidate
npm link
cd [your-project]
npm link @vuelidate/core

Within the vuelidate project, there’s a few ways to build it and a few caveats / workarounds you might need to use. You can either build all the vuelidate packages at once from the project root using:

yarn install
yarn lerna:build

or you can build just the core package by doing:

cd packages/vuelidate
yarn install
yarn build

I’ve found this doesn’t work very well when the vuelidate project has a node_modules folder in it, because vue-demi includes methods from the vuelidate/node_modules/vue-demi folder instead of [your-project]/node_modules/vue-demi folder, so things like vue’s getCurrentInstance don’t work. I tend to use this command to build vuelidate after making a change:

cd vuelidate/packages/vuelidate
yarn install && yarn build && rm -rf node_modules

Maybe one of the maintainers can chime in with a better recommendation!

[aethr]

No problem! I’m not actually a maintainer so the PR will need to go through a review first.

The vuelidate-next release is still shaping up so it’s great to get the community testing and reporting issues like this so we can sort them out early. Thanks for putting together that small repro example, it made it a lot easier to see what the problem was.