Shorthand for prop={false}

[Zizico2]

Is your feature request related to a problem? Please describe. It isn't.

Describe the solution you'd like My proposal is to introduce a shorthand for <Component prop={false}>. We could introduce the following syntax as a short form: <Component !prop>. This is only useful when a prop defaults to true.

Describe alternatives you've considered To continue writing <Component prop={false}>.

How important is this feature to you? Not much really... It would be nice to have though.

Additional context n/a

Is this big enough of a change to open an RFC for?

[dreitzner]

Following considerations:

• it might make sense to also allow something like <Comp !!prop />, for the reverse use case with default to false?
• it might also make sense to enhance the already existing shorthand like so <Comp {!prop} />, to signify we are passing a JS Expression.

[dummdidumm]

I vote against it. I don't think it provides a big enough advantage for the additional learning overhead - it's another small thing to know, that adds up.

[antony]

I think the main problem here is that it would probably break tooling which works with HTML. Everything we've done in Svelte's HTML should work with existing editors, I think prefixing an attribute with an exclamation mark would be an exception to this.

But as @dummdidumm says, it's not something we'd be looking to implement because it seems like additional documentation, testing, maintenance and complexity without a massive advantage.

other than that I quite like it :)

[ymeine]

Then what about the other shorthands like for instance <div class:myclass> for <div class:myclass={myclass}>? It also involves documentation, testing, maintenance, and adds complexity (referring to the learning curve I guess).

The only difference is the very relative concept of "massive advantage". I guess it's not something that can be assessed from only the opinion of a few people (I include both sides on that topic, those against and those for it, or rather those who would use it and those who might not).

Also, saying it's "another thing to learn", what's the limit in features set then? The heaviness it adds into learning it is also very subjective: for instance to me, whether I use it or not, I see that as one single piece of syntax with a clear, direct and simple purpose. Something like one sentence, I take it or leave it.

Moreover, accepting this feature request shouldn't be turned into implying that it would lead to an infinite set of features adding up. I believe there's a limit in what features could be expected from such a language which Svelte is. Now, that feature request is consistent with the philosophy of other shorthands. I'm not talking about the syntax proposal which was just a suggestion, not something to be used as a reason for rejection. I do understand the fair requirement of remaining compatible with existing HTML tooling.

[hjalmar]

I think the main problem here is that it would probably break tooling which works with HTML. Everything we've done in Svelte's HTML should work with existing editors, I think prefixing an attribute with an exclamation mark would be an exception to this.

Real bummer this gets shut down so quick. Really hate the argument that it would be additional work, and the reason to hinder progression, or even the thought of it. But for what it's worth, this should not break any HTML tooling if it's done according to spec. https://www.w3.org/TR/html52/syntax.html#elements-attributes

[pushkine]

this should not break any HTML tooling if it's done according to spec

HTML attributes cannot include the ! character https://svelte.dev/repl/1d539f15919d4850a8a3d3584f20d5eb?version=3.31.2

[hjalmar]

this should not break any HTML tooling if it's done according to spec

HTML attributes cannot include the ! character https://svelte.dev/repl/1d539f15919d4850a8a3d3584f20d5eb?version=3.31.2

It would break just as much as on:click|preventDefault breaks. After compilation, the attribute name would be the prop name without ! and the value be false, the opposite of default true as just passing a prop name is currently, so nothing would actually break because it's not part of the name. The question is how valid is the html and are one "allowed" to write a html tag with an attribute name starting with ! without a parser freaking out, not if you can manipulate dom nodes with it.

[hjalmar]

So I thought I'd explore this to hopefully keep the discussion going. I'm not really confident around the source code currently as this was my first time looking at it and the tests which I haven't looked into at all or mocking something up yet, but I thought I'd share my explorations at least.

branch: https://github.com/hjalmar/svelte/tree/logical-not-prop

commits: https://github.com/hjalmar/svelte/commit/57be18447782ad36213a9a751967533f4e28617e https://github.com/hjalmar/svelte/commit/18c50c97f17578262bedd216c53edd5a619af861

[antony]

Then what about the other shorthands like for instance <div class:myclass> for <div class:myclass={myclass}>

the class shorthand is used across the board to allow an identical prop name to reference a variable of the same name. {myProp} where let myProp = false will also work here.

Prefixing a prop with an exclamation mark for the specific, singular case of a falsy boolean would require:

• new syntax to learn
• new documentation
• a set of new tests
• new parsing configuration
• new linting configuration
• updates to IDE plugins
• modification of acorn (?)

Can you understand why this was shut down? It's such a tiny DX enhancement for such a vast amount of time and work which could be better used elsewhere.

[ymeine]

What I can't understand is the way decisions seem to be made, or at least how the decision process might be hidden. That sounds like one opinion against another, where "members"/"contributors" win right away?

