New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JSX 2.0 #65

Open
sebmarkbage opened this Issue Oct 12, 2016 · 136 comments

Comments

Projects
None yet
@sebmarkbage
Member

sebmarkbage commented Oct 12, 2016

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

@syranide

This comment has been minimized.

Show comment
Hide comment
@syranide

syranide Oct 13, 2016

Contributor

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.

Contributor

syranide commented Oct 13, 2016

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

This comment has been minimized.

Show comment
Hide comment
@syranide

syranide Oct 13, 2016

Contributor

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

Contributor

syranide commented Oct 13, 2016

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

@caub

This comment has been minimized.

Show comment
Hide comment
@caub

caub Oct 16, 2016

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

caub commented Oct 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@theduke

theduke Oct 16, 2016

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.

theduke commented Oct 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@sbussard

sbussard Oct 16, 2016

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.

sbussard commented Oct 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@mohsen1

mohsen1 Oct 16, 2016

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

mohsen1 commented Oct 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@tachang

tachang Oct 16, 2016

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.

tachang commented Oct 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@jasonslyvia

jasonslyvia Oct 16, 2016

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

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

jasonslyvia commented Oct 16, 2016

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

<div>
   <ComponentA />
   <ComponentB />
</div>
@syranide

This comment has been minimized.

Show comment
Hide comment
@syranide

syranide Oct 16, 2016

Contributor

@jasonslyvia That's what fragments are for.

Contributor

syranide commented Oct 16, 2016

@jasonslyvia That's what fragments are for.

@alistairhutton

This comment has been minimized.

Show comment
Hide comment
@alistairhutton

alistairhutton Oct 16, 2016

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

alistairhutton commented Oct 16, 2016

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

@alexander-shvets

This comment has been minimized.

Show comment
Hide comment

alexander-shvets commented Oct 16, 2016

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

@jasonslyvia

This comment has been minimized.

Show comment
Hide comment
@jasonslyvia

jasonslyvia Oct 16, 2016

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

jasonslyvia commented Oct 16, 2016

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

@lacker

This comment has been minimized.

Show comment
Hide comment
@lacker

lacker Oct 16, 2016

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

lacker commented Oct 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@BrendanFDMoore

BrendanFDMoore Oct 16, 2016

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

BrendanFDMoore commented Oct 16, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@kevinsimper

kevinsimper Oct 16, 2016

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

kevinsimper commented Oct 16, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@mohsen1

mohsen1 Oct 16, 2016

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

mohsen1 commented Oct 16, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@BrendanFDMoore

BrendanFDMoore Oct 16, 2016

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

BrendanFDMoore commented Oct 16, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@nkohari

nkohari Oct 16, 2016

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.

nkohari commented Oct 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@fab1an

fab1an Oct 16, 2016

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

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

fab1an commented Oct 16, 2016

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

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

This comment has been minimized.

Show comment
Hide comment
@max-mykhailenko

max-mykhailenko Oct 16, 2016

IMHO jsx has only several problems:

  • code comments
  • conditional attributes

JS should have separate context in curly braces.

max-mykhailenko commented Oct 16, 2016

IMHO jsx has only several problems:

  • code comments
  • conditional attributes

JS should have separate context in curly braces.

@meznaric

This comment has been minimized.

Show comment
Hide comment
@meznaric

meznaric Oct 16, 2016

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.

meznaric commented Oct 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@jmar777

jmar777 Oct 16, 2016

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

jmar777 commented Oct 16, 2016

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

@bjrmatos

This comment has been minimized.

Show comment
Hide comment
@bjrmatos

bjrmatos Oct 16, 2016

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

bjrmatos commented Oct 16, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@fdecampredon

fdecampredon Oct 16, 2016

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>

fdecampredon commented Oct 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@Pajn

Pajn Oct 16, 2016

@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

Pajn commented Oct 16, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@mohsen1

mohsen1 Oct 16, 2016

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

mohsen1 commented Oct 16, 2016

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

@nkkollaw

This comment has been minimized.

Show comment
Hide comment
@nkkollaw

nkkollaw Oct 16, 2016

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

