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.

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

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

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.

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.

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

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.

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

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

@jasonslyvia That's what fragments are for.

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

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

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

@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.

Can we add this ? Quick single line commenting :)

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
#65 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAE10DSCR3-4VAbO6_3MdLCZ7vuDrHvdks5q8deZgaJpZM4KVMnP
.

R. Mark Volkmann
Object Computing, Inc.

@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.

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

@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.

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

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" }));

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

What about annotation

What about no

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.