label field doesn't take precedence over name when used with useField

[ourognao]

What happened?

When using useField with label in options, it is ignored. For example

const { errorMessage, resetField, value } = useField(
  'email',
  'required|email',
  {
    keepValueOnUnmount: false,
    label: 'mixinEmail'
  }
)

generateMessage is defined like this

import ja from '@vee-validate/i18n/dist/locale/ja.json'
configure({
  generateMessage: localize({
    ja: {
      messages: ja.messages,
      names: {
        mixinEmail: 'email'
      }
    }
  })
})

The API reference here says the following explanation for label

A friendly name to be used in generateMessage config instead of the field name, has no effect with yup rules

So I expect label to take precedence over name. But currently it is ignored (I don't use yup). I just got a message saying
mixinEmail is required.

I read this thread here which look similar but it doesn't handle the case where we set label as option in useField.

I also had a look to test cases here
and there is no test to verify that label should take precedence over name when both (name and label) are set in useField.

Btw, it was working before, I just discovered that I got the key in the error message instead of the sentence defined in generateMessage.

Am I missing something ?

Thanks !

Reproduction steps

1. Update to vee-validate 4.9.0
2. Update to vue-i18n 9.2.2
3. Create a simple html input field with name email
4. Use useField and set label with label :'mixinEmail' in the options
5. Set mixinEmail as names in generateMessage.

Version

Vue.js 3.x and vee-validate 4.x

What browsers are you seeing the problem on?

• Firefox
• Chrome
• Safari
• Microsoft Edge

Relevant log output

No error log

Demo link

Here

Code of Conduct

• I agree to follow this project's Code of Conduct

[logaretm]

Your expectation is correct, however this test actually tests that use-case. All the tests use name all the time, so if a label is applied it should be testing this case.

Can you please create a sample that reproduces this with either codesandbox or stackblitz? Will make it faster for me to debug and fix.

[ourognao]

Thanks for the fast answer !! Understood for the use case you mentioned. I got confusing because the test here use useField inside mountWithHoc, so I was expecting a test case like ↓

test('it should fetch label message when label is set as option in useField', async () => {
  let errorMessage!: Ref<string | undefined>;
  configure({
    generateMessage: localize('en', {
      messages: { required: '{field} is required' },
      names: {
        first: 'First test',
        labelFirst: 'Label First test',
        second: 'Second test'
      },
    }),
  });

  mountWithHoc({
    setup() {
      const field = useField('first', 'required', { validateOnMount: true, label: 'labelFirst' });
      errorMessage = field.errorMessage;
    },
    template: `
        <div>
        </div>
      `,
  });

  await flushPromises();
  expect(errorMessage.value).toBe('Label First test is required');
});

But well noted, I will try to create a sample that reproduces this with either codesandbox or stackblitz.

Thanks

[ourognao]

Hi @logaretm, I created a sample that reproduces this with codesandbox here so please have a look.

I tried to reproduce my environment as much as possible. It is a Quasar app in vue 3 + Vee validate 4.9 + Vite 2.9.
I wrapped the input field in a component called vee-validate-input declared globally.

So here is the situation

Case 1 (it doesn't work):
If you set localize to mixinEmail and name to email in IndexPage.vue like below

// src/pages/IndexPage.vue
vee-validate-input(
  :label="$t('mixin.form.email')"
  localize="mixinEmail"
  name="email"
  rules="required"
  type="email"
)

and you set label in useField options in input.vue like below

// src/components/shared/v-validate/input.vue
const { errorMessage, resetField, value } = useField(
  this.name,
  this.rules,
  {
    initialValue: this.initialValue,
    keepValueOnUnmount: this.keepValueOnUnmount,
    label: this.localize ? this.localize : null
  }
)

I got mixinEmailは必須項目です

Case 2 (it works)
If you set localize to mixinEmail and name to mixinEmail in IndexPage.vue

// src/pages/IndexPage.vue
vee-validate-input(
  :label="$t('mixin.form.email')"
  localize="mixinEmail"
  name="mixinEmail"
  rules="required"
  type="email"
)

and you comment out label in useField options in input.vue like below

// src/components/shared/v-validate/input.vue
const { errorMessage, resetField, value } = useField(
  this.name,
  this.rules,
  {
    initialValue: this.initialValue,
    keepValueOnUnmount: this.keepValueOnUnmount,
    // label: this.localize ? this.localize : null
  }
)

It works, I got メールアドレスは必須項目です. This is because name is linked to mixinEmail.

So could you could have a look to case 1 to make it work again please ?

Let me know if you need more information.

Thanks !

[logaretm]

That is expected. the name is the one we look for. The label is only used as a replacement for a name when generating messages, but not when looking for fields in i18n.

If you are using i18n then do not use label and just let the dictionary use the name field to display the field name.

Do you think this is confusing? I will think about it before I close this issue, maybe this should be a supported behavior.

[ourognao]

Do you think this is confusing? I will think about it before I close this issue, maybe this should be a supported behavior.

Well, this behavior was working before, that's why I actually implemented my code this way. So it would be great to have this behavior back again.

The reason I like this feature is that I can keep my names clean in initialValue (which are same name as the one coming from backend) while customize the label with i18n as I wish.

So if you think the implementation is not that hard, having this feature again would be good.

[logaretm]

Right, I had no idea it worked before. I think it broke in some recent fixes around that area because it was never intended. But I guess we can re-introduce it officially with a test case.

Should be released with the next patch.