• new syntax to learn: how does that weight? Yes it's new, but yet it's extremely short and straightforward syntax. With that reasoning then we don't introduce any new syntax anymore
• new documentation: same question, seems to be like one sentence
• a set of new tests: as for any feature, isn't it?
• new parsing configuration: that is the point to be checked, but it is valid HTML attribute syntax as per the specs
• new linting configuration: I agree
• updates to IDE plugins: as for any new syntax anyways, all depends on how complex it is
• modification of acorn (?): I don't really see how it would be the case since it's at "HTML" level

The fact you show a big list like this doesn't mean it's a big thing to implement, it's a quite generic list for ANY feature. If I do the same I can reject any feature in any project then. The shorthand syntax I mentioned (that indeed I showed with the specific example of class) is a similar thing: it's syntax shorthand, to learn, to document, to test, to highlight, to lint, etc. But it wouldn't necessarily have more usage than this feature proposal.

Feature proposal which AGAIN suggested ! as syntax but didn't mean to bind this feature to this suggestion. There's not even been a discussion that could have possibly led to a "better" (if that one is not good) solution for the same intended purpose (which is a shorthand for ={false}).

Also btw: it's "tiny" only for you and other people who think like you. For me and some others it would be big, as much as the shorthand I took as an example. So, who's right then?

Can you understand why this was shut down?

I do interpret that sentence as a bit obnoxious, as if I had a lack of capability of understanding how leading a project works. Trust me I'm just trying to bring fairness into this keeping in mind it is an open source project, and I felt rejecting that feature was not fair given the somewhat fallacious arguments.

[antony]

That sounds like one opinion against another, where "members"/"contributors" win right away?

If multiple maintainers have expressed that the feature isn't desirable, then it isn't desirable. You are correct in that we don't wish to have an endless debate about something once it's been down-voted by a few maintainers. Generally maintainers agree on the roadmap for the language, so the fact that two responded to this issue can usually be taken as a guide that the general consensus of those responsible for the language would be negative on the feature suggestion.

With that reasoning then we don't introduce any new syntax anymore

We try not to, that is correct. Svelte benefits from having a small, simple, predictable API. Every wibble and wobble we add to it increases the learning curve, and reduces the simplicity of the language.

There's not even been a discussion

Because this is a feature request for something that is exceptionally trivial, it refers to one type of variable in one scenario. It's not something that seems deserving of increasing the API surface of Svelte in order to implement.

I do interpret that sentence as a bit obnoxious

It wasn't intended to be obnoxious, it was a genuine question to ask if you understood why I closed the issue - it's because we don't want to implement a boolean shorthand at this time.

[ymeine]

I see five thumbs up on the request, and only after 2 maintainers commented it was closed. I understand not every request should end up accepted, but it remains an open source project and there wasn't ANY debate when you closed it, and yet still not any since the inputs we try to bring are not considered: what do you think about the comments I made on the list you wrote? Is it really a relevant argument to turn down the request? What about discussing about another syntax since it was the only technical argument used to reject the proposal? How about external contributors PRs to overcome everything except the additional learning curve? How is that learning curve limit defined? etc etc

And how would that syntax make it less small, simple and predictable API next to the other pieces of syntax?? How would that feature be the threshold where everything collapses?

it's because we don't want to implement a boolean shorthand at this time.

Even if I feel an open source project of that size shouldn't take decisions that way, that's the very first rationale I can truly receive.

Btw, class:myClassName={myClassActive} is not any different: it's for toggling a class. How is that different from toggling a boolean input property? I have hundreds of boolean inputs if I take all the components I write! And moreover they're most of the time linked to classes btw...

[antony]

This seems like it's of critical importance to you. In that case, please open a RFC to discuss syntax and list all of the advantages (those which outstrip the disadvantages we feel it will cause) it will bring, which haven't been made clear here.

[Zizico2]

I opened this issue and completely left it to dry... To me the !propshorthand (or any other shorthand for this problem) is only solving a problem Svelte itself created. HTML5 already has boolean attributes. These attributes can be set like this <element attr></element>. In HTML5 a boolean attribute NEVER defaults to True. I'm not saying Svelte shouldn't allow boolean props to default to True. I'm saying it would only make sense to complement HTML5 with a feature analogous to one it already has. To me the "increasing the API surface" argument feels weak. A shorthand for attr={True}already exists. Provided by HTML5 itself, why not enhance it, and also add an attribute attr={False} (prop={False}) shorthand?

From the first comment:

it might make sense to also allow something like <Comp !!prop />, for the reverse use case with default to false?

This would be <Comp prop />, no? Or am I missing something?

This said, I understand the point that this is such a small feature and manpower could be used somewhere else.

The API surface, documentation and learning curve points don't really resonate with me though.

[kuchaguangjie]

Seems add the property without assign any value would become boolean true, and don't add the value become undefined.

e.g:

• <HomeModel {modelName} {modelUpperNames} {modelColItemList} {createModel} enableEdit/>
enableEdit = true
• <HomeModel {modelName} {modelUpperNames} {modelColItemList}/>
enableEdit = undefined