Boolean props should be false by default always. (require-default-prop)

[jpickwell]

Tell us about your environment

• ESLint Version: 4.9.0
• eslint-plugin-vue Version: 3.13.1
• Node Version: 8.2.1

Please show your full configuration:

What did you do? Please include the actual source code causing the issue.

<script>
export default {
  props: {
    showText: {
      type: Boolean,
      default: true
    },
    autoPlay: Boolean
  }
}
</script>

What did you expect to happen?
An error should be shown for the showText prop indicating that it should not have a default of true. The autoPlay prop should considered correct even with the require-default-prop rule turned on.

What actually happened? Please include the actual, raw output from ESLint.
With the require-default-prop rule enabled, autoPlay will be flagged. showText will be considered correct.

To make Vue components work like idiomatic HTML elements Boolean attributes/props should always default to false. If a Boolean prop defaults to true then a user who wants to turn that prop off has to bind the prop to a constant false (e.g., :show-text="false").

The require-default-prop rule would need to be modified to either enforce this, or ignore Boolean props. If the rule ignores Boolean props, then a new rule could be added to enforce proper Boolean props.

Boolean props should also never be required.

someBooleanProp: Boolean is how all Boolean props should be declared. There's no need for any other prop options.

At the very least, something should be added to the rules to allow enforcing this. I also believe this rule should be added to the Style Guide.

[michalsnik]

This is a really interesting proposal @jpickwell. I agree that setting default value for Boolean property seems daunting and it makes perfect sense to ignore this type in require-default-prop rule. But validating default property's content for this type of prop sounds like a job for a new rule no-truthy-boolean-prop or something like that.

What do you think about this @chrisvfritz ? It might be a good practice to add in the styleguide, as it would definitely improve consistency in components APIs.

[chrisvfritz]

If we do include it, I think it should be a new rule, but probably not part of the style guide. I agree that most defaults should be false, but there are legitimate exceptions. For example, you may have an alert component that you want to be dismissible 99% of the time in your app. But sometimes, you want notifications that aren't dismissible, so you make the behavior optional with a new dissmissible prop that defaults to true. Does that make sense?

[byCedric]

I really like this proposal, and to be honest I have never thought of the boolean properties this way. But it does make a lot of sense!

Let's say we have a star-rating component which simply displays the 5-star rating and the total amount of ratings. Now sometimes you only need to show the stars, without the total count. With this idiomatic stuff in mind you can either create a show-count or a hide-count depending on if you want to show the count by default or not. I think you can apply this show/hide principle to (almost) everything. The dismissible example could look like can-dismiss and cannot-dismiss for example. Even introduce with-/without- or dismissible/non-dismissible if you prefer it. Combinations are as limited as you make them yourself!

But I also understand that this is maybe too early or too "opinionated" to include this into the style guide. But as said, I really like this proposal and would love to see it as one of the available rules!

[mysticatea]

I feel that this is a good idea 👍, but it should be separated from require-default-prop rule.

[niklashigi]

But sometimes, you want notifications that aren't dismissible,
so you make the behavior optional with a new dismissible prop that defaults to true.

@chrisvfritz This prop could be named persistent making it false by default.

<alert dismissible="false">You have to accept our new terms to continue using XY.</alert>
<!-- vs -->
<alert persistent>You have to accept our new terms to continue using XY.</alert>

I can't think of a single situation where this problem cannot be solved by renaming the prop. I think that with the right error message this rule could really benefit developers, especially if it includes a tip like this:

Try to inverse the name of the prop: If the component is not '{{ currentName }}', it's ...?

If I find the time, I might have a shot at implementing this rule.

[michalsnik]

Feel free to create such rule @shroudedcode ! It would be appreciated :) And we'll ignore default key in require-default-prop for Boolean props.

[chrisvfritz]

Just checking in on all the new rule proposals. What does everything think about calling this boolean-props-default-false? I'm thinking it would stay in uncategorized though, since the benefits of consistency here seem a little more subjective.