-
Notifications
You must be signed in to change notification settings - Fork 376
fix(Truncate): remove resize observer #12055
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
fix(Truncate): remove resize observer #12055
Conversation
|
Preview: https://pf-react-pr-12055.surge.sh A11y report: https://pf-react-pr-12055-a11y.surge.sh |
0104b5a to
ec5e337
Compare
|
I'd want to make sure that #11811 still works - noting this down so I don't forget when I come back to review this. |
ec5e337 to
c047af3
Compare
thatblindgeye
left a comment
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.
One issue with this update is that the truncate always has a tabindex of 0 now, when it should really only have that when truncation is actually in effect. Otherwise potentially a lot of static text that isn't truncated will just add an equal amount of unneccessary tab stops to the page.
|
@thatblindgeye - looks like i can set isTruncated to |
I think both are important, though I don't know which (if either) is more important. That's probably a lengthier discussion. @christianvogt for your use case, are you taking advantage of the resizability of the Truncate component, i.e. whether the content is actually truncated or not can change depending on the viewport width or the content can be of varying length? Or is it pretty reliable that wherever Truncate is being used things will always be Truncated or always not be Truncated (like in a Table column that is always fairly narrow)? Mainly asking because if it's the latter - and assuming using the maxCharsDisplayed prop isn't viable - I wonder if adding a prop to dictate whether the resize observer is even used would be useful (or debouncing the resize observer). |
|
I believe when I created the original issue it was because the component was unmounting and remounting needlessly. Secondary after looking into the code I made the comment about performance and the potential to omit the resize handler. However I didn't consider the tab index case. For our use case I would still like the text react to container size. |
thatblindgeye
left a comment
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.
After having a quick discussion on Slack, we should update this to keep the resizeObserver, and instead within Truncate import our debounce helper and debounce the handleResize being passed to the getResizeObserver.
kmcfaul
left a comment
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.
lgtm with the resizeObserver + debounce
- @patternfly/react-code-editor@6.4.0-prerelease.3 - @patternfly/react-core@6.4.0-prerelease.3 - @patternfly/react-docs@7.4.0-prerelease.4 - @patternfly/react-drag-drop@6.4.0-prerelease.3 - demo-app-ts@6.0.0-prerelease.163 - @patternfly/react-table@6.4.0-prerelease.4 - @patternfly/react-templates@6.4.0-prerelease.3
Signed-off-by: gitdallas <5322142+gitdallas@users.noreply.github.com>
Signed-off-by: gitdallas <5322142+gitdallas@users.noreply.github.com>
Signed-off-by: gitdallas <5322142+gitdallas@users.noreply.github.com>
Signed-off-by: gitdallas <5322142+gitdallas@users.noreply.github.com>
Signed-off-by: gitdallas <5322142+gitdallas@users.noreply.github.com>
f33716f to
e0b9d9d
Compare
|
Looks like #11811 still works, woo! |
| }); | ||
| }); | ||
|
|
||
| test('Tooltip appears on keyboard focus when external triggerRef is provided (ClipboardCopy regression test)', () => { |
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.
| ); | ||
|
|
||
| // Simulate keyboard focus on the external trigger element | ||
| fireEvent.focus(mockTriggerRef.current); |
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.
Could we instead import userEvent and utilize that to handle the focusing in this test?
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 think fireEvent might actually be right here as it's how it would come into the Truncate component, rather than being a full integration test. currently the mockTriggerRef isn't actually rendered as part of the DOM to tab to. could update the .current and check, but now i'm thinking maybe that would be better tested in the clipboardcopy
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.
Yeah maybe worth trying to see if wew can put this sort of test in ClipboardCopy, though having it live in Truncate could make sense if we were ever to use it in other components in the same way we are in ClipboardCopy.
Not a blocker for me, otherwise things lgtm here
thatblindgeye
left a comment
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.
Above isn't a blocker to me, depending if we'd want to try quickly moving the new test to ClipboardCopy I'm good with things as-is
|
@thatblindgeye added a clipboardcopy/truncate integration test.. separate file as i was having trouble not using the mock in the existing 😆 |
|
|
||
| // This test file uses the real Truncate component for integration testing, instead of a mock | ||
|
|
||
| describe('ClipboardCopy Truncate Integration', () => { |
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.
Nit: It feels weird to wrap a single test in a describe block?
| import userEvent from '@testing-library/user-event'; | ||
| import { ClipboardCopy, ClipboardCopyVariant } from '../ClipboardCopy'; | ||
|
|
||
| // This test file uses the real Truncate component for integration testing, instead of a mock |
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.
It also feels weird in general having this test of ClipboardCopy integration for a change that we're making in Truncate 🤔
That being said I don't dislike this test, and I don't know better way of doing it after some quick poking around, so I won't block over it.
Signed-off-by: gitdallas <5322142+gitdallas@users.noreply.github.com>
9d7e85f to
a07e291
Compare

What: Closes #10974