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

Various fixes for the startOfWeek prop #22

Merged
merged 8 commits into from
Jun 27, 2021

Conversation

coling
Copy link
Contributor

@coling coling commented Jun 23, 2021

Description

In both Jalali & Gregorian modes the calculation to work out the shift (padding) used at the start of the month to properly line up the start day with it's appropriate day of the week was wrong. It could lead to a whole blank row. There were also no bounds checks on the value passed in.

I've fixed these issues and documented the prop.

I've also fixed the day titles by default when non-zero values of startOfWeek are passed so these are reordered correctly as you'd expect.

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)

(not really a new feature as it was there just not documented fully as it didn't work :-p)

When using a Gregorian calendar you can change the startOfWeek value but the titles
do not move with it.

Rotate the titles array when a non-zero value for startOfWeek is passed.

If you customise the titles (via components.titleOfWeek.titles) AND the startOfWeek
then you should pass the titles array always starting from Sunday. It will be reordered
automatically allowing you to easily change startOfWeek prop without any other logic
needed.

Also add some story knobs to test.
This should always start with Sunday.
@coling
Copy link
Contributor Author

coling commented Jun 24, 2021

Just FYI, a screen shot showing the problem of the shift value often being greater than 7 and thus leaving a blank row (taken from the "App props" story)

image

I've confirmed it now seems to work properly in both modes (although it took me a while to realise my ignorance when reading the Jalali calendar that as well as reading each individual month from from R-L I also had to read the previous and next months from R-L too!! Obvious really but took me a while 🤦🏼 )

FWIW, I've continued the approach of not allowing startOfWeek in Jalali mode as I presume it's just never presented different in practice. If it should be possible to change it, feel free to let me know and I can make it so. 😃

I had fixed this in 072d886 but for some reason only the
header row fix made it into the commit.

It seems the header row has become corrupted again (likely due to Visual Studio Code trying
to be too clever.
When we've not yet selected a hoverDay and there is no 'to' date selected, the date
we used for comparisons was just an empty string.

If this is the case we should use our 'from' date.

Fixes samsam-ahmadi#21
Copy link
Owner

@samsam-ahmadi samsam-ahmadi left a comment

Choose a reason for hiding this comment

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

I Just fixed the number of start of week for Jalali and Then everything is perfect

@coling Thanks

@samsam-ahmadi samsam-ahmadi merged commit 5be7aa3 into samsam-ahmadi:master Jun 27, 2021
@coling
Copy link
Contributor Author

coling commented Jun 27, 2021

I Just fixed the number of start of week for Jalali and Then everything is perfect

Great. I wasn't sure about that side of things so thanks for fixing it up. I knew the 7 that was there previous would be the same as 0, but wasn't sure if it was the correct result in the end.

Thanks for reviewing and merging 😃

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