Feature request: Component-level token view + Extract hard coded token values about storybook-design-token HOT 15 OPEN

Hey, thanks for your feedback.

Have an all tokens view and a component level usage view (potentially 2 tabs) - maintain a list of all tokens and display only the tokens that each component uses

A coworker pitched that same idea to me the other day. I think it would be a great feature. Analyzing the components for token usage could be quite challenging. But I will definitely give it a try.

Add a check against the css/scss/less/etc. to see if there are any font sizes, colors, etc. that are hardcoded and could instead use the tokens. These could then be called out in the addon.

That sounds really cool. Implementing should be straight forward. I already do similar things when extracting the aliases. I'll add that to my list.

from storybook-design-token.

You could use the doc blocks to add component-specific tokens to your component docs. You would just need to add separate annotations to your component-specific tokens.

@Sqrrl That does work, but it causes some tokens to show both on the addon tab and in the docs page. If you have a lot of components, that causes the addon tab to fill up rapidly making it hard to find the global tokens that apply to the entire library. Is there any way to exclude certain tokens from the addon tab?

from storybook-design-token.

Hey @Sqrrl - Im thinking the same as @bddjong here. There can be so many tokens that arent used in a every component. Other than the doc blocks, is there a path forward here?

from storybook-design-token.

I have put together a first draft concerning the hard coded values. CSS-only for now. Any thoughts?
https://feat-hard-coded-token-values--storybook-design-token.netlify.com

https://github.com/UX-and-I/storybook-design-token/tree/feat-hard-coded-token-values

from storybook-design-token.

@Sqrrl I really like what you've done there and its great that you have the line markers. A couple of comments:

• Looking at the screenshot below, without other context, I wouldnt be able to determine what the token would be used for and I would have to go to the css file to find out. What do you think about adding the style type such as font or font-size of font-width in the first column so that you know that the token is associated with that type:
  
• Just a suggestion but I just did the redesign for the a11y addon and Im working to overhaul the Jest test addon to have the same look and feel. What do you think about doing the same for this addon to add consistency in terms of the accordion?
  

from storybook-design-token.

Released v0.3.0 with hard coded value list. The way I use variables in my css produces quite some false positives.

from storybook-design-token.

I'm also very interested in component-level token documentation. I'm currently looking for a way to document design tokens in storybook, and although the plugin is great for global design tokens which are design system-wide, it's not very practical to have every component show up in the plugin at all times. In our case, component-specific tokens could be identified through a name prefix. e.g. --denhaag-button- would be Button design tokens, and --denhaag-select- are Select specific tokens.

You could use the doc blocks to add component-specific tokens to your component docs. You would just need to add separate annotations to your component-specific tokens.

from storybook-design-token.

@CodeByAlex Will that accordion be part of @storybook/components or any other reusable package? Would be great to reuse more of the actual storybook ui components.

from storybook-design-token.

It will be soon now that Jest and the a11y addon will use it but it isnt at the moment. If you would like to wait to use it until it comes out, I can let you know when it does.

from storybook-design-token.

Sounds good.

from storybook-design-token.

So excited for this(and so are many others that ive spoken to)! Let me know if there is anything I can do to support. How far are we from scss integration?

from storybook-design-token.

Hey. Support for scss is in version 0.3.0-alpha.5 0.3.0-alpha.6. But be aware that detection does not work for shorthand values right now. I will look into that after my vacation.

Thanks for your input. Would be great to see other real world usages of the addon.

from storybook-design-token.

That's Awesome @Sqrrl . Ill check it out

from storybook-design-token.

I'm also very interested in component-level token documentation. I'm currently looking for a way to document design tokens in storybook, and although the plugin is great for global design tokens which are design system-wide, it's not very practical to have every component show up in the plugin at all times. In our case, component-specific tokens could be identified through a name prefix. e.g. --denhaag-button- would be Button design tokens, and --denhaag-select- are Select specific tokens.

from storybook-design-token.

Hey @Sqrrl - appreciate this is an old long lived thread, where did you land with this?

I've just started documenting our new design system with this addon, and each component shows all the tokens in the project. (They get put into ones _variables.scss file)

Just wondering on a per story basis, would it be possible to specify the path of the scss file you're interested in showing the tokens from, and then they get extracted from that for the view? Our project is angular and the sass is independent of the components (i.e. no styled components) so without specifying a path I can't see how you'd be able to infer from the story/component which tokens to care about.

Or if something similar has been implemented already, are there any docs for it?

from storybook-design-token.