Missing support for Flow Unions

[millermedeiros]

react-docgen doesn't recognize the props if it's an union type:

type BaseProps = {|
  label: string,
|};

type LinkButtonProps = {|
  ...BaseProps,
  href: string,
  target?: string,
  rel?: string,
|};

type ButtonProps = {|
  ...BaseProps,
  type?: 'button' | 'submit',
|};

type Props = ButtonProps | LinkButtonProps;

class MyButton extends React.Component<Props> {
  render() {
     // conditionally render `<a>` or `<button>` based on props...
  }
}

I don't want users to pass props that are specific to <a> at the same time as some props that are specific to <button> - I know this kind of pattern of having a single component render to <a> or <button> is "weird", but some of our legacy components use it...

For now I need to define a single type that includes all the props and mark them all as optional - which is "fine", I guess..

More info about unions here: https://flow.org/en/docs/types/unions/

tested on v3.0.0-beta10

[danez]

Can you please be more specific what "doesn't recognize" means?
You get a parser error? If so can you please add the error message.
Or do you receive an output that you would not expect? Then please add the output of react-docgen that you think is wrong.

[Happy-Ferret]

I'd assume OP is talking about missing descriptions.

With

type: PropTypes.oneOf([
			'animal',
			'bacon',
			'beard',
			'bear',
			'cat',
			'food',
			'city',
			'nature',
			'people',

I automatically receive a description containing all possible enum values.

With FlowType and its unions (i e type?: "animal" | "bacon", no such description is generated.

I'm using react styleguidist, btw.

[emilyhorsman]

I'm considering using react-docgen in a Language Server Protocol instance, but the lack of this feature would be a blocker.

[fkling]

If this is about to level unions (which I think the original post is):

We have talked about this internally, but it's not clear how exactly we would represent this in the output. Should props be an array instead then? What if flow type annotation and PropTypes are used (the latter not being able to describe unions).

If this is about prop-level unions: We should support this if we don't.

[neutraali]

Like @Happy-Ferret said, I think the PropTypes.oneOf([ ... ]) -equivalent for Flow would be closest to ideal here.