Babel plugin JSX: Implement Fragment handling

[sirreal]

Closes #12207

Description

As described in #12207, the Babel plugin package that adds imports for JSX now handles Fragments as well:

function MyComponent( props ) {
  return <>
    <h1>Hello!</h1>
    <h2>👋</h2>
  </>;
}

/* ⬇️ After transform ⬇️ */

import { createElement, Fragment } from '@wordpress/element';
function MyComponent( props ) {
  return <>
    <h1>Hello!</h1>
    <h2>👋</h2>
  </>;
}

Replace <Fragment /> usage with <> and remove the Fragment imports where possible in the codebase. This may be better suited as a follow up PR.

How has this been tested?

Includes additional tests.

Types of changes

New feature: Add Fragment handling to the Babel plugin import JSX pragma package as outlined in #12207.

<></> will add a Fragment import if scopeVariableFrag is set and the import doesn't exist.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.

[sirreal]

Should the preset be updated with the recommended config as well?

gutenberg/packages/babel-preset-default/index.js

Lines 57 to 67 in 354c1ff

	[
	require.resolve( '@wordpress/babel-plugin-import-jsx-pragma' ),
	{
	scopeVariable: 'createElement',
	source: '@wordpress/element',
	isDefault: false,
	},
	],
	[ require.resolve( '@babel/plugin-transform-react-jsx' ), {
	pragma: 'createElement',
	} ],

[gziolo]

Should the preset be updated with the recommended config as well?

Sure, why not. If we start using it in Gutenberg, it should be exposed to everyone. It will require adding a note to the changelog file. It seems to be a new feature, right?

[sirreal]

I've pushed a couple of commits that update the codebase to exercise the new functionality for handling JSX <> Fragment imports as well as the babel preset. I've also updated documentation accordingly where I found references to <Fragment />.

I'm happy to roll back those commits or break them out into another PR.

[aduth]

I'm happy to roll back those commits or break them out into another PR.

Technically I'd think they'd be better for a separate pull request, though I don't really feel strongly about it. You may encounter some issue with merge conflicts if it's left to review for much longer.

[aduth]

Can you explain why this was changed?

[sirreal]

Yes, I noticed that without this change, the following test fails (added in this PR):

it( 'adds import for scope variable for Fragments', () => {
	const original = 'let foo = <></>;';
	const string = getTransformedCode( original );

	expect( string ).toBe( 'import React from "react";\nlet foo = <></>;' );
} );

  ● babel-plugin-import-jsx-pragma › adds import for scope variable for Fragments

    expect(received).toBe(expected) // Object.is equality

    Expected: "import React from \"react\";
    let foo = <></>;"
    Received: "let foo = <></>;"

      27 |
      28 |
    > 29 |              expect( string ).toBe( 'import React from "react";\nlet foo = <></>;' );
         |                               ^
      30 |      } );
      31 |
      32 |      it( 'does nothing if there is no jsx', () => {

      at Object.toBe (packages/babel-plugin-import-jsx-pragma/test/index.js:29:20)

It seems that JSX is an alias for most or all JSX that may be encountered.

It seems that <></> should cause the import to be added.

[aduth]

Re: Abbreviations. I suppose part of the purpose is in inheriting the Babel option by the same name?

https://babeljs.io/docs/en/babel-plugin-transform-react-jsx#pragmafrag

A bit unfortunate naming. I guess I'd rather be consistent than avoid the abbreviation, though.