nkkollaw commented Oct 16, 2016

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

@NekR

This comment has been minimized.

Show comment
Hide comment
@NekR

NekR Oct 16, 2016

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 commented Oct 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@NekR

NekR Oct 16, 2016

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

NekR commented Oct 16, 2016

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

@brochington

This comment has been minimized.

Show comment
Hide comment
@brochington

brochington Oct 16, 2016

I would like more granular control over what function the JSX is compiled to.

/** @jsx myImageFunc img*/

import React from "react"
import myImageFunc from "./somewhere"

SomeClass extends React.Component {
     render() {
        return (
            <div> // compiled to default, ie. React.createElement
                <img src={...}/> // compiled to myImageFunc
            </div>
        )
    }
}

brochington commented Oct 16, 2016

I would like more granular control over what function the JSX is compiled to.

/** @jsx myImageFunc img*/

import React from "react"
import myImageFunc from "./somewhere"

SomeClass extends React.Component {
     render() {
        return (
            <div> // compiled to default, ie. React.createElement
                <img src={...}/> // compiled to myImageFunc
            </div>
        )
    }
}
@alexander-shvets

This comment has been minimized.

Show comment
Hide comment
@alexander-shvets

alexander-shvets Oct 16, 2016

@brochington you can do it in that way:

import myImageFunc as Img from "./somewhere"
     render() {
        return (
                <Img src={...}/> // compiled to myImageFunc
        )
    }

alexander-shvets commented Oct 16, 2016

@brochington you can do it in that way:

import myImageFunc as Img from "./somewhere"
     render() {
        return (
                <Img src={...}/> // compiled to myImageFunc
        )
    }
@brochington

This comment has been minimized.

Show comment
Hide comment
@brochington

brochington Oct 16, 2016

@alexander-shvets Those aren't the same.

In my example img would compile to myImageFunc(class/string, props, ...children).
In your example Img would compile to React.createElement(Img, props, ...children).

brochington commented Oct 16, 2016

@alexander-shvets Those aren't the same.

In my example img would compile to myImageFunc(class/string, props, ...children).
In your example Img would compile to React.createElement(Img, props, ...children).

@alexander-shvets

This comment has been minimized.

Show comment
Hide comment
@alexander-shvets

alexander-shvets Oct 16, 2016

@brochington why myImageFunc is better than [Stateless Function Component](react pure functional components) for you?

alexander-shvets commented Oct 16, 2016

@brochington why myImageFunc is better than [Stateless Function Component](react pure functional components) for you?

@brochington

This comment has been minimized.

Show comment
Hide comment
@brochington

brochington Oct 16, 2016

@alexander-shvets Your link doesn't seem to work for me, but I assume you are referring to This. The JSX still uses React.createElement. I would like to be able to control this.

brochington commented Oct 16, 2016

@alexander-shvets Your link doesn't seem to work for me, but I assume you are referring to This. The JSX still uses React.createElement. I would like to be able to control this.

@Pajn

This comment has been minimized.

Show comment
Hide comment
@Pajn

Pajn Oct 16, 2016

@brochington
Why not just write that as myImageFunc(class/string, props, ...children)? The point of JSX is basically to hide the repeated createElement call so if you want to call another function just once, write is as that. It would both be shorter and less surprising than a single tag that behaves differently from all the others.

Pajn commented Oct 16, 2016

@brochington
Why not just write that as myImageFunc(class/string, props, ...children)? The point of JSX is basically to hide the repeated createElement call so if you want to call another function just once, write is as that. It would both be shorter and less surprising than a single tag that behaves differently from all the others.

@alexander-shvets

This comment has been minimized.

Show comment
Hide comment
@alexander-shvets

alexander-shvets Oct 16, 2016

@brochington you can do it using custom jsx pragma:
/** @jsx myImageFunc */

alexander-shvets commented Oct 16, 2016

@brochington you can do it using custom jsx pragma:
/** @jsx myImageFunc */

@brochington

This comment has been minimized.

Show comment
Hide comment
@brochington

brochington Oct 16, 2016

@alexander-shvets That wouldn't work either, as both the <div /> and the <img /> would then use myImageFunc. Please notice the two arguments to my pragma definition above.

