Add JSXSpreadChild

[calebmer]

As per discussions in #57 and babel/babylon#42.

This syntax is the same one I used in writing babel/babylon#42

cc @syranide, @sebmarkbage, @kittens

[calebmer]

Are there any comments? Could we merge this? I’d like to see this functionality adopted in parsers, so it’s important to see this extension in the language.

[sebmarkbage]

Seems fine to me. Merged.

[RReverser]

nit: I would put opt here. as it was before Technically it doesn't matter for the grammar, but would be cleaner to see that the content between braces is optional.

[calebmer]

Yeah, I like that better too 😉

[calebmer]

See #61

[RReverser]

@calebmer @sebmarkbage Does anyone remember why we introduced a separate node type for this and not reused SpreadElement from ESTree which has the same structure and visual syntax?

[calebmer]

@RReverser I don’t think there was a specific reason. I defaulted to creating a new type which may be better for extensibility in the future.

[sebmarkbage]

What does ESTree do for spread properties (object spread)?

[RReverser]

@sebmarkbage

interface SpreadElement <: Node {
    type: "SpreadElement";
    argument: Expression;
}

[RReverser]

@sebmarkbage Ah sorry, just realised that I misunderstood your question. See https://github.com/estree/estree/blob/master/experimental/rest-spread-properties.md - it also reuses SpreadElement / RestElement, hence my suggestion to use the same one in JSX for uniformity.

[sebmarkbage]

I'm skeptical of seeking reuse for things that are specified as separate things in the syntax spec. It seems like a fragile future compatibility issue and convenience issue. E.g. for matchers in Babel or for implementing evaluators.

According to the last TC39 meeting, rest properties will no longer allow a nested pattern - unlike rest element. Only identifiers. So they've already diverged and might diverge more in the future.

[RReverser]

shrugs AST is mostly for syntactic representation of things, there are better IRs for evaluators and checkers. And syntactically this is indeed ... + expression in both places, so can be used by parsers and serializers as such.