-
-
Notifications
You must be signed in to change notification settings - Fork 9.4k
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
UI: Improve controls addon #23635
UI: Improve controls addon #23635
Conversation
No top level dependency changes detected. Learn more about Socket for GitHub ↗︎ |
👍 Dependency issues cleared. Learn more about Socket for GitHub ↗︎ This PR previously contained dependency changes with security issues that have been resolved, removed, or ignored. |
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'm experiencing some buggy behavior, as demonstrated here:
Area.mp4
- On page load (reload), the panel is in a loading state. ✅
- When switching to another addon panel and back to controls, the controls will be forever loading. ❌
- When switching to new stories that have never been rendered before, it won't show the loading state but briefly flash the empty state. ❌
- Navigating to previously rendered stories will show the controls right away without loading or empty-state ✅
- Non-ready controls will have the "Setup controls" link on hover. ✅
Number 2 is a deal breaker here, but I think 3 is okay for now.
Thanks @JReinhold. I'll look at these 2 use cases. |
As I side note, I'm pretty sure there are some research on the topic of loading states, suggesting that there are ideal timings for when to show them or not. Eg. in the first 0.3 seconds, a loading indicator is not necessary and will distract more than it does good, because of the brief flash. Unfortunately I can't find said research, or figure out what this ideal timing is. |
@JReinhold That's not the issue. We don't want to show the loading state when switching stories as it is indeed too short but today if the story is cached the switch will be instantaneous which is nice but for stories not cached you see briefly the empty state instead. But I might have an idea on how to solve this one. |
Controls.mp4@JReinhold I found a way to make 2 and 3 work so we never see the empty state if we don't need it. I added a delay to render the empty state. For now this is the only solution I believe without doing more refactoring or creating new states. |
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.
Minor feedback regarding your last changes
hideNoControlsWarning?: boolean; | ||
} | ||
|
||
export const ControlsPanel: FC = () => { | ||
const [isLoading, setIsLoading] = useState(true); |
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.
Minor suggestion here:
const [isLoading, setIsLoading] = useState(true); | |
const [isLoading, setIsLoading] = useState(!previewInitiated); |
It requires that you move this below useStorybookState()
.
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.
Thanks. I made the change.
useEffect(() => { | ||
if (previewInitialized) setIsLoading(false); | ||
}, [previewInitialized]); |
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'm honestly not sure what happens if you call setState
with the same state that it already has.
useEffect(() => { | |
if (previewInitialized) setIsLoading(false); | |
}, [previewInitialized]); | |
useEffect(() => { | |
if (previewInitialized && isLoading) setIsLoading(false); | |
}, [previewInitialized]); |
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.
As agreed let's not do that as we are at risk of creating an infinite loop in the useEffect.
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.
make sure to add isLoading and setIsLoading to the hook dependencies array too
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 agreed not to do that @yannbf. It's working without it.
@cdedreuille @JReinhold icons packages depends on very old svgr and svgo versions with many vulnerable or deprecated packages. And why it even depends on svgr? Isn't it a collection of prebuilt icons? |
@TrySound it should not depend on svgr. We are only using it to generate icons from Figma. |
So none of these dependencies are really needed? |
You’re right. We need to move them into devDependencies. |
Ref storybookjs/storybook#23635 (comment) Looks like all dependencies are build only and should not bloat user installation with deprecated and vulnerable packages.
if (!control || control.disable) | ||
return isHovered ? ( | ||
<Link | ||
href="https://storybook.js.org/docs/react/essentials/controls" | ||
target="_blank" | ||
withArrow | ||
> | ||
Setup controls | ||
</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.
@cdedreuille @JReinhold Can we find a way to make this Link optional? When rendering action props (aka: onChange, onClick, etc.) they have no control, but they're handled by the actions addon. With this change, even though their control should be empty, we render the link on hover.
I have other examples beyond just action props, but ideally I would like to globally disable any "Setup controls" links with a parameter or something similar.
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.
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.
@MWhite-22 Thanks for your feedback. I see what you mean but I'm not sure why this links is a problem. Are you using the controls as a tool or as a way to show what props you can edit?
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 use storybook as public interactive docs for our component library.
The default behavior of rendering the link on hover makes it look like our docs are not completed, and we like to be incredibly thorough.
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.
Is there a link I can look at? Generally speaking, I think there's a clear distinction between docs and controls. Docs are specifically meant to document your components where controls is more about testing. But I can understand that some users like you can use controls as a way to document your stories. I'll try to think if there's a way to achieve what you need without docs.
What I did
In this PR I am improve how controls look when the story is loading and when the story doesn't have args set up. Today we are showing a yellow warning banner in both cases. This is not ideal and could be considered as a bug even though you sometimes don't need args. We are turning the narrative to make the message more descriptive of what controls are with clear links on how to get started.
This PR also includes:
Select
,Input
in the experimental component libraryIcon
component (used in the empty state of theArgsTable
Link
component (Used in the Args Table)How to test
yarn storybook:ui
Checklist
MIGRATION.MD
Maintainers
ci:normal
,ci:merged
orci:daily
GH label to it to run a specific set of sandboxes. The particular set of sandboxes can be found incode/lib/cli/src/sandbox-templates.ts
["cleanup", "BREAKING CHANGE", "feature request", "bug", "build", "documentation", "maintenance", "dependencies", "other"]
🦋 Canary release
This PR does not have a canary release associated. You can request a canary release of this pull request by mentioning the
@storybookjs/core
team here.core team members can create a canary release here or locally with
gh workflow run --repo storybookjs/storybook canary-release-pr.yml --field pr=<PR_NUMBER>