Port Duet date-picker to Lit

[blackfalcon]

[claviska]

This is the gold standard date picker for web components. I support the effort to translate it to Lit both to make it easier to fork into other libraries and as a standalone component providing the license is respected and the original authors are properly attributed.

I can assist with the effort after the new year.

[blackfalcon]

Proposed scope. Can we make the date-picker so that the input is in a slot?

<date-picker  identifier="date">
  <auro-input id="dateDemo" bordered type="month-day-year">
    <slot slot="label">Arrival date</slot>
  </auro-input>
</date-picker>

Current day is imported to month and then month is imported to date-picker with input. I am wondering if we can get greater flexibility if we create the concept of a calendar and allow for input to be any slotted element?

Then much of the functionality of date-picker can be placed into calendar, then the wrapping date-picker element is only responsible for the relationship between input and calendar.

I bring this up as I am looking for greater flexibility in how input works for our use. Not only does Auro have a very different input UI, but we also have a different UX for date formatting that I don't see the Duet Date Picker supporting. And I don't see any value in pushing for our experience to be the standard for this element.

IMHO, the heavy lifting in this work is creating a calendar experience that is reusable and able to be themed just enough to be personalized. The second part is managing the communication between the input and the calendar.

The more we can be flexible about the input experience, the more opportunity we have for this to be the new gold standard.

[claviska]

I’d be OK with omitting the drop down/input stuff altogether. Make it a primitive that can be adopted and used for inline date pickers, drop down form fields, and even date range pickers.

Just a thought to focus this more on calendar logic since many libraries handle forms and whatnot differently.

[blackfalcon]

@claviska Auro has a auro-dropdown in the mix as well. The concept of auro-datepicker would be a combo component of auro-dropdown with auro-input in a slot and auro-calendar in the other slot.

So yeah, while I would LOVE to have that architecture, I didn't want to push too hard on my opinions of things.

[michaelwarren1106]

i’d agree with @claviska in that the major value would most likely be a reusable, standardized, feature-full calendar component. putting the calendar inside of some popover type thing with popperjs or some equivalent would be trivial imo, but rendering the months, days, selected dates, disabled dates, etc is much more valuable imo.

if we focus more on the calendar, then we also start with a smaller scope with greater focus because we don’t have to worry much about slots and inputs, but only how the calendar itself will communicate with outside comps (events and props etc)

Edit:

Also, I think it would be awesome to maybe have two calendar type components, one for a single calendar, a la datepickers, and one with multiple calendars (up to 3 maybe?) in the same component that knows how to do range selection across both calendars, etc. I would think that having date range selection stuff have to cross the shadow dom lines of 2 separate instances of one calendar component would be more cumbersome than just making a web component with 2 calenders displayed that can internally handle the logic of date range selection across both/all

[calebdwilliams]

I love the energy and ideas here but I'm not sure this is the right place for this component to eventually live. The original idea is to use this repository for utilities that help web developers create form-associate custom elements. I would certainly be thrilled if the result of this effort eventually used some subset of the packages created here.

I'll defer to @westbrook on this however.

[Westbrook]

Agree that that energy here is great! Really points to the benefit of some centralized hosing of expanded features. However, I'm also partial to starting with "utilities that help web developers create form-associate custom elements" as there's already lots of work to go into that, and the scope of anything beyond that is quite unclear (to me) at this point. I'd love to see a conversation around how the calendar features you've outlined here might be decomposed into form-associated helpers such that calendars and other complex interactions can be made more straightforward, and possibly centralized, over time. Maybe that conversation outlines that we have enough excitement to start a new project around form elements, but let's start more narrow and see how expanding looks once we've locked that part of the process down first.

[blackfalcon]

I picked this repo to start the issue, and hey... we're talking!

If not here, where?

But yeah, let's take this opportunity to build centralized tools that we can all take advantage of for our individual calendar needs.

[claviska]

If this isn’t the right place, I’m happy to host the discussion in the Shoelace repo until we have (or decide on) an official place for things to live. If this works out, it will become a very popular web component worthy of its own repo.

[michaelwarren1106]

its prolly not the right home now. When we started talks about a fully qualified date picker component, I linked this repo because a custom element input would super benefit from the mixin we want to get published here soon. But since then we've pivoted to basically "just" a calendar component and leaving out the input part (at least thats my understanding) so somewhere else might be a better home for discussions about it. I'm happy to pivot elsewhere.

But I'll also do a shameless plug for this mixin once it gets published that it should be super helpful with making custom form-associated things like inputs

[blackfalcon]

If I am understanding this correctly, I am seeing this go in this direction.

@michaelwarren1106 your team has pivoted to building your own calendar component? And you intend to release a mixin that will help with the joining of an input element with your new calendar element?

Question: what is the status of the calendar element you creating? It feels like you are already building what others are asking for? Is this integrated into another project? Can it be extracted to be in an individual repo and distributed for consumption? If not...

We have this repo ready for work. We too are looking at a direction where we are only to build a calendar element and have that work in concert with the auro-input with a wrapping element of auro-dropdown (soon to be released) and then calling that auro-datepicker.

I am trying to better understand who has done what and what still needs to be done so that we can support each other in all our efforts.

[michaelwarren1106]

i think there's some miscommunication, so i'll try to be as clear as possible.

@calebdwilliams and I have previously worked on the FormControlMixin in this repo, and have been working to open source a re-written version from this repo via @open-wc.

We were never working on a calendar component. In the twitter thread we all came from, I mentioned that my day job is design system lead developer and my team is going to need to build a datepicker form element component soon for that design system, so I'd be very interested in a really good open source calendar component so I dont have to build one from scratch. :)

I mentioned this repo in the twitter thread, because originally we had talked about building a datepicker component (ie more than a calendar, it would have had an input, label, calendar, etc etc) and the FormControlMixin we're trying to get out would have been good to use to make that. Since we're talking about a calendar component now, the FormControlMixin from this repo won't be much help.

I dont really know who is already building what stuff, but @calebdwilliams and I are not building a calendar component. I would help however I can, but my understanding is that someone is working on porting the duet datepicker to Lit...so maybe that would be a good start, to just port the calendar from duet datepicker to lit? or the auro one? or some combo of both?

[blackfalcon]

@michaelwarren1106 thanks for the clarification. That was really helpful.

In the interest of moving this conversation forward, I have created a new PR with the start of a scope definition document. I welcome you all to be a part of this. Where this ends up being built, named, distributed, etc... all TBD.

https://github.com/AlaskaAirlines/auro-calendar/pull/8

[blackfalcon]

If everyone is cool to move this conversation over to the Auro PR I posted, then I think we can close this issue.

[calebdwilliams]

I think that makes sense. Closing.