-
Notifications
You must be signed in to change notification settings - Fork 45.7k
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
Hiding MUI Components inside React Developer Tools #19162
Comments
Have you tried using the "location" component filter to hide things within that NPM package |
Hey @bvaughn I tried the following alternatives (all of the options presume the first option set to
Sadly none of these worked. I'm not quite sure how I should exactly specify the path location given it does not have example in the docs / link you provided and I'm not even sure if wildcards like Because obviously it would be bit over the top, to filter out every single MUI component per-file basis. Am I just entering it incorrectly, or? |
Location filters support regex: react/packages/react-devtools-shared/src/backend/renderer.js Lines 501 to 504 in 6ba25b9
Components will be filtered if (1) they are built with react/packages/react-devtools-shared/src/backend/renderer.js Lines 619 to 627 in 6ba25b9
The debug source info is typically DEV-only, and gets added here to the |
Component libraries need to apply this transform? I thought this was for app code only. If we do this then wouldn't the source point to a relative path within node_modules? Do the devtools resolve the path? This basically means that we need to ship another bundle for development which means we need to double the bundles unless we want to enforce a particular module system for the development build. I just searched my node_modules where I installed |
"Need to"? No. Just pointing out that the file name filtering won't work if this meta info isn't available. Just to clarify things: React DevTools as a browser extension doesn't know anything about your file system or where a given React component's underlying source file is. This issue is asking how to filter a set of components that share a file system location in common, so I mentioned the location filter as a possibility. Maybe that specific transform could be configured to run against |
No of course we don't "need to" in a literal sense. But if a devtools feature requires additional work for component libraries so that it works as intended then we should do the extra work. It's apparently problematic since no widely adopted component library does this. So there's either a documentation issue (why should component libraries do this? is there some recommended way to do it? etc) or the feature is incomplete because it doesn't support a common use case. It's also confusing because "go to source" works perfectly fine. Now I suspect that this is because these features have a different implementation but this isn't a good explanation for a software user. At a surface level "go to source" and "exclude this source" are the same. One doesn't support all locations though which is confusing. In the end statements like "the components aren't build to support this feature" don't help if virtually no component library is build that way. |
Go-to-source uses function identity and the browser DevTool's built-in
This...is your statement. I never said this. 😄 I just said maybe the component wasn't built using a certain plug-in. I also suggested that you could configure the plug-in to be used in your app?
Ultimately I'm just trying to provide ideas here for things to try. |
Eh, I'll just re-open this for now since there's active discussion |
Responding to my own suggestion here: I don't think this is viable, because the JSX -> Maybe a new plug-in? (Maybe one already exists that I'm unaware of?) I'll ask on Twitter. |
Edit for clarityThe idea I am proposing here would be a new transform, similar to createElement(
type,
{
...props,
__source: {
fileName: "node_modules/react-window",
},
},
...args
); Alternately we could add a new, package-only field, e.g. createElement(
type,
{
...props,
__source: {
packageName: "react-window",
},
},
...args
); But this would also require an update to the DevTools filtering logic. As a proof of concept, I created a small project with create-react-app and the react-window NPM package, then I hacked this into the react-window built source: import { createElement as createElementReact, PureComponent } from 'react';
// Hacky test only; don't copy this.
let createElement = createElementReact;
if (process.env.NODE_ENV !== 'production') {
createElement = (type, props, ...args) => {
return createElementReact(
type,
{
...props,
__source: {
fileName: 'node_modules/react-window',
},
},
...args
);
}
} Then I was able to filter out all of the components internal to the react-window package using a location filter with a value of "react-window": No filterWith filterNote that this didn't filter the outermost |
That makes sense to me. So the source of the component doesn't matter. It's the source of the element creation |
|
I'm still confused. Can MUI components be filtered out of the Dev Tools or not? If yes, how? |
I can't see a solid answer on how to solve this issue. The original post is from 2020. Honestly, the dev tool is unusable with MUI... big letdown |
Hello, recently we've overhauled a client's website with the usage of Material UI. It's been an enjoyable experience, however one thing that really irks me - given the project is pretty large and there's multiple people working on it, sometimes it gets chaotic which component is exactly what and you need to find out which component you should be working on.
My general fallback was using the React Develeloper Tools extension, however given MUI consists of ready-made JSX components, it essentially spams and halts the usefulness of the 'Components' tab.
Is there perhaps any way that would allow for filtering of specific packages / jsx elements inside the React Developer Tools?
I know I could technically user regex to filter out a list of all the known MUI Components, but that seems bit overkill. I sadly suspect such a thing is not supported, but you never know unless you ask.
The text was updated successfully, but these errors were encountered: