Refreshing powertip on click

[sebszocinski]

I'm having trouble getting powertip to refresh to update the tooltip on a click event. I have a gallery of images that rotate on click and a data-powertip field is updated each click. I need to destroy powertip and re-initiate it on each click without mouse-leaving the element.

Does that make sense?

[stevenbenner]

Are you trying to update content in the tooltip while it is open?

The content within the tooltip is only created (updated) from the data when the tooltip begins to open. If you need to update the content while the tooltip is open then you'll actually have to modify the content in the tooltip div.

Here's an example:

// open the tooltip
$(element).powerTip('show');

// wait 5 seconds, then change the content
setTimeout(function() {
    $('#powerTip').html('<p>Updated</p>');
}. 5000);

The default id of the tooltip element is powerTip, but you can change this via the popupId option.

It might be useful to add an "update" method to the API so you can update the data attribute then call update and save the extra work.

[mhelvens]

I'm also experiencing this problem. At the very least, an "update" method seems sensible.

[stevenbenner]

I will investigate what it will take to add some kind of functionality to refresh the content of an open tooltip.

I suspect that it would be pretty easy if we're using jQuery's data() method directly, but more difficult if it needs to support HTML attributes like title or data-powertip because both PowerTip and jQuery cache those away in memory when they're first retrieved (to reduce slow DOM interactions).

[northernlite69]

I had a similar issue and originally brute forced a fix by recreating the entire tip when the content changed but this was ugly because the init caused a visible delay on refresh.

I create a PowerTip on my target element (spans in my case) and place a unique id attribute there too, which is then passed along to the function that does the updating (via ajax):

$(id).data('powertipjq',data);
$.powerTip.hide();
$.powerTip.show(id);

Now when I use the code above, I get a perfect, smooth update. PowerTip's great- hope this helps!

[speedplane]

Any chance this update function will get implemented any time soon?

Replacing the powerTip content has issues. This example illustrates: Suppose you have two links on the screen A and B, each with their own custom powerTip. The user hovers tip A and we then display some information. This hover also triggers an asynchronous ajax call to get more information about tip A with the idea that it will be updated. Then before that request completes, the user moves to tip B. Then the async request for tip A completes. Simply replacing the html here will cause the data for tip A to be displayed in tip B.

[stevenbenner]

@speedplane Good example! That scenario actually makes this request more complicated than I had originally thought. I was thinking about just providing a simple API that updates the currently open tooltip, but if I need to support the use case where the tooltip may no longer be open then the API has to be much smarter. It would need to make sure that the open tooltip is attached to a specific element before updating.

This is starting to get into a couple of the same problems as adding AJAX support. It should be possible, but it changes the implementation in a way that might not be very intuitive and raises some questions.

Implementation

• Instead of something simple, like $.powerTip.setContet('new tooltip'), it will have to accept a specific element, like $.powerTip.setContent('new tooltip', $('#specific-element')).

Questions

• If the open tooltip is not for the specific element that was updated, should that content replace the data already associated to that element? Making the next tooltip open for that element show the new content instead of the original.
  • If always replaced, then if the specific element passed to the API is actually a collection of elements would they all have their content changed to the new value?
• Should the tooltip close and reopen? Or should the content just be immediately replaced?
  • If immediately replaced, should it automatically try to reposition itself? This may cause the tooltip to move around in unexpected ways while it is open.

Thoughts

I'm not entirely sold on this more complicated implementation. It makes sense in the context of this issue, but full AJAX support has been on the table for years (see: #45). In your case I think that what you really want is AJAX support. The reason that has been delayed so long is that it raises some very difficult implementation and UX questions. If you have thoughts on AJAX support or just want to push for me to finally implement it, I'd love to hear your thoughts (in issue #45).

For your use case, this seems like something that doesn't necessarily need to be in the library. The idea would be to use a unique element target for injecting the AJAX content. For example, an ID:

// set content
$('#link-a').data('powertip', 'Basic A info<br /><span id="link-a-extra">Loading more...</span>');
$('#link-b').data('powertip', 'Basic B info<br /><span id="link-b-extra">Loading more...</span>');

// set up tooltips
$('#link-a, #link-b').powerTip();

// set up ajax request to happen on tooltip open event
$('#link-a, #link-b').on('powerTipOpen', function() {
    var thisId = $(this).attr('id');

    // do ajax request
    // assume that the loadAJAX() function signature looks like this:
    //     loadAJAX(url, targetElement)
    swtich (thisId) {
        case 'link-a':
            loadAJAX('my.url/get?content=link-a', $('#link-a-extra'));
            break;
        case 'link-b':
            loadAJAX('my.url/get?content=link-b', $('#link-b-extra'));
            break;
    }
});

This way even if the tooltip has since closed and another opened it will not accidentally inject content into the unrelated tooltip.

Schedule

As far as time-frame. Well, "soon" is a relative term. I want the next release to be a smaller bugfix release, this is new feature work. If this can be done well then I'll try to include it in the next feature release. I'm maintaining this project in my spare time so I don't want to make any commitments about when the next feature release will be. But I would expect it to be measured in months.