@Pajn JSX can and is used in other forms outside of the context of React. JSX is a way to define syntax sugar. In the case of React part of that sugar is hiding the createElement method. But their is no reason why this needs to be the case. Just as @alexander-shvets has pointed out, you can already define JSX compilation via pragma definitions. I just want a more granular approach to this.

brochington commented Oct 16, 2016

@alexander-shvets That wouldn't work either, as both the <div /> and the <img /> would then use myImageFunc. Please notice the two arguments to my pragma definition above.

@Pajn JSX can and is used in other forms outside of the context of React. JSX is a way to define syntax sugar. In the case of React part of that sugar is hiding the createElement method. But their is no reason why this needs to be the case. Just as @alexander-shvets has pointed out, you can already define JSX compilation via pragma definitions. I just want a more granular approach to this.

@oztune

This comment has been minimized.

Show comment
Hide comment
@oztune

oztune Oct 16, 2016

I really like the elegance and subtle benefits of #35.

I think the ability to mix JSX 1 and 2 in the same project will be a high priority for those of us maintaining large code bases.

oztune commented Oct 16, 2016

I really like the elegance and subtle benefits of #35.

I think the ability to mix JSX 1 and 2 in the same project will be a high priority for those of us maintaining large code bases.

@rauchg

This comment has been minimized.

Show comment
Hide comment
@rauchg

rauchg Oct 16, 2016

@lacker I'm curious why you prefer that over do expressions? Seems a more elegant, "pure JS" solution

rauchg commented Oct 16, 2016

@lacker I'm curious why you prefer that over do expressions? Seems a more elegant, "pure JS" solution

@fibo

This comment has been minimized.

Show comment
Hide comment
@fibo

fibo Oct 24, 2016

support <!doctype>: this will make server side rendering a lot easier.

There are also a lot of other tags not supported, like <style>, <script>, etc.

if my jsx is like

<body>
  <h1>Hello JSX2</h1>
<body>

React should understand and mount it automatically, after body.... well this is brainstorimng, right?

fibo commented Oct 24, 2016

support <!doctype>: this will make server side rendering a lot easier.

There are also a lot of other tags not supported, like <style>, <script>, etc.

if my jsx is like

<body>
  <h1>Hello JSX2</h1>
<body>

React should understand and mount it automatically, after body.... well this is brainstorimng, right?

@fibo

This comment has been minimized.

Show comment
Hide comment
@fibo

fibo Oct 24, 2016

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

fibo commented Oct 24, 2016

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

@NekR

This comment has been minimized.

Show comment
Hide comment
@NekR

NekR Oct 24, 2016

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

NekR commented Oct 24, 2016

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

@sophiebits

This comment has been minimized.

Show comment
Hide comment
@sophiebits

sophiebits Oct 24, 2016

Member

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

Member

sophiebits commented Oct 24, 2016

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

@NekR

This comment has been minimized.

Show comment
Hide comment
@NekR

NekR Oct 24, 2016

@spicyj hmm.. which tone? It was addressed directly to the comment right before mine, this one: #65 (comment) For me it sounds like random ideas or jokes. Is that a problem?

NekR commented Oct 24, 2016

@spicyj hmm.. which tone? It was addressed directly to the comment right before mine, this one: #65 (comment) For me it sounds like random ideas or jokes. Is that a problem?

@klimashkin

This comment has been minimized.

Show comment
Hide comment
@klimashkin

klimashkin Oct 24, 2016

@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

klimashkin commented Oct 24, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@sophiebits

sophiebits Oct 24, 2016

Member

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

Member

sophiebits commented Oct 24, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@NekR

NekR Oct 24, 2016

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

NekR commented Oct 24, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@fibo

fibo Oct 25, 2016

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 commented Oct 25, 2016

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

This comment has been minimized.

Show comment
Hide comment
@fibo

fibo Oct 25, 2016

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

fibo commented Oct 25, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@NekR

NekR Oct 25, 2016

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

NekR commented Oct 25, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@jeremenichelli

jeremenichelli Oct 25, 2016

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.

