Optimizing Compiler: Inline ReactElements

[sebmarkbage]

Starting with React 0.14 we will be able to inline ReactElements:

<div className="foo">{bar}<Baz key="baz" /></div>

as objects:

{ type: 'div', props: { className: 'foo', children:
  [ bar, { type: Baz, props: { }, key: 'baz', ref: null } ]
}, key: null, ref: null }

This improves performance over the existing React.createElement call by inlining the result of it.

defaultProps

If a component might have default props they need to be resolved by the transpiler's runtime:

{ type: 'div', props: { className: 'foo', children:
  [ bar, { type: Baz, props: $resolveDefaults(Baz.defaultProps, { }), key: 'baz', ref: null } ]
}, key: null, ref: null }

Exception: ref="string"

Unfortunately we still haven't figured out what the final semantics for refs. The current semantics relies on getting the current React owner. Therefore, we cannot apply this optimization if the ref attribute might be a string.

render() {
  // Neither of these...
  return <div ref="str" />;
  // ...are safe to inline...
  return <div ref={possibleStringValue} />;
  // ...because they might contain a ref.
  return <div {...objectThatMightContainARef} />;
}

Non-JSX

This can work on React.createElement or functions created by React.createFactory if the first argument is an inline object literal. Otherwise it is not safe since the object might be reused and mutated.

Only in Production Mode

This optimization should only be applied in production mode. Currently React.createElement fires various warnings for propTypes and key warnings if the __DEV__ flag is set to true or "production" !== process.env.NODE_ENV. This optimization would skip the warnings which would be very very bad in development mode.

The difficult part of this is figuring out a way that this will work in everyone's environment because not everyone has the ability to use different transpilers for development and production mode.

One solution might be to use a ternary and rely on minifiers to strip out the extra code:

"production" === process.env.NODE_ENV ?
  { type: 'div', props: { ... }, key: null, ref: null } :
  React.createElement('div', ...)

This will a pain for source maps though.

Another solution would be to have different flags in the transpilers themselves but we'd have to make sure that people actually use them correctly. They will otherwise have problems due to not firing warnings, or think that React is slow because they screwed up their config.

[sebmarkbage]

cc @sebmck

[sebmck]

The difficult part of this is figuring out a way that this will work in everyone's environment because not everyone has the ability to use different transpilers for development and production mode.

What do you mean by using different transpilers? You'd just be using the same transpiler flick a switch unless I'm misunderstanding something?

Another solution would be to have different flags in the transpilers themselves but we'd have to make sure that people actually use them correctly. They will otherwise have problems due to not firing warnings, or think that React is slow because they screwed up their config.

Developers already know to use a different build of React for development and production so I don't think it'll be confusing to introduce the same concept to the transpilation step. I've been toying with the idea of having a production and development mode in Babel as there are things like TDZ that I really want to enable by default but would absolutely kill performance in hot code and their only purpose is to basically prevent development errors.

[sebmarkbage]

What do you mean by using different transpilers? You'd just be using the same transpiler flick a switch unless I'm misunderstanding something?

Yea, that's what I meant.

Developers already have minifiers that they only use in production mode. This is effectively the same thing.

[sebmck]

Ah, right. Yeah, definently more a developer education issue than a technical one.

[sebmarkbage]

Nit: developer education is a technical issue. :) Look at how much technical trouble we go through to add warnings and locking down the API so that developers don't unknowingly shoot themselves in the foot.

[sebmck]

Yeah, absolutely agree. Probably should have been more specific, I was referring specifically to educating developers about any potential "production" mode in transpilers since there's no real way to warn them if they've compiled their production code in development mode.

[syranide]

@sebmarkbage

Unfortunately we still haven't figured out what the final semantics for refs. The current semantics relies on getting the current React owner. Therefore, we cannot apply this optimization if the ref attribute might be a string.

There were mentions in the past of "inverting" refs, you instead provide a ref-object to ref which is updated. That sounded great to me, it gets rid of the implicit owner and possibly even the magic object... additionally you could set up a refs-object which could take care of lists of components, this does not work well today with strings.

But... what if we implemented ref as a callback(s) instead which receives the instance as an argument and something to distinguish whether it was mounted or unmounted, kind of similar to how onChange/valueLink works in a sense. That way we leave exact implementations up to the user and there is no preference for either individual instances or lists of instances nor where you store them (if you even store them). These could even be chained easily. But this is no longer a system for refs, it's basically externally chainable life-cycle method listeners which can be used to reimplement refs.

I imagine this could have other benefits in the future; expose all life-cycle callbacks and you could use it to say easily measure frontend objects without ever having to store the instance, nor provide complex logic to determine whether or not the frontend object actually updated. This exact use-case is just an idea, but this approach seems a lot more React:y, reusable and naturally efficient than refs which seems like something you should avoid unless explicitly dealing with uncontrolled components in which case you have no other option.

Perhaps I'm way off on the utility here, but it seems to me that it solves a lot of problems that refs as meant to solve but in better ways and actually storing refs should only necessary when dealing with uncontrolled components. All other uses should reasonable be capable of doing its thing directly on instance when the callback is called.

Re-implementing refs as-is could look something like the code below, it could easily be made into a reusable helper. It could take any number of shapes, perhaps a key isn't even interesting and just putting all instances in a Set is enough. You decide.

function createRef(that, name, next) {
  return {
    next: next,
    componentDidMount: function(instance) {
      that.refs[name] = instance;
    },
    componentWillUnmount: function(instance) {
      delete that.refs[name];
    }
  };
}

To keep updated measurements of a component you would simply as below, if the editor didn't update then you automatically avoid re-measuring for free. If only the editor updates, but not your own component, you still remeasure and get the updated height.

<Editor lifeCycle={{
  componentDidMount: (instance) => {
    this.setState({editorHeight: instance.measureHeight()});
  },
  componentDidUpdate: (instance) => {
    this.setState({editorHeight: instance.measureHeight()});
  }
}} />

[sebmarkbage]

@syranide We already implemented both first-class refs and then switched them to callbacks in #2917. You haven't been keeping up. :)

It is not very convenient and very imperative since you need to keep your own reference to it. The timing of life-cycles isn't ideal too. Therefore I'm not comfortable deprecating the current refs until we're sure which model is final, and make sure that we have a good upgrade path (codemodable).

[syranide]

@sebmarkbage * facepalm * ;)