Support xml namespaces in JSX

[waderyan]

From @mstijak on October 14, 2016 6:29

Visual Studio Code reports syntax errors if namespaces are used inside JSX.

Namespaces are not supported by React (babel-plugin-transform-react-jsx), but Babel correctly parses them (babel-plugin-syntax-jsx).

Is this something that should be added directly to VSCode or an extension would be a better choice?

WebStorm and Sublime Text do not have this problem.

Copied from original issue: Microsoft/vscode#13728

[waderyan]

@mstijak thank you for opening this issue. Would you mind sharing a simple code example? I believe this is an issue for the JavaScript language service.

[waderyan]

From @mstijak on October 16, 2016 20:37

I'm developing a framework which offers advanced data-binding options. It's a non-standard use case, but namespaces provide a very convenient syntax.

This is how you declare a two-way data binding:

<NumberField value:bind="person.height" />

You can see the full example here: http://cx.codaxy.com/fiddle/?f=luv00Rpw

Also, I noticed that of the leading React developers is considering using react namespace to distinguish React-related attributes from everything else (e.g. react:key).

https://github.com/facebook/jsx/issues/66

[waderyan]

@mstijak very cool! I don't believe this is supported through an extension today. This may be a good candidate for a PR on the JavaScript language service or an extensibility point for the language service.

@mhegazy and @dbaeumer can you advise @mstijak on what he can do here?

[waderyan]

From @dbaeumer on October 25, 2016 10:42

@waderyan this needs to be done by the tsserver since according to @mstijak we report an syntax error here.

[waderyan]

From @mstijak on October 25, 2016 10:48

It looks like this:

[RyanCavanaugh]

This issue is now awaiting more feedback. This means we'd like to hear from more people who would be helped by this feature, understand their use cases, and possibly contrast with other proposals that might solve the problem in a simpler way (or solve many other problems at once).

If this feature looks like a good fit for you, please use the :+1: reaction on the original post. Comments outlining different scenarios that would be benefited from the feature are also welcomed.

[Xiphe]

The vast majority of JSX users are probably using it for React and they decided to not use the full spec of JSX for now. But the namespace syntax is still valid by spec and I see no reason why typescript should deviate from this.

My main problem is that VSCode throws a syntax error. Having a major editor declining this feature is hurting development of other JSX target libraries and frameworks.

---

My personal use case is similar to the one of @mstijak. I created a babel plugin for jsx directives that could utilise the syntax in a very beautiful way (in my opinion ;))

For example <a onClick:goTo="/home" /> where goTo would be a routing directive that creates a callback function /home that is then passed to a as onClick.

I'd love to have this supported by typescript. Let me know if I can help with anything.

[mcav]

I work at Adobe on a framework that uses namespaced attributes for data-binding (<input bind:value={expr}>). Our clients use namespaced tags to define libraries of components (<somelib:button>). We transform this syntax before it gets parsed with React's transform.

Since namespaced tags/attributes are valid JSX and the rest of the ecosystem supports this behavior, it seems reasonable that TypeScript should not consider namespaces to be a syntax error.

Similarly, I'm available to help with a patch if it would be accepted.

[mhegazy]

@mcav we would be open to take a PR for the change. We would expect this to stay an error under --jsx React, and is only allowed under --jsx Preserve.

[RyanCavanaugh]

@mcav implementation suggestion - we have a function isIntrinsicJsxName; any place that is called we need to also handle namespaced names. It'd be ideal to just turn that function into something that returns 1 of 3 values (intrinsic, normal identifier, namespaced name).

[kindy]

I'm creating some babel transformer to enhance React's JSX support too. hope we can support namespace soon so we can use it in VSCode.

[nick-ChenZe]

This feature will also help someone who use vuejs in jsx. See this repo babel-plugin-jsx-event-modifiers. Thanks.

[baluubas]

I'm using https://facebookincubator.github.io/fbt for translations in .tsx and it has a neat way of doing string interpolation of text and other markup. Unforunately I'm restricted to using functional API (which is more limited) since namespaces are not supported.

Muting errors when passing --jsx preserve would work for me. Even @ts-nocheck that works with tsx would do it for me (I read that that directive is now supported for .ts files but from what I can tell is does not mute jsx namespace errors).

[weswigham]

JSX namespace errors are parse errors. They're not mute-able, since parse error ruin our basic understanding of the structure of the code. We'd need basic parsing support, at least.

[ludamad]

I believe this feature will aid in the creation of domain-specific XML templating languages. I was going to try my hand at one myself, but am somewhat stopped by this - for me, TypeScript is a huge win for such a thing and a big stamp of maturity (which I can sense is at question here). In this particular case, I was considering applying it to NETCONF payloads. Namespaces are very important as config in this case is from many different namespace'd modules.

Benefits of JSX in this domain:

• This work tends to use 2 implementation languages, one for logic, and another for XML generation. Combining the two cuts on technologies
• The concept of a pure functions that return XML are very meaningful in this often declarative domain. There are many parallels to React.

Benefits of TypeScript in this domain:

• Infrastructure exists (yanger) to generate types from YANG. So far, no language can both natively produce XML and receive types from YANG.
• Typing said pure functions is very useful, and can even be used for automatic API generation.

tl;dr I think this feature applied to NETCONF has the possibility of tightening up the tech stack

[ryansolid]

I have been using JSX as a DSL similar to something like Svelte for the past few years in SolidJS(https://github.com/ryansolid/solid). Having this feature to stop using weird prefix naming would clean things up considerably, especially for patterns like custom directives etc. It would basically blow things wide open in terms of the expressiveness of the JSX. Seeing this just getting past TS in preserve mode would make such a big difference for the API design space of the library.

[ryansolid]

I want to point out that using Babel with JSX namespace works easily. There is no wierd gotchas or config switch. I have used them to support XML namespaces in Solid and intend to use them the way Vue/Svelte does.

So I was very surprised to find out TypeScript is completely broken in this regard even with preserve. There is no way to get around this:

const d = <div namespace:attribute={d} />

In preserve mode ends up as:

const d = <div namespace attribute={d}/>;

Regardless of other considerations like typing I think at a minimum this needs to be addressed as it breaks user code for no obvious reason.