Skip to content
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
Open

JSX 2.0 #65

sebmarkbage opened this issue Oct 12, 2016 · 136 comments

Comments

@sebmarkbage
Copy link
Member

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

Copy link
Contributor

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

Copy link
Contributor

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

Copy link

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

Copy link

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

Copy link

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

Copy link

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

Copy link

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

Copy link

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

Copy link
Contributor

@syranide syranide commented Oct 16, 2016

@jasonslyvia That's what fragments are for.

@alistairhutton

This comment has been minimized.

Copy link

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

Copy link

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

Copy link

@jasonslyvia jasonslyvia commented Oct 16, 2016

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

@lacker

This comment has been minimized.

Copy link

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

Copy link

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

Copy link

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

Copy link

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

Copy link

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

Copy link

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

Copy link

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

Copy link

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

Copy link

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

Copy link

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

Copy link

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

Copy link

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

Copy link

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

Copy link

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

Copy link

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

Copy link

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

Copy link

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

@NekR

This comment has been minimized.

Copy link

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

Copy link

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

Copy link
Member Author

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

Copy link

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

Copy link

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

Copy link

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

Copy link

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

Copy link
Member Author

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

Copy link

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

Copy link

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

Copy link
Member Author

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

Copy link

@tz5514 tz5514 commented Nov 3, 2016

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

@ichpuchtli

This comment has been minimized.

Copy link

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

Copy link

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

Copy link

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

@doitadrian

This comment has been minimized.

Copy link

@doitadrian doitadrian commented Nov 9, 2016

image

Can we add this ? Quick single line commenting :)

@mvolkmann

This comment has been minimized.

Copy link

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

Copy link

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

@doitadrian

This comment has been minimized.

Copy link

@doitadrian doitadrian commented Nov 23, 2016

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

@jpeg729

This comment has been minimized.

Copy link

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

Copy link

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

Copy link

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

Copy link

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

Copy link

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

Copy link

@wqj97 wqj97 commented Dec 16, 2016

What about annotation
image

@neiker

This comment has been minimized.

Copy link

@neiker neiker commented Dec 16, 2016

What about no

@sebmarkbage

This comment has been minimized.

Copy link
Member Author

@sebmarkbage 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.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.