Add possibility to provide a function config (to receive the 'theme' helper) about tailwindcss-filters HOT 10 CLOSED

One thing we could do is what PostCSS does, where a plugin can just be a function, or it can be created using something like:

tailwindcss.plugin('filters', function (options) {
  return function ({ addUtilities }) {
    // ...
  }
})

This would let us type check on the return value of plugin and know to just invoke the underlying function if no options were passed. Wouldn't be a breaking change either way.

from tailwindcss-filters.

Hey @MichaelDeBoey, yeah definitely. I'd look at a PR if you need this soon, or I can do it sometime in the next few weeks. I'm curious, what does hexToCSSFilter() output exactly? I looked at the documentation and it wasn't clear to me...

from tailwindcss-filters.

@benface hexToCSSFilter will output the exact filter you need to apply to get to the specified color, starting from totally black.
So it would be better to do brightness(0) saturate(100%) ${hexToCSSFilter(theme('colors.facebook'))}, so even if you start from a red image/icon, you'll get the correct color.

I'm happy to provide a PR if I find some time the coming days, but I'm not certain I can get to it tho 😕

from tailwindcss-filters.

Hey @MichaelDeBoey I just released v2.0.0-beta.1 which makes this possible:

module.exports = {
  theme: {
    colors: {
      facebook: '#3B5998',
    },
    filter: theme => ({
        facebook: hexToCSSFilter(theme('colors.facebook')),
    }),
  },
  plugins: [
    require('tailwindcss-filters')(),
  ],
};

from tailwindcss-filters.

@benface Not sure if it's intended to have the plugin config into the theme itself...
I thought that would go in the require like in v1.x, no?

from tailwindcss-filters.

No, that code is correct. I'm following the latest recommendations on plugin configuration, as Adam stated here:

it's more flexible and consistent if we encourage that plugins claim a key in your theme instead of configuring them directly. Plugins could make this key customizable if needed for namespace collision reasons, but I bet in practice it would just work. I'm going to update all of the core plugins to source their configuration from the theme/variants sections themselves instead of being configured directly.

Please note that v2.0.0-beta.1 of this plugin requires Tailwind v1.0.0-beta.1 or later.

from tailwindcss-filters.

@benface Indeed I've seen this passing.

Would it be possible to just do require('tailwindcss-filters') tho, instead of triggering it?
Seems more in line with how @adamwathan did the call for @tailwindcss itself without specifying the config

from tailwindcss-filters.

Would it be possible to just do require('tailwindcss-filters') tho, instead of triggering it?

Some of my plugins accept config options, so in order to remain consistent I made them all closures. This is also good for future-proofing: if a new feature ever requires this plugin to accept options, it wouldn't (necessarily) be a breaking change.

from tailwindcss-filters.

@benface Good point 🙂

from tailwindcss-filters.

Sounds like a good idea :)

from tailwindcss-filters.