[Docs] x-bind:class with multiple conditions

[lonix1]

I needed to bind classes based on multiple conditions.

The x-bind page does not explain how to do that, or that it's even possible.

I found the answer on StackOverflow. Something like this:

x-bind:class="[ isFoo ? 'foo' : '', isBar ? 'bar' : 'disabled' ]"

It would be a good idea to put a small note about this behaviour on that page. It's incredibly useful. (I'm still an alpine newbie, so I'm not the best person to update the official docs.)

---

@joshhanley: I'd have opened a docs issue, but it seems to be buggy; it's not possible to create new issues, even blank ones (shows an error "No templates available for the current repository"). I see you're the last one to commit to the repo... maybe you could have a look?

[joshhanley]

This is the correct place, as we are now using discussions to track bugs and ideas.
See this announcement for more details #1423

We did have an issue template that redirected to discussions but GitHub has broken it recently.

But the docs are open source in this repo, so PRs to fix it are welcome! 🙂

[ekwoka]

It does, right here

This would be the way to do that.

[lonix1]

Thank you, I converted all my code to the "official" way!

not documented... because it is way more error prone

Purely out of curiosity, why is it more error prone? I ask because in some cases it's much easier to use the array syntax, for example:

x-bind:class="[ isHidden ? 'foo bar baz qux' : '',
                isNew ? '' : 'abc def xyz' ]"

...is a mess with the object syntax - so it's unfortunate that it's unsupported.

[ekwoka]

That is an easy one with the object

x-bind:class="{ 'foo bar baz qux' : isHidden,
                'abc def xyz' : !isNew }"

Using Ternaries for only a single branch is a strange way to do things. You'd want more isHidden && 'foo' but the object is definitely clearer contextually.

[lonix1]

Thanks - again I learnt something new. The docs did not make clear that I can use multiple classes for the key... your example makes sense, and is much cleaner.

The "strange way to do things" is because I was thinking the other way round - I'm using ASPNET (not Node), so I'm used to thinking of the condition and then the outcome.

One last thing, if I may, why do you believe the array syntax is error prone? I'm avoiding it, and using your technique instead (thanks!), but it does work, so I'm curious. If it's not "incompatible" with alpinejs, it may be useful to some people, some time.

[ekwoka]

Mainly the syntactical complexity and noise it adds over the object based syntax.

Additionally the object syntax allows the binding to remove default applied classes which the other methods won't do.

[lonix1]

I've learnt a lot from you in this thread, thank you!