Closed dlindenkreuz closed 6 years ago
@dlindenkreuz Great find and reporting, thanks! The reason we wrap is to support ref
access. We did not do that before because we used ReactDOM.findDOMNode
.
Options:
findDOMNode
I think option 1 above is the best path forward. A case of not using ref to keep the API simple for consumers is worthwhile IMO. I don't see any downsides currently other than going against the best practice, but again this is a reasonable exception.
Once I get repo permissions back I'm going to mark this issue as a bug as it breaks previous behaviour in an unexpected way.
@dlindenkreuz Thanks for reporting! Try 0.5.3
that I just published. The solution uses findDOMNode
so as a consumer it should JustWork (tm) for you.
Sweet, thx for the quick fix!
Since 0.5.x, react-popover does not work anymore with a
<path>
or any other SVG element astarget
(astonishingly enough, it did before).From now on, react-popover adds a
<div>
wrapper around its target which breaks the SVG layout.Internally, react-popover attaches a ref to the wrapper div. It would be unfeasible to attach the ref directly to
<Popover>
's children usingReact.cloneElement
becausecloneElement
preserves existing refs.The only easy solution I can see right now is to introduce an optional prop that allows specifying a wrapper element type (string). People with SVG usage scenarios would then use
g
, everyone else usesdiv
by default.<Popover wrapperElementType="g">
Thoughts?