Feat/parse html from js template string

[JeffersonCarvalh0]

I was facing a very similar problem to the one related in #21 so I decided to give it a try. The idea is to create a JS extractor that accepts an HTML parser as a parameter, in order to parse the HTML from template strings (pretty much the same idea from the embeddedJs extractor).
Please, let me know how I can improve this PR, and thanks for this amazing library!

PS: I'm not sure the linter worked

[lukasgeiter]

Thanks for your PR!

I'm wondering if limiting this feature to only template string literals with no substitutions is maybe a bit too restrictive? What are your thoughts on that?

[JeffersonCarvalh0]

I agree with you @lukasgeiter , I'm just not sure about which types I could check for (there are barely any docs for the compiler API from typescript - if you found a helpful source somewhere, please I'd like to know)

I could test with other types I find fitting in the .d.ts files from typescript and add them to this feature

[lukasgeiter]

No worries. I recommend you use a tool that makes it easy to explore the AST. Here's two I've used before:

• astexplorer.net
• ts-ast-viewer.com

For this feature there are two potential types of string literals to handle. First, regular string literals (double and single quotes). This one is quite straightforward: SyntaxKind.StringLiteral. Even better, use isStringLiteralLike to check for string literals and template strings without substitutions at once.

Secondly, there's the topic of template strings with substitutions. This one will be a bit more complex because you would first have to build a full string out of the parts that can then be passed to the html parser. Before you attempt that, I would be curious if you have this case in your code base. Just to get an idea if it's even worth it to implement support for template strings with substitutions.

[JeffersonCarvalh0]

Thanks for the tips!

As for html templates within template strings with substitutions, if I understood correctly, I actually have them in the code base, but they are already being extracted. My guess is that the JS extractor actually "sees" the JS code inside the template because it is already programmed to do that, regardless of the string surrounding it, so it doesn't matter if it is an HTML template (and the interpolated values don't generate more HTML code, they are literally calls to the i18n extraction function). I can't think about a use case where we'd have to write a specific logic to handle that

[JeffersonCarvalh0]

I've added isStringLiteralLike as suggested and also added a new test case to illustrate the cases I have in my codebase where template substitutions are used (note that I've added this test to the callExpression tests, not the htmlTemplate tests)

[lukasgeiter]

Yes, expressions inside template strings are JavaScript so they are properly extracted. There's no need for an explicit test for that. Otherwise I would have to add tests for every possible place a call expression can occur in JavaScript.

What I'm talking about is running the HTML parser/extractor on a template string with substitutions. For example:

`<div>
    <translate>Hello World</translate>
    ${substitution}
</div>`

[JeffersonCarvalh0]

No worries. I recommend you use a tool that makes it easy to explore the AST. Here's two I've used before:

• astexplorer.net
• ts-ast-viewer.com

For this feature there are two potential types of string literals to handle. First, regular string literals (double and single quotes). This one is quite straightforward: SyntaxKind.StringLiteral. Even better, use isStringLiteralLike to check for string literals and template strings without substitutions at once.

Secondly, there's the topic of template strings with substitutions. This one will be a bit more complex because you would first have to build a full string out of the parts that can then be passed to the html parser. Before you attempt that, I would be curious if you have this case in your code base. Just to get an idea if it's even worth it to implement support for template strings with substitutions.

Sorry about the delay.

Now I got what you meant. I don't think I have this case in my codebase =/
I've just applied the changes you suggested

[lukasgeiter]

Thanks for the changes!
Let's not bother with templates that have substitutions then. Support can still be added later if requested.

[lukasgeiter]

Thanks for the changes, and apologies for my delay. I think we're almost there 🙂

[JeffersonCarvalh0]

Sorry for the delay on my part, these last weeks have been busy =/
Please let me know if there is anything else that needs to be changed

[lukasgeiter]

Released with v3.8.0