> Hi,
>
> That doesn't work, kinda work in javascript world where the function has
> finite, fixed set of arguments, were there is a definition of last one.
> Typescript helps a lot with that, because
> it can ensure to a higher degree, that types are correct, js on its own,
> loose so you have
Hi,
The one interesting case you have to look at dealing with, is the one I
came across where by the call of a function can return a results and will
then later async call the callback in the future.
Because with the proposal above, you have lost the ability to, return the
return result and
One of the common refactorings I do is:
let file1 = await readFile(filename1)
let file2 = await readFile(filename2)
// to
let [file1, file2] = await Promise.all([
readFile(filename1),
readFile(filename2),
])
I would be very confused if refactoring it in this way made my code break
because of
>
>
> Hi James,
>
> I did alot of upgrading of javascript codebase to typescript code base
> about 2 years ago for a year, where the goal was to get everything promised
> and then basically
> were possible ideally move to the await method. This required for us to
> come up with peace meal approach
For many legacy code bases that are based on callbacks mechanisms like
node.js' promisify function are required to help facilitate the transition
from callback centric code to Promise-centric. A lot of the time, these can
follow straightforward rules without requiring customization. However, at
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
Hi Andrea,
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
btw, in case somebody reads this issue, this is the current workaround:
```js
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`
It doesn't work. There's been a lengthy discussion here
https://github.com/mjbvz/vscode-lit-html/issues/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
That is not raw.
On Mon, Jun 22, 2020 at 1:02 PM François REMY
wrote:
> What exactly are you proposing to do differently than String.raw?
>
>
> https://developer.mozilla.org/en-US/docs/web/javascript/reference/global_objects/string/raw
>
> Sent from my phone
> --
>
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*/`
hello world
`;
Or an even better solution is change your highlight to firstly
What exactly are you proposing to do differently than String.raw?
https://developer.mozilla.org/en-US/docs/web/javascript/reference/global_objects/string/raw
Sent from my phone
From: es-discuss on behalf of Andrea
Giammarchi
Sent: Monday, June 22, 2020
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:
```js
import css from
13 matches
Mail list logo
