Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Addon-docs: Generate escape hatches automatically for blocks #8986

Closed
patricklafrance opened this issue Nov 27, 2019 · 12 comments
Closed

Addon-docs: Generate escape hatches automatically for blocks #8986

patricklafrance opened this issue Nov 27, 2019 · 12 comments

Comments

@patricklafrance
Copy link
Member

patricklafrance commented Nov 27, 2019

Is your feature request related to a problem? Please describe.
Currently, the escape hatches for the doc blocks are inconsistent.

Some use sbdocs sbdocs-<docBlockName> format and other use docblock-<docBlockName> format.

For example, the PropsTable use the following docblock format:

      <Table className="docblock-propstable">
        <thead className="docblock-propstable-head">
          <tr>
            <th>Name</th>
            <th>Description</th>
            <th>Default</th>
          </tr>
        </thead>
        <tbody className="docblock-propstable-body">
          {allRows.map(row => (
            <PropsTableRow key={row.key} {...row.value} />
          ))}
        </tbody>
      </Table>

But one of his sub-component use the docblock format:

      <Expandable className="sbdocs-expandable">
        <span>{summary}</span>
        <ArrowIcon icon={isOpen ? 'arrowup' : 'arrowdown'} />
      </Expandable>

This is unclear to me when to use sbdocs and when to use docblock.

After talking with @domyen we think the best approach would be to use some kind of automation to generate the escape hatch based on the component name. It could also something else like an utility function, at least it would ensure consistency.

If we go forward with this, it should be done before releasing 5.3.

Are you able to assist bring the feature to reality?
Yes

@domyen
Copy link
Member

domyen commented Nov 27, 2019

Thanks @patricklafrance! Naming is hard. The responsibility for naming should be automatic based on the component name rather than having themers adhere to a naming convention – which can be pretty tough to remember as evidenced above.

@shilman what do you think?

@shilman
Copy link
Member

shilman commented Nov 27, 2019

I'm fine with an automatic solution based on the component name provided it's not too complicated. Here's a really simple version:

export const escapeHatch = (id: string) => (
  `sbdocs sbdocs-${kebabCase(id)}`
)

WDYT @domyen @patricklafrance

@patricklafrance
Copy link
Member Author

patricklafrance commented Nov 27, 2019

Looks good to me, where do you plug this to make it "automatic" ?

@shilman
Copy link
Member

shilman commented Nov 27, 2019

Could do something like this, except for blocks?

https://github.com/storybookjs/storybook/blob/master/lib/components/src/html.tsx#L6

I was just thinking to convert all of our existing escape hatch declarations to use this helper

@patricklafrance
Copy link
Member Author

I think using the helper would be easier.

As far as I know there isn't any central location where we loop through all the block components.

Also we must support MDX AND DocsPage

@patricklafrance
Copy link
Member Author

patricklafrance commented Nov 27, 2019

Not sure it will work for "inner" components.

I do think the helper function is the simplest and best solution even if it rely on the block author to remember to use it.

@patricklafrance
Copy link
Member Author

patricklafrance commented Nov 28, 2019

@shilman if we close this PR for 5.3 should we replace the escape hatches following the docblock format for sbdocs or wait for 6.0 ? This is a breaking change.

Easy way to solve this would be add sbdocs to those and then in 6.0 remove all docblock.

@patricklafrance
Copy link
Member Author

patricklafrance commented Nov 28, 2019

@shilman Does it make sense to you if we had sbdocs on component that are part of @storybook/components ?

Ex: the PropsTable component

@shilman
Copy link
Member

shilman commented Dec 2, 2019

@patricklafrance I'm fine with having sbdocs on the doc blocks in lib/components, and the transition plan sounds good

@stale
Copy link

stale bot commented Jan 13, 2020

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!

@shilman
Copy link
Member

shilman commented Jun 14, 2023

We’re cleaning house! Storybook has changed a lot since this issue was created and we don’t know if it’s still valid. Please open a new issue referencing this one if this is still a problem in SB 7.x cc @JReinhold

@shilman shilman closed this as not planned Won't fix, can't repro, duplicate, stale Jun 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants