Hiding MUI Components inside React Developer Tools

[samuelhulla]

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.

[bvaughn]

Have you tried using the "location" component filter to hide things within that NPM package

[samuelhulla]

Hey @bvaughn I tried the following alternatives (all of the options presume the first option set to location)

• @material-ui/core
• @material-ui/core/*
• node_modules/@material-ui/core
• node_modules/@material-ui/core/*

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 * are valid or it needs to be an absolute path.

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?

[bvaughn]

I'm not even sure if wildcards like * are valid or it needs to be an absolute path.

Location filters support regex: https://github.com/facebook/react/blob/6ba25b96df5d4179bf8aba3c3fe1ace3dce28234/packages/react-devtools-shared/src/backend/renderer.js#L501-L504

Components will be filtered if (1) they are built with _debugSource info and (2) the file name matches the path: https://github.com/facebook/react/blob/6ba25b96df5d4179bf8aba3c3fe1ace3dce28234/packages/react-devtools-shared/src/backend/renderer.js#L619-L627

The debug source info is typically DEV-only, and gets added here to the Fiber, and it is on the element from this Babel plugin- so maybe Material components aren't built with this plug-in?

[eps1lon]

it is on the element from this Babel plugin- so maybe Material components aren't built with this plug-in?

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 antd, reakit, @reach/tabs and semantic-ui-react and it seems like neither of these modules was build with the plugin since I couldn't find any occurrence of __source nor _debugSource

[bvaughn]

Component libraries need to apply this transform?

"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 node_module source files as well? Then you could just hide anything with node_modules in the path.

[eps1lon]

"Need to"? No. Just pointing out that the file name filtering won't work if this meta info isn't available.

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.

[bvaughn]

Go-to-source uses function identity and the browser DevTool's built-in inspect method. Filter-by-location does not use function identity. They are vaguely related in topic but they are quite different in practice.

the components aren't build to support this feature

This...is your statement. I never said this. :smile: 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?

Maybe that specific transform could be configured to run against node_module source files as well? Then you could just hide anything with node_modules in the path.

Ultimately I'm just trying to provide ideas here for things to try.

[bvaughn]

I don't think this issue is really actionable so I'm going to close it. Happy to keep talking here, sharing ideas, etc. If something actionable comes up, we can reopen.

Eh, I'll just re-open this for now since there's active discussion

[bvaughn]

Maybe that specific transform could be configured to run against node_module source files as well? Then you could just hide anything with node_modules in the path.

Responding to my own suggestion here: I don't think this is viable, because the JSX -> createElement transform has already been applied.

Maybe a new plug-in? (Maybe one already exists that I'm unaware of?) I'll ask on Twitter.

[bvaughn]

Edit for clarity

The idea I am proposing here would be a new transform, similar to babel-plugin-transform-react-jsx-source but meant only for shared component libraries. This transform would insert only part of the __source object, and would follow the convention of "node_modules/", e.g.

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 filter

With filter

Note that this didn't filter the outermost <List> element, because that was declared in my project source directly. So it's unclear if this is exactly what you want or not, but I think it is?

[kentcdodds]

That makes sense to me. So the source of the component doesn't matter. It's the source of the element creation

[Bugimaster]

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.

[zspitz]

I'm still confused. Can MUI components be filtered out of the Dev Tools or not? If yes, how?

[oliversiket]

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