DatePicker vs Calendar & RangeDatePicker vs RangeCalendar

[dfidler]

Needed a date/time picker to replace my custom one (which I inherited, and hate) so, yesterday, thought I'd give reka a go as the base for my new one (experiment).

In looking at the anatomy of Calendar and DatePicker, I'm wondering why DatePicker replicates all of the Calendar components with different names. In my head, that seems like an anti-pattern (not DRY) as it stands to reason that a calendar is always going to be the same as the calendar inside of the date picker.

I've nearly done my date/picker and I've modeled, mostly, after re-ui's date picker (picking the time from a list) and I like it. But now I want create a calendar item like reka's and have realised that... ooops...I have to duplicate code (or refactor my current code).

I'm just wondering, is it worthwhile to merge those two trees? Because at the end of the day, the "DatePicker" is really just a DateField that acts as an anchor for a [Range]Calendar. I think that, rather than making a date picker component, it makes more sense to have links to an example date/time picker that reuses those two components in one. That would be DRY.

Which I guess brings up another use case, why is there a "Calendar" and a "Range Calendar"? Picking a "range" is just a feature of a calendar. And the anchor for both of those is simply a Date Field and a Date Range field.

So why have separate component/class hierarchies for both?

To me, it makes more sense to have the basic building blocks and then supply examples that show the combined use of them.

Thoughts?

[epr3]

Hello @dfidler

I'm going answer your questions and provide insight into what may seem an anti pattern, but it has been implemented with good reason.

1. Component replication between Calendar and DatePicker - short answer: context and providing a simple way to sync all the different parts of the DatePicker. The long answer is that I thought that the DX of the DatePicker in terms of data manipulation brought a lot more benefits: one entry point for all data processing and manipulation (providing all the data related props in the Root, for example) which in turn is kept in sync with the Calendar and DateField components, predictable keyboard interactions and a way of providing the easiest (in my opinion) implementation of a DatePicker without thinking too much about the moving parts that compose it. Yes, the downside that you would have to maintain components that are, without any context, the same, but I think that the styling should be reusable 99% of the time for both the standalone components and the DatePicker ones.

That being said, there's nothing preventing anyone from using the standalone components and building a DatePicker since it's a Calendar, a DateField and a Popover brought together with some glue code that keeps in sync all these components.

2. Separate component hierarchies between Calendar and RangeCalendar - I agree, a range is just an array of dates (DateValue in this case), which the Calendar already handles, although for discrete dates through the way of multiple property. But, in terms of DX, I thought it would have been confusing as to which properties would be available for usage when using a date range, which ones for discrete dates, not mentioning the potential large API surface and the plethora of conditions needed to handle each case and edge case which I think that might have caused more bugs in the long run.

I hope I provided you with more context regarding the design decisions that were made when implementing these components and that you'll find the library easy to work with.

[dfidler]

Thanks for the reply and I understand your thinking and the challenges inherent in supplying devs with robust infrastructure for component development.

Now that I understand the framework better I'll never use the majority of the date picker class hierarchy. As you say, I'll use the fundamental components to build something that is more flexible so I'm not branching my code (or styling). This was why I suggested the idea of having an "example" page that shows different implementations if the same concepts - so that newbies don't come and do what I did... "oh, i need a datepicker so I'll start with the example and work from there... oh... i need a calendar with a popover.... oh... oops...".

Perhaps I just need to blog my learnings and design decisions for others to critique and/or learn from and maybe OS my datepicker implementation and highlight whey I did what I did. Or maybe contribute an article/suggestion for review to add to the documentation?

[epr3]

I'm thinking a section inside the documentation would help. We have an "Examples" tab: https://reka-ui.com/examples/date-picker-selection.

Also, Vue ShadCN can be used as a library of usage examples for Radix Vue, as the whole philosophy of ShadCN is that you own your code.