DatePickerRrange accepts start_date which is less then min_date_allowed

[ognjengrubac-tomtom]

The following datepicker range will accept start_date although it is less then min_date_allowed.

dcc.DatePickerRange(
id='picker-range',
min_date_allowed=date(2023, 8, 1),
start_date=date(2023, 7, 1),
)

[alexcjohnson]

Good point. Not 100% obvious what the correct solution is though. I suppose it's clear that min_date_allowed (and max_date_allowed) should take precedence over start_date and end_date, but we can't put logic like this at the Python level - that code is all auto-generated so doesn't know about logic like this, anyway it wouldn't be able to catch situations where any of these props is set by a callback.

So we'd need to catch it in JS, then there are two questions:

• Do we delete the offending start_date or set it to the closest allowed date?
• Do we push the new start_date back into the props or just use it in the display? Pushing it back into props would be more self-consistent, but could have weird side-effects such as triggering callbacks that depend on this date to make it look like the user picked a date, when really it's just the app fixing itself. Unless we do something very special, prevent_initial_call=True wouldn't know to ignore this new start_date if this happened during the startup sequence of the app.

@T4rk1n curious your thoughts on this, particularly about whether there's something we could do with validation like this and still have it marked as an initial call. I think something similar is going on in https://github.com/plotly/dash/issues/2668