-
Notifications
You must be signed in to change notification settings - Fork 205
[ARGG-1157][BpkTooltip]: Migrate tooltip to floating-ui #3485
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
Conversation
Visit https://backpack.github.io/storybook-prs/3485 to see this build running in a browser. |
1 similar comment
Visit https://backpack.github.io/storybook-prs/3485 to see this build running in a browser. |
Browser supportIf this is a visual change, make sure you've tested it in multiple browsers. |
Visit https://backpack.github.io/storybook-prs/3485 to see this build running in a browser. |
1 similar comment
Visit https://backpack.github.io/storybook-prs/3485 to see this build running in a browser. |
dbb5c17
to
35587fb
Compare
Visit https://backpack.github.io/storybook-prs/3485 to see this build running in a browser. |
35587fb
to
1b0b280
Compare
Visit https://backpack.github.io/storybook-prs/3485 to see this build running in a browser. |
1b0b280
to
6ec9e40
Compare
Visit https://backpack.github.io/storybook-prs/3485 to see this build running in a browser. |
3 similar comments
Visit https://backpack.github.io/storybook-prs/3485 to see this build running in a browser. |
Visit https://backpack.github.io/storybook-prs/3485 to see this build running in a browser. |
Visit https://backpack.github.io/storybook-prs/3485 to see this build running in a browser. |
*/ | ||
ariaLabel: string; | ||
/** | ||
* "target" should be a DOM element with a "ref" attached to it. |
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.
is that still the case?
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.
Yes this is still the case, we will still want people to pass through a ReactElement and not a function like document.getElementById
which is what the popover did, but the tooltip was never built to support that only
<div>
My target
</div>
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.
I mean the ref
part with a "ref" attached to it.
. I see we're using floating ui to set the ref so I don't think the consumer has to? https://github.com/Skyscanner/backpack/pull/3485/files#diff-2702cb346943a8761bb30c82e1a61efeae40297ed8cee8028da4376b719dc73cR132-R138
Also interesting that you can clone an element and attach a ref to it 😮 I think that's new-ish, I think a few years ago it was not possible
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.
Ah gotcha! Let me do a test with removing that target ref and see what magic happens!
Also interesting that you can clone an element and attach a ref to it 😮 I think that's new-ish, I think a few years ago it was not possible
Interesting didn't realise it was a newer feature! I guess it is just a property to a DOM element so is easy to add this prop as any other?
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.
Ah gotcha! Let me do a test with removing that target ref and see what magic happens!
Cool, have you checked that?
Interesting didn't realise it was a newer feature! I guess it is just a property to a DOM element so is easy to add this prop as any other?
Yeah, I remember it wasn't possible before, but not sure why 🤔
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.
Had a check and yes ref
can be removed so will update the PR now
Visit https://backpack.github.io/storybook-prs/3485 to see this build running in a browser. |
2 similar comments
Visit https://backpack.github.io/storybook-prs/3485 to see this build running in a browser. |
Visit https://backpack.github.io/storybook-prs/3485 to see this build running in a browser. |
Visit https://backpack.github.io/storybook-prs/3485 to see this build running in a browser. |
2 similar comments
Visit https://backpack.github.io/storybook-prs/3485 to see this build running in a browser. |
Visit https://backpack.github.io/storybook-prs/3485 to see this build running in a browser. |
@olliecurtis Are we still doing this, or can we close it? |
Yep we still want to be doing this and its still a valid PR just needs review 😄 as popperjs is deprecated and no longer supported c.c. @anambl |
Visit https://backpack.github.io/storybook-prs/3485 to see this build running in a browser. |
Awesome! There was a conversation here and a question from me - not sure if you've had a look at that? The reason I asked it is because I remember adding those changes and making the ref required, but not sure if it's still needed with the new library. Also as we now have a release schedule in place, we won't be able to just merge as is. I think that given this PR was created before we implemented the release schedule, we have 2 options:
|
Will check out the comment and remind myself on whats going on there to respond to you!
I can check the numbers but from my memory this should work with backwards compatibility and not require too much rework from a consumer, as this was done to manage the impact the same as the BpkPopover when we did the same migration as we didn't want to interfer with the flow but also need to migrate from this unsupported library as it introduces a security risk now |
Visit https://backpack.github.io/storybook-prs/3485 to see this build running in a browser. |
1 similar comment
Visit https://backpack.github.io/storybook-prs/3485 to see this build running in a browser. |
b93e93a
to
a486065
Compare
Visit https://backpack.github.io/storybook-prs/3485 to see this build running in a browser. |
@anambl I did checking on the changes in my PR and how consumers use it and the impact to this is that it still works as previous :) as the changes here are removing the |
Visit https://backpack.github.io/storybook-prs/3485 to see this build running in a browser. |
1 similar comment
Visit https://backpack.github.io/storybook-prs/3485 to see this build running in a browser. |
Visit https://backpack.github.io/storybook-prs/3485 to see this build running in a browser. |
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.
Work well in my local, LGTM
role: 'tooltip', | ||
ref: refs.setReference, | ||
...getReferenceProps(), | ||
}); |
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.
ref={arrowRef} | ||
context={context} | ||
id={ARROW_ID} | ||
className={arrowClassNames} |
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.
I just thought we could use the width
, height
, and fill
of the FloatingArrow
directly so that we don't need arrowClassNames
.
https://floating-ui.com/docs/floatingarrow#height
but unfortunately, in backpack-foundations, it doesn't export spacing token (sm, md,xl ...) .
So i think using arrowClassNames
is ok
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.
I tried using these directly but they had issues with actually styling the arrow and broke the styling of it, so this approach was chosen to ensure the arrow could match the style and colour of the box :)
Hi @olliecurtis late to the party :( It's one of the things reported (multiple times) on the recent Accessibility audit :D It seems that floating UI does support this, is this simple enough to add to our implementation? |
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.
Copilot reviewed 9 out of 12 changed files in this pull request and generated 1 comment.
Files not reviewed (3)
- packages/bpk-component-tooltip/src/BpkTooltip.module.scss: Language not supported
- packages/bpk-component-tooltip/src/snapshots/BpkTooltip-test.tsx.snap: Language not supported
- packages/bpk-component-tooltip/src/snapshots/BpkTooltipPortal-test.tsx.snap: Language not supported
role, | ||
]); | ||
|
||
const targetWithAccessibilityProps = cloneElement(target, { |
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.
The target element is being assigned a role of 'tooltip', but according to ARIA guidelines the tooltip container (not the target) should have role 'tooltip'. Consider removing the role from the target and instead use aria-describedby on the target to reference the tooltip content.
Copilot is powered by AI, so mistakes are possible. Review output carefully before use.
I can take a look here! I guess for an interaction such as this, this is where we would advocate for using the If we decide to add this functionality, can we possibly defer that to a separate minor PR to add functionality so we don't block this going in during the current major cycle and its becomes a year (total time since open) before this is closed off? I can quickly spin that PR up once this one goes through so its not forgotten about and still goes in swiftly |
}: TooltipProps) => { | ||
const classNames = getClassName('bpk-tooltip', className); | ||
}: Props) => { | ||
const [isOpenState, setIsOpenState] = useState(isOpen); |
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.
Not blocker:
Hi @olliecurtis, I noticed that you introduced the FloatingPortal
and the isOpen
property to manage its state. This made me think about the controlled mode of BpkTooltip
and its related code.
In theory, BpkTooltip
should not be used in situations where the parent component controls whether it is open or closed. Allowing this might lead to scenarios where the isOpen
state does not change when the FloatingPortal
unmounts in certain situations. Have we stated this somewhere? 🤔
I'm not quite sure if it is used in the right way by consumers. I have worked on an experimental feature named CE Budget filter which used a BpkPopover(similar implementation, we got that implementation from another squad due to a feature ownership change) and met this question. I know that's not the right way to use it. I feel like we need to highlight that to designers and engineers.
Hi @gert-janvercauteren for this comment, can we make it to the later PR? This PR is more focused on the core code migration. |
Made an offline chat. The functionality mentioned in Gert's comments is missing from the original component. That's not a blocker of this PR. That would be introduced in later PR. |
Visit https://backpack.github.io/storybook-prs/3485 to see this build running in a browser. |
Migrating the underlying library of the
BpkTooltip
to use the maintainers replacement libraryfloating-ui
, a much more lightweight library and has a lot of functionality built in that means we can remove our use of custom built react Portals!This is one PR of a few to update components away from popperjs to floating-ui so can be used as a base!
Changes here are as follows:
TooltipPortal
, as we no longer need to use our custom React Portal implementation as this is handled via floating-uirenderTarget
prop as this is longer needed to apply where in the DOM the tooltip should be and is located byfloating-ui
relative to the targetportalStyle
andportalClassName
as these are no longer required as we aren't using a custom portalpopperModifiers
property as these no longer have an effect on the componentclassName
property to prevent overriding of componentMigration guide:
The main changes for this component is removing properties that have minor to no impact to the current functionality of the component.
So remove use of the following properties:
renderTarget
,portalStyle
,portalClassName
,popperModifiers
andclassName
.Should the design/style not be fit for purpose please align with design to make sure they use the component as expected before getting in touch.
Remember to include the following changes:
[KOA-123][BpkButton] Updating the colour
README.md
(If you have created a new component)README.md