-
Notifications
You must be signed in to change notification settings - Fork 0
feat(Tooltip): Engineering guideline #429
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
base: main
Are you sure you want to change the base?
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
…ace.yaml, and package.json
…mbus Tooltip component.
export const LiveCodeEditor = (props: LiveCodeEditorProps) => { | ||
const [code, setCode] = useState(props.children); | ||
const [activeTab, setActiveTab] = useState<"preview" | "editor">("preview"); | ||
const [activeTab, setActiveTab] = useState<"preview" | "editor">( |
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 had to introduce this change since we agreed that for the engineering guideline, the code editor should be the default view.
|
||
Component Anatomy here - image with parts and description as can be seen on [combobox](https://www.figma.com/design/AvtPX6g7OGGCRvNlatGOIY/NIMBUS-design-system?node-id=5311-13804&p=f&m=dev) for example | ||
|
||
 |
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.
This is likely not relevant to this component but since this is almost like a Poc, I added it. The idea is the component anatomy image might not be necessary for simple components so it is optional.
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.
This is very valuable conceptually, especially for consumers who prefer to learn visually. I think it'd be worth including in every guideline
) | ||
``` | ||
|
||
```....Add example snippets for each relevant component prop``` |
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.
In react aria, the docs showcases a good number of the relevant props use cases with code snippets. Should we consider doing the same thing?
|
||
### API Reference | ||
|
||
<PropsTable id="Tooltip" /> |
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.
We still need a different topic to discuss how we would manually add props. The exposed props listing on the props table does not capture a lot of the important props.
| UI Kit Component | Nimbus Component | Notes | | ||
|------------------|------------------|-------| | ||
| `<Tooltip>` | `<Tooltip.Root>` + `<Tooltip.Content>` | Now uses compound component pattern | | ||
| `title` prop | `<Tooltip.Content>` children | Text content now goes as children | | ||
| `isOpen` prop | `isOpen` prop | ✅ Same API | | ||
| `onClose` | `onOpenChange` | ⚠️ Renamed, now receives boolean parameter | | ||
| `horizontalConstraint` | Not supported | ❌ Removed - use CSS or container sizing | |
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.
Beautiful. I cried. 10/10
- **Testing**: Include both providers in test wrapper | ||
- **Accessibility**: Built-in ARIA support, keyboard navigation included | ||
|
||
### Migration Checklist |
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.
This should calm some nerves - it may not ever be totally complete for every instance but that's a lovely idea.
|
||
Use the [Nimbus storybook Tooltip component story](https://nimbus-storybook-6l4m4g78g-commercetools.vercel.app/?path=/docs/components-tooltip-tooltip--docs) as a playground for visual testing of the component. | ||
|
||
#### 3. Regression tests |
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.
Anything in here?
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.
Its kind of a placeholder for now since we have not fully come up with a regression test strategy yet.
- `delay` and `closeDelay`: More granular control over timing | ||
- `horizontalConstraint`: Use CSS width constraints on content instead | ||
- `tone`: Styling is now handled through design tokens | ||
|
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.
For discussion: should there be a pitfalls/don'ts section for devs?
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.
Do you have any examples? Do the design guidelines suffice?
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 the design guideline does that already, but good point, I think we can have a note somewhere that states something like "for design guidelines, see [link]".
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.
This is absolutely what I would want. I know it will be a big lift to provide this for every component but this should make life so much easier 🙏
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 this is a great place to start. Are we going to look into tabs (one for design, dev, and migration) for the final product?
|
||
```....Add example snippets for each relevant component prop``` | ||
|
||
### API Changes |
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.
This section feels like it belongs in the migration guide
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.
Oh yes, I added it there too. I can take it out from here.
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.
Are we going to look into tabs (one for design, dev, and migration) for the final product?
Yes, I thinks we discussed exploring that possibility.
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 agree, this belongs in the migration guide
- `delay` and `closeDelay`: More granular control over timing | ||
- `horizontalConstraint`: Use CSS width constraints on content instead | ||
- `tone`: Styling is now handled through design tokens | ||
|
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.
Do you have any examples? Do the design guidelines suffice?
// Test wrapper with required providers | ||
const TestWrapper = ({ children }: { children: React.ReactNode }) => ( | ||
<IntlProvider locale="en" messages={{}} defaultLocale="en"> | ||
<NimbusProvider> | ||
{children} | ||
</NimbusProvider> | ||
</IntlProvider> | ||
); |
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.
Aren't we going to put NimbusProvider
into App Kit? One of Tobi's biggest complaints was this here pattern in tests.
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.
If we are doing that, then that would be great!
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.
Do you have any examples? Do the design guidelines suffice?
Yes, I think we can point to the guidelines here
```tsx | ||
<Tooltip.Root> | ||
<Button>Button</Button> | ||
<Tooltip.Content style={{ maxWidth: '200px' }}> |
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.
Forgive my ignorance, isn't one of the main benefits of Nimbus that we can put styles directly on our components like maxWidth="200px"
?
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.
No, forgive my ignorance actually 😅
You are correct!
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 made some updates here to handle most of the feedback 27715fe
Thank you.
…mentation - Adjusted JSX formatting in tooltip examples for consistency. - Updated migration guide to clarify usage of `maxWidth` property in Tooltip.Content. - Added caution note regarding provider availability in testing setups.
This PR provides a sample template or what we can call an initial draft to building a workflow for our Nimbus component developer docs / Engineering guideline. It should serve as a base where as much feedback as possible is provided until we arrive at a satisfactory template that other components can build upon.