Sometimes it is useful to modify a tooltip while it is displayed. An example of this can be seen in this stack: when a message is successfully copied, a tooltip label has to bo modified.
Updating the tooltip is challenging in our architecture, because instead of simply rendering it as a part of the tree, we're creating it and sending to another component in order to be presented. So even if we decide to update the original node, the view won't be updated because only sending it (using renderTooltip function) affects what is displayed.
Fixing this issue completely would be great, so that our approach becomes more declarative instead of the current imperative approach. However, this will be time-consuming.
There are a couple of options to work around the issue. One which I considered was to call renderTooltip as an effect when a tooltip content should be changed. This almost works but is buggy due to a fact that a user might decide to move a pointer to a different message or outside of it - that would result in timeouts being created which reference the older content and synchronizing this is really complex. The root cause of it is that we're firing the effect when a tooltip changes, but it might change even after another tooltip was shown. We can introduce a close callback that is called when someone decides to show a new tooltip, but the timeouts complicate things a lot.
Another option might be a solution where MessageTooltip is modified directly. This causes a problem because we use labels as keys there and modifying any of it from outside isn't straight forward. Also, directly modifying MessageTooltip component would make the data flow really convoluted.
Yet another option was to return a symbol of created tooltip when we're rendering it. By having and comparing that we could avoid some issues from the first solution but the data flow would be still degraded.
The cleanest solution so far is presented in this diff. It is a modified version of the 3rd solution, but without exposing the symbol, which is an implementation detail, to the caller. This still isn't ideal, but without changing the approach to more declarative one, it should be hard to figure something significantly better.
Depends on D6074