-
-
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
feat(storiesNav): deep theming for stories nav panel #6098
Conversation
b832752
to
90d641b
Compare
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.
@ndelangen Yeah this seems way verbose to me. @MansoorBashaBellary what's the minimum you'd want to be able to style to achieve your desired output? I think we should add 1-2 vars at most. |
Codecov Report
@@ Coverage Diff @@
## next #6098 +/- ##
==========================================
+ Coverage 37.11% 37.11% +<.01%
==========================================
Files 648 648
Lines 9523 9524 +1
Branches 1352 1352
==========================================
+ Hits 3534 3535 +1
Misses 5410 5410
Partials 579 579
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@
## next #6098 +/- ##
=======================================
Coverage ? 37.11%
=======================================
Files ? 648
Lines ? 9524
Branches ? 1352
=======================================
Hits ? 3535
Misses ? 5410
Partials ? 579
Continue to review full report at Codecov.
|
@shilman - These are the minimum things that i could think off to get the desired output. What i can do instead is to wrap all the variables in
But the only thing is in |
90d641b
to
0ec9773
Compare
@MansoorBashaBellary I totally understand the request for more customization. I was planning to enable this using addons. I'm still unsure how much theming to allow. On 1 hand I want users to be able to create the storybook of their dreams, but on the other hand, we don't want to have hundreds of theme variables, that we'll have to keep sane and compatible. |
@ndelangen I think this adds more complexity and maintenance surface area for the UI code so I'd prefer to leave it mostly the same. Storybook helps you build UIs, theming is an aesthetic choice that doesn't really contribute or detract from that value prop. I think we should keep the theming API as minimal as possible, that way maintainers can focus on building new functionality instead of maintaining support for theming edge cases into the future. (Background: I worked on theming support with Norbert) |
Thanks @ndelangen and @domyen. We are maintaining our storybooks with stories nav panel themed from Storybooks 4.0. In order to use SB 5.0, we needed these changes. I don't think these changes are going to make storybooks complex. But i totally agree that theme variables are to be minimal. Let me know if we can use any other approach that i am unaware of, to get this thing done. |
If that's the long term stance on this topic (while not ideal, I'm not the one who has to maintain so it's an acceptable reason IMO), can additional attrs/classes/id's be added to the specific elements that this PR enables theming for so that we can still override them by injecting styles using the |
@adamlohner good point. Perhaps adding |
Not specifically related to the Storybook nav (I'm thread-jacking a bit here), but this seems relevant to theming within Storybook in general... This has been one of my biggest pain points with open-source tools that use CSS-in-JS -- I certainly understand the appeal in terms of maintenance, but as an end-user, not having class names available in the DOM to make custom style overrides easy (or in some cases possible at all) can be incredibly frustrating. Even if it's not technically supported, simply making it possible to override default styling would go a long way -- and I'd happily accept the risk of minor upgrades breaking my custom styles.
Agree with @adamlohner -- while not ideal, it's certainly understandable. Storybook is an incredible tool as-is (the updates introduced in v5 are awesome). And taking theme customization too far could absolutely detract from the amazing work the Storybook team is doing. I do, however, feel like it's not always simply about meaningless aesthetics, but rather the UX -- which is consistent with that value prop if an improved UX helps people build UIs. Take the following example: I want to help my team build UIs. Having the props documented in an intuitive, easy-to-read way will help them do that. Unfortunately, it's hidden behind this little blue button: I see there's an option to display it all on one screen, but it looks a bit clunky... What I really want is for it to show up in the addons panel. I see that's not actually supported (#1147) but there's a workaround. This is a lot closer to what I'd actually consider a good experience, but it could use some tweaking. But there's not much else I can do here (that I'm aware of, at least). And it's still a far cry from where I want it to be: (^ These styles were achieved via editing styles in Chrome's dev tools. It doesn't seem this level of customization is actually possible.) This is obviously just one example, but there have been more than a couple of areas that I've fought with only to realize overriding styles that would otherwise be very simple to do is either going to be way too much work, or is just not possible. I think adding class names to the Storybook UI could be huge -- even just a few sprinkled throughout so that I could write selectors like |
@jonmilner you could always write a custom addon to achieve the desired functionality rather than working around the existing notes implementation. I actually just did this and found the Addon API to be super flexible and easy to use. |
Thanks everyone, I definitely appreciate the good thinking behind this PR. I'm closing this because there isn't clear consensus on theme API expansion and the impact on future maintainability. @jonmilner That use case probably isn't in the scope of SB theming. Rather, it's the visual implementation and functionality of addons. I reckon you'll be pleased with the additional documentation features in Storybook Docs coming soon. Specifically the new If folks still want extra visual customization, I'd propose an alternate PR that assigns static classNames to DOM elements for styling. |
- adding classNames to stories nav elements - updating LogoLink to support html elements This PR is a replacement for the deep theming PR: #6098
- adding classNames to stories nav elements - updating LogoLink to support html elements This PR is a replacement for the deep theming PR: #6098
- adding classNames to stories nav elements - updating LogoLink to support html elements This PR is a replacement for the deep theming PR: #6098
Feature:
deep theming for stories nav panel
What I did
LogoLink
to support html elementsThis is similar to the deep theming PR of SB 4.0:
#4702