# Bounty 200$ - VSCode haxe-jsx extention
**URL:** https://community.haxe.org/t/bounty-200-vscode-haxe-jsx-extention/436
**Category:** Job Postings
**Tags:** haxe-js, react, jsx
**Created:** [February 15, 2018, 11:32am UTC](https://community.haxe.org/t/bounty-200-vscode-haxe-jsx-extention/436 "2018-02-15T11:32:52Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@alex\_dja](https://community.haxe.org/u/alex_dja)
#### Post date: [February 15, 2018, 11:32am UTC](https://community.haxe.org/t/bounty-200-vscode-haxe-jsx-extention/436/1 "2018-02-15T11:32:52Z")
Hello, haxe developers!
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:)
---
### Author:  [@elsassph](https://community.haxe.org/u/elsassph)
#### Post date: [February 15, 2018, 4:18pm UTC](https://community.haxe.org/t/bounty-200-vscode-haxe-jsx-extention/436/2 "2018-02-15T16:18:24Z")
Why “separated from vshaxe”
---
### Author:  [@alex\_dja](https://community.haxe.org/u/alex_dja)
#### Post date: [February 15, 2018, 9:23pm UTC](https://community.haxe.org/t/bounty-200-vscode-haxe-jsx-extention/436/3 "2018-02-15T21:23:21Z")
Just because of modularity principles. It’s easy to maintain, develop and provide release independence from haxe language extention.
I’d also like to take this opportunity to say thank you Philippe for your work in the field of haxe and react.js worlds integration:)
---
### Author:  [@elsassph](https://community.haxe.org/u/elsassph)
#### Post date: [February 15, 2018, 9:42pm UTC](https://community.haxe.org/t/bounty-200-vscode-haxe-jsx-extention/436/4 "2018-02-15T21:42:22Z")
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.
---
### Author:  [@alex\_dja](https://community.haxe.org/u/alex_dja)
#### Post date: [February 15, 2018, 9:47pm UTC](https://community.haxe.org/t/bounty-200-vscode-haxe-jsx-extention/436/5 "2018-02-15T21:47:04Z")
By the way as you know haxedevelop does this thing without any problem.
---
### Author:  [@jeremyfa](https://community.haxe.org/u/jeremyfa)
#### Post date: [February 18, 2018, 12:05pm UTC](https://community.haxe.org/t/bounty-200-vscode-haxe-jsx-extention/436/6 "2018-02-18T12:05:37Z")
Regarding syntax highlighting of jsx, I did make a PR to haxe grammar a while ago but it was considered a bad idea to mix JSX/Framework-specific stuff with Haxe syntax itself. (see [Add jsx() support. by jeremyfa · Pull Request #30 · vshaxe/haxe-TmLanguage · GitHub](https://github.com/vshaxe/haxe-TmLanguage/pull/30))
I guess it would be nice if the same thing was possible with a separate plugin that extends the official syntax without having to mix them together.
---
### Author:  [@elsassph](https://community.haxe.org/u/elsassph)
#### Post date: [February 20, 2018, 4:28pm UTC](https://community.haxe.org/t/bounty-200-vscode-haxe-jsx-extention/436/7 "2018-02-20T16:28:14Z")
@jeremyfa and whay about @back2dos suggestion to colorise any XMLish string? Can an extension override the syntax without annoying user manipulations?
One point against colorizing everything XMLish: you would get a hint that it’s not JSX if it doesn’t get colourised if you forget the `jsx` function.
---
### Author:  [@back2dos](https://community.haxe.org/u/back2dos)
#### Post date: [February 20, 2018, 5:17pm UTC](https://community.haxe.org/t/bounty-200-vscode-haxe-jsx-extention/436/8 "2018-02-20T17:17:22Z")
I really wonder if anyone would mind if the standard Haxe plugin colorized strings that look like markup as markup. What would the downsides be?
---
### Author:  [@elsassph](https://community.haxe.org/u/elsassph)
#### Post date: [February 20, 2018, 5:36pm UTC](https://community.haxe.org/t/bounty-200-vscode-haxe-jsx-extention/436/9 "2018-02-20T17:36:23Z")
That probably should be optional, but that could be useful in many scenarios.
---
### Author:  [@back2dos](https://community.haxe.org/u/back2dos)
#### Post date: [February 20, 2018, 6:04pm UTC](https://community.haxe.org/t/bounty-200-vscode-haxe-jsx-extention/436/10 "2018-02-20T18:04:49Z")
> [@elsassph](#):
>
> That probably should be optional
Why though? I’m all for making it optional if there are good reasons, but so far I haven’t heard one, so forgive my curiosity ^^
---
### Author:  [@nadako](https://community.haxe.org/u/nadako)
#### Post date: [February 20, 2018, 7:44pm UTC](https://community.haxe.org/t/bounty-200-vscode-haxe-jsx-extention/436/11 "2018-02-20T19:44:56Z")
> [@back2dos](#):
>
> colorized strings that look like markup as markup.
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.
---
### Author:  [@back2dos](https://community.haxe.org/u/back2dos)
#### Post date: [February 20, 2018, 10:12pm UTC](https://community.haxe.org/t/bounty-200-vscode-haxe-jsx-extention/436/12 "2018-02-20T22:12:07Z")
Well, I think we should start somewhere. This is how HXX currently looks:
This is how the same code looks with the normal XML highlighting:
It’s certainly not perfect in that inline code is not treated at all, but it’s two things:
1. way better
2. 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.
> [@nadako](#):
>
> That’s not how tmLanguage works I think
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](https://github.com/HaxeFoundation/haxe-evolution/pull/26). 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™.
---
### Author:  [@jeremyfa](https://community.haxe.org/u/jeremyfa)
#### Post date: [February 21, 2018, 11:34am UTC](https://community.haxe.org/t/bounty-200-vscode-haxe-jsx-extention/436/13 "2018-02-21T11:34:13Z")
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('string')`.
Similarly, it would be fairly easy to match strings preceded by a specific haxe metadata as mentioned in the PR like:
`@xml 'string'`
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.
---
### Author:  [@jeremyfa](https://community.haxe.org/u/jeremyfa)
#### Post date: [February 21, 2018, 12:32pm UTC](https://community.haxe.org/t/bounty-200-vscode-haxe-jsx-extention/436/14 "2018-02-21T12:32:27Z")
@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.
---
### Author:  [@jeremyfa](https://community.haxe.org/u/jeremyfa)
#### Post date: [February 21, 2018, 12:57pm UTC](https://community.haxe.org/t/bounty-200-vscode-haxe-jsx-extention/436/15 "2018-02-21T12:57:14Z")
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](https://github.com/Microsoft/vscode/issues/43538), 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.
---
### Author:  [@nadako](https://community.haxe.org/u/nadako)
#### Post date: [February 21, 2018, 1:06pm UTC](https://community.haxe.org/t/bounty-200-vscode-haxe-jsx-extention/436/16 "2018-02-21T13:06:14Z")
Let’s do it 🙂
---
### Author:  [@elsassph](https://community.haxe.org/u/elsassph)
#### Post date: [February 21, 2018, 1:53pm UTC](https://community.haxe.org/t/bounty-200-vscode-haxe-jsx-extention/436/17 "2018-02-21T13:53:40Z")
Cleanest would be to be able to completely override syntax coloring from another extension - feasible?
Otherwise, maybe we ask @nadako very nicely to add an option to Haxe’s VSCode?
---
### Author:  [@jeremyfa](https://community.haxe.org/u/jeremyfa)
#### Post date: [February 21, 2018, 2:22pm UTC](https://community.haxe.org/t/bounty-200-vscode-haxe-jsx-extention/436/18 "2018-02-21T14:22:59Z")
@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](https://github.com/vshaxe/haxe-TmLanguage/pull/30/commits/c196a2364cc5c492e4693c789c74d1e62fbf99c0) 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.
---
### Author:  [@elsassph](https://community.haxe.org/u/elsassph)
#### Post date: [February 21, 2018, 2:59pm UTC](https://community.haxe.org/t/bounty-200-vscode-haxe-jsx-extention/436/19 "2018-02-21T14:59:53Z")
If it’s enough to install a “haxe-jsx” extension to get that working it would be ok - not sure how the prioritisation of extensions work.
---
### Author:  [@jeremyfa](https://community.haxe.org/u/jeremyfa)
#### Post date: [February 21, 2018, 3:06pm UTC](https://community.haxe.org/t/bounty-200-vscode-haxe-jsx-extention/436/20 "2018-02-21T15:06:27Z")
As mentioned [here](https://github.com/Microsoft/vscode/issues/13292) or [there](https://github.com/vshaxe/vshaxe/issues/84), relying on extensions load order to override config or grammar is rather hacky and should be avoided 😕
[Next page](https://community.haxe.org/t/bounty-200-vscode-haxe-jsx-extention/436.md?page=2)