Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Get tooltip content dynamically in the render method #281

Merged

Conversation

alfonsomunozpomer
Copy link
Contributor

Get the tooltip content in the render method using a function instead of setting it in state.placeholder. This allows for the tooltip contents to change dynamically and react to changes to props (or be hidden if you return null in the getContent prop).

… of setting it in state.placeholder. This allows for the tooltip contents to change dynamically (or be hidden if you return null in the getContent prop).
@huumanoid
Copy link
Contributor

Thank you for your contribution!
It seems like the bottom examples at http://wwayne.com/react-tooltip/ doesn't work with your PR applied. What can we do with it?

@wbazant
Copy link

wbazant commented Mar 29, 2017

@alfonsomunozpomer I think it's because you take out the code which sets this.intervalUpdateContent ?

@alfonsomunozpomer
Copy link
Contributor Author

@wbazant I think you’re right. Quite an oversight from my part... I’ll fix it tomorrow!

@alfonsomunozpomer
Copy link
Contributor Author

@huumanoid I’ve now tested it and everything looks fine.

Notice, though, that the tooltip content changes as you move the mouse, which is the intentded behaviour at least in our use case. updateTooltip is invoked with every mouse movement which, in turn, calls getContent. If you want to have different tooltips for the same target depending on the region where you are hovering (or because some other changes in props) this is necessary. If you want to avoid this, maybe a new boolean prop can be added, e.g. dynamicContent, to have the tooltip content be set in the state or computed for every render. However, I think it’s a bad idea and unneeded complexity unless a substantial number of users prefer the old way.

@huumanoid
Copy link
Contributor

huumanoid commented Mar 30, 2017

Thank you for a quick fix!
Your opinion is reasonable about unneeded complexity is reasonable.

If you want to have different tooltips for the same target depending on the region where you are hovering

Use case you mentioned sounds interesting!
Could you tell me more, please?

As far as I understand:
For example, we've got a single <span data-tip> with text into it.
And we want to show different content depending on which word is hovered right now.
Is getContent suitable for it?

Is svg with a complex content relates to this use case?

Why don't user pass changes to props.children instead? Why do we need to make getTooltipContent called every time the updateTooltip is called?

@alfonsomunozpomer
Copy link
Contributor Author

Precisely our use case is that we have a SVG, more specifically a Highcharts heatmap (we’re using react-highcharts). It can fire events when you hover the mouse pointer over different parts of the chart, and we pass a callback from the react-tooltip container component that changes the contents of the tooltip depending on the hovered element (i.e. the event fired).

Yes, getContent works perfectly in our case, but the problem was that the tooltip didn’t change. It kept the contents of the first rendered area, and that’s why I changed the code to be called on updateTooltip.

Let me know if anything is unclear.

@datzun
Copy link

datzun commented Jun 19, 2017

@huumanoid any chance of this getting merged soon? Also running into this problem. ☹️

@NathanBWaters
Copy link

Also running into this problem.

@SamMcFaddenBJSS
Copy link

+1 Please can you merge this branch as am having the same issue. Cheers dude :-)

@Tommy10802
Copy link

Same here pls merge this fix asap thanks a lot

@seanmhanson
Copy link

+1

@huumanoid is there any hope of getting this merged in? This is definitely causing me issues I am not enjoying working around.

@Soletiq
Copy link

Soletiq commented Jul 26, 2017

+1

@egarza54
Copy link

Any update on this pull request?

@utajum
Copy link

utajum commented Sep 22, 2017

Can you please merge this.

Thank you

@dokinoki
Copy link

dokinoki commented Oct 2, 2017

I had the same issue, content would not reload, I fixed it in the meantime by doing the following:

This case does not reload the UI when props change

<ReactTooltip>
    <Component {...someProps} />
</ReactTooltip>

This case does reload the UI when props change

<ReactTooltip 
    getContent={[() => <Component {...someProps} />]}
/>

@aronhelser
Copy link
Collaborator

aronhelser commented Apr 10, 2018

I like this change, but it does change the behavior of the API - the left example in the last row of http://wwayne.com/react-tooltip/ uses getContent={() => Math.floor(Math.random() * 100)} and that now changes every time the mouse moves, instead of changing only when the tooltip is shown. The right example also updates every time the mouse moves, and at a 1 sec interval if the mouse is still.

Is there a reason this shouldn't be merged because of this?
Re-reading @alfonsomunozpomer explanation above, this was intended behavior. I'm fine with that.

@aronhelser aronhelser merged commit 6d06849 into ReactTooltip:master Apr 11, 2018
@aronhelser
Copy link
Collaborator

🎉 This PR is included in version 3.5.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

@slimgabsi
Copy link

slimgabsi commented Jun 30, 2022

the solution is to hide and then show the tooltip on state change and if your cmp is hovered .
Note that am using functional cmps and useRef hook
I guess you can do the same with componentDidUpdate()
use onMouseEnter and onMouseLeave to set the hovred state

        const handleOnMouseLeave = () => {
		setIsHovered(false);
	};
	const handleOnMouseEnter = () => {
		setIsHovered(true);
	};

		useEffect(() => {
       if (myRef?.current && isHovered) {
		ReactTooltip.hide();
		ReactTooltip.show(myRef.current);
	}, [myState]);


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.