[Component] Date Picker

[eduayme]

[atinux]

You can use the popover component with https://github.com/Vuepic/vue-datepicker

We can show an example of it like we did in https://volta.net

[sandros94]

We can show an example of it like we did in https://volta.net

It would be a great example!

[eduayme]

You can use the popover component with https://github.com/Vuepic/vue-datepicker

We can show an example of it like we did in https://volta.net

It would be amazing to add an example

[ddahan]

As a personal opinion, I'd prefer not adding a new package for each missing component I need. In a ideal world, I would only need a single external library to use components (with a single documentation, etc.). This would make the whole solution simpler and easier to maintain over time.

I don't know much about licences, but is there a way to "copy" and integrate this Vue-datepicker work into nuxtlabs ui?

[januarfonti]

For <UInput> component, I can use type="date" to have a date picker input

[sandros94]

For component, I can use type="date" to have a date picker input

Could you elaborate on this?

[neilmerton]

@Sandros94 when you include type="date" on the UInput tag you'll end up with something like this:

Selecting the calendar icon (default shown in Firefox):

This was achieved by doing this:

<UInput type="date" />

You can read more about this native input type on this MDN page.

[benjamincanac]

Here is the DatePicker component we made for Volta using v-calendar:

<template>
  <VCalendarDatePicker
    v-model="date"
    transparent
    borderless
    :is-dark="isDark"
    title-position="left"
    trim-weeks
    :first-day-of-week="2"
  />
</template>

<script setup lang="ts">
import { DatePicker as VCalendarDatePicker } from 'v-calendar'
import 'v-calendar/dist/style.css'

const props = defineProps({
  modelValue: {
    type: Date,
    default: null
  }
})

const emit = defineEmits(['update:model-value', 'close'])

const colorMode = useColorMode()

const isDark = computed(() => colorMode.value === 'dark')

const date = computed({
  get: () => props.modelValue,
  set: (value) => {
    emit('update:model-value', value)
    emit('close')
  }
})
</script>

And we use it inside a UPopover component:

<template>
  <UPopover>
    <UButton icon="i-octicon-calendar-24" :label="dueDate" />

    <template #panel="{ close }">
      <DatePicker v-model="dueDate" @close="close" />
    </template>
  </UPopover>
</template>

[TomSmith27]

Could this be put into NuxtLabs, as it means having to install less components in a consuming project?

[benjamincanac]

Honestly, I'm not sure I want to add components that rely on other libraries. What happens the day someone asks for the same thing but with a different calendar library? There is so many ways to achieve this and this example is less than 40 lines of code.

[atinux]

I think that's where the Examples section come in 👀

[sandros94]

Personally this two options shown in this issue are more than enough for most, if not all, the use cases that comes to mind. But I'm always happy to hear people with new ones that I didn't think of.

IMO I would spend dev and research time for new components. Rather than for others that could easily adapted like this one. And for this last category it would be nice to show them in the Examples section. Idk, like for example how to build the Volta's drag and drop for issues between statuses. 😏

EDIT: or the "old LMB to scroll". I imagine that for both we are talking about vueuse.

[benjamincanac]

Closing this as an example has been added to the documentation: https://ui.nuxtlabs.com/getting-started/examples#datepicker.

[ddahan]

This confirms this library won't focus on building complex components and won't replace something like Prime Vue in terms of comprehensiveness.

This not a problem at all but should be clearly stated on the documentation IMO.

[neilmerton]

I disagree with your opinion @ddahan.

There's a roadmap that is helpful for the Dev team to understand priorities (as voted for by the users of the library). If it's missing features, and the feature request gets enough votes and the Dev team feel it's a good use of their limited time then I'm certain they'll work on those features.

