Defining dynamic comments on the fly

💡 Ideas
21

Let me see if I can understand what you want @GHNewbiee

You say there's a problem, because you want to be able to comment out a chunk of template literal, and there's currently no way to do that conveniently in JavaScript.

And, it's sounding like you want to be able to use such a feature without editor help (because you've turned down the option of having an editor automatically disable the ${} stuff when you push a comment hotkey)

Your proposed solution is to make "//* ... */" deactivate any ${} stuff within a template literal. It also seems you want the actual "//* ... */" text to still be part of the string, such that you need to comment the comment using the comment system of your language of choice.

ok. This is a solution. I don't find it to be the most ideal. Let me suggest an alternative.

The text ${''/* is a start of a comment.
The text */} is the end of a comment.

This is backwards compatible (you're not taking something that's already a valid string and turning it into something that means something else - which is @aclaymore's valid concern).
This is doable today.
It's a little more verbose, but this can be offset by the fact that you don't need to also wrap it in comments using the language of your choice, since the whole chunk will be removed from the string.

html`
<div>
  ${''/*
  <span id="xyz">${content}</span>
  */}
</div>
`
1 Like
22

Please have a look at:

23

You say there's a problem, because you...

I think first there is a problem how the ES parses the comments within tagged template literals.

And, it's sounding like you want to be able to use such a feature without editor help (because you've turned down the option of having an editor automatically disable the ${} stuff when you push a comment hotkey)

I am not aware about this possibility, but that does not mean that I will close my eyes to the imperfection of the parser.

Your proposed solution is to make "//* ... */"

It was an example to codify my idea. I wrote eg ... might help....

...Let me suggest an alternative.

I believe that this is not a solution. It's is a workaround.

Thanks for your time!

24

I think first there is a problem how the ES parses the comments within tagged template literals.

Your overall premise seems to be that it makes sense to interpret JavaScript comments right in the middle of a tagged template literal, and the parser is currently acting in an unexpected way by not doing so. This premise doesn't really hold water.

For one, it's a template literal - comments are allowed in between tokens, not smack in the middle of something. For example, all of these are also illegal:

0./* whatever */2 // Can't put a comment in the middle of a numeric literal
fun/*!!*/ction() {} // Can't put a comment in the middle of a keyword
'ab/*whatever*/cd' // Can't put a comment in the middle of a string literal
`ab/*!!*/cd` // Can't put a comment in the middle of an untagged template string literal
/.+/* hi there */abc/ // Can't put a comment in the middle of a regex literal

There's nothing inconsistent about the way JavaScript does its comments, in fact, it's quite consistent and predictable, and it's very similar to comment systems of other languages. The ability to add comments to a template literal should be seen as an extra nice-to-have feature, not a "JavaScript is broken and must be fixed" thing.

With that said, I do agree that this sort of feature would be nice to have, so it's ok to have an open discussion around it - it's just not magically elevated to top priority due to a non-existent inconsistency.

