ERA-11311: Dropdown list hidden when at bottom of event

[gaboDev]

What does this PR do?

• Changes the way our main Select component render its options menu, We change the behavior of the menu making it aware of the space around it and based on this display the option menu properly.

How does it look

Relevant link(s)

• Tracking tickets: ERA-11311
• Hosted demo environments

[gaboDev]

By customizing menuPortalTarget and styles of menuPortal to render the menu options in the body We ensure no other element blocks the menu, I know We've avoid the usage of zIndex but in this case this styles are only applied to the portal which is rendered only when the options menu is opened, from there also menuPlacement is added, making the select component aware of the space around it allowing it to render the menu in the best place possible.

I'm adding this behavior as the default to all our Select components which are implemented based on src/Select.
And also I'm adding the same behavior for the fields used to render a v2 event type form.

cc
@JoshuaVulcan @luixlive

[luixlive]

I remember we discussed this ticket in a frontend refinement and we agreed that the best solution would be to just add an extra empty space at the bottom of the form when needed (for new reports I guess, since existing reports will have the History section, which adds the space needed to open the dropdown). This z-index solution is not scalable, since we may want to render our fields in drawers, modals, popovers, etc...

Actually, we do render the v2 selects in modals when they are in a collection, and I couldn't test that. Why not to simply add that extra space? Sounds like a good solution and wouldn't involve these magic z-index numbers.

@gaboDev

[gaboDev]

I remember we discussed this ticket in a frontend refinement and we agreed that the best solution would be to just add an extra empty space at the bottom of the form when needed (for new reports I guess, since existing reports will have the History section, which adds the space needed to open the dropdown). This z-index solution is not scalable, since we may want to render our fields in drawers, modals, popovers, etc...

Actually, we do render the v2 selects in modals when they are in a collection, and I couldn't test that. Why not to simply add that extra space? Sounds like a good solution and wouldn't involve these magic z-index numbers.

@gaboDev

Yep, I got your point about the z-index, I don't think calculating extra space will be something that resolves the root of the issue, because it has several implications like the order of appearance of the dropdown or the layout of the form, the same goes when having lets say a dropdown as the third element in a form but the content of the menu options also requires to calculate extra space? it would be a calculation We need to do for all dropdown that meet specific criteria.

For me, this is an issue of component behavior and not a layout problem.

I think the problem is making aware the component itself of its surroundings and display the menu as better as possible, this is not new, react-select already solves this issue through menuPortalTarget and menuPlacement, I added the fixed z-index to ensure nothing would block the menu but it is possible to delegate this calculation to react-select by just removing the styles I added.

So I think that applying this behavior to all our dropdown it is way more reliable than adding space/layout calculations.

I will remove the z-index, I will add some event to replicate the issue, feel free to take a look to the feature env and if after removing the z-index still seems like a bad path to go I can take a look to the spacing stuff

[gaboDev]

Carcass is the event type with the dropdowns form

@luixlive