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>
}