[RAC] is there a way to capture and control the calendar state in the date picker popover?

[binaryartifex]

Using the date picker, is there a way to control when the selected calendar value is passed to the date picker state context and when i want to close the actual popover? I want to be able to select a date in the calendar and hit submit within the popover which would pass the value to state and close the popover. ive tried a combination of context combinations but i can't seem to prevent the parent date picker from immediately getting the selected value. Ive gotten as far as the snippet below. but every click on the calendar still propagates the change to the date picker state context immediately which im trying to control myself. i tried useContextProps but even overriding the onChange handler doesn't stop it as i believe all callbacks are chained together instead of replaced entirely.

export function CalendarDialog() {
  const state = useContext(DatePickerStateContext);
  const [value, setValue] = useState<DateValue | null>(() => state.value);
  const styles = calendarDialogStyles();

  const handleSubmit = useCallback(
    (dateValue: DateValue | null) => {
      state.setValue(dateValue);
      state.close();
    },
    [state],
  );

  return (
    <Dialog className={styles.base()}>
      <Calendar onChange={setValue} value={value} />
      <div>
        <Button isFullWidth onPress={() => handleSubmit(value)} slot={null}>
          Confirm
        </Button>
      </div>
    </Dialog>
  );
}

[snowystinger]

Assuming I haven't overly simplified, could you track the selected date externally along with the open state? Then when the dialog closes you could commit the selected date? or when the confirm button is pressed?
Something like https://codesandbox.io/p/sandbox/funny-sound-mr7kyp

[binaryartifex]

ahh ok yeah i was trying to manage the state within the scope of the CalendarDialog component by using DatePickerStateContext, OverlayTriggerStateContext and a useContextProps for the CalendarContext to keep it all tucked away without increasing the 'footprint' of the implementation. granted your suggestion does indeed work, although i was hoping i could of juggled the above contexts to achieve the same thing, if anything to further reinforce my understanding of how they can be composed together...