JSX for Reason #647

SanderSpies · 2016-07-16T21:21:04Z

DO NOT MERGE

What I want to get working:

let selfClosing = <Foo />;
let selfClosing = <Foo a={1} b={true} />;
let a = <Foo> <Bar c={fun a => a + 2} /> </Foo>;
let text = <Yo>"string"</Yo>;

which should be translated into something like:

let selfClosing = Foo.createElement []
let selfClosing = Foo.createElement a::1 b::true [];
let a = Foo.createElement [Bar.createElement c::(fun a => a + 2) []];
let text = Yo.createElement ["string"];

Although this PR is far from finished (I've only tested the feasibility in the parser) I'd like to get the discussion started.

Current limitations:

using quoted strings
spaced needed between > and <

What do you guys think of adding JSX support like this?

bsansouci · 2016-07-16T21:34:46Z

Wow this is amazing. Thanks for doing this!

SanderSpies · 2016-07-18T02:01:03Z

Update: this should be fairly simple to finish.

Syntax-wise I now have support for:

let selfClosing = <Foo />;
let selfClosing = <Foo a={1} b={true} />;
let a = <Foo> <Bar c={fun a => a + 2} /> </Foo>;
let a = <So> <Much> <Nesting> </Nesting> </Much> </So>;
let a = <Sibling> <One test={true}/> <Two foo={b}> </Two> </Sibling>;
let a = <Foo>"testing a string here"</Foo>;
let a = <Foo>"testing a string here" <Test /> "another string" <Bar> </Bar>{ 2 + 4 }</Foo>;

Wiring everything up is also straightforward, I just need to figure out how to perform the nesting of children within the AST.

SanderSpies · 2016-07-18T20:08:17Z

Ready for review.

yunxing · 2016-07-18T20:11:30Z

woah this is sick!

jordwalke · 2016-07-18T22:54:58Z

One thing I always wanted in JSX, was the ability to put any simple expression to the right of the =.

let x = <Component count=10 point={x: 0, y:0} callBack=(fun x => x) />

jordwalke · 2016-07-18T22:58:59Z

I'm trying to think of ways that this could conflict with custom infix operators such as:

let ( /> ) a b => a + b;

If so, we'd need to provide operator swapping support for the set of operators that conflict.

chenglou · 2016-07-18T23:17:02Z

Big request while this is still in its early phase: prop punning please.
<Foo prop1 prop2>
This'll prevent early flux-ification where devs start pulling props out into stores for the sake of looking at less props.

yunxing · 2016-07-18T23:18:51Z

How do we swap "createElement" with something else? Do we ever have the need?

sophiebits · 2016-07-18T23:20:43Z

I personally see the primary advantage of JSX being the matching closing tags; the other syntax differences don't seem as valuable to me.

So I wonder if we can find something with that benefit but without special complicated syntax rules that JSX introduces (ex: whitespace parsing, entity escaping, similar spread operator but no shorthand property support). I like that your PR here already is much more minimalist than JSX.

chenglou · 2016-07-18T23:24:05Z

@spicyj is it possible for us to eliminate the needs of jsx if we auto insert comments for "closing tags"?

normalFunc prop1::value 
  (normalFunc2 prop2::value) // "self-closing". No comment needed here really...
// normalFunc end

sophiebits · 2016-07-18T23:26:50Z

Interesting. Maybe!

jordwalke · 2016-07-18T23:34:50Z

I pitched that idea when first building support for JSX in JS and for some reason people didn't get as excited about it as true JSX support.

chenglou · 2016-07-18T23:40:06Z

Yeah but times have changed and people like functions more than HTML now! (jk no idea what I'm saying).

The good thing about using comments is that it provides a nice down(up?)grade path, where people who don't like matching closing tags can simply remove the comment. Also this would be editor-level rather than syntax level. But I'm sure you've heard all of these before.

SanderSpies · 2016-07-19T05:04:49Z

@chenglou - Punning support has been added.

@jordwalke Not sure how feasible omitting { and } for attribute values is as the syntax will then conflict with things like exp GREATER exp.

SanderSpies · 2016-07-19T07:04:31Z

That was actually a lot easier then I thought, replacing expr with simple_expr did the trick.

bsansouci · 2016-07-19T07:04:45Z

@SanderSpies Wow you're a magician.

SanderSpies · 2016-07-19T20:04:16Z

Spread operator is out, as it's too troublesome to add.

SanderSpies · 2016-07-22T04:43:24Z

I've added namespace support, eg. <Namespace.Foo.Bar />.
Spaces are now optional between tags
Ensured that the operators that worked before in Reason still work.

jordwalke · 2016-07-22T22:16:56Z

Spaces are now optional between tags

Awesome!

SanderSpies · 2016-07-23T05:07:27Z

I also like to support lowercase tags, simply because writing <div> is more pleasing to my eyes then <Div>. This currently doesn't work because OCaml's module identifier is capitalized. I was wondering if we could make this work in some smart way. So far unsuccessful though, so open for suggestions.

jordwalke · 2016-07-23T07:06:05Z

Lowercase could trivially be made into function calls, but come time to format, there's no way to know which lowercase functions to render as JSX and which ones not to. You could always parse (and therefore preserve at render time), some small attribute on those function application nodes which preserve its JSX-ness.

SanderSpies · 2016-08-18T15:19:40Z

Remaining work:

add tests for added tokens to ensure they can be used as operators if needed
improve fragment support (currently only tags)

# Conflicts: # src/reason_parser.messages # src/reason_parser.mly

SanderSpies · 2016-08-19T04:40:50Z

Check again please - esp. the added support for fragments.

jordwalke · 2016-08-27T08:26:14Z

src/reason_lexer.mll

@@ -510,6 +517,7 @@ rule token = parse
  | "-"  { MINUS }
  | "-." { MINUSDOT }
  | "<>" { LESSGREATER }
+  | "<><" { LESSGREATERLESS }


I think there's no test cases for this infix operator.

I tried this on the master branch at the time and it didn't work. Will try again.

jordwalke · 2016-09-01T05:26:29Z

Okay, I've got the printing working on top of the latest master (rebased).
There's some issues with how it's parsed though, and would require a bunch of hacky token splitting work. I'd rather not do the token splitting work if it's not necessary because the whole motivation for token splitting will go away once object types have {} syntax, so I don't want to add more use cases for token splitting when not needed. I think there's a way.
As it stands, with @SanderSpies' latest work to make jsx tokens considered simple in the parser, things like <X><Y> do not parse. (It fails on the <Y).

Here's what I believe the solution is: we need lexer rules that generate tokens for the following cases:

# One token
><Tag
# Two tokens
> <Tag

# One token
></Tag
# Two tokens
> </Tag

# One token
/></Tag
# Two tokens
/> </Tag

# One token
/><Tag
# Two tokens
/> <Tag

Where you see two tokens above one of those tokens is often one of these individual tokens:

</Tag
<Tag
/>

/> is the only token which might cause shift reduce conflicts with infix /> token, but I don't think it will. I think we can reuse the same token as /> infix without conflicts (let me know if I'm wrong). If it does cause unsolvable conflicts, then we'd have to express the infix /> as \/> but I hope it doesn't come to that.

The following should parse correctly as well:

   simple + simple
   <t /> + <t />
   <t> </t > + <t> </t >

and

   simple simple simple
   myFunc <t /> <t />

Constraints:

In order for this to work, without ruining the natural ability for people to use > and < without being confused for JSX tags, the following must be true:

Closing tags must be written as </t> not </t > (I think)
Opening tags must be written as <tag and not < tag
Infix < must be written as x < y not x <y
Infix >< must be written as x >< y not x ><y
Infix /></ must be written as x /></ y not x/></y.
Infix />< must be written as x />< y not x/></y.

and so on. Those constraints above don't require any additional work in the parser/lexer/printer - they're just things the user must keep in mind.

If this is done in the parser, then the printer that I just rebased on master should work and we can merge this PR.

vjeux · 2016-09-14T02:36:55Z

@jordwalke One thing I always wanted in JSX, was the ability to put any simple expression to the right of the =.
let x = <Component count=10 point={x: 0, y:0} callBack=(fun x => x) />

I think that this is a mistake to support this. I understand the desire to fix JSX in order to make it what you wished it was and to use Reason as a good forcing function to do so. But this is going to yet another small difference between JavaScript and Reason that's going to be in the way of people trying to read/write both languages, for no obviously good benefit than a nice to have.

I'm not part of the project so feel free to disregard my opinion, but I think that there's a higher chance of it being more successful if it's seen as a "better JavaScript" than a "friendlier Ocaml".

If you want to run with my theory, then you should strive to make the syntax a good subset of JavaScript and only deviate when there's a strong and clear reason to do so. This is the pattern we used for React Native where we tried as much as possible to make it a good subset of the web.

Right now it seems like there's a desire to make it look like JavaScript but in practice, it's a weird mix of ocaml and js but the code doesn't look anything like actual JavaScript.

Anyway, I'm happy to chat more about it and this pull request is probably not the best forum for it, sorry about it :)

bobzhang · 2016-09-14T02:59:29Z

but I think that there's a higher chance of it being more successful if it's seen as a "better JavaScript" than a "friendlier Ocaml".

200% agree

jordwalke · 2016-09-14T06:58:55Z

@vjeux It's definitely a tough balance to strike and it might take a couple of attempts to find the sweet spot. We definitely want to keep moving Reason towards JS, the good parts. But to provide a counter-argument, there can be a positive effect to having some syntactic differences and a little bit of unfamiliarity. Remember when we released React with JSX, how it immediately filtered out a ton of people who were quick to dismiss something new? I think in retrospect that was the best possible outcome, even if accidental. To the observer, it almost looked like React flopped - and we can thank JSX for that. But the truth is that there was a great community being seeded. That's not to say we should make things worse or foreign just for the sake of it. But the truth is that if people want the benefits that sound static typing brings (safety + performance (optimized compilation)), they're going to have to learn some stuff. There's just no way around it. It can't be obtained via JavaScript as we know it today - JavaScript would have to be changed into something it's not and make the programmer learn many new concepts anyways.

So maybe it's the case that having some differences in syntax is a good way to manage expectations that there will be things to learn in order to reap those benefits. It could have the same beneficial filtering effect that JSX for React had. Thoughts?

But if you have some suggestions even beyond JSX, I'd love to hear them. A few people have even requested that parenthesis be mandatory around function arguments (we're also open to that suggestion as it makes named argument syntax much better - but opinions may vary).

