[Request] displayValue prop

[Alan Sprecacenere]

I'd really like a displayValue prop to further customize what is shown when a value is picked, similarly to QSelect's displayValue.

I'll try to add this myself when I have some spare time, if nobody tries.

[Tobias Mesquita]

I already have something similar in mind, but to that, we'll need to make the internal QInput readonly, since will be nearly impossible to mask the input ans revert the inputed value to ISO format.

But u can use the prefix and suffix properties to customize that a little.:

[Tobias Mesquita]

Now u can use the prop display-func to customized how the value is displayed, of course, u can combine that with the lang prop to display the date in another culture/language

<q-datetime-picker class="q-mb-md" outlined label="DateTime Picker" mode="datetime" color="negative" dark v-model="datetime" lang="ar-EG" display-func></q-datetime-picker>
<q-datetime-picker class="q-mb-md" standout label="Standout DateTime Picker" mode="datetime" color="negative" dark v-model="datetime" format24h clearable :display-func="displayFunc"></q-datetime-picker>

export default {
  data () {
    var self = this
    return {
      date: '2018-11-02',
      time: '15:46',
      datetime: '2018-11-02T15:46',
      displayFunc: (date) => {
        return `iso: ${date} | i18m: ${new Date(date).toLocaleString(self.language)}`
      }
    }
  }
}

preview

[Alan Sprecacenere]

To be honest I expected something simpler. I say that with all due respect for your work.

We already have the date on the parent component, there's no need for a factory function, so something like this would be enough for customizing the display value:

{
  props: {
    displayValue: [String, Number]
  }
}

<q-input :value="displayValue || value" />

<q-datetime-picker
  v-model="myDate"
  :display-value="formatDate(myDate)"
/>

This is also in line with quasar's terminology on QSelect.

I agree with you that this is just the beginning, tough:

• The input should be optionally readonly to reduce user errors, but we cannot disable/readonly QInput because it will change its aspect and stop being clickable.
• The entire input could optionally be clickable, not just the icon.
• The event icon should be personalizable. For example, I like having just the dropdown symbol.

I guess there's more. Maybe ability to get realtime updates from the picker (@input instead of @change)? Or customizable button text/location?

I'll try to fix some of these in the weekend. Thanks for your work!

[Tobias Mesquita]

The input should be optionally readonly to reduce user errors, but we cannot disable/readonly QInput because it will change its aspect and stop being clickable.

Any input in the QInput would be reflected in the QDate/QTime and QDatetimePicker would be able to check if the value is valid. but unfortunally, QDatetimePicker is unable to validate a customized display value.

currently, when display-func had a value, the QInput is replaced with a QField with a readonly input inside, both QField and appended QIcon is still clickable.

The entire input could optionally be clickable, not just the icon.

In the case of the whole QInput/QField work as proxy to the popup, so will be a pain to select the value inside the QInput or even focus on it.

of course, we can try mimic the datetime input from quasar 0.17, where the calendar cover all the input and take the focus to himself

The event icon should be personalizable. For example, I like having just the dropdown symbol.

that is a good suggestion, probably I'll implement that today.

I guess there's more. Maybe ability to get realtime updates from the picker (@input instead of @change)? Or customizable button text/location?

we already listening the @input event for changes.

const renderDate = function (self, h) {
  return [
    h(QDate, {
      props: {
        dark: self.dark,
        color: self.color,
        value: self.values.date
      },
      on: {
        input (value) { self.values.date = value }
      }
    }, [])
  ]
}

regarding of use display-value instead of display-func, I agree with that, a function makes nonsense than the user can use a computed property to archive the same goal.