Does not properly split out JS injection for django/jinja templating

[djpeach]

Django + Alpine is growing in popularity every day, and this plugin has been great. Except that it reports some annoying js error due to it not being parsed correctly.

Here is an example:

I see that in the AlpineJavaScriptAttributeValueInjector, you do some parsing for php templating. Could we add something like this for jinja/django templating?

Tested locally with something like this in the getJavaScriptRanges():

        val djangoMatcher = Regex("(\\{\\{.*}})")
        val ranges = mutableListOf<TextRange>()

        var offset = valueRange.startOffset
        djangoMatcher.findAll(content).forEach {
            ranges.add(TextRange(offset, it.range.first))
            offset = it.range.last + 1
        }

        ranges.add(TextRange(offset, valueRange.endOffset))

        return ranges.toList()

This works:

But should probably be implemented better, and maybe would be worth considering a more general approach for more templating engines in the future. Would be willing to help/collab on this, if this is something you would be willing to add.

[inxilpro]

I definitely would love to add better language support for these inline-type templates, but they're quite hard to get right. The PHP/Blade handling doesn't really work right now, either, so I'd like to find a better way to handle the language injection.

I'm definitely open to PRs related to these language features, but I want whatever I end up merging in to be fairly solid. The PHP support is already too hack-y—I'll probably remove it in favor of another solution—so I don't want to just add more hacks :)

[djpeach]

What are a few core languages/template engines you'd like to make sure to support? I'll take a swing at this.

[inxilpro]

The main one is Blade. Alpine is big in the Laravel world (and I use it heavily in Blade files) so I want that support to be solid. Everything else is great.

In an ideal world, we’d figure out how to only inject the JS language contexts in the right places, and let the native IntelliJ plugins do their part for the rest.

[djpeach]

Ok i am not personally familiar with Blade, but should be able to use existing implementation as a starting point. I think it would be useful to split the regex parser to select ranges per language. Right now we have

host.containingFile.viewProvider.languages.filter { "PHP" == it.id || "Blade" == it.id }.isEmpty()

I am thinking a small change would be to essentially switch on the language id, and call a specific getJavascriptFromPHP(), getJavascriptFromJinja(), etc. and of course the default would be just to return the entire content as a list as it is currently.

Would you view something like this as still hacky? This would give us at least a dedicated method per language to focus changes and enhancements per language when issues are filed, without stepping on the toes of other languages.

[djpeach]

In an ideal world, we’d figure out how to only inject the JS language contexts in the right places, and let the native IntelliJ plugins do their part for the rest.

This is how it is implemented today correct? It just mixes php and blade style php regex together, which we may want to split out? Do i understand that correctly?

[rubenjonk]

If somewhat possible, I would like this to work together with django templating.