Genstyl — Design System tool | Export customisation
#DesignSystems #UIDesign #UIUX #FrontEnd #BuildInPublic #WebDesign #ComponentLibrary #DesignToCode #DesignToCodebase
Join the waitlist 👇🏻
https://genstyl.ovidiu.works/?utm_sou...
A design tool specialised in generating design system and component library code would be incomplete if you were unable to customise the output. I’m talking HTML tags and CSS classes.
The first version of Genstyl is focused on the end-to-end workflow, meaning pure HTML and CSS for now. Different output flavours will change the export rules a bit, especially when targeting framework-specific ecosystems (React, Vue, Svelte, etc.).
I’ve tackled pure HTML & CSS using BEM-style classes (”prefix-slug__nested--id”). This allows complex hierarchies without needing CSS namespacing. We don’t have styling isolation and a clash-free environment (*.module.css, CSS-in-JS, web components), but this has the benefit of not requiring a CSS bundler, which means you can open the exported files in the browser immediately after export without any extra tooling. Personally, I find this extremely valuable. What you see is what you get!
The app allows you to control what HTML tag will be used by a specific node in your component and layout trees. With the future aim to provide semantic auditing reporting to ensure your nested HTML is valid (e.g. no `div` inside a `p` tag!).
On the CSS side, you can configure each node to have a custom CSS class. As an example let’s say we’re working on an About page with a card node: we use `about` (the page slug, derived from the name) with a custom node CSS class of `card` which will yield `about__card`.
By default the prefix `about__` will reference the top-most node (layout slug for layouts and component slug for components, respectively).
You have the option to reference the nearest parent node, or provide a completely custom prefix of your choosing, if needed.
For components, if you have a node with the full class `button__label` and customise the instance of that button in a layout (say you want to change the label colour), a new class will be generated for this override `about__[hash]`, applied to that instance only, but exported as part of the layout CSS file. The generated classes are deterministic, so every time you export you get the same ones (unless you change slugs manually).
I found that this works quite well, at least for the time being, provided we include the CSS files in the correct order (the app does that for you) so that overrides are applied correctly without increasing the selector specificity.