Every time a tooltip is changed, render an updated version using the api introduced in this stack.
Depends on D6087
Details
Details
Tested a couple of scenarios including copying a message and then e.g. keeping the cursor on a tooltip, exiting a tooltip, entering a different message, changing threads, etc. Also tested clicking a copy button multiple times.
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Branch
- ENG-2332
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
| web/utils/tooltip-utils.js | ||
|---|---|---|
| 566–567 | Haven't found an easy way to unset these when we no longer need them. We could consider introducing on tooltip close callback and pass it to render tooltip, but I tried that previously and making it work safely might be intensive. The fact that we keep these set shouldn't affect the performance significantly. | |
| 577 | Saving this on mouse enter because this is the last thing independent of tooltip content. Other variables depend on it so after e.g. tooltip actions are changed, they are also likely to change. | |
| 630 | Flow thinks this is nullable here | |
| web/utils/tooltip-utils.js | ||
|---|---|---|
| 613 | Why do we need this? I'm not sure if I understand, but it looks like we recreate entire tooltip when internal state of one of the buttons changes. Shouldn't it happen automatically after successful state changes in useMessageCopyAction | |
| web/utils/tooltip-utils.js | ||
|---|---|---|
| 613 | I tried to explain this earlier in the stack in the summary of D6075. But basically, the flow is that we create tooltips based on props / state but then send them to the provider only on mouse enter. So even if the hooks rerender, it won't affect what the provider is rendering, because it received and saved a node that was rendered earlier. The mentioned diff contains a discussion about possible solution and calling update seems to be the best one so far. | |
| web/utils/tooltip-utils.js | ||
|---|---|---|
| 613 | Thanks for clarifying | |