JSX 2.0

[sebmarkbage]

We have accumulated a number of these nice-to-haves breaking changes that would be nice to incorporate. However, at this point JSX is a hugely adopted syntax in all kinds of tooling. Making breaking changes will churn that ecosystem significantly. I think it is probably only worth doing as a batch when the accumulated amount of changes makes it worth while.

Let's call it JSX 2.0.

What should go into it?

Since a completely incompatible version of JSX has landed in Reason it would be good to find a way to unify them.

I'd say at least we'd want:

• 4 - Drop HTML encoding in text and attributes.

• 21 - Computed attribute names.

• 23 - Object short hand notation.

• 25, #51, #64 - Drop the need for curlies around attribute values if they're a single literal, or parenthesis.

Some more controversial/problematic ones that could plausibly be fixed:

• 39 - Implicit do expressions.

• 35 - Drop implicit text content and curlies as children.

• 66 - Custom attribute namespaces.

What else?

cc @jordwalke @SanderSpies

[fibo]

support script, and shaders!!!! So we can write fragment and vertex shaders in JSX!

[NekR]

Are you just throwing random ideas here or just joking already?

[sophiebits]

@NekR I don't think that tone is necessary.

[NekR]

@spicyj hmm.. which tone? It was addressed directly to the comment right before mine, this one: https://github.com/facebook/jsx/issues/65#issuecomment-255860039 For me it sounds like random ideas or jokes. Is that a problem?

[klimashkin]

@fibo It's not recommended to use react for generating whole page (with header content), because in this case you also bind body to react and you will face unpleasant problems with some third-party scripts such as analytics or ads

[sophiebits]

@NekR It seems clear to me that at least the four comments (from the same author) before that were made in earnest, and your comment sounds dismissive of the entire set of them. Given the existence of projects like react-three, react-three-renderer, aframe-react, and react-vr, writing shaders in JSX certainly sounds within the realm of possibility – albeit less familiar to many people.

[NekR]

@spicyj Sorry, but I don't get you. You could just mention those projects initially and say that it isn't a joke, instead of looking for some problems with the tone. Anyway, nevermind.

[fibo]

Add plain numbers support in props

This is better

<MyComponent num=2 />

than this

<MyComponent num={2} />

and why not add hex colors?

<MyComponent fill=#ccc />

[fibo]

@NekR it is not a random idea, it would be great to support shaders. I don't know what the syntax could be but JSX brings HTML tags into JS, why not extend it with a tag like

<x-fragment version={300} numIterations={1000}>

// Webgl2 code copied from https://github.com/fibo/mandelbrot-webgl2/blob/master/index.html

for (int i = 0; i < {numIterations}; i++) {
      tempX = x * x - y * y + float(cx);
      y = 2.0 * x * y + float(cy);
      x = tempX;
      if (x * x + y * y > 100.0) {
        runaway = i;
        break;
      }
    }

</x-fragment>

then having something similar to stack.gl that compiles the shader automatically.

[NekR]

@fibo Okay, let's clarify. You can write that already in JSX, but actual result depends on implementation used with JSX. I assume currently you talk about it with React.

So with React, you can do that with Components. Just read the children as a string and compile the shader when Component is mounted and remove when unmounted. If you want to pass params, it isn't just getting children as a string, but anyway, you will just need to serialize all children into a string because shader is a string actually.

So I think that's possible already. @fibo what special support of it you are looking for?

[jeremenichelli]

The <use> tag for reusable SVG images must be supported in my opinion. It's an improvement you can apply with the native web that needs helper components or bad practices like dangerouslySetInnerHTML today.

[sebmarkbage]

@jeremenichelli For context, this specification is not specific to React. The JSX part already supports <use> but React might not. So the issue should be opened on the https://github.com/facebook/react/ repo.

[jeremenichelli]

@sebmarkbage I knew this not directly related to React but thought that the limitation around the use tag was because of JSX and not React itself. Thanks for the response.

[sunstorymvp]

if-else can be written like this:

<div>
  { !!something && <Component1 /> }
  { !something && <Component2 /> }
</div>

please DON'T implement ng-if or something, be backward compatible, thanks.

[lesterzone]

Less features, more html like stuff. i.e: class Simple html. The simplest, the best.

[tracker1]

I'm expressly not in favor of breaking changes... sure, you could support auto-migrations... but there's already a fairly rich set of libraries out there in npm, and if you introduce incompatible changes, how will that work exactly?

I mean, adding a few additional features and element support that isn't there now, even supporting "class" as a property directly would be nice... some of the props things, I really don't get...

<example {{ prop1, prop2 }} />

should work... I wouldn't mind seeing doctype, script and style elements added, as they would allow for an easier use as a global template/render engine server-side, which is a pretty popular usage..

Other pieces can (as I stated above) be done via additional components and existing structures. Keep the changes very minimal and mostly additive imho...

[sebmarkbage]

@lesterzone @tracker1 The things you mentioned above are all part of React. Not the JSX syntax specification that we're discussing here.

