Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More flexible styling #47

Merged
merged 2 commits into from
Aug 11, 2022
Merged

Conversation

coling
Copy link
Contributor

@coling coling commented Aug 3, 2022

Description

These changes allow for more flexible styling

Motivation and Context

We're using the calendar to select start and end dates for holiday bookings (unsurprisingly!)

At present the calendar only has a single "invalid" class for dates that cannot be selected. This is generally fine but for better UX, we may wish to differentiate days that are not technically sold out, but perhaps don't meed certain rules. e.g. a given property may only allow check-in's on Saturdays. All other days of the week are invalid for selection but that doesn't mean they are sold out.

But allowing a callback which can be used to apply custom class names to the days, we can allow great downstream flexibility.

I've also added some more generic classes to the various objects. This allows for general purpose styling without having to override the components.

How Has This Been Tested?

I have written a storybook entry for this change which adds the odd or even class to each day and a little inline style to see this in action.

I have also incorporated this into another project which uses it in a more complex way.

Types of changes

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

This will allow custom functionality such as differentiating what kind of
'invalid' a day might be. e.g. when used as a booking calendar, you might
not be allowed to select a given day to check in because it's sold out,
or it may simply not be a valid check-in day. Differentiating this is
key to user experience.
This just gives a bit of control over downstream styling that can't always
be achieved via styled component overrides (that I can work out anyway)
@@ -35,6 +36,7 @@ export interface InitialProps {
numberOfMonths?: number;
initialMonthAndYear?: string;
onRangeDateInScreen?: DatePickerWindowUpdated;
dayClasses?: (day: Dayjs) => string[];
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's great, @coling , Thank you so much for your great feature.

Before we are going to merge it, can we have a specific type for dayClasses and export it and use it in all places?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good shout. Will get that sorted at some point soon (for various values of "soon" 😛 )

@samsam-ahmadi samsam-ahmadi merged commit 5793de6 into samsam-ahmadi:master Aug 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants