Given the following
```js
a = <F new/>
```
We used to generate:
```js
a = React.createElement(F, {"new": true})
```
but now we generate
```js
a = React.createElement(F, {new: true})
```
If you need to quote these (ie for ES3 you can use
transform-property-literals)
* Bail out on JSX fragments instead of throwing
The `transform-react-inline-elements` plugin doesn't handle JSX fragments. It throws an exception because `node.openingElement` is undefined.
* Add a comment explaining `node.openingElement`
* Use helper-builder-react-jsx inside plugin-transform-react-inline-elements.
This avoids duplicating the logic for converting jsx elements to plain JavaScript.
* Add a comment which explains the _jsx signature, [skip ci]
so it is a little bit easier to understand what all those .splice() calls do
* Remove whitespace generation and rely on default printing
Changes to printing:
* Add newline after last empty SwitchCase
* Add newlines around block comments if they are non-flow comments or contain newlines
* Fix a few more fixtures
- Have the `jsx` helper do the `defaultProps` work instead of calling `defaultProps` inline.
- Put `key` after `props` and make it optional.
- Inline `children` as rest args instead of in the object.
- Rename `createRawReactElement` to `jsx`. I wish I was kidding.
Most of these are silly microoptimizations. In my test file (based off an internal RN app), this reduces the parsing overhead of inlining from around 1% to 0.1% in JSC and from 0.6% to 0.0% in V8 (compared to element inlining before this commit).
Once parsed, the initial render with inlining is the same speed as not inlining in JSC and ~1% slower in V8. A second initial render in the same context (reusing the function objects, JIT, etc) is 2.0% faster in JSC and 5.5% faster in V8.
Either due to lower parsing costs or better type inference, this seems
to perform better than direct object inlining. (All along, the main win
was skipping a loop through props, not avoiding a function call.)
