Change default label in <Tooltip /> #638
Conversation
|
Caution Review failedThe pull request is closed. WalkthroughThe Changes
Assessment against linked issues
Possibly related PRs
Suggested reviewers
Poem
Tip CodeRabbit's docstrings feature is now available as part of our Early Access Program! Simply use the command 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
src/components/ui/Tooltip/tests/Tooltip.test.tsx (1)
13-26: LGTM! Well-structured interaction test.The hover test is well implemented with:
- Clear test steps through comments
- Proper async handling
- Complete interaction cycle testing
Consider adding these additional test cases:
test('renders with different placement values', () => { render(<Tooltip label="label" placement="bottom">Hover me</Tooltip>); // ... verify placement }); test('spreads additional props to Tooltip', () => { render(<Tooltip label="label" data-testid="my-tooltip">Hover me</Tooltip>); expect(screen.getByTestId('my-tooltip')).toBeInTheDocument(); });
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/components/ui/Tooltip/Tooltip.tsx(1 hunks)src/components/ui/Tooltip/tests/Tooltip.test.tsx(1 hunks)
🔇 Additional comments (2)
src/components/ui/Tooltip/Tooltip.tsx (1)
25-25: LGTM! Good improvement in the component API.
Making the label prop required is a positive change as it:
- Prevents accidental empty/meaningless tooltips
- Makes the component's requirements more explicit
- Provides better TypeScript type safety
src/components/ui/Tooltip/tests/Tooltip.test.tsx (1)
7-11: LGTM! Good basic test coverage.
The initial render test effectively verifies that:
- The trigger element renders correctly
- The tooltip is hidden by default
|
@kotAPI @GoldGroove06 |
|
Yeah sure it requires clsx, nice catch |
| import userEvent from '@testing-library/user-event'; | ||
| import Tooltip from '../Tooltip'; | ||
|
|
||
| describe('Tooltip', () => { |
There was a problem hiding this comment.
awesome! great job on adding tests
following the above comment, let us treat label as an empty string
test for weird cases when say label is a number, boolean etc (you might have to write tests in js instead of ts for those tests)
There was a problem hiding this comment.
test for weird cases when say label is a number, boolean etc
Is this just because this is a public library and could be used in someone's JS project?
edit: and if so, shouldn't we be increasing the scope of label's type in TooltipProps to include other types in addition to string?
There was a problem hiding this comment.
Is this just because this is a public library and could be used in someone's JS project?
Correct, that's the goal here
There was a problem hiding this comment.
edit: and if so, shouldn't we be increasing the scope of
label's type inTooltipPropsto include other types in addition tostring?
No, so the label will always be a string, the component shouldn't crash and bring the entire app down when weird props are passed - we do the error handling inside the component so its smart enough to deal with such real life edge cases
There was a problem hiding this comment.
Ah then should I just be testing that the component renders the toooltip without any errors when non-string props are passed in?
There was a problem hiding this comment.
Ah then should I just be testing that the component renders the toooltip without any errors when non-string props are passed in?
correct, it shouldn't break the component - say when bool or integers are passed (this doesn't happen in ts projects, but its a risk in js projects)
|
@kotAPI just added the tests. Could you take a look at them? |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (1)
src/components/ui/Tooltip/tests/Tooltip.test.tsx (1)
6-11: Consider adding accessibility assertionsWhile the basic visibility tests are good, consider adding assertions for ARIA attributes and roles to ensure accessibility:
test('renders component', () => { render(<Tooltip label='label'>Hover me</Tooltip>); expect(screen.getByText('Hover me')).toBeInTheDocument(); expect(screen.queryByText('label')).not.toBeInTheDocument(); + // Verify accessibility attributes + const trigger = screen.getByText('Hover me'); + expect(trigger).toHaveAttribute('aria-describedby'); });
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/components/ui/Tooltip/Tooltip.tsx(2 hunks)src/components/ui/Tooltip/tests/Tooltip.test.tsx(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- src/components/ui/Tooltip/Tooltip.tsx
🔇 Additional comments (3)
src/components/ui/Tooltip/tests/Tooltip.test.tsx (3)
1-5: LGTM! Proper testing setup
The imports follow testing best practices using @testing-library/react and user-event for interaction testing.
14-27: LGTM! Comprehensive hover interaction testing
The test thoroughly covers the tooltip's visibility lifecycle with clear, descriptive comments.
29-42: LGTM! Good accessibility testing
Excellent use of role selectors for testing empty label case, which aligns with accessibility best practices.
| test('renders tooltip when label is of an invalid type', async() => { | ||
| // @ts-expect-error: label should be a string | ||
| expect(() => render(<Tooltip label={42}>Hover me</Tooltip>)).not.toThrow(); | ||
|
|
||
| // @ts-expect-error:label should be a string | ||
| expect(() => render(<Tooltip label={true}>Hover me</Tooltip>)).not.toThrow(); | ||
|
|
||
| // @ts-expect-error: label should be a string | ||
| expect(() => render(<Tooltip label={null}>Hover me</Tooltip>)).not.toThrow(); | ||
| }); |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Enhance invalid type testing
While the current tests verify that the component doesn't throw errors with invalid types, they should also verify the rendered content:
test('renders tooltip when label is of an invalid type', async() => {
// @ts-expect-error: label should be a string
- expect(() => render(<Tooltip label={42}>Hover me</Tooltip>)).not.toThrow();
+ const { getByText } = render(<Tooltip label={42}>Hover me</Tooltip>);
+ const trigger = getByText('Hover me');
+ await userEvent.hover(trigger);
+ // Verify that number is converted to string
+ expect(screen.getByText('42')).toBeInTheDocument();
// @ts-expect-error:label should be a string
- expect(() => render(<Tooltip label={true}>Hover me</Tooltip>)).not.toThrow();
+ const { getByText } = render(<Tooltip label={true}>Hover me</Tooltip>);
+ const trigger = getByText('Hover me');
+ await userEvent.hover(trigger);
+ // Verify that boolean is converted to string
+ expect(screen.getByText('true')).toBeInTheDocument();
// @ts-expect-error: label should be a string
- expect(() => render(<Tooltip label={null}>Hover me</Tooltip>)).not.toThrow();
+ const { getByText } = render(<Tooltip label={null}>Hover me</Tooltip>);
+ const trigger = getByText('Hover me');
+ await userEvent.hover(trigger);
+ // Verify empty tooltip is rendered for null
+ expect(screen.getByRole('dialog')).toBeEmptyDOMElement();
});Committable suggestion skipped: line range outside the PR's diff.
There was a problem hiding this comment.
The second expect won't pass but that's not a bad suggestion tbh
There was a problem hiding this comment.
@chromium-52, understood. Thank you for your feedback.
There was a problem hiding this comment.
Oh I didn't think you'd respond lol
There was a problem hiding this comment.
@chromium-52 I'm always here to help! Let me know if there's anything else I can assist you with.
There was a problem hiding this comment.
Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!
chromium-52
changed the title
kotAPI
added
the
automerge
3 participants
Purpose
Fixes #629
This PR
Changes the default
hellolabel to an empty string for the tooltip component.Adds tests for the tooltip component.
Summary by CodeRabbit
Summary by CodeRabbit
labelprop for theTooltipcomponent is now optional, with a default value of an empty string.Tooltipcomponent when no label is provided or when the label is of an invalid type.Tooltipcomponent to validate rendering and interaction behavior, including hover visibility.