Fix datepicker elevation, props and bottom-lined input ref

[martimalek]

What

• Fixes Datepicker elevation when appearing on a Modal
• Fixes Datepicker props not extending Input props
• Fixes "bottom-lined" Input variant ref

Media

Before (Datepicker underneath Modal)

After (Datepicker on top of Modal)

Why

To offer a consistent experience on the Datepicker and Input components

How

• Move z-index to the highest Datepicker container (before it was in a lower level container and the Modal would take preference)
• Extend InputProps in DatepickerSingleInputProps since props are being sent to trigger Input
• Point ref in InnerInput with "bottom-lined" variant to the actual html input instead of the the wrapper div
• Minor addition of a label for the "Datepicker on Modal" story

Closes #421

[nlopin]

I'd try attaching the datepicker popup to the modal, not to the body. In that case, the elevation of the modal will be used and we can rely on it. I'm not confident it will work, but I don't see the reason why it shouldn't

[martimalek]

I'd try attaching the datepicker popup to the modal, not to the body. In that case, the elevation of the modal will be used and we can rely on it. I'm not confident it will work, but I don't see the reason why it shouldn't

@nlopin how can we know to which element to attach it to? Do you mean having a new prop (e.g. portalContainer)?

[nlopin]

I'd try attaching the datepicker popup to the modal, not to the body. In that case, the elevation of the modal will be used and we can rely on it. I'm not confident it will work, but I don't see the reason why it shouldn't

@nlopin how can we know to which element to attach it to? Do you mean having a new prop (e.g. portalContainer)?

yep, that's the issue. Let's merge this solution and see whether the z-index war will start or not 😂

[github-actions[bot]]

:tada: This PR is included in version 2.1.1 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket: