Calendar doesn't update view with outside click

[liborzahradka]

Hey, when I select date in calendar for example.. June 14th. I do have outside button to set current date, so after click, the calendar will update to the current date but the view will stay on June and doesn't update to current month where selected date is.

• Version: 3.0.0

const [date, setDate] = useState(new Date());

<Calendar onChange={(value) => setDate(value)} value={date} view="month" showFixedNumberOfWeeks />

[giacomocerquone]

@liborzahradka This is not completely correct.
This code works for example. If you open the page and don't touch the calendar, pressing the button it will focus on the correct set date:

function App() {
  const [date, setDate] = useState(null);

  return (
    <div className="App">
      <Calendar value={date} onChange={(v) => setDate(v)} />

      <button
        onClick={() => {
          const dateToSet = new Date();
          dateToSet.setMonth(10);
          setDate(dateToSet);
        }}
      >
        change
      </button>
    </div>
  );
}

export default App;

Though there is a but.
If you manually navigate around between years and months or click on a new day, when you click the external button the date gets set, but it doesn't gain focus.
Now if you ask me this could be a correct behavior if the user first click the button and only then just navigate between dates.
At that point, it's correct for me if it doesn't regain focus if you re-click the button.
The problems come while clicking on a different day of a different month of the one in the button, so setting a new value prop, and clicking again on the button it doesn't give focus and this might be a wrong behaviour.

@wojtekmaj do you care to take a fast look at this telling us if there is a prop or something we can use to reset the calendar view?
In case I could implement it somehow

Sadly if I add this package to codesandbox it goes in an endless loop of 500 HTTP calls so can't share a repro

[wojtekmaj]

I'm not sure if it's a bug or a feature :D

React-Calendar 3.0 can be used as a controlled or as an uncontrolled component. Using value, similarly to when added on <input>, indicates we're opting for a controlled component.

If you add value prop, you're expected to handle changing it by providing onChange function.

activeStartDate, when not provided, is "defaulting" to the value inherited from current value and, if this is also not provided, from new Date().

Navigating in the Calendar sets activeStartDate in Calendar's state. Also, changing value alters activeStartDate in Calendars's state. This is because, for example, if you click a date in a neighboring month, Calendar is expected to change the view to the one in which the date you clicked is in. The latter was implemented in #322 (fixing #305).

So:

• ❌ We can't really remove setting activeStartDate on value change
• ❌ We could set activeStartDate to undefined on value change, fixing the problem in this particular case (it'd default to the value inherited from current value), but it would not fix the problem if activeStartDate was set using Calendar navigation.

What can we do, then? Update documentation. Unless I'm mistaken, there's no other way to keep these variables in sync, other than requiring the user to opt in to fully controlled Calendar, or fully uncontrolled one. If they need to alter value, and expect activeStartDate to change, it also needs to be provided.

[giacomocerquone]

Ideally activeStartDate shouldn't be used both for navigating the calendar and re-focusing the calendar on value change, so internally we could use a "private" variable as a nav pointer.
The second point I suppose looks good to me and to resolve the calendar navigation problem I'd use an internalActiveStartDate which has precedence over the one passed by the developer through props that is changed whenever the user clicks on the next/prev button.

Still, going uncontrolled what the user is asking can't be done. Going controlled, yes but the dev must disable the navigation panel and implement it himself keeping track of the activeStartDate which is what I'm suggesting to do but at a lower level, directly inside the lib.

PS: Though I think I didn't quite properly understand why the second point doesn't work for calendar navigation. If on value change we set activeStartDate to undefined, can't we still change the value of activeStartDate while navigating in the calendar?

[wojtekmaj]

Though I think I didn't quite properly understand why the second point doesn't work for calendar navigation.

Because both using navigation arrows and setting a new value causes internal activeStartDate to be updated. We can set it to undefined in the latter case, but it doesn't change anything - the bug will still be there reproduced like so:

1. Navigate back/forward/up in Calendar
2. Change value prop
3. Calendar doesn't update the view

So, the bug is really there, but I don't think it could be coded any better. The solution is to handle all variables (so: activeStartDate too), if you opted in for a controlled calendar. This without a doubt requires better documentation.

So based your example, all you have to do to fix this:

export default function App() {
  const [date, setDate] = useState(undefined);
  const [activeStartDate, setActiveStartDate] = useState(undefined);

  return (
    <div className="App">
      <Calendar
        activeStartDate={activeStartDate}
        value={date} 
        onActiveStartDateChange={setActiveStartDate}
        onChange={setDate}
      />

      <button
        onClick={() => {
          const dateToSet = new Date();
          dateToSet.setMonth(10);

          const beginOfMonth = new Date(dateToSet.getFullYear(), dateToSet.getMonth(), 1);

          setActiveStartDate(beginOfMonth);
          setDate(dateToSet);
        }}
      >
        Change
      </button>
    </div>
  );
}

CodeSandbox

You should probably also make view controlled as well, to ensure the user lands on "month" view on button click.

[giacomocerquone]

Sorry, in the previous message I mixed "controlled" and "uncontrolled" words and didn't notice.
Anyway, this is nice and completely solves op's problem I think and for this reason I do still think that #376 it's the same.

That 'onactivestartdatechange' prop is what I was talking about initially anyway, that is the missing piece that very easily handles the situation!

The only thing that doesn't work, which is not a bug for me, is clicking the button, navigate towards some other month and re-clicking the button, now that value doesn't regain focus and I think it's right like this.

This just needs better documentation, I'm on it

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this issue will be closed in 14 days.

[github-actions]

This issue was closed because it has been stalled for 14 days with no activity.