Add support for JSX fragments

[mindplay-dk]

JSX fragments are a thing now - we should add support for this.

Note @JorgeBucaran: since you're planning to rewrite the diff algo, I'd suggest writing it with fragments in mind - that is, work from the assumption that everything is a set. It's generally simpler/easier to work from the assumption of zero-or-more sets of (V)Nodes than dealing conditionally with nulls. (I tried to work from that assumption in my own rewrite, where, internally, the patch operation works with sets, and the public patch-function starts by dealing with null by turning it into an empty set, so that the internal algo doesn't need to deal with nulls at all.)

[jorgebucaran]

@mindplay-dk Hmm, not really sure I'd want this at all, but why? What are the benefits; how does this help me make apps?

[mindplay-dk]

It enables you to implement functional components that return a range of elements - in other words, you're not longer forced to start every component with a (sometimes dummy) wrapper element.

Anyways, it's what JSX is now - it's already supported both by Babel and Typescript.

[mindplay-dk]

It's definitely low on my wishlist though - the critical thing (IMO) is sorting out the life-cycle events. Once that's done, I can actually start building my app with this 😄

[jorgebucaran]

@mindplay-dk It enables you to implement functional components that return a range of elements - in other words, you're not longer forced to start every component with a (sometimes dummy) wrapper element.

We can create components that return a range of elements already!

const MyList = props => [<p>A</p>, <p>B</p>, <p>C</p>]

What we don't currently support is patching a root node that it itself is an array.

[mindplay-dk]

We can create components that return a range of elements already!

I know, but that's kind of ugly, and it's not how the JSX community wants to do it.

What we don't currently support is patching a root node that it itself is an array.

React also does not support that, as far as I know - the point of JSX fragments, if I understand correctly, is merely to be able to create a range of elements using XML-like JSX syntax, without having to wrap it in braces and brackets.

Anyhow, as said, this is definitely not a high priority for me, personally - but the community has decided they want this, and it's likely not much work to support it, especially if you factor your new implementation so it consistently operates on sets.

I'm much more interested in solving the ordering issues, for one :-)

[jorgebucaran]

You mean "the community" would prefer to rewrite my example as 😮

const MyList = props =>
  </>
    <p>A</p>
    <p>B</p>
    <p>C</p>
  </>

?

[mindplay-dk]

?

Apparently, yeah 😆

[Pyrolistical]

the syntax is

const MyList = props =>
  <>
    <p>A</p>
    <p>B</p>
    <p>C</p>
  </>

and the main advantage is text nodes. people rather write <>hello<hr/></> over ['hello', <hr/>]

[jorgebucaran]

@Pyrolistical What does it compile to?

[Pyrolistical]

i don't understand your question, <>hello<hr/></> compiles to the same thing as ['hello', <hr/>]

[jorgebucaran]

Well, that answers the question. Thanks!

[Pyrolistical]

Apparently in order to support this you need to expose a function and set it to paramFrag

https://github.com/babel/babel/blob/master/packages/babel-plugin-transform-react-jsx/README.md