Popup as the trigger prop.Get the popup when mousing over the trigger component.
Don't get a popup when mousing over the trigger component.
0.64.2 (master)
So it seems that trigger is injecting some props, as I've discovered by logging the props that TriggerComponent gets in this forked example.
I don't know where this behavior is documented, and I'd like to override at least one of those methods (onClick).
Because I'm effectively creating a wrapper out of Popup, how should my ignorant children components know to expect these props? Outside of boilerplate adding onBlur, onClick, etc. to every possible child component, I don't see how I could get consistent behavior.
I've chased this down to Popup creating a Portal and passing it's trigger prop through. Portal, then uses React.cloneElement to inject props 鈥撀爐his seems to make sense.
This is confounding though, because in the forked example above, I had to make use of onBlur, onClick, onFocus, onMouseEnter, and onMouseLeave in my TriggerComponent by consumping {...props}.
But in the example of what does work in my Testcase, the successful component doesn't consume any props.
So I might've gotten this to work using the Inheritance Inversion Higher Order Component technique (iiHOC).
Here is a working fork.
I realized that my components weren't handling props that were passed to them by Portal (namely, the onFocus etc. functions that I've mentioned above). That said, I couldn't figure out how the framework elements are using these props, either.
I'll leave this open so maybe someone can shed some additional light on what's going on and why I needed the iiHOC approach while the framework itself does not. Thanks.
I think I can answer the remaining question now. RSUI components use a function called getUnhandledProps (example for elements/Image) to capture those events (onBlur, onMouseEnter, etc.).
Those props are then passed to the ElementType component.
Effectively, this is the same approach as my first solution, above where I consume all props on Line 8.
It is best practice to consume handled props and pass the rest along, which is what is required for the trigger to work. Here is a fork that shows the necessary changes:
http://codepen.io/levithomason/pen/QdpvRm
-const TriggerComponent = () => (
- <span>Mouseover fails</span>
+const TriggerComponent = (props) => (
+ <span {...props}>Mouseover fails</span>
);
That said, this actually confused me at first as well. So, it is at the least unintuitive. I believe we can make this work for custom components that do not consume their props and pass the rest. I'll leave this issue open for that work.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 30 days if no further activity occurs. Thank you for your contributions.
StaleBot not really working as intended here... Or has this issue been resolved elsewhere?
@neutraali can you please create a new issue with a repro if you faced an issue that can't be fixed with this comment (https://github.com/Semantic-Org/Semantic-UI-React/issues/1187#issuecomment-273988903)?
Most helpful comment
It is best practice to consume handled props and pass the rest along, which is what is required for the trigger to work. Here is a fork that shows the necessary changes:
http://codepen.io/levithomason/pen/QdpvRm
That said, this actually confused me at first as well. So, it is at the least unintuitive. I believe we can make this work for custom components that do not consume their props and pass the rest. I'll leave this issue open for that work.