Create a basic "MVP" to discuss the functionality and design

[danillouz]

I've spent some time to see if I could create a basic calendar component. What I have so far can be seen here:

https://mooncake-react-date-time-picker-demo.netlify.com/

It's heavily inspired by Calendly 😅. I tried my best to reproduce a clean design, but my main goal was/is to create a functional date/time picker that looks decent enough. I think we should have someone with good design skills have a look at it, but for now I think it's good enough.

In terms of functionality, you can now only browse months and click on a day, which logs the date to the console. This is currently the "first step". The "second step" should be picking a time slot (with support for timezones etc.).

This should be an npm module at some point, but currently it's not. You can run it locally with npm start which uses Parcel to build a simple (demo) app. This is also used for the Netlify demo page.

The <DateTimePicker /> component doesn't accept any props at the moment. We should discuss the API, but I think there's at least passing a currentDate (i.e. to render the proper date in the picker) and a validator (i.e. to determine which days can be interacted with, e.g. to disable past dates). Additionally we should think about the best way to "get" the selected date/time data from this component, to be used in any parent. This could be as simple as passing some sort of setData function prop, but other patterns are possible as well.

But we can create issues for the stuff I mentioned and any other things as we work on/discuss it.

[danillouz]

I obviously also have to document a lot of stuff still 🙂

[dinostheo]

Some of the questions that I thought we might have to answer.

1. Do we want to be able to select past dates?
2. Do we want to limit/disable future dates, past a specific date?
3. Do we want to guess the timezone and allow the users to change it or always prompt them to select it if available?
4. Do we want to select time by minute, by every 30 minutes or by 60 minutes (hour)? e.g. Valid times by minute: 17:01, 06:30, 08:00, 09:29 Valid times by 30 minutes: 17:00, 06:30 Invalid times by 30 minutes: 17:01, 09:29 Valid times by 60 minutes: 17:00, 06:00 Invalid times by 60 minutes: 17:01, 09:29, 17:30
5. Do we want to specify the available times per day (provide them or disable times and/or ranges of times)?
6. Do we want to specify the available dates (possibility to disable selected dates, ranges of dates, e.g. all weekends or a single Tuesday)
7. Do we want to enable/disable the UI of the date picker or the time picker?
8. Do we want to enable/disable timezone selection?
9. Do we want to be able to select date ranges (in combination with calendar limitations - future dates that are not available, or there is date availability support)?
10. Do we want to be able to select time ranges (in combination with calendar limitations - future times that are not available, or there is time availability support)?

[dinostheo]

My answer would be more focused on what we want to achieve with this calendar, so if I have to answer the questions above.

1. No
2. Yes
3. Guess the timezone and allow the users to change it. If not able to guess, require it from the users.
4. 30 minutes or 60 minutes would make a cleaner UI in my opinion. The less the cleaner.
5. No. All possible times available within a date range.
6. No. All possible dates available within a calendar range.
7. No. Both visible.
8. No. Always visible.
9. No. Select a single date.
10. No. Select a single time.

My opinion is to narrow the scope, so we can avoid logic that needs to deal with conflicting configurations. e.g. Selecting a date range that includes a non available date. Some of my answers could be easily solved though. e.g. (7) You could say that it's easy to use on of those.

[danillouz]

I think it makes sense what you say to primarily focus on the behaviour we need. Meaning it's a date- time picker, so you should always pick a date and time. In the future these could potentially be configurable but I don't have a current use case for that (point 6 7, 8, 9, 10).

I also think some behaviour can be easily configured, like being able to select (past) dates or not. And what time slots to show. For example by passing "validor" functions or prop (point 1, 2, 4, 5). The benefit of this is making the component more usable in other use cases, but this can be a slippery slope, so we should be vigilant and not go crazy here, unnecessarily complicating things. What I'm thinking now is have an API for:

• Allowing only future dates or not (preventing selecting months in the past of the current month)
• Some sort of prop that renders the calendar in the desired month (should conflict with the option above)
• Some sort of validator function to determine if a date (in the rendered month) is valid or not (i.e. selectable or not)
• Some sort of function to generate slot times (per 15min, per 30min, per hour, etc.)

For point 3 I think that's a nice way of doing it. Sane default with the option to change the timezone. Although one thing to not here is that I think this setting is more for the "sanity" of the user (person using the picker). Because the timezone is less important when scheduling against specific slots, since you don't have to take someone else's time slot + time zone into account. (like with Calendly et all; does my local time slot overlap with the other's person local time slot). So do we actually need a time zone selector?