Rerender at initial position

[an4ger]

1. Create tooltip with delayShow={300} delayHide={300} place="top" options.
2. Move cursor to element with tooltip and wait for tooltip, it should appear not at the top position.
3. Quick move cursor from element with tooltip and back.

Result: tooltip try to render with bottom arrow as at top place (initial option) and after that appear at right position. So, we have some blinking effect.
If set delay to 5 seconds we have the same effect.

https://codesandbox.io/s/j70q5w7p1w

[smakosh]

I'm having the same issue when the tooltip should appear near the corner of the window

[an4ger]

Here some info after investigation:

mouseenter event trigger this function:

https://github.com/wwayne/react-tooltip/blob/c44cc2d0aa89b7e6268a61a277326be6903b00ae/src/index.js#L256

and than we call

https://github.com/wwayne/react-tooltip/blob/c44cc2d0aa89b7e6268a61a277326be6903b00ae/src/index.js#L404

here we have some problem:

 if (result.isNewState) {
      // Switch to reverse placement
      return this.setState(result.newState, () => {
        this.updatePosition()
      })
    }

in my case function updatePosition triggers 2 times:

• first time result.isNewState = true, because in showTooltip function we set desiredPlace in state every time on mouseenter and that desiredPlace not equal current available position;
• second time result.isNewState = false and all good;

So, it will be better to ignore first call of updatePosition function.

One of solution is to do some caching and try to set desiredPlace not from attribute but from last available place:
https://github.com/wwayne/react-tooltip/blob/c44cc2d0aa89b7e6268a61a277326be6903b00ae/src/index.js#L286

lets try to change it this way:

this.state.place || desiredPlace: e.currentTarget.getAttribute('data-place') || this.props.place || 'top',

Is it good idea? Any suggestions?

[P0lip]

Well, I didn't check it myself, yet I suppose you are right and updatePosition is called more than once.

The trick with desiredPlace may be a bit troublesome and may introduce new bugs, as it doesn't take into account any external changes that could affect the position of tooltip in the meantime.
By external changes, I mean window resize, page scroll or any other layout changes.
In your particular case, the item is always bound to the left top corner and always has a fixed position, so this would do the job, but in some other scenarios, it's not the case, unfortunately.

Examples:
I have a tooltip I want to display above the content. It's displayed below, because there is no enough space at the top of viewport. Once I scroll down, I have enough space and I can display it above.

I have a tooltip I want to display below the content. It's displayed above, because there is no enough space at the bottom of viewport. Once I scroll down, it should be displayed below. Instead, it's still displayed above and I can't see it fully as it's still stuck to the top of my screen, above the content.

Once again, I didn't test the change myself, so I may be totally wrong and the proposed solution may work like a charm.

I'd say that getPosition function should be refactored, as this is the pure source of error.
It should be produced the same results, since nothing on screen has changed, so the position of tooltip should be exactly the same for both calls.

[gris-martin]

The way getPosition works in regards to desiredPlace is altered slightly in #391 (if it gets merged). Not sure if it relates directly to this issue, but you should take a look and see if it makes sense.

[gris-martin]

I did some more research, and this issue doesn't have to do with updatePosition being called twice, but rather with setState being called (and thus the component rendered) before we know which orientation the tooltip should have:
https://github.com/wwayne/react-tooltip/blob/c44cc2d0aa89b7e6268a61a277326be6903b00ae/src/index.js#L283-L287
After the rendering, the orientation is then immediately updated to the correct one (and the component re-rendered) by a callback added in the same setState call. This callback calls the updateTooltip function, which in turn calls the updatePosition function.
https://github.com/wwayne/react-tooltip/blob/c44cc2d0aa89b7e6268a61a277326be6903b00ae/src/index.js#L304-L306

While the updatePosition function is called twice (through recursion), setState is actually called at most one time (unless something goes wrong) during the callback.
https://github.com/wwayne/react-tooltip/blob/c44cc2d0aa89b7e6268a61a277326be6903b00ae/src/index.js#L404-L418

I agree that updatePosition and getPosition should probably be reworked, but it's not the cause of this issue (unless I'm completely mistaken!).

EDIT: I did a quick fix in my fork (https://github.com/hassanbot/react-tooltip/commit/9b2c115f716d46289c0cb7655987870f5ae5e6ac), but it feels a little hacky so maybe someone has a better suggestion?

[aronhelser]

I feel like your solution is reasonable, and it seems like we don't have any other input. Should we go with it?

[an4ger]

@hassanbot can you make pull request with this fix?

[diachini]

@aronhelser I believe this issue (#388) can be closed (#413 just didn't have "close"/"closes" in it to do so automatically).