Discuss
  • A Function.tag proposal?

A Function.tag proposal?

# Andrea Giammarchi (4 years ago)

This is something somehow bothering developers and tools, sooner or later, the need for a no-op template literal tag function that just returns the string as is.

The current workaround to have highlights, proper content minification, etc, is the following one:


import css from 'dummy-tag';import html from 'dummy-tag';
const style = css`  body {    color: green;  }`;
const node = html`  <div>hello world</div>`;

but as irrelevant as the dummy-tag code is, in size, it's a dependency, and a function that can't get easily optimized, due the nature of the tag signature.

Proposal

Provide a static Function.tag which internally flattens out any template literal content.


const css = Function.tag;
const html = Function.tag;

const style = css`  body {    color: green;  }`;
const node = html`  <div>hello world</div>`;

Internally it will place eventual interpolations within template chunks, and return a string.

Function.tag`1${2}3` === '123';

That's it. Thoughts?

Best

# François REMY (4 years ago)

What exactly are you proposing to do differently than String.raw?

developer.mozilla.org/en-US/docs/web/javascript/reference/global_objects/string/raw

Sent from my phone

# Bruno Macabeus (4 years ago)

You could just use comments in order to provide metainformations to your developer tools instead of adding a new feature on language.

const style = /css/body { color: green; };

const node = /html/<div>hello world</div>;

Or an even better solution is change your highlight to firstly try to match a HTML, if fail try to match CSS, if fail match as a plain string.

IMHO it isn't necessary to increase the complexity of JS to do that.

# Andrea Giammarchi (4 years ago)

That is not raw.

# Andrea Giammarchi (4 years ago)

It doesn't work. There's been a lengthy discussion here mjbvz/vscode-lit-html#14 and comments are not welcome in most tools, but even GitHub fails at highlighting the string, and no intellisense works within comments.

The simplest request considered as "increased JS complexity" also feels a bit of an exaggeration: there are various use cases, and I wouldn't have proposed this if useless.

Although, String.tag instead of String.raw seems like a welcome compromise, actually even more semantic, so the proposal would be to add a tag that does exactly what String.raw does without escaping sequences.

As there is already an identical function that is a footgun for the described use-case, I don't see any extra complexity in having String.tag.

Best .

# Andrea Giammarchi (4 years ago)

btw, in case somebody reads this issue, this is the current workaround:

const tag = (raw, ...values) => String.raw({raw}, ...values);

it's still better than my dummy tag (hopefully at least on performance), but as it's becoming more common than ever, it'd be great to have String.tag doing exactly that.

Best

# Bergi (4 years ago)

my 5ct: Putting the static function on the Function object doesn't make any sense to me. Using String.tag seems like much more sensible choice. Or, how about String.plain, in contrast to String.raw?

I can see the use case, altough I'd really prefer tooling to become more intelligent in that regard.

best, Bergi

# Andrea Giammarchi (4 years ago)

I think it doesn't matter where it lands, and I've overlooked at the already available String.raw.

My idea is to have it "no matter where, or how named" as it's the functionality I am after, not the name.

String.plain sounds great, but since template literals tag functions are named "template literals tag functions", I've thought String.tag would implicitly describe the intent.

And then again, I don't care about the name, "we" (developers that use template literals a lot) would love it no matter how it's called ;-)

# #!/JoePea (4 years ago)

I don't know what you mean about the raw stuff, but using /*css*/ works perfectly fine in VS Code with a plugin. There's no reason intellisense can't work inside the commented string. If you meant about completing the css part, if you accidentally write /*ccs*/ then the colors won't look right. Missing auto-completion inside the little comment isn't that bad.

I prefer using the comment because using an identity tag just for syntax feels like I'm adding a performance cost for no reason related to my runtime code.

But perhaps a built-in identity tag would be fast.

#!/JoePea

# #!/JoePea (4 years ago)

Perhaps a built-in identity tag would be only a parse-time performance cost. #!/JoePea

# #!/JoePea (4 years ago)

I mean, it would be only a parse time cost if the identity tag is used like

String.tag`...anything...`

assuming it is not monkey-patchable (readonly). But maybe if it is patchable then all bets are off, and it has a runtime cost.

#!/JoePea

# #!/JoePea (4 years ago)

By the way, the VS Code plugin I use is Comment tagged templates. Works great, allows any extension in the comment, and it will highlight as long as you have that syntax installed separately.

I got tired of pasting my identity tag everywhere.

#!/JoePea