Customizability of tooltip/popover/overlay

[jrmyio]

For some time I am using blueprint.js to handle tooltips, popovers and overlays. I love that it is written in typescript, I love the split into these 3 components and it's based on the great popper.js

However, in order to use these components as a general popover handler I have to manually patch the package to make them somewhat customizable. With blueprint.js 3 things got even worse. The popover component wraps your target into 2 additional elements? Having all these wrappers and additional elements on a simple <button/> seems gigantic overkill. Nowadays CSS uses a lot of direct child relationships to style (flexbox / grid) and wrapping elements breaks these styles.

Another problem is that the popover component is impossible to use with css-in-js libraries like styled components because you cannot specify the components that are being generated.

I am at the point of dropping the use of blueprint for popover related use-cases but before doing so I thought it would be fair to list down every single change I am doing with each release cycle to see if you are open to add this functionality by default.

Overlay
I am adding a "component" and "portalProps" in order to overwrite the default Portal component. When using styled components you want to be able to switch a component with a styled version of it. Portal props can be very handy to add attributes to the generated element.

Popover
I am adding "portalProps" and "portalComponent" to feed the overlay's properties from above.

I am adding "popoverProps" in order to add custom attributes to the popper.
I am adding "targetProps" to add custom props/attributes to the targetProps.
I am adding a "arrowRenderer" in order to customize the rendering of the arrow.

In BP3 there data-placement and data-x-out-of-boundaries are no longer there. I also added them manually because they are useful to make targeted CSS to these properties.

Tooltip
I am adding "tooltipProps" to feed the "popoverProps".
I pass along the "portalProps" , "portalComponent, "arrowRenderer.

With blueprint.js 3 it's impossible to pass "false" to wrapperTagName. Using React.Fragment throws an error because a class is set to this wrapper (not sure why this is needed or a wrapper is needed). I made an empty React component that returns a Fragment in order to ignore the classnames from being set.

I understand I might be trying to customize things that were never meant to be customized. Still I think as a component library having hooks to customize is very important in order to handle edge use-cases.

What do you think?

I am also interested on what your stance is on all these wrappers? Are they really required to make a tooltip/popover functionality?

It seems today https://atomiks.github.io/tippyjs/ released a https://github.com/atomiks/tippy.js-react and they seem to have no auto-generated wrappers whatsoever.

[giladgray]

@ConneXNL there is a lot here so let's see what I can do...

Styled components
We do not use styled-components at Palantir so I cannot offer support for it. We instead use typestyle (for CSS-in-JS) or CSS modules through webpack for encapsulation. If you can come up with a minimal set of changes to better support styled-components then I'd potentially be open to it.

Wrapper elements
Basically, one exists for React 15 support and the other for DOM encapsulation.

Tippy.js only supports React >= 16.3 so that's a straight up non-starter for us and allows them to use fragments to avoid wrapper elements. Blueprint cannot make this commitment so we cannot use fragments, hence the need for the wrapper element.

The target element is used to reliably attach DOM handlers without requiring the user-rendered target to explicitly support the full set of DOM events.

Supporting false for the wrapper in React 16 is a nice idea, definitely open to adding support for that. Submit a PR please.

Additional props
I'm open to adding more composition props. Feel free to submit individual PRs per component and we can discuss the proposals.

[amanbora]

@ConneXNL @giladgray I would like to contribute to this bug.

[giladgray]

@amanbora awesome! do you have thoughts on specific code changes to address this issue?

[amanbora]

@giladgray could you pls give some more specification/background of the problem?

[giladgray]

@amanbora I cannot offer any more general guidance than the comments above, which I think do a smashing job of explaining the issues (from @ConneXNL) and the technical reasoning from me. i'd be happy to answer specific questions (but I can't commit much time to this).