[klimashkin]

@tracker1 You pull from npm and use in 99.99% cases compiled code, there is no JSX

[neiker]

return an array of components without a container, like:

function List(items) {
  return (
    <div>
      {items.map(item => <Item item={item} />)}
    </div>
  );
}

Turns to:

function List(items) {
  return items.map(item => <Item item={item} />);
}

[sebmarkbage]

@neiker That has nothing to do with the JSX specification. That's just how React works (one of several uses of JSX).

You could propose fragment syntax to JSX 2.0 but that's something else.

E.g.

return <><Item item={item1} /><Item item={item2} /></>;

[tz5514]

template directive is fucking silly in JSX. Don't mess it up.

[ichpuchtli]

Please don't change JSX.

Its now become a popular DSL for html outside of React/Facebook and needs representation from the community and stakeholders.

Lots of work has already gone into supporting jsx in editors, libraries and tools like Typescripst's TSX etc..

None of the 'improvements' in this thread warrant the havoc/churn in the ecosystem,

tl;dr please don't.

[mvolkmann]

Sam, can you explain why you would be opposed to adding support for HTML/XML-style comments?

---

R. Mark Volkmann Object Computing, Inc.

On Nov 4, 2016, at 6:28 AM, Sam Macpherson notifications@github.com wrote:

Please don't change JSX.

Its now become a popular DSL for html outside of React/Facebook and needs representation from the community and stakeholders.

Lots of work has already gone into supporting jsx in editors, libraries and tools like Typescripst's TSX etc..

None of the 'improvements' in this thread warrant the havoc/churn in the ecosystem,

tl;dr please don't.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[ichpuchtli]

@mvolkmann JSX can and should be improved and evolve over time, but the authority to change the JSX specification should be moved to a governance model akin to the tc39 commitee.

[adrians5j]

Can we add this ? Quick single line commenting :)

[mvolkmann]

I imagine that would be hard because it is in the middle of XML-ish syntax. I was hoping it could at least support XML-style comments since this feels like XML.

On Wed, Nov 9, 2016 at 8:24 AM, Adrian notifications@github.com wrote:

[image: image] https://cloud.githubusercontent.com/assets/5121148/20141408/84959de2-a690-11e6-9bac-865bb05bb459.png

Can we add this ? :)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/facebook/jsx/issues/65#issuecomment-259426004, or mute the thread https://github.com/notifications/unsubscribe-auth/AAE10DSCR3-4VAbO6_3MdLCZ7vuDrHvdks5q8deZgaJpZM4KVMnP .

R. Mark Volkmann Object Computing, Inc.

[jpeg729]

@jamesseanwright while it is good to understand the reason why "className" is used, I do think that given that jsx is syntactically closer to html than jsx it would be more natural to use "class" rather than "className".

Let's keep "className", but let's add support for "class" too.

I would then have one less thing to do when I copy-paste static html produced elsewhere in order to transform it into jsx.

[adrians5j]

@jpeg729 copy-pasting static html? You use http://magic.reactjs.net/htmltojsx.htm ? :)

[jpeg729]

@adrian1358 sure I could use htmltojsx as you rightly point out, but it seems to me to be an intermediate step that could easily be avoided with a few small changes to jsx.

[jokeyrhyme]

As an alternative to becoming more like HTML, what if JSX is more like JavaScript ?

For example, it would be nice if we could use template strings without the braces:

<input name=`field${index}` />

[ghost]

+1 . Please add ability to use class attribute and ability to pass a string to style attribute. This is the main problem which requires me to always change copy-pasted html markup.

[drcmda]

I wish JSX default args/spread could be extended to behave like a real object. The JSX parser could easily dump args into the _extends function.

const localProps = { a: 1, b: 2 }
const opacity = 0.5;
<Component {...this.props, b: 3, ...localProps, opacity, visible: opacity > 0} title="hello" />

Results in

React.createElement(Component, _extends({}, this.props, { b: 3 }, localProps, { opacity: opacity }, { visible: opacity > 0 }, { title: "hello" }));

Or optimized

React.createElement(Component, _extends({}, this.props, { b: 3 }, localProps, { opacity: opacity, visible: opacity > 0, title: "hello" }));

[gt3]

Revisit: Choosing Type at Runtime

In JSX:

let fns = [() => <p>a</p>, () => <p>b</p>]
<RepeatTwice>{n => <(fns[n]) />}</RepeatTwice>

But instead:

<RepeatTwice>{n => { let F = fns[n]; return <F />; }}</RepeatTwice>

<RepeatTwice>{n => React.createElement((fns[n]))}</RepeatTwice> //OR

With CSS in JSX gaining traction, perhaps it is time to revisit?

Concerns:

1. Security implications
2. Component naming convention in React

[wqj97]

What about annotation

[neiker]

What about no

[sebmarkbage]

I'm locking this conversation now. This thread is really too long to read so it's difficult for anyone new to get context on the previous suggestions so we end up repeating old points. Please search the issues or open another issue with new suggestions.