Add support using x as a JSX pragma

[wooorm]

This PR tests that xastscript can be used as the pragma for JSX with bublé
and babel.

Code-wise, this adds support for using x to generate root nodes.
This is done by omitting the tag name (like so: x(), x(null, 'child')).
Previously, omitting a name resulted in an exception.

Another aspect of supporting JSX is supporting fragments as children.
As fragments yield root nodes, we unravel them and use only their children.
While this could be seen a change, xast prohibits roots occurring in nodes,
so the unraveling instead fixes what would otherwise be a broken tree.

Related to: GH-3.

/cc @remcohaszing, @ChristianMurphy

[ChristianMurphy]

LGTM 👍

[remcohaszing]

This happened really fast.

I think the idea of using null to define fragments is clever, although it doesn’t work with TypeScript and I doubt if using this to define the root element is the most useful use case.

What about adding support for adding actual functional components, so these can be used to generated non-element nodes.

I.e. the root node:

Implementation:

function Root(props, ...children) {
  return { type: 'root', children };
}

Usage:

/** @jsx h */
const { Root, x } = require('hastscript')

module.exports = (
  <Root>
    <foo>
      <bar />
    </foo>
  </Root>
)

This way more types of nodes can be defined as well, i.e.:

/** @jsx h */
const { Comment, Doctype, Instruction, Root, x } = require('hastscript')

module.exports = (
  <Root>
    <Doctype name="" public="" system="" />
    <Instruction name="" />
    <Comment>Hello</Comment>
    <foo>
      <bar />
    </foo>
  </Root>
)

The implementation in x would be something along the lines of the following, where children is flattened:

if (typeof tag === 'function') {
  return tag(attributes, ...children)
}

I think the most common use case for fragments is to do something like this:

/** @jsx h */
const { Comment, Fragment, Root, x } = require('hastscript')

module.exports = (
  <Root>
    <Doctype name="" public="" system="" />
    <Instruction name="" />
    <people>
      {people.map(person => (
        <>
          <name>{person.name}</name>
          <age>{person.age}</age>
        </>
      ))}
    </people>
  </Root>
)

[wooorm]

This happened really fast.

Yes, sorry!

although it doesn’t work with TypeScript

Would any other symbol work? React.Fragment is also just a value. Because undefined is handled too, and if this were CJS or we’d explicitly export Root as undefined or null, your first usage example works.

and I doubt if using this to define the root element is the most useful use case.

The changes in the API introduced in this PR are a two part act: yes, roots can be made, but roots are also unraveled. So fragments in your last example also work: https://github.com/syntax-tree/xastscript/pull/4/files#diff-f5b3878f8f75d9cd3df39252cba892d4689833207338622ddb3ae7ecb2c6ef17R106

What about adding support for adding actual functional components, so these can be used to generated non-element nodes.

This to me sounds like a different feature that could be added on top. Or not. As JSX handled Capitalized and members.of.objects as identifiers instead of strings, they can all be used already: https://github.com/syntax-tree/xastscript/pull/4/files#diff-f5b3878f8f75d9cd3df39252cba892d4689833207338622ddb3ae7ecb2c6ef17R44, if they resolve to valid values for name.

What is the benefit of adding “components”?

This way more types of nodes can be defined as well, i.e.:

Those nodes aren’t used a lot, is this an actual need? React also doesn’t support comments. Nodes can also already be passed as children: https://github.com/syntax-tree/xastscript#jsx.

If we’d just want to add other nodes, we could also support “templates”:

x.Comment = {type: 'comment'}
x.Doctype = {type: 'doctype'}
x.Fragment = undefined
x.Root = undefined

function x(name, attributes) {
  var node =
    name == null
      ? {type: 'root', children: []}
      : typeof name === 'object'
      ? Object.assign({}, name)
      : {type: 'element', name: name, attributes: {}, children: []}

  // ... and handle `attributes` as direct props instead of `node.attributes`
}

const { Comment, Doctype, Fragment, Root, x } = require('xastscript')

module.exports = (
  <Root>
    <Doctype name="" public="" system="" />
    <Instruction name="" />
    <people>
      {
        // ...
      }
    </people>
  </Root>
)

[remcohaszing]

although it doesn’t work with TypeScript

Would any other symbol work? React.Fragment is also just a value. Because undefined is handled too, and if this were CJS or we’d explicitly export Root as undefined or null, your first usage example works.

Apparently the React TypeScript definitions don’t match the React code here. I think your solution below to define Fragment / Root as undefined is pretty awesome. If this is then “wrongfully” typed as a function returning xast.Root, this should work with TypeScript.

I do love the idea fragments don’t need to be imported. :)

and I doubt if using this to define the root element is the most useful use case.

The changes in the API introduced in this PR are a two part act: yes, roots can be made, but roots are also unraveled. So fragments in your last example also work: https://github.com/syntax-tree/xastscript/pull/4/files#diff-f5b3878f8f75d9cd3df39252cba892d4689833207338622ddb3ae7ecb2c6ef17R106

I didn’t know that. That’s awesome! Never mind any of my objections then. :)

What about adding support for adding actual functional components, so these can be used to generated non-element nodes.

This to me sounds like a different feature that could be added on top. Or not. As JSX handled Capitalized and members.of.objects as identifiers instead of strings, they can all be used already: https://github.com/syntax-tree/xastscript/pull/4/files#diff-f5b3878f8f75d9cd3df39252cba892d4689833207338622ddb3ae7ecb2c6ef17R44, if they resolve to valid values for name.

What is the benefit of adding “components”?

The main reason for this was to define Root, Comment, or Doctype as functional components. Your “templates” solution works as well, although it does mean type definitions will have to be technically incorrect to support their usage in TypeScript.

It still may be useful to support components, so the XML tree can be composed using JSX syntax.

This way more types of nodes can be defined as well, i.e.:

Those nodes aren’t used a lot, is this an actual need? React also doesn’t support comments. Nodes can also already be passed as children: https://github.com/syntax-tree/xastscript#jsx.

This was basically a continuation on the thought Fragments must be functions.

[wooorm]

Apparently the React TypeScript definitions don’t match the React code here. I think your solution below to define Fragment / Root as undefined is pretty awesome. If this is then “wrongfully” typed as a function returning xast.Root, this should work with TypeScript.

and:

This was basically a continuation on the thought Fragments must be functions.

That seems weird? I thought this was pretty common? Such as: https://stackoverflow.com/a/33471928

It still may be useful to support components, so the XML tree can be composed using JSX syntax.

Yeah, I wonder how that’d work. If it would be useful.
Functions may be nicer than templates btw, as those could have deep props, and a factory is just easier than adding deep clone support.