New "Framework" which renders server-side routes

Is your feature request related to a problem? Please describe We have an express app that powers a lot of different pages, it does not use a single framework and does not have an easy way to render directly to html. Knowing what routes are available requires digging through code for the express routers.

Describe the solution you’d like Being able to provide a *.stories.ts file next to each route which looks something like:

export default  {
  title: "Product/Product Page"
  route: "/product/:productid",
  argsTypes: {
    productid: {
      control: {
        type: "select",
        options: ["product-id-1", "product-id-2", "product-id-3"]
      }
    }
  }
}

Then in storybook this would load <base-url>/product/product-id-1 in the preview iframe and changing the productid control would reload it replacing :productid with the respective id. This could be extended to also support query parameters and hash values and maybe POST body data as well.

Describe alternatives you’ve considered Currently we just have a page of links, which does not regularly get updated and is not overly used. Making storybook the primary interaction point locally would likely solve that issue.

There are likely already products that solve this problem, however we use storybook for our design-system and using the fairly recent Storybook Composition feature to bring the documentation inside our main application dev environment would be fantastic.

Are you able to assist to bring the feature to reality? Potentially.

[jonspalmer]

@shilman is right. You need that change but its very simple to setup Storybook Server by hand. I suspect from your description that server will be what you need. I would expect you do write a few stories as json and off you go. It might be that you can auto generate the json from your other code much like we do with this gem for Rails: https://github.com/jonspalmer/view_component_storybook. I’d be happy to collaborate on that and figure out what it might look like.

[jonspalmer]

@AndrewLeedham a root story is likely possible. I suspect its’ a simple bug somewhere (Though IMO a story ‘without an id’ is a slightly strange idea. In my projects I’d want to make it explicit)

Supporting path params as well as just query params is likely pretty doable.

The details for all this are here: https://github.com/storybookjs/storybook/blob/next/app/server/src/client/preview/render.ts#L10

You can see how the request is constructed from the various params. It’s not that hard to see how you could pick out variables in the path and substitute them with param values. The good news is you can customize the fetch function: https://github.com/storybookjs/storybook/tree/next/app/server#fetchstoryhtml

Perhaps you can experiment with that feature. If there is a good general purpose solution submit it as a PR and we can support it out the box?