I’m going to write some articles about react.js/redux/mobx programming with haxe.
But to compete with typescript, haxe needs cross platform IDE with nice jsx support.
So here visual code studio haxe-jsx extention demands:
Separated from vshaxe
Support for haxe-react lib and it’s jsx-function
Components and properties highlight
Go to component class definition from jsx
?Close tag and properties auto complete(may be this option requires separate bounty)
Bounties for implementation are 200$ from me and gratitude of haxe-js users. Please contact me via skype rebelxman or comment here:)
Admittedly the foundation might not agree with building react support inside the general plugin (though something generic enough might be designed), but it would be troublesome to replicate project awareness / code navigation for instance.
That’s not how tmLanguage works I think, maybe we could have jsx highlighting included for haxe-react jsx(...) function and coconut’s function render() '...', because these are two largest libs in Haxe world (I think?)
Still I’d love to find a solution when we could keep library-specific highlighting separate from the basic haxe syntax rules.
It’s certainly not perfect in that inline code is not treated at all, but it’s two things:
way better
not in any way framework specific
If we could say that string interpolation gets treated as before, that’d be a workable solution. I currently don’t use ${} which would highlight inline code, because I find it disturbing when inline code jumps out at me while the greater markup structure fades into the background.
I admit to have no clue about this part. But let’s not conflate feasibility and desirability. Jeremy said he could do it and it was rejected on quite philosophical grounds. Assuming for the sake of the argument that it can be done: are there concrete reasons not to do it?
In the end, we need to come to a conclusion on how haxe will handle this. I don’t see that happening any time soon. If in the mean time we could have a pragmatic solution, I would very much prefer that to having no solution at all. If you want to pitch Haxe as a front end tech, showing JSX/HXX without even highlighting is not exactly going to score points.
As mentioned in the PR, this solution wouldn’t be framework specific and would generally work whenever some kind of markup is embedded in Haxe code, which I would say is a Good Thing™.
Matching all strings that start with '< or "< is doable, but current work on the PR would need to be improved to match incomplete xml strings gracefully, which I believe is possible though not trivial.
An easier approach is a more pragmatic solution that matches specific cases like jsx('<somexml>string</somexml>').
Similarly, it would be fairly easy to match strings preceded by a specific haxe metadata as mentioned in the PR like:
@xml '<somexml>string</somexml>'
That would still be valid haxe syntax and allow to opt-in for xml syntax highlighting on a per-string basis.
None of these options is perfect and they all have pros and cons.
Imo, best option would be the one mentioned by @back2dos : match every string that starts with '< or "<, but with the addition that we update the tmLanguage syntax file so that invalid xml doesn’t break the whole file syntax highlighting (doable but not trivial).
I stopped working on these because it didn’t seem to get anywhere and I don’t want to spend my time for nothing but the issue (syntax highlighting of xml-like syntax) is still valid and indeed, as long as this is not solved, Javascript/Typescript will be miles ahead Haxe to make React applications despite the work of @elsassph and others. That feature would also be nice for generic inline xml string templating as well (non jsx/react).
I will be happy to resume my work on this if we come up with a practical solution that people could agree on though.
@elsassph I am not aware of any way to extend a grammar syntax file with a separate extension, but that would indeed be the best option. Should check out if there is any way to do this with VSCode.
After checking a bit more, I guess it would be possible to embed a grammar into another one if this vscode feature ever gets implemented, but no idea when this will become a reality.
Meanwhile, we could be pragmatic and add xml-string syntax highlighting in official haxe grammar file (in a way that it doesn’t break existing string parsing, so no harm done), and remove it in the future when vscode allows us to do it from a separate extension/grammar.
I am personally in favor of a solution that would be useful today, which can always be replaced by a better solution in the future if there is any. The xml syntax highlighting is fairly easy to remove or add from the haxe grammar file anyway so nothing has to be definitive here.
@elsassph Not sure we can use an alternative grammar file depending on an option in haxe plugin (but maybe there is a way I don’t know?)
The only way to have alternative haxe grammar files I see is to first split current haxe plugin into 2 separate extensions: one for the completion/language server etc… and one just for the grammar. That way, it would be possible to replace the grammar independently from the rest.
Anyway, in both cases that means we need to create an haxe+xml grammar file, which may or may not become the default grammar, for now, in haxe plugin, like what I started in the PR.
I will see if I can update the grammar file I have been working on to match every xml string and be robust enough so that it doesn’t break syntax of whole file if the xml isn’t valid then.