But for JSX, why not go the other direction? Why not work towards JSX supporting simple expressions to the right of the = sign even in JavaScript?
Also, punning is really really great and we shouldn't neglect it just because JSX doesn't support it (if I could go back in time, I would have added punning to JSX from day one - instead an attribute with no =value is transpiled as attribute=true. JS itself didn't yet have punning - now it does, so maybe it's a good time to reevaluate).

jordwalke · 2016-09-14T07:20:46Z

Oh, and one other thing @vjeux. There's actually room for a couple different "layers" here. I think with what we have for Reason right now, even though it's got some inspiration from JS (the good parts), I really do believe it is a more friendly way to use OCaml since we've fixed the top ten reported syntactic pitfalls. The benefit of this mode is that it can perfectly be converted back and forth between OCaml and Reason (in theory). All function styles interop perfectly between the two worlds.

But if you're willing to give that up, there's all kinds of syntactic transforms we could do on top, even going as far as to recreate things from JS that we really believe are worse. These transforms would not be "recoverable"(you can't go back to plain Reason from them) and that would be totally okay. There's an entire spectrum we can/should explore, even if some of those solutions (that very much resemble JS) have performance drawbacks - because at the end of the day we maintain the most important thing - we have a way to write parts of our in something lower that performs better in a way that interops perfectly with all the other stuff that targets the same allocator.

vjeux · 2016-09-19T21:14:43Z

I was doing some archeology around React and you ( @jordwalke ) wrote the following in the initial diff that brought JSX to React.

Making the sugar sweeter:

I'd like to omit the need for braces in as many places as possible. Not sure how difficult that
would be.

So you were indeed write saying "One thing I always wanted in JSX, was the ability to put any simple expression to the right of the =." :)

