bootstarted / flowtip Goto Github PK

Create a site (something like http://react-dnd.github.io/react-dnd/) to document and demo flowtip

There seems to be some incorrect scrolling calculations that happen with this, and different behaviour between Chrome and Safari. Originally part of #70.

On iOS devices, the screen.width and screen.height always return the values for portrait mode even when the device in is in landscape mode. As a result these calculations (https://github.com/qiushihe/flowtip/blob/master/src/dom.js#L123-L124) are off in this situation resulting in unexpected positioning.

This is noticeable on https://www.walmart.com on the account flyout in landscape mode. screen.width returns 768 even though the expected value would be 1024. As a result, the flyout appears to the left even though there is plenty of room underneath.

When the target is scrolled outside of the viewport and the tooltip is constrained to the edge of the window, Chrome's behavior of apparently debouncing window scroll events causes the tooltip position to shift around slightly as the user scrolls. This is a consequence of the absolute positioned tooltip being transformed to appear to be fixed to the viewport edge. This transform amount is never pixel accurate while scrolling.

A solution could be to detect when the edge constraint is active, and to switch the tooltip from absolute to fixed position, effectively detaching it from the page and properly attaching it to the viewport edge.

The simulated DOM used in jest tests isn't capable of providing the required layout information for flowtip to operate properly. (getBoundingClientRect and getComputedStyle are both stubbed to return constant mock results)

We need to set up in-browser tests (potentially using https://saucelabs.com/open-source) to create proper test coverage for flowtip-react-dom.

findDOMNode is slated for deprecation soon, and support in React 16 appears to be partially dropped already.

We currently rely on a custom findDOMNode function that will safely attempt to detect the rendered node using react fiber internals when necessary. This universally supports React 16 and earlier versions.

This isn't the best long-term solution since it relies on undocumented internals.

Dan recomments passing a ref handler prop down throug the component tree: jsx-eslint/eslint-plugin-react#678.

I'm not completely sold on this approach as it would complicate the consumer-facing interface. The provided content handler would need to manually pass a contentRef prop to its outermost element. Although this isn't too different from how the style prop is used.

Looking for ideas.