Don't bail out on referential equality of Consumer's props.children function

[iamdustan]

I was playing around with the new context API and ran into some unexpected bail outs. The exact scenario was something like the following:

class React extends React.Component {
  state = { name: '' };
  onChange = (event) => {
    const { name, value } = event.currentTarget;
    this.setState({[name]: value});
  };
  renderChildren = (context) => {
    return (
      <form action={context.action}>
        <input value={this.state.value} onChange={this.onChange} name="name" />
      </form>
    );
  };

  render() {
    return <Consumer>{this.renderChildren}</Consumer>;
  }
}

The test case here is similar but without any DOM dependencies. I would expect this to “just work” but alas. My only thoughts for “solving” this is checking if the function exists on the instance before optimistically bailing out and assuming it is pure.

[gaearon]

I’m struggling to understand what you’re trying to do a bit.

Do you expect React to propagate the context update even though the context value prop has not changed? Is there any reason you can’t put the thing you want to pass to the consumer into the context value?

Why are both provider and consumer in one component? Is this representative of the real code you’re writing?

Can you provide a real world example? I’m not sure I see how the code in your test case relates to the code in the description.

[iamdustan]

@gaearon The issue is not so much about context propagating, but that this instance method that reads from state to be rendered and updated when setState is called.

[iamdustan]

The following is pretty close to actual code that experienced this.

// @flow

import * as React from 'react';
import { login } from 'api';
import { BetaFeatureConsumer } from 'BetaFeatures';
import { SingleSignOn } from 'SingleSignOn';

type P = {};
type S = {
  username: string,
  password: string,
  loading: boolean,
  errors: *,
};

export default class Login extends React.Component<P, S> {
  state = {
    username: '',
    password: '',
    loading: false,
    errors: null,
  };

  onChange = (event: SyntheticEvent<HTMLInputElement>) => {
    const { name, value } = event.currentTarget;
    this.setState({ [name]: value });
  };

  onSubmit = (event: SyntheticEvent<*>) => {
    event.preventDefault();
    this.setState({ loading: true, errors: null });
    login(this.state.username, this.state.password).then(data => {
      this.setState({ loading: false });
      if (data.hasError) {
        this.setState({ errors: { ...this.state.errors, ...data.errors } });
      }
    });
  };

  _render = v => {
    return (
      <form onSubmit={this.onSubmit}>
        <input
          label="Username"
          name="username"
          onChange={this.onChange}
          value={this.state.username}
        />
        <input
          label="Password"
          name="password"
          onChange={this.onChange}
          value={this.state.password}
          type="password"
        />
        <button type="submit" disabled={this.state.loading}>
          Submit
        </button>
        {v.singleSignOn && <SingleSignOn onComplete={this.onSubmit} />}
      </form>
    );
  };

  render() {
    return (
      <BetaFeatureConsumer>
        {this._render}
      </BetaFeatureConsumer>
    );
  }
}

[gaearon]

I see. Here's an example:

const Ctx = React.createContext();

class Thing extends React.Component {
  state = {counter: 0};

  renderValue = (value) => {
    return <h1>Hello, {value}, {this.state.counter}</h1>;
  }

  render() {
    return (
      <React.Fragment>
        <Ctx.Consumer>
          {this.renderValue}
          {/* it would work with v => this.renderValue(v) */}
        </Ctx.Consumer>
        <button onClick={() =>
          this.setState(prevState => ({ counter: prevState.counter + 1 }))
        }>
          +
        </button>
      </React.Fragment>
    );
  }
}

ReactDOM.render(
  <Ctx.Provider value="hello"><Thing /></Ctx.Provider>,
  document.getElementById('container')
);

It's confusing that setState has no effect.

[iamdustan]

Yes. That exactly.

[sebmarkbage]

If we want to fix it, it seems that we should remove this whole bailout branch.

[sebmarkbage]

Normally we bail out of children equality because it is very unusual to cache React elements but not impossible. E.g. this pattern would still fail to update:

class ... {
  ...
  consumer = <Ctx.Consumer>{value => <h1>Hello, {value}, {this.state.counter}</h1>}</Ctx.Consumer>;
  render() {
    return consumer;
  }
}

There is an argument to be made that since it is common to cache closures, we shouldn't apply the same bailout strategy for render props.

It's pretty sketchy though. I think in the future, we'll just want to move away from bound closures on instances and instead always provide new closures.

So the tradeoff is whether we want to optimize for future best practices or current. If we allow this pattern now, we can't really easily unallow it later.

[bvaughn]

(The same is true for this.props)

[bvaughn]

This change looks good to me.

[iamdustan]

thank you! 👍