fix the bug that disabled date becomes central date #2361
Conversation
🦋 Changeset detectedLatest commit: 65d11f9 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
ryubro
requested review from
tlouisse,
gerjanvangeest,
narzac,
Knorgias and
okadurin
as code owners
|
@ryubro can you add a changeset, and fix the failing tests? |
| @@ -573,7 +572,7 @@ describe('<lion-calendar>', () => { | |||
| .disableDates="${/** @param {Date} d */ d => d.getDate() === 15}" | |||
| ></lion-calendar> | |||
| `); | |||
| el.focusDate(el.findNearestEnabledDate()); | |||
| el.focusDate(el.findNearestEnabledDate(new Date())); | |||
There was a problem hiding this comment.
Without any argument findNearestEnabledDate uses the centralDate which is today by default, but after the PR, the initial centralDate moves to the nearest enabled date if today is disabled. Hence we're supplying explicitly today as the argument.
| expect(isSameDate(el.centralDate, new Date('2019/06/03')), 'central date').to.be.true; | ||
| expect(isSameDate(elSetting.centralDate, new Date('2019/07/03')), 'central date').to.be | ||
| .true; | ||
| expect(isSameDate(el.centralDate, new Date('2019/07/03'))).to.be.true; |
There was a problem hiding this comment.
After the PR, the central date would be nearest enabled date instead of today even when the date is disabled, which is the desired behavior, I believe.
What I did
this.__calculateInitialCentralDate()andthis.__createData()infirstUpdatedinstead ofconnectedCallbackbecause props (likeminDate) are not assigned yet whenconnectedCallbackis called.