function Button = ({ children }) => <button className={80 tailwind classes here}>{children}</button>
<Button>Create</Button>
<Button>Edit</Button> // Same style
<Button>Delete</Button> // Same styleSome are big and some are small; some are bold and primary and some are muted and secondary; some have icons; some have shadows; some are disabled, etc, etc.
It's easy to make them identical. The challenge is to be as flexible as necessary in a mature application, while minimizing verbosity and complexity.
In my experience Tailwind hurts more than it helps here. It forces you to use your component system to abstract things which otherwise wouldn't warrant the extra level of indirection.
<button class="btn large shadow">Edit</button>
.btn {
...default button styles
}
.btn.large {
font-size: larger;
}
.btn.shadow {
box-shadow: 0 0 8px #0004;
}.btn.large {} .field.large {} .fieldgroup.large {} .title.large {} .link.large {} .large {}
to find all the elements that the .field.large declaration impacts we need to enumerate all the elements that have both .field and .large in any order.
we've coupled out html and css files
<Button variation="primary" size="large">Primary Button</Button>
<Button variation="secondary" size="medium">Medium</Button>
<Button variation="tertiary" size="small">Small</Button>For example when using React you can create 5 button components first and the refactor your code to make the 5 buttons use/call a generic button. Or have 2 generic buttons if the combinations are hard to handle. The thing with atomic CSS like Tailwind is that it very easy to quickly create a few different buttons.