SanderSpies · 2016-09-21T07:48:04Z

Closed due to #775

Start with implementing JSX.

18c52a9

facebook-github-bot added the CLA Signed label Jul 16, 2016

SanderSpies added 2 commits July 17, 2016 12:02

JSX syntax: add string and siblings support

0f72259

JSX syntax: add inline expressions

ed7123a

SanderSpies changed the title ~~[WIP] JSX support~~ JSX support Jul 18, 2016

ghost added the CLA Signed label Jul 18, 2016

ghost added the CLA Signed label Jul 19, 2016

Add fragment support.

529704c

SanderSpies added 4 commits August 19, 2016 05:29

Add support for expressions and constants for fragment children

38c4ec7

Ensure operator keeps working

036bcab

Update tests

bd34b6b

Merge branch 'master' of https://github.com/facebook/reason into jsx3

b96e83b

# Conflicts: # src/reason_parser.messages # src/reason_parser.mly

SanderSpies added 3 commits August 19, 2016 11:36

Forgot to commit .messages file.

2e9bff6

Remove curly braces for children.

f5d103d

Improve JSX simple_expression children pretty printing

b6eba43

chenglou mentioned this pull request Aug 25, 2016

Output to JSX rescript-lang/rescript-compiler#676

Closed

jordwalke reviewed Aug 27, 2016
View reviewed changes

