`render` as a function of props and state

[chenglou]

This comes from my discussion with several people around animation, but I feel like it's important enough to warrant its own issue.

We already insist that render should be a pure function of this.props and this.state. How about taking this further and pass those in CompositeComponent? This way we can write:

render: function(props, state) {
  return <div>{props.something}</div>;
}

While most of the time we'll still call render(this.props, this.state) internally, with this we will be able to do render(somePrevProps, someTestState) from React or even from the user. Being able to "test the water" would be very valuable in the future. For example:

componentWillReceiveProps: function(nextProps) {
  var result1 = this.render(this.props, this.state);
  var result2 = this.render(nextProps, this.state);
  // Collection of changed stuff. Good for preparing mounting/unmounting animations or such logic.
  React.reconciler.getDiff(result1, result2);
  this.setState({...});
}

I've heard this can also solve some problems with pendingState? Not too familiar with the issue.
@jordwalke @sebmarkbage @petehunt

[sebmarkbage]

As you mentioned in the end. This API change shouldn't be considered in isolation, but with all other life cycle events and how this correspond to prev/current/next at every stage.

[sophiebits]

cf.

#122 Pending state updates may be confusing
#629 Store pending state updates directly in this.state

[syranide]

Though kind of unrelated, I personally would :+1 this in isolation, in a lot of cases this.props.whatever becomes quite tedious and a visual annoyance. Being able to avoid this. without having to declare them locally at the start of every render would be nice.

[sebmarkbage]

Note that there's a potential hazard here if this.state were the pending state. Callbacks that refer to this can be updated with new references locally, but closures cannot. Closures cannot get access to pending state. Likewise this issue can occur if we had partial reconciliation.

render() {
  return <div onClick={() => doSideEffect(this.state.x)} />;
}
// is not equivalent to
render() {
  var x = this.state.x;
  return <div onClick={() => doSideEffect(x)} />;
}
// or
render() {
  var state = this.state;
  return <div onClick={() => doSideEffect(state.x)} />;
}
// or
render(state) {
  return <div onClick={() => doSideEffect(state.x)} />;
}

I think that it's possible to have the same issue with this.props and this.refs but don't have a case off the top of my head.

[syranide]

@sebmarkbage Oh yeah you're right, at least if we allow the user to replaceState the object itself (like we already do I assume), which is neat in that whatever the user provides it gets (like numbers). Also yeah, the exact same thing would be true of props if we don't reuse the same object.

[YurySolovyov]

+1 on that, what are general arguments against passing props and state to render function?

[nhunzaker]

+1 from here too. I really wish the drawbacks about pending state weren't an issue. Though my desires for this are purely aesthetic.

Edit: Though additionally, it would make PureRenderMixin more declaratively accurate in its name

[nhunzaker]

Maybe it's a terrible idea, but what if you passed this? Then you could use destructuring to get something similar:

render({ props, state }) {
    // do stuff
}

Maybe this is worse, but I wanted to get the idea on the table

EDIT: actually this works for me already:

render({ props, state } = this) {
    // do stuff
}

but that's hardly fantastic, I think

[chenglou]

Is this still alive? @sebmarkbage you can just pass a state reference to the callback and tell them to use that instead right? That's what tween-state does. Breaks a lot of code though.

[alexpods]

If you want to pass props and state to the render method, then I think you must pass context too. In this case It will look a little weird to me. For example if someone uses only context property:

// You must write `pass` and `state` arguments although you aren't using them.
render(props, state, context) {
    return <span>{context.name}</span>
}