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:

• Document parsing of (X)HTML entities, or drop it even? #4 - Drop HTML encoding in text and attributes.
• AssignmentExpression in JSXAttributeName #21 - Computed attribute names.
• support object literal property value shorthand #23 - Object short hand notation.
• Allow template literal in JSXAttributeValue #25, JSX Compiler interpolation alternatives. #51, Support numeric attribute values #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:

• Proposal: implicitly use do-expression for any JSX expr container #39 - Implicit do expressions.
• Crazy Idea: Deprecate JSXText? #35 - Drop implicit text content and curlies as children.
• Custom attribute namespace #66 - Custom attribute namespaces.

What else?

cc @jordwalke @SanderSpies

[syranide]

I would be interested in having a real story for comments e.g. #7. {/**/} feels like a hack, and kind of also is as it affects the children when used in certain places. If we actually end up going with #35 (bold, I like it :)) then just properly supporting regular comment syntax is a no-brainer IMHO.

[syranide]

Also, having an actual syntax for fragments would be a very welcome feature (e.g. the previously talked about <>).

[caub]

what would it be for fragments?

const frag = <>
    <div>hello</div>
    <div>world</div>
</>;
// vs 
const frag = [
    <div>hello</div>,
    <div>world</div>
];

then it's the same, you'll need {frag} to insert it.
I think arrays are good enough, similar to DOM fragments, and more powerful to manipulate

comments is a good idea, <!-- --> like html could be fine, but would they be inserted in the DOM (I guess no)? would it conflict with how react uses comments sometimes for text nodes I think

[theduke]

but would they be inserted in the DOM?

There should be a setting to turn it on for dev / off for production in the implementing libraries.

[sbussard]

We need more restrictions on how JSX can be written. People are using terrible practices and teaching it to others. Example: child props should only be passed into components via childProps, otherwise it's a mess. There are so many ways to do things but few even ask if they should do it that way.

[mohsen1]

Something like Angular ng-if would be nice to have in JSX. Making rendering of an element conditional is not easy in JSX. Maybe adopt Angular 2 *if

[tachang]

Most of these changes wouldn't affect my codebase since I use them sparingly. Comments however would be great. It's kind of insane that normal javascript commenting isn't supported even with all the crazy tool chains we are running.

[jasonslyvia]

I'd say allow adjacent elements without enclosing tag, really hate additional <div>s like this:

<div>
   <ComponentA />
   <ComponentB />
</div>

[syranide]

@jasonslyvia That's what fragments are for.

[alistairhutton]

Would be nice to have something like how Adobe/Apache Flex deals with conditional inclusion of components. It is refered to as state in Flex world. You can assign a child component a state name and then when you set the parent components state it hides/shows child components as appropriate

[oleksandr-shvets]

Hi guys! What do you think about this idea? https://github.com/alexander-shvets/cascading-component-layers-react

[jasonslyvia]

@syranide It would be better if it could be solved in syntax level.

[lacker]

<if {myCondition}>
  <div>This part only gets shown if myCondition is true</div>
</if>

[BrendanFDMoore]

@mohsen1 our convention for our stateless functional components is to use:

import MyInnerComponent from '../my-inner-component';
function MyOuterComponent({ isInnerComponentIncludedBool }) {
  ...
  return (
    <div>
      <SomeOtherComponent />
      {
        isInnerComponentIncludedBool
        ? <MyInnerComponent />
        : null /*Or some fallback component / messaging*/
      }
    </div>
  );
}

which works pretty well for us. It's pretty clean as long as your outer component props are a clear pre-calculated boolean for show/hide. Because your components don't have any business logic, this should be fine already, right? ;)

edit: the ternary allows us to include an alternative, which we commonly do want, without needing to add an if !someBoolFlag check also.

[kevinsimper]

@mohsen1 @lacker @BrendanFDMoore

You can make it as easy as angular if like this, so I don't see any need for an if tag

