feat: startValue binding for RangeCalendar/DateRangePicker

[epr3]

This PR adds a new convenience property to RangeCalendar/DateRangePicker for setting up the startValue on the aforementioned components plus an event for listening for said startValue changes. The property cannot be modified outside the component, you would need to update the modelValue for that.

Also, this PR cleans up some of the conditions inside the DateRange components for consistent behaviour regarding modelValue updates plus some clean code updates on the defaultValue.

Context for feature: https://www.shadcn-svelte.com/docs/components/date-picker#date-range-picker

cc @sadeghbarati for the feature suggestion

[zernonia]

Let's also add a story in Chromatic to showcase this ya 😁

[epr3]

@zernonia I've updated the watcher inner variables in both DateRangeField and RangeCalendar and added the startValue story in RangeCalendarChromatic.story.vue.

[zernonia]

removing defaultValue, and allow startValue to take action, causing the placeholder month to be different from the startValue.

Maybe let's show the same month as the startValue? That behave more "natural"

[zernonia]

Also, what's the benefit of adding this new prop ya? Can't we use modelValue with value { start: new CalendarDate(2024, 2, 20), end: undefined } to achieve the same?

And I don't quite understand you mentioned

Context for feature: https://www.shadcn-svelte.com/docs/components/date-picker#date-range-picker

Is the startValue being used anywhere?

[epr3]

The prop can be used for getting a fresh startValue whenever the user first clicks a date range, since the RangeCalendar only updates the modelValue once both the start and the end are filled.

On the shadcn-svelte link, the startValue is used for this piece of code(the DateRangePicker)(I've marked with comments where the startValue is used):

<script lang="ts">
  import CalendarIcon from "lucide-svelte/icons/calendar";
  import type { DateRange } from "bits-ui";
  import {
    CalendarDate,
    DateFormatter,
    type DateValue,
    getLocalTimeZone
  } from "@internationalized/date";
  import { cn } from "$lib/utils.js";
  import { Button } from "$lib/components/ui/button/index.js";
  import { RangeCalendar } from "$lib/components/ui/range-calendar/index.js";
  import * as Popover from "$lib/components/ui/popover/index.js";
 
  const df = new DateFormatter("en-US", {
    dateStyle: "medium"
  });
 
  let value: DateRange | undefined = {
    start: new CalendarDate(2022, 1, 20),
    end: new CalendarDate(2022, 1, 20).add({ days: 20 })
  };
 
  let startValue: DateValue | undefined = undefined; // here
</script>
 
<div class="grid gap-2">
  <Popover.Root openFocus>
    <Popover.Trigger asChild let:builder>
      <Button
        variant="outline"
        class={cn(
          "w-[300px] justify-start text-left font-normal",
          !value && "text-muted-foreground"
        )}
        builders={[builder]}
      >
        <CalendarIcon class="mr-2 h-4 w-4" />
        {#if value && value.start}
          {#if value.end}
            {df.format(value.start.toDate(getLocalTimeZone()))} - {df.format(
              value.end.toDate(getLocalTimeZone())
            )}
          {:else}
            {df.format(value.start.toDate(getLocalTimeZone()))}
          {/if}
        {:else if startValue} // here
          {df.format(startValue.toDate(getLocalTimeZone()))}
        {:else}
          Pick a date
        {/if}
      </Button>
    </Popover.Trigger>
    <Popover.Content class="w-auto p-0" align="start">
      <RangeCalendar
        bind:value
        bind:startValue //here
        initialFocus
        numberOfMonths={2}
        placeholder={value?.start}
      />
    </Popover.Content>
  </Popover.Root>
</div>

[epr3]

@zernonia I gave more of a thought about the startValue prop: you're right, we don't actually need it, but the @update:start-value event is useful for always getting a fresh startValue from the RangeCalendar.

I've also renamed the inner watcher variables as suggested. 🚀

[zernonia]

@zernonia I gave more of a thought about the startValue prop: you're right, we don't actually need it, but the @update:start-value event is useful for always getting a fresh startValue from the RangeCalendar.

I've also renamed the inner watcher variables as suggested. 🚀

Icic.. How about we only expose update:startValue emit? and user can use this emit to manipulate the modelValue.

[epr3]

@zernonia I gave more of a thought about the startValue prop: you're right, we don't actually need it, but the @update:start-value event is useful for always getting a fresh startValue from the RangeCalendar.
I've also renamed the inner watcher variables as suggested. 🚀

Icic.. How about we only expose update:startValue emit? and user can use this emit to manipulate the modelValue.

Sure thing! I've exposed the event and removed the startValue property in the latest commits. 👍🏻