Add Auto Import to Babel Plugin

[lunaruan]

This babel transform is a fork of the @babel/plugin-transform-react-jsx transform and is for experimentation purposes only. We don't plan to own this code in the future, and we will upstream this to Babel at some point once we've proven out the concept.

As per the RFC to simplify element creation, we want to add the ability to auto import "react' directly from the babel plugin. This commit updates the babel plugin with two options:

1.) importSource: The React module to import from. Defaults to react.
2.) shouldCacheImportFns: If this is set to true, React functions that are imported will be cached at the top of the file (ex. var _jsx = _react.jsx) instead of calling the member expression (ex. _react.jsx) directly in the code. Defaults to false.
3.) autoImport: The type of import. Defaults to none.
- none: Does not import React. JSX compiles to React.jsx etc.
- namespace: import * as _react from "react";. JSX compiles to _react.jsx etc.
- default: import _default from "react"; JSX compiles to _default.jsx etc.
- namedExports: import {jsx as _jsx} from "react"; JSX compiles to _jsx etc.
- require: var _react = _interopRequireWildcard(require("react"));. jSX compiles to _react.jsx etc.

namespace, default, and namedExports can only be used when sourceType: module and require can only be used when sourceType: script.

It also adds two pragmas (jsxAutoImport and jsxImportSource) that allow users to specify autoImport and importSource in the docblock.

We plan to test #16432 before landing this diff.

[sebmarkbage]

@Jessidhia Why can’t we just emit a require call without the interop since we’re a CommonJS module in this mode?

[Jessidhia]

It's possible by giving options to the helper-module-imports calls (3rd argument).

https://github.com/babel/babel/blob/v7.5.5/packages/babel-helper-module-imports/src/import-injector.js#L21-L62

I'm not 100% sure this is public API as it's only documented here, but it could as well just be an omission from the docs since the jsdoc is pretty comprehensive.

[sebmarkbage]

We could add an additional option to emit a variable to cache these at the top of the file.

import * as _react from "react";
const _jsx = _react.jsx;
const _fragment = _react.Fragment;

...

var x = _jsx(_Fragment, {

For a native ES module system this wouldn't matter but the way most module transpilers are implemented this becomes an object. Which may need an indirection to load the object and then the current function in the object for each call. Instead of just loading the current function.

Note that this also applies to namedExports. It should be something like:

import {jsx as __jsx, Fragment as __Fragment} from "react";
const _jsx = __jsx;
const _fragment = __Fragment;

Modern browser VMs may optimize for the inline cache containing this information perhaps. So I don't think this matters but it might for Hermes.

Additionally this approach would slow down initialization of the module scope and use more memory.

So I doubt this approach will actually be better overall but it would be nice to have an option so we can experiment with it and test which one is faster in practice.

[rickyvetter]

Ditto for shadowing question and tests on these variables if we add this!

[sophiebits]

I believe I tested this once with React.createElement in V8 and found it didn't make a significant difference (IIRC slightly worse; definitely wasn't better or I would've gone through with it).

[sebmarkbage]

Yea I tested it as well and came to the same conclusion. So we’re not doing this.

The key is that as long as the VM optimizes for storing methods on the object hidden class it’s guaranteed to be worse once you use more than one method.

What I’m wondering next is if it would be worth while having React be a global property.

[rickyvetter]

I don't know too much about generateUidIdentifier but it seems like it's limited to the scope you call it in. How much do you care about shadowing? I can imagine a number of ways that _react could be created in the file but in different scopes that might mess with your usage here. Does generateUidIdentifier handle all possible scopes in the file? Would be good to have a test if it does! Here's a tricky-ish example:

const Component = ({thing, ..._react}) => {
  if (!thing) {
    var _react2 = "something useless";
    return <div />;
  };
  return <span />;
};

[lunaruan]

generateUidIdentifier would generate an identifier that doesn't collide with any locally defined variables, so it doesn't just consider the scope it was called in. So in that case it generates:

import * as _react3 from "react";
var _jsx = _react3.jsx;

const Component = function ({
  thing,
  ..._react
}) {
  if (!thing) {
    var _react2 = "something useless";
    return _jsx("div", {});
  }

  ;
  return _jsx("span", {});
};

I added a couple of tests to verify this!

[rickyvetter]

Ditto for shadowing question and tests on these variables if we add this!

[lunaruan]

This PR has not been abandoned. Still working on adding it to WWW.

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit ac7d715:

Sandbox	Source
vigorous-yalow-sp1ul	Configuration

[sizebot]

No significant bundle size changes to report.

Size changes (stable)

Generated by 🚫 dangerJS against ac7d715

[sizebot]

No significant bundle size changes to report.

Size changes (experimental)

Generated by 🚫 dangerJS against ac7d715

[sebmarkbage]

Should probably fix lints and land this.