ES6 generator as a component: react-dom.development.js bug

[doasync]

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

bug

What is the current behavior?

react-dom.development.js behavior is different from the behavior of react-dom.production.min.js

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

Here is an example: https://codepen.io/doasync/pen/RxWoJQ?editors=1010 (doesn't work)

Replace https://unpkg.com/react-dom@16.2.0/umd/react-dom.development.js with https://unpkg.com/react-dom@16.2.0/umd/react-dom.production.min.js and it will work again

What is the expected behavior?

Generators should work with react-dom.development.js (see the given example)

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

16.2.0

[gaearon]

I believe this is not a bug, it's just a somewhat confusing intentional behavior.
See here for an explanation: #11502.

[simonbuchan]

I read #11502 and I'm not sure why it would be considered "intentional"? I would think it would either error or do what C#-ers have done forever and avoid multiple iteration by converting it to an array.

[mcjazzyfunky]

No proposals - just some additional information:

As I have written in #11502 IMHO it's commonly not the best idea to pass iterators (aka. generators) to the outside world as they are higly stateful and can only be enumerated one single time (at least in most programming languages => in C# and PHP it may be a different, there you find some odd "IEnumerator#reset"/"Iterator#rewind" methods, anyway...), means you will never know what the outside world will do with your iterator. Instead it is advisable to pass some stateless, unmodifiable iterator-aggregate, because then the outside world can iterate that sequence as often as desired without any unwanted side effects.

Issue #11864 is different from #11502 because in the example of #11502 a generator object is passed to the outside world (which like said, is not really advisable) while #11864 only passes the generator function (passing functions should often - at least for pure functions - not cause any problems as they are mostly stateless => here it causes indeed some odd unexpected issues!!!). Nevertheless both examples lead to the same problem:

In most programming languages there's a strict distinction between iterators (aka "generator" aka "IEnumerator" etc.) and iterator aggregates (aka. "Iterable"/"IEnumerable" etc).
If you have a iterator aggregate and you want to iterate through all elements then you just invoke the "getIterator()" method (aka "[Symbol.iterator]() aka "iterator()" aka "getEnumerator()" etc.) and you will get a brand new iterator object dedicated only for you (in "for-each"/"for (... of ...)"/"for (... : ....)" loops that iterator object will be generated internally of course).
Unfortunately things are different in ECMAScript: For IMHO very odd design decisions, ES generators also have a [Symbol.iterator] property - which makes them be both an iterator and an iterator aggregate at the same time ... and that [Symbol.iterator]() method of the generator will NOT generate new generators each time invoked - as would normally be expected for iterator aggregates.

React checks for the "[Symbol.iterator]()" function. If this property is given it considers the object as a "normal" iterator aggregate and thinks it should not be a problem to iterate the whole sequence twice in the development module.

In the above linked example React treats the generator function "Test" as normal render function, invokes it, gets a generator object (as single children), checks for a [Symbol.iterator] method, finds that methods and iterates it twice on DEV which causes the above described trouble....

Here's a little demo about that generator stuff (has to be run in Chrome and you have to click "Run" first):
https://jsfiddle.net/x5eaw8kr/

[simonbuchan]

I can say that it is considered quite strange in C# to pass around IEnumerators, I've only seen them escape a method body in the internals of parser-like code myself.
Also, C# generator functions do operate differently to JS: https://stackoverflow.com/questions/44847342/generator-method-called-twice-during-multiple-enumeration
React can fix this without too much juggling, essentially have createElementWithValidation() pre-iterate arguments, something like:

const fixedArgs = Array.prototype.map.call(arguments, arg => {
  const iteratorFn = arg[ITERATOR_SYMBOL]; // actually check all the polyfills
  if (!iteratorFn) return arg;
  return [...iteratorFn()]; // iterators (as opposed to iterables) can only give their results once.
});
const element = createElement.apply(null, fixedArgs);
...
validateChildKeys(fixedArgs[i], type);
...

[mcjazzyfunky]

@simonbuchan - thanks for your answer
#11864 is about the question whether ES6 generator functions should be allowed as first argument in createElement.
The code snippet above does much more than this: It allows generator objects as random arguments in the createElement function (which is basically #11502).
Allowing iterators/generators as input arguments for functions will sooner or later end in trouble.

See for example the following demo (it uses React's production modules):
https://jsfiddle.net/664tnsy7/
It's really not easily understandable why you only see three stripes instead of four (the red "ITEMS" stripe is missing).

But of course "allowing generator objects as arguments" is a completely different subject than "allowing a generator function as first argument". Just because the first one may not be such a good idea does not say anything about the latter. It's just that the suggested code change would lead in unexpected side effects.

[simonbuchan]

Yes, I was going off the description in #11502, sorry. I dug around for a bit, but couldn't find where the heck the stateless component or Component#render is actually called, which is where you would do the iterator check and spreading, if the issue actually is due to multiple iteration.

[doasync]

I agree that passing a generator object to the outside world is a bad idea, but I pass a stateless generator function to React (not a "nextable" object). The problem is that React treats the generator function as normal function, invokes it and uses the resulting stateful iterator. Generator function can be treated properly (so that "development" behavior will be the same as "production" behavior).

Each generator function has a Symbol.toStringTag which equals to "GeneratorFunction". React can create a stateless iterable object from generator function and pass it around as React node. It looks like: { [Symbol.iterator]: generatorFunction }.

P.S. Or leave it to developers and recommend against using bare generator functions as a component (to make things clear). Suggest the following pattern instead:

const Component = (...props) => {
  [Symbol.iterator]: function* Test () {
    /* ... */
  }
});

[simonbuchan]

I addressed why you don't want to check for generators. If you want to fix this specific gone, you care if the result is an iterable iterator, so use result[Symbol.iterator]() === result, but it's irrelevant, since React shouldn't be invoking [Symbol.iterator] separately for validation even for regular iterators: it means there is visible behavioral difference between development and production, it means the actual results used are not the ones validated, and it's even worse for performance than to collect the results into an array first.
I'm of the opinion that react should in general either just remove support (ie deprecate) iterables, or be careful to not multiply iterate even regular iterables, especially differently than in production.

[gaearon]

We're going to start warning about this.
#13312