Storybook: Props not showing in the DocsPage when they're imported from another file into the component (Vue)

[puyt]

Describe the bug
I have a component where the props are in a different JavaScript file because it's used for multiple button components but the props aren't rendered in the docs, am i doing something wrong?

To Reproduce
Steps to reproduce the behavior:

1. Run storybook with the 3 example files below

Expected behavior
Props being rendered in the DocsPage

Screenshots

Code snippets

// ButtonBrops.js
export default {
    label: {
        type: String,
        default: 'Button',
    },
};

// Button.vue
<template>
    <button @click="clickButton">{{ label }}</button>
</template>

<script>
    import ButtonProps from './ButtonProps';

    export default {
        name: 'button',
        props: ButtonProps,
        methods: {
            clickButton() {
                this.$emit('click-button');
            },
        },
    };
</script>

// Button.stories.mdx
import { Meta, Props } from '@storybook/addon-docs/blocks';
import Button from './Button.vue';

<Meta title='Components/Button' component={Button} />

## Props, Events & Slots
<Props of={ Button } />

System:

Environment Info:

  System:
    OS: Linux 5.4 Ubuntu 19.10 (Eoan Ermine)
    CPU: (8) x64 Intel(R) Core(TM) i7-10510U CPU @ 1.80GHz
  Binaries:
    Node: 12.13.0 - ~/.nvm/versions/node/v12.13.0/bin/node
    npm: 6.12.0 - ~/.nvm/versions/node/v12.13.0/bin/npm
  Browsers:
    Chrome: 84.0.4147.125
    Firefox: 78.0.2
  npmPackages:
    @storybook/addon-actions: ^6.0.16 => 6.0.16
    @storybook/addon-docs:  ^6.0.16 => 6.0.16
    @storybook/addon-essentials:  ^6.0.16 => 6.0.16
    @storybook/addon-links:  ^6.0.16 => 6.0.16
    @storybook/vue:  ^6.0.16 => 6.0.16 

[shilman]

@elevatebart is this a known limitation with vue-docgen-api?

[elevatebart]

Hello @puyt, Thank you @shilman,

It is indeed a known limitation of vue-docgen-api. The library does not resolve variables in props.
Since it is a static analyzer of the code, not its runtime, it often can't guess what variables will contain.

Though, @puyt you make me think of a scenario where it would make sense to have the props as a separate object.
Tell me if you have another scenario where it would be necessary.

Here it is:

Button.vue has 3 props color, size and variant. We then make an ActionButton.vue, who encapsulates the button and keeps all it's props using v-bind. The props validations now have to be defined at 2 levels, and copied and pasted.

It would be better to have them defined once and imported.

This sounds feasible but not easy.

For reference here are other issues related to resolving non-explicit prop types:
https://github.com/vue-styleguidist/vue-styleguidist/issues/923
https://github.com/vue-styleguidist/vue-styleguidist/issues/881

[shilman]

Thanks for clarifying @elevatebart! Static analysis is a beast--you're really doing the Lord's work. I'm fine to say it's a limitation of Storybook right now.

@puyt in 6.0 it's possible to specify types by hand if needed as a workaround: https://github.com/storybookjs/storybook/blob/next/addons/controls/README.md#my-controls-arent-being-auto-generated-what-should-i-do

[puyt]

Button.vue has 3 props color, size and variant. We then make an ActionButton.vue, who encapsulates the button and keeps all it's props using v-bind. The props validations now have to be defined at 2 levels, and copied and pasted.

@elevatebart This is actually the way we implemented Button.vue but with a few more props and we're creating multiple variants which are frequently used to prevent other developers from using a different color, icon, label, rounded,... for those cases.

So we have variants such as AddButton, DeleteButton, EditButton,... We could have used something to variant but there would be too many if else code or computed values inside the button to handle the styling that's why we moved the props to different object and merge that object with the props with the settings for a specific button. This way the props and default values are always in that other object instead of v-binding it every new variant.

I can't really think of another use-case except for the one you mentioned.

I'm oke with the suggested workaround that @shilman mentioned, it's a edge case anyway and we're currently only having this issue with the button component.

Thanks for the fast reply and the great work on the libraries both!

[elevatebart]

If you were to use a mixin for these props instead of an object, docgen would be able to pick it up out of the box.
I hope it helps you at all ;)

[visualjerk]

Just wanted to add a similar usecase:

When sharing component functionality with the composition api, quite often prop definitions also need to be shared.

Example:

import { boxProps, useBox } from '@components/box'

export const tabbableProps = {
  ...boxProps,
  disabled: {
    type: Boolean,
    default: false,
  },
  focusable: {
    type: Boolean,
    default: false,
  },
}

export function useTabbable(props, context) {
  const box = useBox(props, context)
  ...
}

export const Tabbable = {
  props: tabbableProps,
  setup: useTabbable,
}

[elevatebart]

@visualjerk good added feedback!

Spreads and multi-level props resolving makes static parsing all the more interesting... and complicated.

I will try and integrate these use cases in version 5 of docgen.
Hopefully they can be sorted out simply.

Would you be interested in learning how I do that?

[visualjerk]

For sure 😄 Is there a related issue, that I can watch?

[elevatebart]

Not yet. will probably work on it this Week end

[stale[bot]]

Hi everyone! Seems like there hasn't been much going on in this issue lately. If there are still questions, comments, or bugs, please feel free to continue the discussion. Unfortunately, we don't have time to get to every issue. We are always open to contributions so please send us a pull request if you would like to help. Inactive issues will be closed after 30 days. Thanks!