Next - we have to keep JavaScript backwards compatable. What's valid as a string today needs to stay as a valid string tomorrow. In your duplicate post, @lightmare gave a number of examples of what would happen if we were to all of a sudden change the interpretation of "/*" within a string from a literal "/" and "*" character to the start of a comment. Lots of existing JavaScript would break. The only way to preserve backwards compatibility would be to make the start-of-a-comment character-sequence within the template string be something that's currently invalid JavaScript today. As far as I can tell, this leaves us with very few options - the start-of-comment sequence must contain a backtick (`) or this "${". Anything else would already be valid JavaScript and can't be used.

So, for example, we could make ${* be a comment-start, and *} be a comment end. This would be a valid solution we could discuss.

html`
<div>
  ${*
  <span id="xyz">${content}</span>
  *}
</div>

Or, if we accept that JavaScript is not broken in its current state (along with every other language with multi-line strings), then we could also discuss adding smarts to editors, so that they can do the ${''/* ... */} workaround.

2 Likes
25

The ability to add comments to a template literal should be seen as an extra nice-to-have feature, not a "JavaScript is broken and must be fixed" thing.

We see the same thing from different aspect. Imagine:

  • a bus without grips/handles,
  • a train, airplane without toilets, and
  • a long highway without rest/parking areas

All of them fulfills their purpose of construction in an excellent constructive way, ie to help people move from one place to another. Now, imagine that one needs to evacuate his/herself. One, after being finally evacuated on his/herself, starts complaining and blaming the maker. One of the maker's company contends that the construction is quite consistent and predictable with its purpose. The ability to add toilets to the construction should be seen as an extra nice-to-have feature, not a "Construction defect/lack and must be fixed" thing. Very nice!

So, for example, we could make ${* be a comment-start, and *} be a comment end.

It is obvious, that any solution has to work as per code chunk and not as per expression to help de-activating/isolating many expressions at the same time. It should also be combined with HTML comments without problem.

Or, if we accept that JavaScript is not broken in its current state (along with every other language with multi-line strings), then we could also discuss adding smarts to editors, so that they can do the ${''/* ... */} workaround.

Editor's smarts is not a solution; it's just a "throw the ball to someone else" workaround, like maker's asking subcontractor to install bigger windows and advising you to take your b@ttocks out of them and evacuate yourself!

Please transfer your comments to

since there is nothing related to dynamic comments definition.

26

It's more like you don't like the shape of the toilet that's there.

The device available to you today works like this: place cursor inside the template string right before the part you want to disable, type:

${''&&`

Then, place cursor right after the part you want to disable, type:

`}

Done. Yes it's ugly, but it's also not meant to stay in the code, it should be temporary.

If you can come up with a better, cleaner toilet, great. But you can't put it in the cockpit. If it breaks existing valid code, it's not a valid solution.

27

Here are the results that I get:

import {LitElement, html} from 'lit';
import {customElement, property} from 'lit/decorators.js';

@customElement('my-element')
export class myElement extends LitElement {
  @property() fruit = 'apple';
  @property() price = 15;

  render() {
    return html`
      <p>This is an ${this.fruit}!</p>
      <p>It costs ${this.price} cents.</p>
      <p>The condition of the fruit is ${this.fruitCondition}</p> <!-- NO, it does NOT give an error. -->
      <p>The colour of the fruit is ${fruitColour}</p> <!-- YES, it DOES give an error as expected. -->

      <hr>

      <p>The colour of the fruit is ${''/*fruitColour*/}</p> <!-- NO, it DOES NOT give an error. -->
      ${''/*
        <p>The colour of the fruit is ${fruitColour}</p>
        <p>The taste of the fruit is ${fruitTaste}</p>
      */} <!-- NO, it DOES NOT give an error. -->

      <hr>

      <p>The size of the fruit is ${'' && `fruitSize`}</p> <!-- NO, it DOES NOT give an error. -->
      ${'' && `
        <p>The size of the fruit is ${fruitSize}</p>
        <p>The weight of the fruit is ${fruitWeight}<p>
      `} <!-- NO, it DOES NOT give an error. -->

      <hr>

      ${''/*
        <p>This is a backtick(`)</p>
      */} <!-- NO, it DOES NOT give an error. -->
      ${'' && `
        <p>This is a backtick(`)</p>
      `} <!-- YES, it DOES give an error! -->
  `;
  }
}

Yes, code chunks can be commented out. Many thanks for your time and patience!

28

Maybe I'm confused.

You want these comments to let everything within them into the string? You just simply want them to disable the string interpolation parts?

Why?

In other words, if I understand your previously stated concerns, if I had this template string:

html`
  <div>
    ${*
    <span>${content1}</span>
    <span>${content2}</span>
    *}
  </div>
`

I've commented out parts using the "${* ... *}" syntax. I was suggesting that the above example would then become interpreted as follows:

html`
  <div>
  </div>
`

But it sounds like you're saying you would rather it get interpreted as follows:

html`
  <div>
    <span></span>
    <span></span>
  </div>
`

Is this correct? Or do you still want the comment characters themselves to become part of the string as well?

29

Gentlemen, I apologize! Mea culpa! It works fine! I will remove my last remark which is totally unfair! Also I will change the remarks in the code so readers not to get confused!