Skip to content
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

Allow specifying different component page layouts #683

Open
mihkeleidast opened this issue Nov 4, 2020 · 3 comments
Open

Allow specifying different component page layouts #683

mihkeleidast opened this issue Nov 4, 2020 · 3 comments

Comments

@mihkeleidast
Copy link
Member

What problem would this feature solve?

In pattern libraries and design systems, there are often a few "special components" like colors and icons that are not well represented by the default iframe pen layout. For example, icons - when collated - could be rendered larger, in a grid layout and have a custom search in the layout (see bootstrap as an example). We have implemented this in our custom theme but this would fit well in Mandelbrot as well. Colors are often "defined" in a doc page but in my opinion, it would be better do define them similarly to icons as variants and render them as a grid of colored boxes.

Of course, this would only work for components that are mostly "static" in nature - since they would be rendered in the theme environment without their custom styles applied, the theme needs to define fixed structure / ui how these components are rendered.

What the feature should look like?

  • add a layout config option that should be heritable - can be set on collections, components, variants
  • add icon and color layouts in addition to default that would render the custom view. the icon layout does not need to have search in the first iteration.
@LeBenLeBen
Copy link
Member

LeBenLeBen commented Nov 8, 2020

I really like the idea of providing ready-to-use layouts for those, we could even add font families in the same way. However, it feels weird to me to have this in the "components" part, especially because it doesn’t really make sense to be displayed in the preview iframe and to have all the common components stuff (html, view, …).

I’d rather see these as documentation pages, giving a better overall layout, focusing on the content. That would allow to add extra content before and/or after instead of using component notes. You can see how I’ve done it in the past on styleguide.liip.ch for example.

I know docs currently don’t have the concept of layouts but I guess that shouldn’t be too hard to add though. Or maybe we don’t even need that and can rather provide partials that can be included wherever people wants them being displayed? Just pass the colors/icons list as context and it works.

@mihkeleidast
Copy link
Member Author

I would display this instead of the iframe, not in it. To me, at least icon is exactly a component that should keep the component browser - the component template etc is quite useful. Colors are a bit different story. That said, I do get where you're coming from and they could go in docs as well. I guess that's why I proposed moving away from the separation of components and docs a few months back :)

@cojaco
Copy link

cojaco commented Sep 22, 2021

Hi I just want to share how I organize this "design token" colors, fonts, grid setting, etc.

I use style-dictionary https://amzn.github.io/style-dictionary/#/README

It allows me to define all this design tokens in one or multiple JSON files.

This JSON Files will then be converted into sass files with sass maps/variables custom properties etc. but also can I access the JSON file in my colors.config.js and build an array to iterate over in the colors.hbs file.

This Design Token files like colors.hbs, fonts.hbs etc. are then accessible under a folder e.g. "design tokens"

Maybe this workflow can be useful for others.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants