Automatic display error-message if exists

[robsontenorio]

Hi!

Currently for displaying error messages you need to explicitly also to set :error="..."

<q-input label="Name"  v-model="form.name" :error-message="form.errors.name" :error="!!form.errors.name" />

Why not simply display error message detecting the presence of :error-message="..." ? If its not empty just show it, otherwise don't.

<q-input label="Name"  v-model="form.name" :error-message="form.errors.name" />

[pdanpdan]

Because that would mean extra work - you would update a full message instead of a boolean.

[markusheiden]

@pdanpdan I don't get your point or maybe you misunderstood the use case.

We get the errors from the backend. Thus there is no single error message but there may be many different ones. Thus we can't simply toggle the error flag. So it would be nice, if there is an error message, it would be displayed directly. Otherwise, we need to always duplicate the code for error and error-message like shown in the above example.

Suggestion: Maybe error could have a third value automatic to enable this behavior.

[yusufkandemir]

There are valid cases like this:

<q-input :error="hasError" />

<q-input error-message="An error occurred" :error="hasError" />

<q-input :error-message="t('error')" :error="hasError" />

<q-input :error-message="fieldToErrorMap[field]" :error="hasError" />

If I were to design a new API, I would probably go with error?: string | bool, similar to how the validation functions in the rules prop work.

<q-input :error="hasError" />

<q-input :error="hasError ? 'an error occured' : false" />

<q-input :error="form.errors.name" />

but, introducing any API changes to these would either be breaking or confusing. So, I'd say it would be better to do this in v3.

[ivanjaros]

I am just guessing here but the element might be "errored" without a message. Hence two separate properties.

[markusheiden]

It is perfectly fine to keep that use case.

Thus my suggestion is to introduce a second "error mode": Display error messages if there are any. That would reduce code duplication by avoiding to set error to true by almost the same code that determines the error messages (see the examples).

[ivanjaros]

makes little sense. you can error if you have error message, optionally you can error without error message. it is up to you which one you want. there is no limitation yet your approach would introduce something that is not needed or useful whatsoever.

You should REALLY think about what you are talking here.

v1
<q-input :error="!!errMsg" :error-message="errMsg" />

v2
<q-input :error="maybe" :error-message="errMsg" />

v3
<q-input :error="certainly" />

[markusheiden]

My point is: <q-input v-model="some.field" :error="!!errorHolder.forField('some.field')" :error-message="errorHolder.forField('some.field')" /> has code duplication and thus is error-prone. Especially when having many fields of this kind in a page. One could extract extra variables to reduce the code duplication, but that would produce even more code at a different location. I can live with that, but IMO it is suboptimal.

My suggestion was to add something like this that makes this use case as short as possible overall:

• <q-input v-model="some.field" errors="auto" :error-message="errorHolder.forField('some.field')" />
• <q-input v-model="some.field" auto-errors :error-message="errorHolder.forField('some.field')" />
• <q-input v-model="some.field" :error-message.auto="errorHolder.forField('some.field')" />
• or something similar that fits best into Quasar.

We priorly used Vuetify and there the approach just using error-messages worked fine. We switched to Quasar because it has a better developer experience for us. This is the first point where that's not the case for me.

[ivanjaros]

Your "error" is that you are looking at the message as the primary logic whereas it is actually the error boolean that drives the main logic. The error message is only secondary functionality. Imagine using notify plugin to display error messages instead of printing them into the field where the developer would use only the boolean. The message itself is irrelevant without the boolean driving the entire thing.

Adding another layer of complexity makes no sense. If you really think this is a big deal then you can simply wrap the input into your own component and simply trigger error whenever there is error message, otherwise all attributes will be inherited.