I have to use a framework based on custom elements. The framework also defines and uses some new boolean attributes (e.g. "visible"). Hence, a :visible="dlg_displayed" does not work correctly because visible is not recognized as a boolean attribute and is always set instead of removed if dlg_displayed is false.
I looked into the code and found this constant list definition: https://github.com/alpinejs/alpine/blob/75f730f034fb7e93482fe96b63dc2251bb1e42cb/src/utils.js#L119
Adding visible to the list fixes the issue. So could you please add some way to add attribute names to the list of boolean attributes?
Thanks for alpine.js! I love it!
The list is based on the HTML standard list of boolean attributes not sure if there's a plan to support custom attributes.
Ok, I understood why the lists currently looks like this. Makes sense.
Here are a few, non-breaking changes which should do the trick and offer the list as a configuration parameter: https://github.com/alpinejs/alpine/compare/master...pohlt:pohlt-patch-1
Sorry, this is not a full PR because I currently do not have the right build environment.
Yeah that code isn't actually complete but I get the idea.
I think you should try to find a workaround for this, since I don't think it's going to get implemented, although that's @calebporzio's call.
Just tried it and a Alpine.config.booleanAttributes.push("visible"); does the trick for me. Don't know what could be missing.
Given the small footprint and the flexibility it brings, I would highly appreciate this modification, but then I'm slightly biased. ;-)
An alternative approach would be:
if the value to bind is null, rather than converting it to "null" (which I find weird, not sure if it's expected) we remove the attribute. It's been a while since the last time I used Vue but I believe it's what it does, right?
That would just be a bug fix rather than a new feature so more likely to be accepted.
For your specific case, you would need to use a function and return null when you want to remove the attribute. Any thoughts?
I like your approach since it's minimally invasive for alpine, but it's weird that true/false does the right thing for some attributes (the ones in the list), but not for others. Web components are here to stay IMHO, so making alpine play nicely with them would make alpine more future-proof.
Long-term, I still see a lot of benefit in making such settings available for user modifications.
What are the design principles or goals for alpine? Keeping it small and simple, no feature bloat, I guess. What I'm proposing checks all these boxes for me.
Don't get me wrong: It's just a proposal. I'm grateful for the time and effort you are putting into alpine. :-D
Yeah, both will do the trick. 馃憤
I was just putting more options on the table.
The configuration is a big feature (not in terms of code but in terms of impact and expectations) so I think Caleb would like to take care of it and think about it thoroughly.
He's focusing on livewire right now so it may pass some time before a proper configuration is available.
I dunno about allowing configuration of internals. We probably still want to figure out why all attributes don't behave as Boolean by default (adding/removing the attribute given a falsy value) probably there's either a performance or (at the time) complexity overhead?
Ok, I get your point now: Introducing configs has quite some impact and can potentially turn into a can of worms. Let's see what Caleb thinks about this, when he has time to look into this.
Thanks for the discussion, guys. Stay healthy.
Yep,
The way I see it you're just as well forking Alpine.js and adding whichever extra Boolean attributes you want. I think that piece of Alpine will remain quite stable so you'll just need to keep an eye out for releases to integrate them (if you want the new features).
I just ran into this with an optional aria-label attribute when I was porting over a Vue component to Alpine. I like @SimoTod 's approach above to just remove the attribute if the value is null. That is how Vue works.
For example, in Vue this would just not set the aria-label:
:aria-label="label == null ? null : 'This is the label'"
In Alpine it creates an aria-label="null" which I also agree is odd.
An alternative approach would be:
if the value to bind is null, rather than converting it to "null" (which I find weird, not sure if it's expected) we remove the attribute. It's been a while since the last time I used Vue but I believe it's what it does, right?That would just be a bug fix rather than a new feature so more likely to be accepted.
For your specific case, you would need to use a function and return null when you want to remove the attribute. Any thoughts?
This is a cool solution would need input from @calebporzio as to why this is not the case currently
Instead of "stringify by default" we could do "delete attribute when null"
Yeah I'd prefer the delete if null approach. Won't be hard to implement at all
Yeah I'd prefer the delete if null approach. Won't be hard to implement at all
Would also get rid of that list of Boolean attributes
Moving this here from https://github.com/alpinejs/alpine/issues/485
If I write x-bind:href="article.external_url" and if the value of article.external_url is null or false then in Alpine the href is still bound but with a value of null

However, from the Vue.js docs, for example: https://vuejs.org/v2/guide/syntax.html#Attributes
If isButtonDisabled has the value of null, undefined, or false, the disabled attribute will not even be included in the rendered
What is the expected output here?
PR to delete attributes when their value is null/undefined/false has been merged https://github.com/alpinejs/alpine/pull/486
@pohlt I believe this solves this issue without needing a way to configure the list of boolean attributes.
YAY
Ok I'm going to close this for now since we've worked around the issue by removing attributes in certain circumstances. Feel free to reopen or start a discussion (especially re boolean attribute support)
It's out as 2.3.4 if you care to upgrade 馃槃