sameAs doesn't work

[GalacticHypernova]

Describe the bug
Using sameAs according to the documentation doesn't seem to work, not as a string and not as a ref.

Reproduction URL
This can be seen in any composition API project that uses vuelidate sameAs (specifically tested with Nuxt 3.8.2)
Didn't have time to make a reproduction as I'm currently not home, if needed I'll gladly provide it when I get the chance.

To Reproduce
Steps to reproduce the behavior:

1. Create a useVuelidate instance:

const form=reactive({
f1:'',
f2:''
})
const v$=useVuelidate(
  {
    f1:{required},
    f2:{sameAsF1:sameAs('f1')
  }
})

2. Try to complete a form with these validations
3. F2 field is always red (meaning invalid) even when it's the same as F1 (tested with aaaaaaaa, 12345678)

Expected behavior
sameAs should work correctly.

Screenshots
Inapplicable, the red outline is simply a design choice of mine, adding any sort of color to it will prompt it.

Additional context

[m3c0d322]

Same issue. Is there any update? Thank you.

[m3c0d322]

To resolve my issue, I just created a custom validation to check if the password is same to confirm password.

[GalacticHypernova]

@m3c0d322 yea, the only solution is to use custom validation

[letehaha]

@GalacticHypernova it's because you're using it in the wrong way. You can only pass string | Ref. In your case sameAs compares to f1 as to a string value, but not as a reference to your form field.

In your particular example this is the only way for it to work (at least I didn't find any other):

const form = reactive({
  f1: "",
  f2: "",
});
const v$ = useVuelidate({
  f1: { required },
  f2: { sameAsF1: sameAs(computed(() => form.f1)) },
});

Not sure why toRef() doesn't work, like below, to avoid using computed in that case. But we have what we have.

f2: { sameAsF1: sameAs(toRef(form.f1)) },

Also, if you hardcode your value to be a ref, but not a part of reactive form, it will also work. But that's definitely an invalid use-case...

const f2Hardcoded = ref('test')
const form = reactive({
  f1: "",
  f2: "",
});
const v$ = useVuelidate({
  f1: { required },
  f2: { sameAsF1: sameAs(f2Hardcoded) },
});

[GalacticHypernova]

Well, this does seem a little too overcomplicated with a bit too much boilerplate, and there's the very valid concern of data leaks when needing to create more reactive objects than necessary.. But thanks anyway for the workaround!

[letehaha]

Well, I both agree and disagree :) Agreed, it looks a bit over-complicated, but at the same time, you need to do such manipulations quite rarely. And I don't really follow your concern about memory leaks – computed is being passed a simple value here, so it will be released as soon as your component is released, so no tricks :)

[joao-pedro-alves]

TLDR;
For those facing the same problem, especially if you're using composition API, here's the solution: just pass a computed function as a parameter for the sameAs function. Here is an example:

const form = reactive({
  password: '',
  password_confirmation: '',
  email: '',
})

const rules = {
  email: { email, required },
  password: { required, minLength: minLength(3) },
  password_confirmation: { required, sameAs: sameAs(computed(() => form.password)) },
}

const v$ = useVuelidate(rules, form)

[yuuzora]

Using Vue with Nuxt here.
The second I try to used a computed into sameAs the whole validation break with the following error
TypeError: v is undefined

My solution was to just do a custom validation:

sameAsPassword: helpers.withMessage(t('validations.sameAsPassword'), function (value: string) {
    return value === state.password
 }),

[GalacticHypernova]

computed is being passed a simple value here, so it will be released as soon as your component is released, so no tricks :)

I apologize for.the comically late response, I completely forgot about this. The reason I was talking about data leaks is because I have different uses for this, including something in an async context (after await). And I know some vue internals get funky when that happens, prime example being watchers not being auromatically stopped and unregistered, which would reult in a mem leak if you don't manually stop them. I'm not necessarily saying that it would for sure break anything, but I do not know how it would behave which could result in some peculiar edge cases.

[GalacticHypernova]

My solution was to just do a custom validation

I also opted for a custom validation with a simple computed property. As it turns out, sometimes using the frameworks core features is the ideal option can save much of the abstraction overhead and complexity =)