-
-
Notifications
You must be signed in to change notification settings - Fork 4.7k
Support CSS-in-JS syntax in plugins #412
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
Conversation
Wow. |
Nice |
@inxilpro You might like this! |
Is there a way to |
👍👏 |
Technically there's nothing stopping you from doing this: plugins: [
function ({ addComponents }) {
addComponents({
'.btn-indigo': {
'@apply .px-4 .py-2 .inline-block .bg-indigo .text-white': {}
},
})
}
] ...which will totally work, but I strongly recommend against it, because out of the 5 classes in that example, you can only safely expect
|
Would it be possible to do something like this (psuedocode) ? @apply {
.px-4 || 2rem
.py-2 || 4rem
.inline-block
.bg-indigo || blue
.text-white || white
} It seems a lot of the "css in js" config surrounds mostly adding default values, so it would be nice to keep the concise ...then again I guess people could turn off padding module, or have |
Also, could you just add a bunch of raw css to it instead, in case you find adding css in js too much? addUtilities(`
.object-fill {
object-fit: fill;
}
`); |
Yeah this is the annoying problem that makes it sort of a bad idea to work that way inside of plugins 😕 There might be a way to make that experience a bit better though, and the nice thing is since it's all just JS it's easy to build helpers outside of the main framework and test them out there.
Yep could totally make this work; as it stands you could do this already if you import addUtilities(postcss.parse(`
.object-fill {
object-fit: fill;
}
`)); |
This PR introduces some significant changes to the API of Tailwind plugins, with a focus on making things much more accessible and less verbose.
Breaking Changes
Although it was never officially announced and documentation was never published, the existing plugin system does exist in v0.4.3, so I think it's only responsible to address any breaking changes, even though it probably affects literally zero people.
rule
helper is goneatRule
helper is goneutility
helper is goneaddUtilities
will respect the user'sprefix
andimportant
options by defaultaddComponents
will respect the user'sprefix
option by defaultAll of these have been replaced by CSS-in-JS syntax, with the option to drop down to raw PostCSS if necessary (I haven't actually encountered any situations where this is needed.)
New syntax
Instead of the horrendous
rule
/atRule
driven API we have currently, this PR adds support for a CSS-in-JS-style object syntax.Demonstrated by example, this code:
...would now be written like this:
CSS-in-JS styles can either be passed in as one big object:
...or as an array of objects, which is useful to avoid clobbering if you need two instances of the same selector:
Awesome things about this change:
Complete updated plugin signature
The updated plugin signature now looks like this:
config(path, defaultValue)
lets you access data from the user's configprefix(selector)
allows you to apply the user's configured prefix to a selectore(string)
lets you escape a string to make it valid as part of a CSS class name; useful if your plugin generates class names derived from user inputaddUtilities(utilities, options)
lets you add new utilitiesaddComponents(components, options)
lets you add new componentsaddUtilities
improvementsPreviously, the second argument to
addUtilities
was just a list of variants to generate for those utilities. While this is still supported, you can also pass an object as the second argument that exposes two new options:respectPrefix
lets you specify whether Tailwind should automatically prefix your classes with the user's configured prefix. Defaults totrue
.respectImportant
lets you specify whether Tailwind should automatically mark declarations as!important
if the user has configured that in their config file. Defaults totrue
.I doubt people will need to disable these two options very often, but the option is there when it's necessary.
addComponents
improvementsaddComponents
now takes a secondoptions
argument as well, but only exposes one option:Just like with utilities,
respectPrefix
(defaults totrue
) makes it easy for you to apply the user's configured prefix to your component classes automatically. Set this to false if you need fine grained control over if or how prefixes should be applied.prefix
improvementsPreviously, the
prefix
function was very dumb in its implementation and always assumed the selector your were trying to prefix was a simple single class, like.object-contain
.Now,
prefix
will intelligently prefix every class in a selector, leaving non-classes untouched:This behavior applies when using the
respectPrefix
option as well as when using theprefix
helper directly.If you only want to prefix certain classes in a selector and not others (why I don't know but whatever), you can build up the prefixed selector yourself:
Using raw PostCSS
Both
addUtilities
andaddComponents
can also accept an array of raw PostCSS nodes. If you need that much power for any reason, simply importpostcss
into your plugin and work with the PostCSS API directly:You can also mix raw PostCSS nodes with CSS-in-JS:
For more examples, check out the tests.