Favorites in grouping chooser should scroll

[febbraiod]

We had discussed that users should truncate their favorites if they have so many that it clips. However we do have one in a context (in a widget toolbar) where there is just not enough room to see even a reasonable amount of favorites.

[amcclain]

Can this be managed in an app-specific way via CSS? The issue here is that we don't know where a groupingChooser will be placed on the page, so we don't have a solid way to constrain the height, therefore we don't have a good way to trigger scrolling.

We could declare some default maxHeight and ensure a long lists of favorites scrolls if hit, but that might still result in an off-screen chooser. Even using vh - it could be in the middle of the screen.

We have pretty thorough coverage with defined CSS classes on all the major sub-components - plan was to allow an app to then use those as needed to fine-tune the layout. Can you look at that option?

Happy to entertain any ideas we could action here in Hoist, but I had not come up with any. I had considered adding more top-level props like maxChooserHeight but then thought, eh, this is exactly what CSS is for

[minusleaf]

Ran into this for a client app, though also for the ViewManager. Since I only use the chooser in one screen (or I can guarantee the y-position is consistent if used in multiple screens), I just hard-coded within the App.scss max-height: calc(100vh - arbitraryOffset).

Wondering if we could make use of obtaining the trigger button element's bounds via getBoundingClientRect, add its top (or y position) and height values to obtain the offset that we can use to pass along the popover object.