jeremenichelli commented Oct 25, 2016

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

This comment has been minimized.

Show comment
Hide comment
@sebmarkbage

sebmarkbage Oct 25, 2016

Member

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

Member

sebmarkbage commented Oct 25, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@jeremenichelli

jeremenichelli Oct 25, 2016

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

jeremenichelli commented Oct 25, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@sunstorymvp

sunstorymvp Oct 25, 2016

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.

sunstorymvp commented Oct 25, 2016

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

This comment has been minimized.

Show comment
Hide comment
@lesterzone

lesterzone Oct 26, 2016

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

lesterzone commented Oct 26, 2016

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

@tracker1

This comment has been minimized.

Show comment
Hide comment
@tracker1

tracker1 Oct 28, 2016

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

tracker1 commented Oct 28, 2016

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

This comment has been minimized.

Show comment
Hide comment
@sebmarkbage

sebmarkbage Oct 28, 2016

Member

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

Member

sebmarkbage commented Oct 28, 2016

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

@klimashkin

This comment has been minimized.

Show comment
Hide comment
@klimashkin

klimashkin Oct 28, 2016

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

klimashkin commented Oct 28, 2016

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

@neiker

This comment has been minimized.

Show comment
Hide comment
@neiker

neiker Nov 1, 2016

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

neiker commented Nov 1, 2016

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

This comment has been minimized.

Show comment
Hide comment
@sebmarkbage

sebmarkbage Nov 1, 2016

Member

@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} /></>;
Member

sebmarkbage commented Nov 1, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@tz5514

tz5514 Nov 3, 2016

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

tz5514 commented Nov 3, 2016

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

@ichpuchtli

This comment has been minimized.

Show comment
Hide comment
@ichpuchtli

ichpuchtli Nov 4, 2016

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.

ichpuchtli commented Nov 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@mvolkmann

mvolkmann Nov 4, 2016

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.

mvolkmann commented Nov 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ichpuchtli

ichpuchtli Nov 5, 2016

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

ichpuchtli commented Nov 5, 2016

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

@adrian1358

This comment has been minimized.

Show comment
Hide comment
@adrian1358

adrian1358 Nov 9, 2016

image

Can we add this ? Quick single line commenting :)

adrian1358 commented Nov 9, 2016

image

Can we add this ? Quick single line commenting :)

@mvolkmann

This comment has been minimized.

Show comment
Hide comment
@mvolkmann

mvolkmann Nov 9, 2016

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.

mvolkmann commented Nov 9, 2016

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.

@jpeg729

This comment has been minimized.

Show comment
Hide comment
@jpeg729

jpeg729 Nov 19, 2016

@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 commented Nov 19, 2016

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

@adrian1358

This comment has been minimized.

Show comment
Hide comment
@adrian1358

adrian1358 commented Nov 23, 2016

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

@jpeg729

This comment has been minimized.

Show comment
Hide comment
@jpeg729

jpeg729 Nov 23, 2016

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

jpeg729 commented Nov 23, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@jokeyrhyme

jokeyrhyme Nov 25, 2016

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

jokeyrhyme commented Nov 25, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Nov 30, 2016

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

ghost commented Nov 30, 2016

+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

This comment has been minimized.

Show comment
Hide comment
@drcmda

drcmda Dec 3, 2016

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

drcmda commented Dec 3, 2016

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

This comment has been minimized.

Show comment
Hide comment
@gt3

gt3 Dec 13, 2016

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

gt3 commented Dec 13, 2016

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

This comment has been minimized.

Show comment
Hide comment
@wqj97

wqj97 Dec 16, 2016

What about annotation
image

wqj97 commented Dec 16, 2016

What about annotation
image

@neiker

This comment has been minimized.

Show comment
Hide comment
@neiker

neiker Dec 16, 2016

What about no

neiker commented Dec 16, 2016

What about no

@sebmarkbage

This comment has been minimized.

Show comment
Hide comment
@sebmarkbage

sebmarkbage Dec 16, 2016

Member

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.

Member

sebmarkbage commented Dec 16, 2016

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.

@facebook facebook locked and limited conversation to collaborators Dec 16, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.