feat(calendar): multiple selection mode

[marcjulian]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our
  guidelines: https://github.com/goetzrobin/spartan/blob/main/CONTRIBUTING.md#-commit-message-guidelines
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Documentation content changes
• Other... Please describe:

Which package are you modifying?

• accordion
• alert
• alert-dialog
• aspect-ratio
• avatar
• badge
• button
• calendar
• card
• carousel
• checkbox
• collapsible
• combobox
• command
• context-menu
• data-table
• date-picker
• dialog
• dropdown-menu
• hover-card
• icon
• input
• label
• menubar
• navigation-menu
• pagination
• popover
• progress
• radio-group
• scroll-area
• select
• separator
• sheet
• skeleton
• slider
• sonner
• spinner
• switch
• table
• tabs
• textarea
• toast
• toggle
• tooltip
• typography

What is the current behavior?

Calendar selection mode

• single selection
• removing selection not supported

What is the new behavior?

Calendar selection mode

• single | multiple
• removing single selection supported

Date Picker

• supports single | 'multiple'
• autoClose only for single

Does this PR introduce a breaking change?

• Yes
• No

Other information

[marcjulian]

@ashley-hunter since you created the calendar component, do you mind reviewing the changes? What do you think remains to support DateRange (e.g. {from: T, to: T})?

[ashley-hunter]

@ashley-hunter since you created the calendar component, do you mind reviewing the changes?

Hey! Nice work! Sure I will take a look this evening!

What do you think remains to support DateRange (e.g. {from: T, to: T})?

Well it depends, we could have everything as one component, or we could introduce a date range component (that uses many of the existing brain directives under the hood.

There are a few things to consider.

Having the value as an object has a few disadvantages, notably with how change detection works, for example I can't just do value.from = new Date(), because the object reference wouldn't change, therefore change detection may not update the UI, you would have to create a new object each time.

There is also the added challenge of having a single event for value changes - it doesn't make it obvious whether it was the from date or to date that actually changed.

While having separate inputs and outputs for both start and end has benefits, when integrating with Angular forms, that only expects a single value, so an object would have to be used in this case - which I guess is ok.

Having everything as a single component may start to get complicated, we would support a single date, an array of dates and an object of dates - this could end up with a lot of conditions determining the correct format to read and handle.

We also have the disadvantage of not having great type inference in Angular components based off inputs, what I mean by that is in React we can easily type components so that if mode is single, then value will be a Date, and if mode is multiple then value will be a Date[]. We can't do that in Angular components which is unfortunate, so we lose some type safety here - someone could easily set mode to multiple and pass in a single date and TypeScript will not flag this up, same with the output event. Having a separate component that explicitly types these correctly is nice.

So I guess, personally I lean towards a separate hlm-date-range component with individual start and end inputs rather the overloading the existing date picker with more functionality. It may mean a bit of code duplication with the date picker, but personally I'm ok with that. That being said, I'm very open to hearing everyones thoughts and suggestions on the matter 😊

[marcjulian]

Thank you. Let me know if single and multiple mode makes sense to handle in one component.

Well it depends, we could have everything as one component, or we could introduce a date range component (that uses many of the existing brain directives under the hood.

Perhaps, it makes sense what you described to introduce a hlm-date-range (or maybe even brn-date-range) component and reuse existing brain directives under the hood.

We also have the disadvantage of not having great type inference in Angular components based off inputs, what I mean by that is in React we can easily type components so that if mode is single, then value will be a Date, and if mode is multiple then value will be a Date[]. We can't do that in Angular components which is unfortunate, so we lose some type safety here - someone could easily set mode to multiple and pass in a single date and TypeScript will not flag this up, same with the output event. Having a separate component that explicitly types these correctly is nice.

Yes, that would be quite useful to infer the correct type based on the mode input value.

So I guess, personally I lean towards a separate hlm-date-range component with individual start and end inputs rather the overloading the existing date picker with more functionality. It may mean a bit of code duplication with the date picker, but personally I'm ok with that. That being said, I'm very open to hearing everyones thoughts and suggestions on the matter 😊

I agree, adding hlm-date-range and perhaps also hlm-date-range-picker component for separating concerns and for additional functionality needed for date-range. We could also think about, if the date-range can be configured to show multiple month next too each other, similar to shadcn/ui.

https://ui.shadcn.com/docs/components/date-picker#date-range-picker

[ashley-hunter]

Thank you. Let me know if single and multiple mode makes sense to handle in one component.

Well I guess if we are going to split out the date range picker into a separate component then perhaps this too might make sense? We would get better typing which would be nice. It might lay the foundations for the date range picker nicely.

Perhaps, it makes sense what you described to introduce a hlm-date-range (or maybe even brn-date-range) component and reuse existing brain directives under the hood.

Yes, I suspect we would need to introduce a brn-date-range too, again for the reasons mentioned, but I suspect most of the other brain date picker components would remain the same, just perhaps with a few minor changes. If we make all the date picker components (brn-date-picker, brn-date-range-picker etc) implement a common interface and they register themselves using a token then the child brain components will work with any implementation.

I agree, adding hlm-date-range and perhaps also hlm-date-range-picker component for separating concerns and for additional functionality needed for date-range. We could also think about, if the date-range can be configured to show multiple month next too each other, similar to shadcn/ui.

Yes, this was another reason why having a separate component would be nice, we aren't tied to just the same structure, we can add this second calendar too!

[MerlinMoos]

Hey guys, sorry for jumping into that topic. I'm not so deep into that topic as you. It would be awesome if we could get a behavior like Angular Material e.g. for the date-range picker:

and for the single select:

We are using a lot of forms in Angular for all our applications. The current behavior is {from: T, to: T}, which makes it tricky to transform that value back into a flat structure every time. We have deep nested objects which bring us every time code that we have to write, e.g. v.shipments?.forEach((shipment, i) => { shipment.canceling = shipment.laycan.end; shipment.laydays = shipment.laycan.start; delete shipment.laycan;}) it's just a small example.

@ashley-hunter and @marcjulian, what do you think about that?

[marcjulian]

closing in favor of #653