[API] DEFAULT_RANGE is internal and cannot be used when creating composable functions

[Nek-12]

Constants.DEFAULT_RANGE is internal, as such, it cannot be used to create composables which wrap the CalendarDialog.

Sample:

@Composable
fun calendarDialog(
    title: String?,
    style: CalendarStyle,
    dateRange: ClosedRange<LocalDate>? = null,
    onSelectDate: (LocalDate) -> Unit,
    initialDate: LocalDate = LocalDate.now(TimeZone.currentSystemDefault()),
): UseCaseState {
    val state = rememberUseCaseState()

    CalendarDialog(
        state = state,
        selection = remember(initialDate) {
            CalendarSelection.Date(
                withButtonView = true,
                selectedDate = initialDate.toJavaLocalDate(),
            ) { onSelectDate(it.toKotlinLocalDate()) }
        },
        config = remember(style, dateRange) {
            CalendarConfig(
                style = style,
                monthSelection = true,
                yearSelection = true,
                boundary = dateRange ?: DEFAULT_RANGE,
                icons = LibIcons.Rounded,
            )
        },
        header = remember(title) { title?.let { Header.Default(title = it) } },
        properties = DialogProperties(),
    )
    return state
}

[maxkeppeler]

I don't see any issue here. You can define your own default range and utilize it for both the CalendarDialog and your wrapper composable function. If the standard range needs to remain the same, you can easily copy and paste it those constants, allowing you thus easily to change the range if desired. I will keep the constant files and the respective constants internal.
Why would you define the state inside your wrapper function instead of passing it along?

[Nek-12]

Alright, I see. For now I used the approach you suggested, just thought you would consider providing sensible defaults for people to use, however user-defined-defaults work too
I'm making these helper functions for the dialogs because I want to streamline the process of composing and showing the dialog. I've noticed that all of the usecases I've encountered involve declaring the state and immediately calling the Dialog composable, so I've merged those operations together. I'm passing the state as a return value of the function and using it later in the parent composable.

P.S. Github is experiencing serious issues :D