feature request: add first class support for filtering HTMLAttributes

[cdaringe]

problem

often times, one defines an a prop interface by extending HTML attributes, e.g React.ReactNode<HTMLInputAttributes>.

e.g.

interface MyProps extends React.ReactNode<HTMLInputAttributes> {
  /** a really great prop */
  bestProp: string
}

consequently, the styleguidist prop types generates prop documentation for all of the HTML attributes, not simply bestProp.

discussion

• first, thanks for this great lib
• second, because this pattern is so common in react, it may be worth considering adding first class support for omitting HTML attributes from the generated definitions.

thoughts? thanks!

[swashcap]

Looking at the parserOptions.propFilter, it looks like the first arg, PropItem has a parent property which points to the source file:

// styleguide.config.js
// ...
module.exports = {
  propsParser: reactDocgenTypescript.withCustomConfig('./tsconfig.json', {
    propFilter(prop, component) {
      debugger
      return true
    }
  }).parse,
  // ...
}

When debugging, it looks like prop.parent points to the source definition file:

> prop.parent
{ fileName: 'baby-registry-components/node_modules/@types/react/index.d.ts',
  name: 'HTMLAttributes' }

One could use that to conditionally return based on the definition file's path.

[cdaringe]

is it recursive? perhaps this lib could expose a composable filter function?

const { withHtmlAttributesFilter } = require(...)

// case 1
module.exports = {
  propsParser: reactDocgenTypescript.withCustomConfig('./tsconfig.json', {
    propFilter: withHtmlAttributesFilter
  }).parse,
}

// case 2
module.exports = {
  propsParser: reactDocgenTypescript.withCustomConfig('./tsconfig.json', {
    propFilter: withHtmlAttributesFilter((prop, filter) => {
        // your other filters
    })
  }).parse,
}

[swashcap]

This propsFilter function solves this problem for me:

// styleguide.config.js
// ...
module.exports = {
  propsParser: reactDocgenTypescript.withCustomConfig('./tsconfig.json', {
    propFilter(prop) {
      if (prop.parent) {
        return !prop.parent.fileName.includes('node_modules')
      }

      return true
    },
  }).parse,
  // ...
}

Only outputs the component's own props. Could we perhaps modify the Readme so other users know about this?

[pvasek]

Extending README.md is a great idea. This is actually duplicate of #49 which was about the same thing. This was fixed by PR #111.

[ejuo]

I encountered the problem. prop.parent always is null for typescript version > 3.5.

[shermanhui]

@ejuo I'm also experiencing this issue as our project is also using TypeScript 3.5.0 is your workaround just to downgrade the version of TS?

[drewlustro]

I encountered the problem. prop.parent always is null for typescript version > 3.5.

Is there a workaround for this?

[tkiethanom]

propFilter(prop) {
      if (prop.parent) {
        return !prop.parent.fileName.includes('node_modules')
      }

      return true
    },

This doesn't seem to work if my props are named with names like color or onClick. They seem to be conflicting with existing HTML props.

[hipstersmoothie]

seems like this one can be closed @pvasek