Hoverable Component refactor #31518
Hoverable Component refactor #31518
Conversation
|
TODO:
|
There is no feature that would solve the issue, so we will stick to current |
kacper-mikolajczak
changed the title
|
According to discussion held on Slack, we decided to refactor rest of the functionality after the upgrade to new arch. |
|
@ Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button] |
|
Hi @mountiny, I think Melvin did not mention anyone - is it due to the fact that no actual GH issue is linked (just Slack discussion)? Thanks for help! 👍 |
|
@cubuspl42 Can you please give this one a good test on various platforms? thanks! |
|
Hi @cubuspl42 👋 Let me know if we are ready to move forward 👍 |
Reviewer Checklist
Screenshots/VideosWebhoverable-component-web.mp4Mobile Web - Chromehoverable-component-android-web-compressed.mp4Mobile Web - Safarihoverable-component-ios-web.mp4Desktophoverable-component-desktop.mp4iOShoverable-component-ios.mp4Androidhoverable-component-android-compressed.mp4 |
There was a problem hiding this comment.
Looking good I am not TS master yet, @roryabraham would you want to review this too?
Co-authored-by: Vit Horacek <36083550+mountiny@users.noreply.github.com>
src/components/Hoverable/index.tsx
Outdated
| return React.cloneElement(child, { | ||
| ref: hijackRef, | ||
| }); | ||
| function Hoverable({disabled, ...props}: HoverableProps, ref: Ref<HTMLElement>) { |
There was a problem hiding this comment.
NABish but this prop should be isDisabled:
| function Hoverable({disabled, ...props}: HoverableProps, ref: Ref<HTMLElement>) { | |
| function Hoverable({isDisabled, ...props}: HoverableProps, ref: Ref<HTMLElement>) { |
| ); | ||
|
|
||
| // Expose inner ref to parent through outerRef. This enable us to use ref both in parent and child. | ||
| useImperativeHandle<HTMLElement | null, HTMLElement | null>(outerRef, () => elementRef.current, []); |
There was a problem hiding this comment.
Why useImperativeHandle instead of forwardRef?
There was a problem hiding this comment.
Hi @roryabraham, in this case we use both. useImperativeHandle is there to let us access forwarded ref at the Hoverable level. As you can see, it basically passes elementRef (local useRef for holding the HTML element ref) to the outerRef (parent's scope).
Without using useImperativeHandle we could not forward the ref and at the same time have it accessible in the Hoverable (techincally we could, but that would mean hacking around with refs, while this hook hides it behind the abstraction).
Here is an example of BaseTooltip component (noise removed for brevity):
{/* Requires an HTML element ref from the direct children */}
<BoundsObserver>
{/* Thus we need to forward the ref through Hoverable to the button,
while still being able to access it inside Hoverable for the onBlur handler */}
<Hoverable>
<button>Click me</button>
</Hoverable>
</BoundsObserver>Hope that helps!
There was a problem hiding this comment.
If BoundsObserver is the single reason we have to do the "tricky stuff", we can consider changing the BoundsObserver implementation. But I don't have any specific idea.
The relevant line in BoundsObserver is probably this one.
There was a problem hiding this comment.
Requires an HTML element ref from the direct children
Yes, it requires its direct child to be "compatible" with this method of retrieving the HTML element.
There was a problem hiding this comment.
Thank you for additional insight @cubuspl42! In my opinion, the current flow, even if not clear at the first sight, is well suited for such task.
|
Looks pretty good, just had a few questions. The main thing is I don't understand why we need to do |
Thanks for the review 👍 Let me know if I answered your question here |
|
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
|
🚀 Deployed to staging by https://github.com/roryabraham in version: 1.4.7-0 🚀
|
|
We reverted this PR because it caused this blocker #32379 |
|
🚀 Deployed to production by https://github.com/yuwenmemon in version: 1.4.7-4 🚀
|
Acknowledged, thanks. We'll start working on a follow-up. |
|
Hi folks! Thanks for reverting the PR 👍 In the PR thread, I posted a quick explanation of what is the issue and what are possible ways to overcome it. Feel free to join the discussion - link to the comment |
Based on the proposal, we are trying to simplify how
Hoverablecomponent flow is defined.Details
Fixed Issues
$ #32096
Tests
Offline tests
N/A
QA Steps
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectiontoggleReportand notonIconClick)myBool && <MyComponent />.src/languages/*files and using the translation methodWaiting for Copylabel for a copy review on the original GH to get the correct copy.STYLE.md) were followedAvatar, I verified the components usingAvatarare working as expected)/** comment above it */thisproperly so there are no scoping issues (i.e. foronClick={this.submit}the methodthis.submitshould be bound tothisin the constructor)thisare necessary to be bound (i.e. avoidthis.submit = this.submit.bind(this);ifthis.submitis never passed to a component event handler likeonClick)StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG))Avataris modified, I verified thatAvataris working as expected in all cases)ScrollViewcomponent to make it scrollable when more elements are added to the page.mainbranch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTeststeps.Screenshots/Videos
Android: Native
android.mp4
Android: mWeb Chrome
mandroid.mp4
iOS: Native
ios.mp4
iOS: mWeb Safari
mios.mp4
MacOS: Chrome / Safari
web.mp4
MacOS: Desktop
desktop.mp4