As reported here:
https://github.com/ReactTraining/react-subjects/blob/master/subjects/RenderOptimizations/lecture.js
change that 200 to 5000
Tagging as good first bug (but a complex one). The actionable work here is to assess what is causing performance issues. For example, you could completely remove the panel rendering, and test if it is still crashing. If not, maybe it鈥檚 the amount of DOM nodes. Or maybe it鈥檚 how many messages we pass between the page and the extension. Maybe we can cut some overhead there by passing less messages, or including less content.
Hello, I saw your Twitter conversation and I hope I can help somehow.
I've checked this and basically it's crashing after trying to render X nodes. I can say it's strictly related to rendering and memory / CPU consumption is kind of consequence. I've checked what Chrome DevTools are doing when we have 500+ nodes, basically they show button which will show another batch of nodes:
My proposition is (not sure about "flow" of contributing to react-devtools
is to:
react-virtualized
List or similar solution to show only nodes which are in viewportThanks for you time and hope to make my first contribution to this amazing tool.
Thank you for checking! I think @bvaughn was looking into using react-virtualized
but this seems like a much simpler solution in the meantime. Would you like to implement this "show all" button?
Sure! Will get back with PR.
Any progress on this? Anything I can do to help?
I don't see any PRs opened by @benedyktdryl, so I'm guessing you could pick up the issue yourself and submit a PR if you'd like, @fossage.
Is this something that's still being worked on?
I don't think it's been actively worked on by anyone (at least to my knowledge).
Would it be worth removing the 'someone is working on this' tag so someone else can pick it up? This makes it hard to use the React dev tools on our site (which is open source if you need a repro!) Remix https://glitch.com/~community to get your own copy of our site and play around with it in dev tools.
@bvaughn has been doing a DevTools rewrite so maybe it works there. Do you want to test it?
The original link from Ryan is not available anymore, but I would anticipate the new DevTools extension to be able to handle significantly larger loads (my intuition tells me orders of magnitude, though I have not yet stress tested the two of them since the rewrite is ongoing).
I don't believe it would be worth anyone investing time into the legacy DevTools extension (this one) in the meanwhile because (a) I think the underlying cause is systemic and (b) because we hope to launch the new replacement extension sometime within the next couple of months (although no ETA yet).
I too am having big problems with React Dev Tools. If anyone is familiar with React-Select
I have a options list with about 1100 options. It used to be when the extension was enabled, the page would just hang all of Chrome, but after moving the options to the redux store (or useState), all works fine; until I actually open the React tab in dev tools and try to Select to Inspect.
Disabling the extension, like I said before, fixes any issues I am having.
Yeah. This is a known issue. Not sure what else there is to say about it that hasn't been said above 馃槄
You're welcome to take the (work in progress) rewrite DevTools for a spin if you'd like:
https://react-devtools-experimental.now.sh/
Chrome and Firefox links in the top/right corner.
I'm testing out the experimental dev tools and while it's not crashing for me (as the current one does) I'm experiencing an issue very similar to what I reported in: https://github.com/facebook/react/issues/14365
Basically, I have a toggle that mounts/unmounts a large number of components. With the new devtools enabled this toggle take a long long time as opposed to when devtools are disabled
Thanks for all the hard work!
@uriklar Please file a new issue in new DevTools repo with a reproducing example?
Basically, I have a toggle that mounts/unmounts a large number of components. With the new devtools enabled this toggle take a long long time as opposed to when devtools are disabled
How long are we talking? I would expect it to take _longer_ since DevTools needs to (synchronously) walk the entire tree of newly mounted components and generate op codes.
Agreed with Dan that a GH issue with a repro and more info would be useful.
Will do. Thanks
I have been having this problem as well. My current project pulls nearly 5000 JSON objects from a database, and uses react-window to render a scrollable list which only shows 10 elements at a time. With React Developer Tools closed, the list is highly responsive; however, I have found that with React devtools open, there is a noticeable delay after scrolling (up to several seconds) before the list re-renders.
In addition, I have found that at times when working on this project, React devtools will crash and refuse to reset- having been somehow disabled in the Chrome web store. Clicking 'enable this item' has no effect but reloading the page; the only option is to remove React devtools from my Chrome extensions and re-install.
I understand I may not be the only one experiencing delays or crashes, but has anyone else been having this difficulty in reactivating React Developer Tools? And if so, is it something which is addressed in the experimental build mentioned above?
@Zev-Engineer Have you tried the new beta version of DevTools yet?
@bvaughn I have not tried it yet. I see the experimental version takes less space than the original, which is promising- does it have the same level of functionality? Based on the test app provided it does seem similar, but I want to be sure I wouldn't miss any major capabilities by using the experimental version.
I'm not suggesting you make a permanent switch to the new version. (You can always remove or disable it and use the old one instead.) Just suggesting you might want to try it if the old one is performing badly for you- because the new one should be much faster. :)
That's fair :) I'll try it tomorrow and see how much of a difference it makes.
Also would it be possible to link me to the website so I can look too?
I tried out the new extension with http://destinyitemmanager.com and it pretty quickly goes unresponsive and then OOMs.
@bvaughn unfortunately, the project is currently being run on a local server and there is no way to effectively link to the website just yet, given that it can only read in the data while said server is activated from this end. I will look into changing that- may take a bit of time, given that several of my team members are currently away.
Additionally, I have been reading GitHub for some time, but only joined recently and so am relatively unfamiliar with some parts of it. What is the best way to convert your code repository into a usable Chrome extension?
To get the Redux devtools to work, we had to blacklist a couple big properties using their support for filtering. Perhaps The new React devtools should support something similar - a blacklist of props that the tool won鈥檛 attempt to display. Or this could be automatic where objects with more than some number of properties don鈥檛 get displayed by default.
I tried out the new extension with http://destinyitemmanager.com and it pretty quickly goes unresponsive and then OOMs.
@bhollis Thanks for the pointer. Looks like using the "inspect" button causes things to become super unresponsive. I wonder if this is what you were doing? or something else?
@bhollis Let's move the chat over to https://github.com/bvaughn/react-devtools-experimental/issues/195
React DevTools has been rewritten and recently launched a new version 4 UI. The source code for this rewrite was done in a separate repository and now lives in the main React repo (github.com/facebook/react).
Because version 4 was a total rewrite, and all issues in this repository are related to the old version 3 of the extension, I am closing all issues in this repository. If you can still reproduce this issue, or believe this feature request is still relevant, please open a new issue in the React repo: https://github.com/facebook/react/issues/new?labels=Component:%20Developer%20Tools
Most helpful comment
The original link from Ryan is not available anymore, but I would anticipate the new DevTools extension to be able to handle significantly larger loads (my intuition tells me orders of magnitude, though I have not yet stress tested the two of them since the rewrite is ongoing).
I don't believe it would be worth anyone investing time into the legacy DevTools extension (this one) in the meanwhile because (a) I think the underlying cause is systemic and (b) because we hope to launch the new replacement extension sometime within the next couple of months (although no ETA yet).