ghost added the CLA Signed label Sep 1, 2016

ghost added the CLA Signed label Sep 14, 2016

ghost added the CLA Signed label Sep 19, 2016

SanderSpies closed this Sep 21, 2016

magnus-madsen mentioned this pull request Dec 1, 2019

Investigate Whether to Support JSX-style Syntax flix/flix#921

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

JSX for Reason #647

JSX for Reason #647

SanderSpies commented Jul 16, 2016

bsansouci commented Jul 16, 2016

SanderSpies commented Jul 18, 2016

SanderSpies commented Jul 18, 2016

yunxing commented Jul 18, 2016

jordwalke commented Jul 18, 2016

jordwalke commented Jul 18, 2016

chenglou commented Jul 18, 2016

yunxing commented Jul 18, 2016

sophiebits commented Jul 18, 2016 •

edited

Loading

chenglou commented Jul 18, 2016 •

edited

Loading

sophiebits commented Jul 18, 2016

jordwalke commented Jul 18, 2016

chenglou commented Jul 18, 2016

SanderSpies commented Jul 19, 2016

SanderSpies commented Jul 19, 2016

bsansouci commented Jul 19, 2016

SanderSpies commented Jul 19, 2016

SanderSpies commented Jul 22, 2016

jordwalke commented Jul 22, 2016

SanderSpies commented Jul 23, 2016 •

edited

Loading

jordwalke commented Jul 23, 2016

SanderSpies commented Aug 18, 2016 •

edited

Loading

SanderSpies commented Aug 19, 2016

jordwalke Aug 27, 2016

SanderSpies Aug 27, 2016

jordwalke commented Sep 1, 2016 •

edited

Loading

vjeux commented Sep 14, 2016 •

edited

Loading

bobzhang commented Sep 14, 2016 •

edited

Loading

jordwalke commented Sep 14, 2016 •

edited

Loading

jordwalke commented Sep 14, 2016

vjeux commented Sep 19, 2016

SanderSpies commented Sep 21, 2016

JSX for Reason #647

JSX for Reason #647

Conversation

SanderSpies commented Jul 16, 2016

bsansouci commented Jul 16, 2016

SanderSpies commented Jul 18, 2016

SanderSpies commented Jul 18, 2016

yunxing commented Jul 18, 2016

jordwalke commented Jul 18, 2016

jordwalke commented Jul 18, 2016

chenglou commented Jul 18, 2016

yunxing commented Jul 18, 2016

sophiebits commented Jul 18, 2016 • edited Loading

chenglou commented Jul 18, 2016 • edited Loading

sophiebits commented Jul 18, 2016

jordwalke commented Jul 18, 2016

chenglou commented Jul 18, 2016

SanderSpies commented Jul 19, 2016

SanderSpies commented Jul 19, 2016

bsansouci commented Jul 19, 2016

SanderSpies commented Jul 19, 2016

SanderSpies commented Jul 22, 2016

jordwalke commented Jul 22, 2016

SanderSpies commented Jul 23, 2016 • edited Loading

jordwalke commented Jul 23, 2016

SanderSpies commented Aug 18, 2016 • edited Loading

SanderSpies commented Aug 19, 2016

jordwalke Aug 27, 2016

Choose a reason for hiding this comment

SanderSpies Aug 27, 2016

Choose a reason for hiding this comment

jordwalke commented Sep 1, 2016 • edited Loading

Constraints:

vjeux commented Sep 14, 2016 • edited Loading

bobzhang commented Sep 14, 2016 • edited Loading

jordwalke commented Sep 14, 2016 • edited Loading

jordwalke commented Sep 14, 2016

vjeux commented Sep 19, 2016

SanderSpies commented Sep 21, 2016

sophiebits commented Jul 18, 2016 •

edited

Loading

chenglou commented Jul 18, 2016 •

edited

Loading

SanderSpies commented Jul 23, 2016 •

edited

Loading

SanderSpies commented Aug 18, 2016 •

edited

Loading

jordwalke commented Sep 1, 2016 •

edited

Loading

vjeux commented Sep 14, 2016 •

edited

Loading

bobzhang commented Sep 14, 2016 •

edited

Loading

jordwalke commented Sep 14, 2016 •

edited

Loading