@mainframev can you please check if this can be achieved with the current implementation of Tooltip / Overflow?

@tudorpopams @gouttierre

Hello folks 👋🏻

I've checked this, v8 Tooltip had a specific property and overflow logic. It's selecting for overflow check either self or parent based on overflowMode property passed to TooltipHost. The current v9 implementation does not have this by design. The visibility of Tooltip based on overflow content can be added additionally by the user.

I quickly made a a couple examples demonstrating this.

I suggest, that maybe instead of creating a story example of this scenario, provide this issue and our migration doc, that says:

"overflowMode=> Not supported. If this behavior is needed, the tooltip's visibility can be controlled using thevisibleprop andonVisibleChange` event."

It's already covered with controlled example and adding a simple check for overflowing content via ref should not be a problem for user.

I suggest we could add the useIsOverflowing hook to the core library to streamline both examples. This approach could enhance simplicity and efficiency. Here's the link with your examples slightly updated:

https://stackblitz.com/edit/fu8vhs-iz3vyv?file=src%2FuseIsOverflowing.ts,src%2FSelfOverflow.tsx

wdyt?

@dmytrokirpa

Good question. I feel like it might not be used often and such things can be abstracted to utility hook on the user side without a problem. We can add it to react-utilities, but currently it holds hooks and other utilities that a re being first used in our development, where we sure that they are useful and used, this might end up as a kind of a "dead code".

We always use such a feature in our products, especially in v8 DetailsList: Our customers always want to display more columns/informations, than it is usefull for a fluent/responsive design. At same time no wrapping is wanted and a fixed column width is required to build a result view with grouped entries.

So we use the overflow feature to only show the tooltip if the data of the user does not fit the cell.

Isn´t it desired to "hide" the HTML/DOM specifics by the library? In this case the inclusion of overflow-check via a OoB hook would be some way.

Btw:
The initial TooltipOverflowSelf example contained an error in the cleanup function: the listener needs to be removed, not added. One of many mistakes that can happen, if the "user" does this logic by himself ;)

@nikolaiessel

The initial TooltipOverflowSelf example contained an error in the cleanup function: the listener needs to be removed, not added. One of many mistakes that can happen, if the "user" does this logic by himself ;)

Thank you for the feedback! I appreciate that you understand this was just a quickly made example for demonstration purposes. 😊

We always use such a feature in our products, especially in v8 DetailsList: Our customers always want to display more columns/informations, than it is usefull for a fluent/responsive design. At same time no wrapping is wanted and a fixed column width is required to build a result view with grouped entries.

I understand your perspective—thank you for providing the context. Component APIs can change significantly from version to version, and when a feature is not supported, it’s often an intentional decision. In my opinion, the Tooltip component should not handle overflow logic by default. However, it does provide the necessary props to control its visibility, leaving overflow handling as the user’s responsibility.

To support your migration, we could create documentation examples featuring a custom hook that checks for overflowing content. If, after discussion, if it will be decided to make this hook reusable, we can include it in react-utilities and suite. This should help ease the transition from v8 to v9.

UPD: here is the context on last change to this topic

UPD2: onlyIfTruncated story example existed in preview version

This issue has been automatically marked as stale because it has marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. Thank you for your contributions to Fluent UI!