-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[popover2] feat: new prop targetProps #5802
[popover2] feat: new prop targetProps #5802
Conversation
packages/popover2/src/popover2.tsx
Outdated
let target: JSX.Element | undefined; | ||
|
||
if (renderTarget !== undefined) { | ||
target = renderTarget({ | ||
...targetProps, | ||
className: classNames(targetProps.className, targetModifierClasses), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
since we apply the fill class to the child target when renderTarget isn't defined, I figured we should apply this class to the custom target as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR @bvandercar-vt. This enhancement makes sense to me, especially after doing a bunch of Popover2 migrations of our internal code. When I initially designed Popover2, I figured most target customizations should happen via renderTarget
, and that would be sufficient, but I now realize that it's a lot better from a developer experience perspective if we allow minor modifications to target element attributes through a new prop like this.
One use case I imagine this will be useful for is something like:
<Popover2 targetProps={{ style: { /* absolute positioning */ } }}>
On naming... to avoid potential confusion/conflation with "wrapper" terminology from Popover "v1", and because the existing prop which customizes the .bp4-popover-target
element is named targetTagName
(rather than targetWrapperTagName
), I think this should be called targetProps
.
* | ||
* This prop is mutually exclusive with the `renderTarget` API. | ||
*/ | ||
targetWrapperProps?: React.HTMLProps<HTMLSpanElement> | React.HTMLProps<HTMLDivElement>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
targetWrapperProps?: React.HTMLProps<HTMLSpanElement> | React.HTMLProps<HTMLDivElement>; | |
targetProps?: TProps; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK done, please review.
In the case of a renderTarget
, targetProps
props will also be appliedto the renderTarget
, so I made the warning basically say that they will be applied, but that it doesn't really make sense to do it that way vs. just applying them in your renderTarget
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@adidahiya I'm not sure why CI is failing, is TProps
not the best type for targetProps
here maybe?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TProps
is the correct type to use here, but adding this constraint exposed some type issues with the way I had designed Popover2. It required adding a stricter typedef to validateProps
, which further exposed some complex issues with the renderTarget
API and the inferred value of TProps
. I think I've solved those issues in the commits I just pushed to this branch.
Co-authored-by: Adi Dahiya <adi.dahiya14@gmail.com>
…vt/blueprint into popover2wrapperprops
I've updated your PR to no longer inject |
@bvandercar-vt this is nearly good to go, I just need to test it out locally to see if it breaks anything downstream... stay tuned, I'll try to get this in for the release I'm cutting today |
This change seems to work well downstream for the class MyComponent extends React.PureComponent {
public render() {
return (
- <Popover2<React.HTMLProps<HTMLDivElement>>
+ <Popover2
renderTarget={this.renderTarget}
content="content"
/>
);
}
private renderTarget = ({
isOpen,
ref,
...targetProps
- }: Popover2TargetProps & React.HTMLProps<HTMLDivElement>) => {
+ }: Popover2TargetProps & Popover2ClickTargetHandlers) => {
return (
<div
ref={ref}
{...targetProps}
/>
);
};
} |
Fixes #0000
Checklist
Changes proposed in this pull request:
Allow
targetProps
to be passed to popover2 that get passed to thespan
wrapper of the popover target.Mutually exclusive with
renderTarget
, sincerenderTarget
doesn't get wrapped.With existing functionality, this could still be accomplished by specifying a custom
renderTarget
that wraps their child in aspan
, ie before:after:
But with this proposed change, one could do:
So, for us, this isn't an "essential" change, since we can accomplish the same with
renderTarget
-- but I wanted to propose it to the Blueprint team.