Tooltip does not work inside repeat with dynamic value

[chriscantu]

Hello...

When I try the following, the column value (user.firstName) never displays. When I remove the tooltip directive, it reappears. I also tried displaying a hard coded value and the tooltip reappears although it was not displayed in the correct location. (This may be due to the fact, that I am rendering a template).

<tr ng-repeat="user in users | filter:myFilter | orderBy:predicate:reverse">
    <td>....</td>
    <td><a><span tooltip-placement="right" tooltip="Some Text">{{user.firstName}}</span></a></td>
</tr>

Please let me know if made a mistake.
Thanks!

Chris

[pkozlowski-opensource]

@christophercantu could you please prepare a plunk with a reproduce scenario? It would help a lot!

[pkozlowski-opensource]

OK, I can see, there is clearly something wrong: http://plnkr.co/edit/x8gCfz?p=preview

[pkozlowski-opensource]

@joshdmiller It looks like a scoping issue, didn't look into the details, but looks like transclusion breaks things here...

[joshdmiller]

Well, shoot-darn. I'll PR a fix in a little while.

[ajoslin]

Thanks for making this @joshdmiller. I've been wanting to have this in for awhile but never got to it.

Could you also move the mouseenter and mouseleave events to the template (probably just by adding show and hide to the popover scope)? We want the template to have full control of dom-ish stuff with these directives. Someone might want to have this tooltip on mobile for example, and wouldn't want the mouseenter and mouseleave events stuck in the directive code.

Also sometime we should factor out the placement logic to a service or directive controller and add a popover directive. Popover will probably also want to work like $dialog, being a service that opens with a template. I'm not sure about it yet. If we do it the service way, we should factor out a bit of $dialog's functionality too (the insert-html-and-locals-and-controller-into-dom part).

[joshdmiller]

@ajoslin For the leave/enter events, we cannot move them to the template because there is no template for the DOM element that receives the events. This follows the general pattern of the jQuery plugin in that we do not touch the element on which the directive is applied. On mouseenter of the tooltip directive's element, we create an additional DOM element from the tooltip-popup directive that is compiled and inserted after the dom element of tooltip. It is destroyed on mouseleave.

The only way I can think of to put the events in the template would be to have the tooltip directive replace the original DOM element and transclude its contents; I actually prototyped it before I wrote this version, but it seriously limited on what we could place the tooltip.

I also created another version that kept the popup element in the DOM and showed/hid it as necessary, so that logic was entirely within the template. Problem there was that the Boostrap CSS by default gives the tooltip class a high z-index, so it blocked the mouseenter events of adjacent tooltips. I solved this, too, but only by including a hack to conditionally set the z-index of the popover to -1. Since this was also in the link function and less portable across templates/styles, I opted for the other solution.

Also, the trigger events will eventually be configurable (defaulting to mouseenter/mouseleave, but also supporting focus/blur, etc.) to be feature-complete with the jQuery plugin. So, you make good points, but I am unsure how to solve them here. If you have suggestions, I'd love to hear them.

For the placement logic and popover - I completely agree that the placement logic would be best externalized so it can be reused. That's not a problem to implement. We discussed on the mailing list a while back that there would be popover/tooltip/dialog overlap we'd have to discuss before writing the popover directive, but that we'd cross that bridge when we came to it.

I guess we've come to it. :-)

[ajoslin]

Oh you're right, it wouldn't work in the template. Never mind me then haha

...and I need to remember to check that angular-ui mailing list

Sent from my iPhone

On Jan 14, 2013, at 4:53 PM, Josh D Miller notifications@github.com wrote:

@ajoslin For the leave/enter events, we cannot move them to the template because there is no template for the DOM element that receives the events. This follows the general pattern of the jQuery plugin in that we do not touch the element on which the directive is applied. On mouseenter of the tooltip directive's element, we create an additional DOM element from the tooltip-popup directive that is compiled and inserted after the dom element of tooltip. It is destroyed on mouseleave.

The only way I can think of to put the events in the template would be to have the tooltip directive replace the original DOM element and transclude its contents; I actually prototyped it before I wrote this version, but it seriously limited on what we could place the tooltip.

I also created another version that kept the popup element in the DOM and showed/hid it as necessary, so that logic was entirely within the template. Problem there was that the Boostrap CSS by default gives the tooltip class a high z-index, so it blocked the mouseenter events of adjacent tooltips. I solved this, too, but only by including a hack to conditionally set the z-index of the popover to -1. Since this was also in the link function and less portable across templates/styles, I opted for the other solution.

Also, the trigger events will eventually be configurable (defaulting to mouseenter/mouseleave, but also supporting focus/blur, etc.) to be feature-complete with the jQuery plugin. So, you make good points, but I am unsure how to solve them here. If you have suggestions, I'd love to hear them.

For the placement logic and popover - I completely agree that the placement logic would be best externalized so it can be reused. That's not a problem to implement. We discussed on the mailing list a while back that there would be popover/tooltip/dialog overlap we'd have to discuss before writing the popover directive, but that we'd cross that bridge when we came to it.

I guess we've come to it. :-)

—
Reply to this email directly or view it on GitHub.

[joshdmiller]

I never opened the PR on the first one, but Github apparently decided to reference here it anyway. They're the same commits, but the second one with the real PR is the right commit to look at.