search

brandonmcconnell / tailwindcss-signals

Signals for Tailwind CSS simplifies styling based on ancestor state via style queries. Its declarative API for signaling states eliminates complex selectors, resulting in cleaner, more maintainable code.
MIT License
763 stars 10 forks source link

change variant name to `effect`, update documentation for clarity and readability #1

Open AlexVipond opened 5 months ago

AlexVipond commented 5 months ago

"Signals" is the perfect name, this PR clarifies the mental model

brandonmcconnell commented 5 months ago

Thanks for the PR!

I wonder if there's something else meaningful that signal could do as a variant if we free it up with effect, even to complement the existing signal utility behavior and make that more powerful.

Because this is built upon style queries, it can do plenty more than the group variant can naturally do. I think we're just scratching the surface here, and I would love to iterate on this change while it's early.

Any ideas?

AlexVipond commented 5 months ago

I agree, I'm not quite sure about use cases for signal as a variant, but I do think there's an opportunity to change the way values and modifiers are used, to tap into even more container style query features.

For example, could do signal-[<signal name>]/<signal value>, then write effect-[<signal name>]/<signal value> to say "when the signal is set to this specific value, apply a new style"

Demo here: https://play.tailwindcss.com/2QgwOtGwFK

I can't think of any great real-world use cases off the top of my head, but even just refactoring to signal-[<signal name>] feels a little more intuitive to me than using the modifier as the signal name.

brandonmcconnell commented 5 months ago

@AlexVipond The modifier order used to bug me. It's sort of the standard now for all Tailwind CSS utilities that accept a name, so I want to be in line with that— as close to native as possible. 🙂