Customized BayView Calendar Component

[cpilande]

Description

This PR reimplements the calendar component with the agreed-upon wireframe styles and provides the capability for different error checks. No date can be picked before today's date. For cards with two dates, the user must input the Departure Date before the Return Date input is enabled. No date before the Departure Date can be inputted.

Motivation and Context

This PR is necessary for all of the cards in order to have a calendar for the user to select dates for reservations and bookings. Having a calendar that matches the decided-upon styling ensures a more uniform appearance. The use of a custom component also gives us more range to modify the calendar to our needs.

How Has This Been Tested?

Screenshots (if appropriate):

Dialog Demo The following demo showcases the updated styling of the calendar and the error checks provided for the Flight Card component. https://github.com/heyitsmass/BayView/assets/120698868/3c3b5e04-8a92-4447-ad44-8b4c1eecf518

Note: All input cards must be refactored with the new calendar component

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Refactoring (non-breaking change)
• [x] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• [x] - My code follows the code style of this project.
• [ ] - My change requires a change to the documentation.
• [ ] - I have updated the documentation accordingly.
• [ ] - I have read the CONTRIBUTING document.
• [ ] - I have added tests to cover my changes.

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
bay-view	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 23, 2023 10:56pm

[rdoinhs]

👍 Nice! A couple points from my side, some notes/observations and one recommendation:

• 🛠️ Regarding the code, with way the calendar is linked to the input in this pr, treated as a separate entity component rather than a modal that transmits data on click of the existing shared input icon prop, some refactoring will be necessary to integrate it smoothly into our current card component structure, as mentioned. This was somewhat expected, as we haven't fully addressed this before, but it really underlines the chance we have for some significant refactoring when/if time allows to modify the existing shared input and treat the calendar popup alone as a separate entity.
• 🎨 On the design side, I propose rounding the outer edges of the modal to match the rounded-2xl style of our cards (removing the outermost gray border, etc.) and making sure it's compatible with dark mode. These adjustments can be tackled in a subsequent pr of course.

[cpilande]

👍 Nice! A couple points from my side, some notes/observations and one recommendation:

• 🛠️ Regarding the code, with way the calendar is linked to the input in this pr, treated as a separate entity component rather than a modal that transmits data on click of the existing shared input icon prop, some refactoring will be necessary to integrate it smoothly into our current card component structure, as mentioned. This was somewhat expected, as we haven't fully addressed this before, but it really underlines the chance we have for some significant refactoring when/if time allows to modify the existing shared input and treat the calendar popup alone as a separate entity.
• 🎨 On the design side, I propose rounding the outer edges of the modal to match the rounded-2xl style of our cards (removing the outermost gray border, etc.) and making sure it's compatible with dark mode. These adjustments can be tackled in a subsequent pr of course.

Sounds good! I was able to refactor it a bit earlier with the Flight Card. I'll wait until all our cards are merged in, so I can modify all of them before I push. I'll submit a new PR after that with the changes (visual & refactoring) for final review.