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
Tooltip - unable to control using *open* props #2849
Comments
@dakahn Any update on this issue ? |
None yet. Haven't had a chance to do any first aid on this issue just yet. @asudoh might have a workaround though |
A workaround may be force-remount technique. |
force-remount is not the good solution for us since tooltip wraps input fields. |
it looks like this is caused by the @tomkdgun here is an example of the controlled tooltip functioning properly with the show/hide buttons (although it does not account for clicking the tooltip itself yet) https://deploy-preview-3357--carbon-components-react.netlify.com/?path=/story/tooltip--test, the code is currently a draft in #3357 @asudoh I think we may need to allow refs to be passed into the tooltip trigger node as well as the floating tooltip body to properly determine the source of click events once we have confirmed the direction we want to take with this fix I can backport this to v9 as well |
@emyarod I've looked into the example, but the issue is more general. In our code we are changing open prop programatically based inside custom validation methods, e.g. during typing in input text/number field. So user doesn't perform clicks, but it types values, we can even validate 3 input fields values during edit of one, and based on the result open tooltip with proper message. |
@tomkdgun I may be misunderstanding but the |
@emyarod When this issue was opened, open prop didn't work at all (controlled tooltip). We have found this on version 9.x. Later on we created simple example with buttons, which didn't work on both versions, 9.x and 10.x.
|
@tomkdgun that external I can backport the fix to v9 after we confirm the issue is resolved, just want to understand the issue first so I'm demoing in v10 with the netlify builds edit: the behavior appears to be identical in v9, as the component itself is unchanged |
The use case brought up (opening tooltip as user types something IIUC) makes me feel that definition tooltip or icon tooltip is more suitable for the use case. The usage scenario of the interactive tooltip is for letting user open the tooltip by user gesture. |
@emyarod I've updated https://codesandbox.io/embed/codesandbox-lo5ox, by adding the example with controlled tooltip around input. This is simplified example from our app, since open also dependent on value validation. Current behaviour:
|
Tooltip content(text) is empty in case of valid input, tooltip should be opened only in case of invalid value (controlled). Because of this issue (still handling clicks on controlled tooltip), user can open controlled tooltip, which in case of empty text results with sth like this: |
@tomkdgun the codesandbox example appears to be unchanged from the original example. were your changes saved? |
@emyarod Try this one: https://codesandbox.io/embed/codesandbox-jilyl |
I thought controlling the open state by |
@asudoh What in case when click on trigger is performed (input wrapped by tooltip) ? |
Skipping user interaction controlled case will be an interesting idea, will take a note. |
@asudoh @emyarod When fix will be ready and released ? It seems that some fix were prepared almost 2 weeks ago, which probably require some minor correction and tests on uncontrolled Tooltip, see #2849 (comment) |
As I stated, you don't have to wait for our fix - |
@asudoh Its difficult to apply this for 40, 200 or 400 places |
Latest netlify works well for my scenario (controlled one). Probably you need to just check if most common scenario (uncontrolled one) still works. Edit: Actually I've noticed that on netlify, under Tooltip component test, there are default one examples, which it seems doesn't work, probably because of things I've noticed under this comment #2849 (comment) |
@asudoh I've tried workaround you have suggested, with setTimeout. |
I don't quite understand what you wrote in your edit, can you elaborate on the issue? there should be an example of an uncontrolled tooltip and another example of a controlled tooltip right? and the |
@emyarod Yes, |
@tomkdgun |
@emyarod Can we talk on Slack ? https://w3.ibm.com/bluepages/profile.html?uid=P40065820 |
To shed some light on this topic; The reduced case in this issue description (https://codesandbox.io/embed/codesandbox-lo5ox) can be changed below way so the demo works: --- test.js.orig 2019-08-21 12:38:12.000000000 +0900
+++ test.js 2019-08-21 12:38:01.000000000 +0900
@@ -15,13 +15,13 @@
<div>
<Button
style={{ padding: "15px 20px", margin: "4px 20px" }}
- onClick={() => this.setState({ value: false })}
+ onClick={() => { setTimeout(() => { this.setState({ value: false }) }, 0); }}
>
Hide
</Button>
<Button
style={{ padding: "15px 20px", margin: "4px 20px" }}
- onClick={() => this.setState({ value: true })}
+ onClick={() => { setTimeout(() => { this.setState({ value: true }) }, 0); }}
>
Show
</Button> |
@asudoh On Buttons yes, but on input wrapped by Tooltip it doesn't, because clicks are perform on tooltip trigger, not outside, and there is not change in state and condition in parent component. |
|
@asudoh Jun 11: #2849 (comment) |
reopening for v9 |
since this fix actually requires a breaking change, it isn't suited for backporting to previous versions |
Tooltip - unable to control using open props
What package(s) are you using?
Same happens also for version 6.x:
carbon-components
carbon-components-react
Detailed description
Unable to control visibility state of the Tooltip (open/close), using already existing open prop. It could be easy observed using provided codesandbox.
Steps to reproduce the issue
Expected: Tooltip will react on change for open prop
Issue exists on both carbon-components-react versions 6.x and 7.x.
We are expecting a fix for version 6.x.
It's a blocking issue for us.
The text was updated successfully, but these errors were encountered: