fix(Table): add ability to redefine max height for menu popup

[leushin]

No description provided.

[gravity-ui]

🎭 Component Tests Report is ready.

[gravity-ui]

Preview is ready.

[Raubzeug]

@leushin Hi! Could you please explain what issue is being addressed in this pull request?

[leushin]

@leushin Hi! Could you please explain what issue is being addressed in this pull request?

We have a case where important menu items are hidden behind a scroll, making it unclear to users that there is anything else there.

These changes allow you to disable the maximum height for the entire menu and set the required minimum height.

This way, you can customize the display of the table's menu actions: show everything without hiding it behind a scroll, or stretch it to the desired number of menu items.

[Raubzeug]

@leushin Adding two new props here makes the component API a bit heavier, and it looks like these are purely styling concerns rather than behavior.
Could we consider using a CSS custom property instead? That would keep the component API clean and still allow consumers to override the styling when needed (including theming), without introducing extra props.

[leushin]

@leushin Adding two new props here makes the component API a bit heavier, and it looks like these are purely styling concerns rather than behavior. Could we consider using a CSS custom property instead? That would keep the component API clean and still allow consumers to override the styling when needed (including theming), without introducing extra props.

I don't want to redefine the component's CSS class by its generated name, as it may change and cause issues in the final service. Moreover, the element itself is located in a portal, so the redefinition will need to be done globally.

CSS API is not used in the component, but it could be a solution (put 200px in a variable and override it at the service level)

Therefore, you can try to switch to the CSS API at least in this place, although I don't see it being used anywhere. Alternatively, I will ask you to expand the API to at least one method.

[Raubzeug]

@leushin When I say “CSS API”, I mean exposing styling controls via documented CSS custom properties (CSS variables) that the component itself reads, rather than overriding generated class names.

Yes, Table doesn’t have this kind of API yet, but other UIKit components (e.g. Button) already do. That’s why I’m suggesting we follow the same approach here: keep the React props API focused on behavior, and use CSS variables as the styling contract that can be overridden at the service level (including for portal cases).

[leushin]

@leushin When I say “CSS API”, I mean exposing styling controls via documented CSS custom properties (CSS variables) that the component itself reads, rather than overriding generated class names.

Yes, Table doesn’t have this kind of API yet, but other UIKit components (e.g. Button) already do. That’s why I’m suggesting we follow the same approach here: keep the React props API focused on behavior, and use CSS variables as the styling contract that can be overridden at the service level (including for portal cases).

Updated the PR, please take a look