addon-docs: Allow setting argTypes for subcomponents

[randak]

Is your feature request related to a problem? Please describe
I have a situation where I want to use subcomponents but I need to be able to customize some of the values displayed in the generated table. As far as I can tell, I can only apply argTypes customization to the main component, not the subcomponent.

Describe the solution you'd like
A method of setting argTypes for subcomponents. I'm not sure what the best config structure would be for this, and am open to suggestions.

Describe alternatives you've considered
N/A

Are you able to assist to bring the feature to reality?
Yes, with pointers on where the relevant code is.

Additional context
N/A

[AmirTugi]

How about

export default {
  title: 'Components/Calendar',
  component: Calendar,
  subcomponents: { 
    CalendarLegend: {
      component: CalendarLegend,
      argTypes: {
        label: { control: 'input' },
      },
    },
  },
  argTypes: {
    onSelect: { action: 'selected' },
  }
};

And in case we don't want to add manual argTypes it will be left as in today -

export default {
  title: 'Components/Calendar',
  component: Calendar,
  subcomponents: { CalendarLegend },
  argTypes: {
    onSelect: { action: 'selected' },
  }
};

[Fernker]

Anyone know of a workaround for this? I find it incredible that argTables is considered a first-class citizen but there's no support for it on subcomponents.

[curtvict]

@AmirTugi to be clear, this has yet to be added as a feature, correct?

[vhoyer]

@AmirTugi to be clear, this has yet to be added as a feature, correct?

correct.

[vhoyer]

Anyone know of a workaround for this? I find it incredible that argTables is considered a first-class citizen but there's no support for it on subcomponents.

So, the most I could do was set a description for the args in the subcomponents by creating a jsDoc style comment on top of the props for the subcomponents, but the other settings, sadly apparently we cannot change using this method. Here is an example of the description:

  // this is a vue component, I'm pretty sure we can still do this strategy on other frameworks though.
  props: {
    /**
     * sets the main text of the item
     */
    title: {
      type: String,
      required: true,
    },
    /**
     * sets the secondary text of the item
     */
    subtitle: {
      type: String,
      default: undefined
    },
  },

[vhoyer]

I like this syntax, this was the first one I tried to see if it worked on my project before being greeted by a lovely message saying what was the expected format for the subcomponents key.

The only problem I have with this is that, since this is an open format, this proposal would not be "ignorable" by other tools working with this format, since it's technically a breaking change, I'd like to propose another API for getting around this problem:

// proposal "subcomponent in argTypes"
export default {
  title: 'Components/Calendar',
  component: Calendar,
  subcomponents: { 
    CalendarLegend,
  },
  argTypes: {
    onSelect: { action: 'selected' },
    CalendarLegend: {
      label: { control: 'input' },
    },
  },
};

This could easily be ignored by other tools applying the CSF, and it gets the job done, I don't suppose we'd have the need to configure anything else in the subcomponents other than the ArgTable anyway, right?

Another possibility I just came up with while typing this message was this other API, but I preffer the "subcomponent in argTypes" proposal:

// proposal "subcomponent as namespace"
export default {
  title: 'Components/Calendar',
  component: Calendar,
  subcomponents: { 
    CalendarLegend,
  },
  argTypes: {
    'onSelect': {
      action: 'selected',
    },
    'CalendarLegend/label': {
      control: 'input',
    },
  },
};

[mtirimie1]

Any progress on this? Running into quite a few scenarios on my current project where this would alleviate a lot of confusion for the end user.

[vhoyer]

@shilman, since we removed the "needs triage" does it mean the its green lit to be implemented? do you have any considerations about the proposed APIs? Which do you think should be implemented?

[shilman]

@vhoyer No, it just means that I don't want it to show up anymore when I look through the "needs triage" issues in Storybook. I'll let @JReinhold comment on the future of subcomponents...

[JReinhold]

We're deprecating subcomponents in 7.0. The API is very limiting and hard to improve in (as evident by this issue and others). It is somewhat of a half-baked feature, that we want to rethink and do better.

Subcomponents will be removed from the default DocsPage in 7.0, but since it's still available in the now deprecated <ArgsTable /> doc block, they can be re-added by defining your own DocsPage globally.

We don't have a clear path forward from this yet, we want to collect feedback from the community about what they want from their subcomponent documentation and how they want to use it.

[mtirimie1]

Okay thank you, there are definitely quite a few things I have wanted to do with nested/subcomponents so it's nice to know there's interest in this

[nnaydenow]

We're deprecating subcomponents in 7.0. The API is very limiting and hard to improve in (as evident by this issue and others). It is somewhat of a half-baked feature, that we want to rethink and do better.

Subcomponents will be removed from the default DocsPage in 7.0, but since it's still available in the now deprecated <ArgsTable /> doc block, they can be re-added by defining your own DocsPage globally.

We don't have a clear path forward from this yet, we want to collect feedback from the community about what they want from their subcomponent documentation and how they want to use it.

What's the alternative of that?

[JReinhold]

We've since reverted the decision to remove subcomponents support, so this feature request is valid again.

See #20782 (comment)