docs(boolean-prop-shorthand): rfc for the feature

[praveenpuglia]

Rendered

[haoqunjiang]

I like this idea at first glance.
It can help fix the inconsistency between web components syntax and Vue template syntax vuejs/vue-web-component-wrapper#3

[haoqunjiang]

This RFC should address the grammar ambiguity, though.
How should we deal with <foo bar !bar />? Depend on the order of appearance?

[haoqunjiang]

🤔But my proposed use case is an anti-pattern actually (https://eslint.vuejs.org/rules/no-boolean-default.html).
I'm not sure if it can be used as an argument for this syntax proposal.

[na-pel]

How should we deal with <foo bar !bar />? Depend on the order of appearance?

Nothing new in this RFC.
It's just the same as <foo :bar='true' :bar='false' />.

[clemyan]

This RFC should address the grammar ambiguity, though.
How should we deal with <foo bar !bar />? Depend on the order of appearance?

In the same way we deal with duplicate attributes now?

<div :data-value="1" :data-value="2"></div>

which I believe is a compiler error.

But my proposed use case is an anti-pattern actually (https://eslint.vuejs.org/rules/no-boolean-default.html).
I'm not sure if it can be used as an argument for this syntax proposal.

Well, that rule is "Uncategorized" (not even enabled by the vue/recommended preset). I would say only rules in the Essential category are straight up anti-patterns.

[smolinari]

At face value, it seems like a pretty cool idea.

However, I'm wondering about its usefulness. I'm wondering, because, the idea of boolean props should be this. If the boolean flag should be set, it means you want whatever that flag setting does to happen, so you just write the prop out, as demonstrated in this RFC.

However, if you don't want whatever the boolean flag does to happen, as in it would be false, you simply don't add the prop, which is infinitely easier than this proposal.

Hmmmm...... 🤔

Scott

[jacekkarczmarczyk]

Unless the default prop value is true

[smolinari]

Unless the default prop value is true

Which is an anti-pattern, if I'm not mistaken....

edit: Maybe some more poignant code examples would highlight the problem trying to be solved?

Scott

[praveenpuglia]

@smolinari

Which is an anti-pattern, if I'm not mistaken....

Not really. Just like any other kind of values that we may want to have default values. Example -

• default height of rows in this table is gonna be 48px unless specified otherwise.
• Always show menu for this widget unless specified by prop being false.

When components, specially dynamic components are built that are generated from a configuration, you want pretty much all of your props to have default values and then look at configuration for overrides.

However, if you don't want whatever the boolean flag does to happen, as in it would be false, you simply don't add the prop, which is infinitely easier than this proposal.

This forces you to only come up with props that are negative in nature and kind of says that everything is true by default unless you specificy. Works great for props like

• disabled
• hidden
• closed

not for

• opened
• enabled

Take an example. If I don't add the show-menu prop, what does it mean?

• does it mean I don't want the menu to be shown OR
• does it mean I don't care, whatever is default
  It becomes ambiguous to figure out if omitting is setting to false or to default. Also, in that case I am forced to set the default for show-menu to false.

Again, this RFC isn't something we can't live with. It is just a syntactic sugar so I can totally see if this doesn't seem worthwhile. However, I genuinely believe it will bring better UX to developers who need to use boolean props.

[michaeldrotar]

When reading the examples

<!-- OLD -->
<my-component :standalone="false"></my-component>
<!-- NEW -->
<my-component !standalone></my-component>

I actually didn't notice the ! for a minute, it looked too similar to the : -- I think this might actually hurt readability.

I do agree it's easy to mix setting boolean true and false with strings "true" and "false" but I guess it's not something I do frequently.. usually if I'm setting a boolean there's a variable handling the state, not something hard-coded.

For instance, a button could have different appearances like raised, text, or flat -- I've seen components handle this with <my-button flat=true> but then what if you say raised=true flat=true .. what wins? Or is there an error? Also, what's the default state here? It's not clear... personally I opt instead to say appeareance="raised|flat|text" .. then I can pick a default.. or if there's truly not a default than I throw an error if there's no value.

I agree that I'd like to see more examples of where this would be helpful for dealing with hard-coded booleans. Maybe there's a better solution.

---

To the earlier concerns of default values, I also usually want to phrase my properties such that false is the logical default. Inputs are not disabled, dropdowns are not open, checkboxes are not checked... however there are times where I have to break the rule.

For instance, if I'm showing a loading indicator component that has some css transitions when it moves in and out of its loading state.. the default state should probably be that it is loading. That seems more logical to me than to say that it's not idle by default... isLoading=somePromise.isPending

I also get tripped up with disabled sometimes as I find positive booleans to be easier to reason about.. avoiding the not not paradigm in my head. To that effect, I usually add enabled as property for my custom inputs and that also defaults to true... enabled=formIsComplete

[smolinari]

If you have to put logic behind the boolean to toggle or switch it, then you have to write it out anyway. This RFC won't help in those situations.

I will stick to what I said. Default true booleans are an anti-pattern.

Scott

[praveenpuglia]

@michaeldrotar about missing the !. It's like all the other shortcuts. We know about them because they are documented.

• @
• :
  both are single character and the : shortcut is even easier to miss in that sense. In my mind, it's not easy to miss it when coding because you are already thinking about negation and we are all familiar with using the ! operator.

[michaeldrotar]

@michaeldrotar about missing the !. It's like all the other shortcuts.

To clarify, it's not that I didn't see anything, it's that for a good minute I thought it was a colon. They look very similar. Just an initial impression.

[sustained]

I dislike this proposal. </opinion>

[praveenpuglia]

@sustained, @zhangenming - I would love to know why. Why do you think it should not be done?

[sustained]

Oh, I read the proposal again and then I rechecked the docs and I figured out the issue here.

I had no idea you could do <my-component standalone /> to send in true!

Now this proposal makes complete sense and in that case I am okay with it.

That is why I was against it - it seemed like a strange new syntax that only works for one of two possible cases (:standalone="true" versus !standalone).

My apologies.

[smolinari]

Well, because Vue will imply a true value by just adding the prop name, it is an anti-pattern to do anything else for false. Or rather, false = not adding the prop at all, which is much easier to understand, quicker to do and it's less verbose than this suggestion.

Default true boolean props are an anti-pattern in Vue (at least they should be IMHO).

Scott

[yyx990803]

After reviewing the comments so far and a round of voting among core team members, we believe this is not something we will be implementing because the benefits doesn't justify adding a new syntax (which is an extra thing to remember for all users). Thanks for submitting your idea though!

Regarding the web component wrapper issue mentioned by @sodatea - I think it should be fixed in the web component wrapper instead.

[praveenpuglia]

@yyx990803 - Thanks for the comments. I kind of always knew it wouldn't get implemented but happy to have tossed the idea around and get so many different perspectives.