A Function.tag proposal?

# Andrea Giammarchi (23 days 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 (23 days 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 (22 days 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 (22 days ago)

That is not raw.

# Andrea Giammarchi (22 days 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 (22 days 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 (22 days 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 (22 days 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 ;-)