Can I prevent fieldName from defaulting to id for error messages.

[silvaDominic]

I wrote a validator that I assumed would produce a more generic message if fieldName was undefined/null (i.e. the name attribute was not set on an input field).

extend("minLength", {
  validate(value, { length }) {
    return value.length >= length;
  },
  params: ["length"],
  message: (fieldName, placeholders) => {
    let message;
    if (fieldName !== "{field}") {
      message = `${fieldName} must have at least ${placeholders.length} characters.`;
    } else {
      message = `Must have no more than ${placeholders.length} characters.`;
    }
    return message;
  }
});

It turns out that if a name is not provided the fieldName defaults to the input id. My id is not useable as a field name.

Is there a way to prevent the fallback? Should it even use id?

[logaretm]

Can you create a demo for this? you can use codesandbox

[silvaDominic]

This closest resembles my custom input component:

CodeSandbox

To trigger the behavior in question just remove the 'name' attribute from custom-input in App.js.

[logaretm]

That's intended, at the moment the field name falls back to the id if name isn't provided.

https://github.com/logaretm/vee-validate/blob/v3/src/components/Provider.ts#L230

You could have your own custom component that has a default name of {field} and you can pass that to the ValidationProvider.

[silvaDominic]

So this is another limitation that has me slowly just creating my own implementation for validation...

I question this fallback design as the id is nearly always used internally for reference and written in an unformatted way (i.e. with dashes, underscores, numbers, etc.). Perhaps I could do what you suggested or the return object can have the properties id and name(?), but my real question is 'is using id in the validation message even a reasonable usecase?'

[logaretm]

is using id in the validation message even a reasonable usecase?

It beats displaying {field}, no?

[silvaDominic]

It's actually no better to the user's point of view. The project I work on has partially generated ids that are cryptic. My point is that field name != field Id because they are used for and represent different things and therefore shouldn't be related. Returning undefined is probably what you should do and for the developers to handle. If they want to enforce field names, they can add a linter rule. If not, they can add a conditional check for undefined like I did. The current implementation actually requires developers to do the former if they don't want ids to ever be exposed...or the workaround you suggested, but then again..'workaround'.