-
Notifications
You must be signed in to change notification settings - Fork 46.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug: DevTools calls arbitrary generators which may be stateful #19726
Comments
This is similar to #19660 where the same line of code causes devtools to crash with infinite generators. I wasn't able to reproduce that devtools calling stateful generators was an issue though I definitely expected it to be a problem. |
@gaearon I could give a shot on this! |
@gaearon I would love to give this a go. |
@gaearon : I would like to address this bug |
@todortotev Go for it 👍 Please let us know if you no longer intend to work on it. |
On it! |
just let us know branch you are putting your efforts, more guys would like to contribute, for it 👍 |
@eps1lon I agree with you both issues are related. if we choose to not extract generator. We’re not gonna have the issue anymore |
Just a note, I'm nearly done! Sorry for being slow it just was my first attempt! |
This should be resolved by #19831 once it lands. |
Currently if you put
gen
into state or props and then open this component in DevTools, it will consume that generator while trying to format it. Sogen.next()
will give you{ done: true }
next time you call it.This happens here:
react/packages/react-devtools-shared/src/utils.js
Lines 616 to 623 in 60ba723
I think that maybe we should treat iterables differently if they return themselves as an iterator. Since that means they're likely stateful and it's not ok to iterate over them.
We detect iterables here (DevTools terminology is wrong btw, it should be
iterable
rather thaniterator
):react/packages/react-devtools-shared/src/utils.js
Lines 438 to 439 in 60ba723
I think maybe we could split this into
iterable
andopaque_iterable
, and make sure none of the codepaths attempt to traverseopaque_iterable
or pass it to something that would consume it (e.g.Array.from
).We could detect it based on
data[Symbol.iterator]() === data
— that clearly signals the iterable is its own iterator (which is the case for generators), and therefore it's not OK for DevTools to consume it.Maybe some other heuristic could work. But overall, the goal is that
Map
and friends is still being iterated over, but an arbitrary generator is not.The text was updated successfully, but these errors were encountered: