-
Notifications
You must be signed in to change notification settings - Fork 144
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
feat(tooltip): implement tooltip to beta phase #882
Conversation
🦋 Changeset detectedLatest commit: d401c37 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
commit:
|
hover={true} | ||
bind:anchor={triggerRef} | ||
floating={placement} | ||
id={localId} |
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.
Where should localId
actually go?
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.
localId is the "same id" across the headless component. it's usually for when you have 1:1 components. Such as one trigger, one input, one root, etc.
Then you can prefix these in any file with a new variable:
const inputId = `${context.localId}-input`
And the component knows you are referring to that instances input, as long as the id
prop is passed to the input JSX
68dab4e
to
ad7e538
Compare
@thejackshelton , implemented |
const placements = ['top', 'right', 'bottom', 'left'] as const; | ||
|
||
test.describe('Tooltip Placements', () => { | ||
placements.forEach((placement) => { |
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.
sometimes generated tests from a loop are harder to debug
An alternative approach is to encapsulate all of the setup in a dedicated setup function for this test (for example, everything until line 92 and just create this test 4 time and call the "custom setup" function with a param for the placement.
It's not a must, but it might be easier to debug if we'll run into issues in the future.
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 refactored some helpers into the driver split out the different cases.
Great job @cwoolum ! 👏 Left one comment, other than that, LGTM! 🙏 |
What is it?
Why is it needed?
Implements #853
Checklist:
pnpm change
and documented my changes