{ somethingTrue &&
  <div>Will only show if somethingTrue is true</div>
}

[mohsen1]

@BrendanFDMoore I'm aware of those workarounds and we're using them. Since JSX is syntax sugar for React.createElement adding more syntax sugar won't hurt.

In your example the syntax can look like this:

return (
    <div>
      <SomeOtherComponent />
      <MyInnerComponent *if={isInnerComponentIncludedBool} />
    </div>
  );

I guess mentioning Angular earns you lots of downvotes here!

[BrendanFDMoore]

@kevinsimper True, it's more compact. We stick to the other convention because instead of null we often want to show some placeholder text or replacement component.

@mohsen1 you're right, there's no harm in more helpful sugar to clean up unpleasant syntax where there is wide interest and a commonly accepted pattern. I'm not necessarily against the addition of an if helper.

[nkohari]

I find that assigning optional components to variables helps for clarity, for example:

function Profile({ user }) {
  let avatar;
  if (user) {
    avatar = <Avatar user={user} />;
  }
  return (
    <div>
      ...whatever the outer component represents...
      {avatar}
    </div>
  );
}

While it would be nice to have direct support in JSX for conditional components, I'm really wary of adding things like <if> or an if=... attribute. Next people will want <for> and <while>... IMHO there's no need to replicate that much JS functionality in JSX.

[fab1an]

Automatically bound arrow function that don't allocate a new function everytime:

<div onLoad={@this () => doSomething(blabla)}/>

[max-mykhailenko]

IMHO jsx has only several problems:

• code comments
• conditional attributes

JS should have separate context in curly braces.

[meznaric]

With current syntax {something && <Component />} when you render a more complex component this introduces another level of indentation. Which in my opinion helps us to spot conditional logic, but does not look as nice.

I think that having multiple ways of doing the same thing adds to overhead when reading the code. It's small but noticeable.

[jmar777]

Make whitespace handling more consistent with HTML: facebook/react#4134 (sorry for brevity, currently mobile...).

[bjrmatos]

@mohsen1 "It's just JavaScript, not a template language" -> no need to replicate JS functionalities with custom syntax. That is the main benefit of JSX IMO, seriously is so easy to do this with js even if it looks "weird" (for me it is not weird, it is just the syntax of the language)

[fdecampredon]

I would like to be able to specify some property value with tag :

<SplitContainer
  left={<div>...</div>}
  right={<div>...</div>}
/>
// vs
<SplitContainer>
  <.left>
    <div>...</div>
  </.left>
  <.right>
    <div>...</div>
  </.right>
</SplitContainer>

[Pajn]

@mohsen1
It has nothing to do with mentioning Angular but with introducing additional syntax that makes it harder to learn and harder to read without adding any benefit as it's more characters to type than {condition && VDOM} and it's harder to understand (&& will return the lhs if it's falsey as all JS, what will *if do? return null? undefined? rip out the element completely as it was never there?)

Also with #35 and #39 you could do

if (condition) {
  VDOM
}

wich would be JS instead of some special thing

[mohsen1]

@Pajn That looks much better than *if or anything like that. Also #35 is a great proposal! 👍

[nkkollaw]

Don't fuck it up like Google did with Angular 2, keep the thing compatible with older versions...

[NekR]

I highly doubt that it makes sense to have full backwards compatibility for JSX 2.0. If we are going to improve it -- we should improve.

After all, no one is forced to migrate to JSX 2.0 and you still will be able to write your React apps in JSX 1. React elements/components are just JavaScript calls, so there is no matter what you are using. In some case, if you would like, you probably will be able to use JSX 1 and JSX 2.0 in the same project, e.g. for migration. Just apply new transform for new components.

IMO, that's it.

[NekR]

Though, I'm not a fun of adopting features from Angular. Like some already here proposed are already possible with JSX + React.

[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 [email protected] 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 [email protected] 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
#65 (comment), 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.