Provide a way to filter types of components from the Elements tree view

[bvaughn]

Based on some user recent feedback I gathered via Twitter, one common request is some sort of method of filtering elements from the tree to make it less noisy.

Some people have mentioned using a string/regex to filter, and that could work for hiding e.g. HOCs– but I'm picturing a panel that shows all of the types of elements (e.g. host nodes, fragments, context consumer/provider, etc) with checkboxes next to them to indicate whether they should be visible or not.

These settings should be persisted between page reloads through the use of a mechanism like utils/storage added in PR #1069.

[markerikson]

Yep, definitely! Prior existing issues: #503, #604, #864, #997, and #1001 .

[diegohaz]

I think there should be a way to hide those components from within the code. For example, setting a static property on the component type:

Component.devTools = false; // example

Some good points I see on this approach:

• It's very explicit!

• This configuration would be consistent within a team working on the same project.

• Library authors would be able to say which components are "useless" for the devtools (but the user should have a way to show them, perhaps combining it with the checkboxes solution, where the components hidden with the static property would be checked by default).

Well, just some thoughts. Thank you for the amazing work, guys.

[markerikson]

As a slightly alternate suggestion: perhaps if React exported some Symbol.devToolsHideable value (which I think is what was basically suggested in #997 ), and then the DevTools could make that an easily toggleable thing (either "Toggle All Hideable", or some list of detected components marked hideable).

[bvaughn]

Proof of concept (hack) pushed to https://github.com/bvaughn/react-devtools/tree/hidden-types

Has a couple of pain points to work out if we decide it's worth releasing:

• Keyboard navigation is a bit "broken" for expanding/collapsing nodes since children might be "hidden.
• Hiding native nodes looks a little weird at the moment when you drill down to the lowest function/class component, because Node expects there to be children.

[dimensi]

Half a year has passed, is there news? This is the most important feature I've seen in devtools. I am very much tired of this information noise when working with react devtools when you see tons of native elements

[bvaughn]

If there was an update on this, we would have updated the GitHub issue. 😄 We're a small team and we maintain a large surface area. Things often don't move as fast as we'd like.

That being said, you may be interested in taking the new (still experimental) DevTools version for a test drive. It doesn't show native elements at all, so it may reduce some of the "noise" you're talking about. You can find early release builds in the top-right corner of the demo page:
https://react-devtools-experimental.now.sh

[ErikLarsson82]

Proof of concept (hack) pushed to https://github.com/bvaughn/react-devtools/tree/hidden-types

Is this the place to give feedback on your build @bvaughn ? (the fork repo has issue tab disabled)

I'm confused how the ForwardRef option should work. I expect my component StyledAppView to remain and the very generic StyledComponent forwardedRef={null} to be hidden.

Otherwise - I'm loving this feature as it makes the tree readable again!

[davidfurlong]

I really appreciate any work towards this issue.

My team members have mentioned that they don't often use react devtools because the number of HOCs/dom elements is too noisy and the scrolling UX + complexity is too great with nested HOCs. The experimental version looks like a big improvement, and hopefully a full migration to hooks will help as well. I've attached a screenshot to help explain our struggles. One common use case for us is "I want to change the code relating to this piece of the website, how do I find the code". Steps would be inspecting the part of the website in Elements panel, switching to react devtools where it nicely selects the correct dom element, and then scrolling up to find the closest parent React Component which has a name which looks non generic (non library, non HOC). Then switching to vscode and searching for a file with that name. The scrolling up and identifying the closest relevant react component part is pretty tricky (hard to find, false positives).

An alternative way to solve this flow is to search for some text on the page in the codebase but that doesn't always yield accurate results as text can be duplicated/internationalized.

Another common use case involves similarly trying to find a react component, to inspect its props to see what value they have to debug an issue, which ideally should be faster than adding a console log and waiting for a webpack rebuild (in our case) but sometimes isn't because if you're new to the codebase its hard to identify which elements in the devtools panel are internal components/library components/HOCs and there may be a lot of dom elements adding noise too.

[bvaughn]

@davidfurlong You and your teammates should check out the DevTools beta. It has a pretty sweet component filtering UI built into it that's much more powerful than this prototype. It also shows the list of "owners" for each component (meaning the things that rendered it, not just its parents in the tree) which should make the scanning you described much faster.