I've used PrimeVue for a while, and whilst it's free to use, to actually get any bugs fixed they charge $8999 per year. Then if you want bespoke features adding that's extra on top (depending on the size and complexity of the feature). We have issues with the PrimeVue Calendar component, PrimeTek won't work on improving it (unless money is involved I'm guessing), so we've ended up using Vue3Datepicker - and that's our choice.

Stating that this library won't focus on building complex components is immature (and premature) in my opinion.

The Dev Team have provided a reasonable example of how to use an external library to meet this "feature request" (I put this in quote because I wouldn't call this a feature request, all it has is a title, nothing else!). I've also provided an example of having a date picker using the built-in browser capabilities.

[ddahan]

@neilmerton I'm not sure to understand all the anger here, but I'll try to explain more clearly my previous post and avoid a fight here.

First, please note there is a context to my last message: a previous message I wrote in this thread. It has been upvoted 5 times and downvoted 0 times, meaning It may be an interesting point of view from a user need perspective.

Don't get me wrong: with my last message, I'm not trying to say "Nuxt Labs should definitely build this component themselves", I'm just explaining my need as a simple user among many others, and this is just a single voice.

As I said, my opinion is not about what Nuxt Labs should create or not create, but rather being crystal clear about the philosophy and the future of the library to help users make the right decisions.

I know about the roadmap and it actually helps a lot. However I still think it would be helpful for newcomers to know why they should pick this lib or why they should not pick it, and all of this without the need to browse a roadmap, which will grow over time.

Currently in the documentation landing page it is stated:

its goal is to provide everything related to UI when building a Nuxt app.

Now, knowing that some components like Datepickers won't be done ("not planned"), I think a little more detailed explanation could help newcomers. Something like:

This library provided an extensive set of basic components. For some more complex components (eg. Datepickers), you'll find examples using external librairies.

With this in mind, newcomers can decide to not use Nuxt Labs UI if they want an all-in-one UI library like PrimeVue or if they don't want to use N external libs for their UI.

I'm not sure how trying to be accurate to users to help them could be somehow immature here.

If you think this extra information in the documentation is worthless, then I disagree, but in the end it is your choice and I'll respect it. But remember that I'm just trying to help here, and I want the best for this library.

EDIT: mea culpa, I did not see about the new data table component initially, and it is actually a "complex component" IMO which means Nuxt Labs UI makes "some complex components".

[neilmerton]

I'm not sure where you get "anger" from, I guess that's the joys of written communication over verbal - context is often left open for interpretation.

My intention was not to come across angry, but rather express support in the wonderful work the Devs are doing with this library.

It's still in it's infancy and users should not jump to conclusions.

[sandros94]

@ddahan This last explanation does explain your point of view quite a bit better.

But while I do agree with you, I also agree that adding such information like:

atm we don't replace more complex and mature libraries

could just prevent small and independent contributors to the growth of the Nuxt UI library itself.

Providing solutions like the example page are the best in this early stages, they should be treated like:

Yes we don't currently have that, but until we have time to implement here is how you can do it.

And to me, giving options, is always the best practice.

I guess that's the joys of written communication over verbal

@neilmerton that's so true

P.S.: I always felt that the GitHub "closed this as not planned" could include an optional "(for now)".

[ddahan]

@Sandros94 thanks for the explanation.

could just prevent small and independent contributors to the growth of the Nuxt UI library itself.

That's a good point. And that's why I think too short explanations about the intentions can be misleading.

Providing solutions like the example page are the best in this early stages

100% agree, you're providing the best possible workaround currently.

We don't currently have that, but until we have time to implement ...

Yep, as you've noticed, that's not how I interpreted the "not planned". For me, something you may want to do someday lives in the backlog with the lowest priority. This explains my misunderstanding about this. And again, writing down this philosophy and intentions somewhere else that in this thread could be helpful to make a decision, knowing exactly the tradeoffs. As @neilmerton said, users should not jump to conclusions. But we can do a lot in terms of communication to lead them to the right conclusions :)

Anyway, thanks to all developers for the amazing work that has been done until now.