can't yield children from a generator in render()

[threepointone]

Do you want to request a feature or report a bug?

bug.

What is the current behavior?

via this thread https://twitter.com/aweary/status/1004837394439290880
passing the result of a generator as a child doesn't 'work'. it renders no children, without an error or warning.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle (https://jsfiddle.net/Luktwrdm/) or CodeSandbox (https://codesandbox.io/s/new) example below:

repro - https://codesandbox.io/s/5zp0j8389x

What is the expected behavior?

for the above example, a hundred <span>s, numbered 100 -> 1

Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?

16.x, all browsers

(It appears the validation logic drains the iterator, so when we finally try to 'get' the children again, it returns nothing.)

[threepointone]

a 'workaround' is to use an iterable like so - https://codesandbox.io/s/wykrmvv1n8

[gaearon]

I don’t think that’s a workaround, it’s how iterators work right?

Seems expected to me.

Note the iterable support was primarily for things like Immutable Lists etc.

[threepointone]

Yes, I suppose I agree. 👍 just seemed unexpected.

[gaearon]

Yeah, we get an issue like this about every few months. Maybe we could materialize it early?

[threepointone]

having a look at source (ReactChildren and ReactElementValidator) to see if there's an easy win here

[aweary]

The biggest problem with this is that it works fine with production builds: https://codesandbox.io/s/ol6nzlwoo6

[gaearon]

What if you embed the result twice? I think you’d expect to see it twice but would actually see it once (even in production mode).

[aweary]

@gaearon if you embed the same iterable more than once it only renders the first result, but you can always make multiple calls to the generator which I think would be more common.

It's definitely confusing if you don't understand generators though.

[gaearon]

The biggest problem with this is that it works fine with production builds: https://codesandbox.io/s/ol6nzlwoo6

I disagree. It would be a big problem if it worked in development builds but then didn't work in production builds. The current behavior is actually safer because it highlights the problem early on.

The reason it's a problem is because enumerating a generator is a mutation. By passing a generator to React, you're forcing React to perform a mutation in the render phase. And that's bad both for async rendering and for some cases in sync rendering.

For example:

class Container extends React.Component {
  handleClick = () => {
    this.setState({});
  }
  render() {
    return (
      <div onClick={this.handleClick}>
        {this.props.children}
      </div>
    );
  }
}

function App() {
  return <Container>{renderChildren()}</Container>;
}

function *renderChildren() {
  for (let i = 0; i < 10; i++) {
    yield i;
  }
}

ReactDOM.render(
  <App />,
  document.getElementById('container')
);

This will (even with the production version) show 0123456789 on the first render, but then erase it on click. It will be erased because the first render has consumed the generator, and the next render doesn't have anything to read.

So I think we should start trying to detect this pattern and warning about it. It's not supported.

[aweary]

Agreed, a warning is the right solution.

[gaearon]

#13312