@storybook/server-webpack5

Storybook for Server

---

Storybook for Server is a UI development environment for your plain HTML snippets rendered by your server backend. With it, you can visualize different states of your UI components and develop them interactively.

Storybook runs outside of your app. So you can develop UI components in isolation without worrying about app specific dependencies and requirements.

Getting Started

cd my-app
npx storybook init -t server

To configure the server that Storybook will connect to, export a global parameter parameters.server.url in .storybook/preview.js:

export const parameters = {
  server: {
    url: `http://localhost:${port}/storybook_preview`,
  },
};

The URL you connect to should have the ability to render a story, see server rendering below.

For more information visit: storybook.js.org

Writing Stories

To write a story, use whatever API is natural for your server-side rendering framework to generate set of JSON or YAML files of stories analogous to CSF files (see the server-kitchen-sink example for ideas).

{
  "title": "Component",
  "parameters": {
    "options": { "component": "my_widget" }
  },
  "stories": [
    {
      "name": "Default",
      "parameters": {
        "server": { "id": "path/of/your/story" }
      }
    }
  ]
}

In your .storybook/main.js you simply provide a glob specifying the location of those JSON files, e.g.

module.exports = {
  stories: ['../stories/**/*.stories.json'],
};

Notice that the JSON does not specify a rendering function -- @storybook/server will instead call your parameters.server.url with the story's server id appended.

For example the JSON story above is requivalent to the CSF3 definition:

export default {
  title: 'Component',
  parameters: {
    options: {
      component: 'my_widget',
    },
  },
};

export const Default = {
  name: 'Default',
  parameters: {
    server: {
      id: 'path/of/your/story"',
    },
  },
};

With the story HTML will be fetched from the server by making a GET request to http://localhost/storybook_preview/path/of/your/story`

Ruby/Rails support

In particular the View Component::Storybook gem provides a Ruby API for easily creating the above with a Ruby/Rails DSL (as well as providing a server rendering endpoint).

Server rendering

The server rendering side of things is relatively straightfoward. When you browse to a story in the sidebar, Storybook will make a fetch request to ${parameters.server.url}/{parameters.server.id} and display the HTML that is returned.

You need to ensure the route in your server app renders the appropriate HTML when called in that fashion.

Passing parameters to the server

Many components are likely to be dynamic - responding to parameters that change their content or appearance. @storybook\server has two mechanisms for passing those parameters to the server - params and args. Parameters defined in this way are appended to the fetch url as query string parameters. The server endpoint is responsible for interpreting those parameters and vary the returned html appropriately

Constant parameters with params

Static parameters can be defined using the params story parameter. For example suppose you have a Button component that has a label and color options:

{
  "title": "Buttons",
  "stories": [
    {
      "name": "Red",
      "parameters": {
        "server": {
          "id": "button",
          "params": { "color": "red", "label": "Stop" }
        }
      }
    },
    {
      "name": "Green",
      "parameters": {
        "server": {
          "id": "button",
          "params": { "color": "green", "label": "OK" }
        }
      }
    }
  ]
}

The Red and Green story HTML will be fetched from the urls server.url/controls/button?color=red&label=Stop and server.url/controls/button?color=green&label=OK

Like all story parameters server params can be defined in the default export and overridden in stories.

{
  "title": "Buttons",
  "parameters": {
    "server": {
      "params": { "color": "red" }
    }
  },
  "stories": [
    {
      "name": "Default",
      "parameters": {
        "server": {
          "id": "button",
          "params": { "label": "Stop" }
        }
      }
    },
    {
      "name": "Green",
      "parameters": {
        "server": {
          "id": "button",
          "params": { "color": "green", "label": "OK" }
        }
      }
    }
  ]
}

Dynamic parameters with args and Controls

Dynamic parameters can be defined using args and the Controls addon

{
  "title": "Buttons",
  "stories": [
    {
      "name": "Red",
      "parameters": {
        "server": {
          "id": "button"
        }
      },
      "args": { "color": "red", "label": "Stop" }
    },
    {
      "name": "Green",
      "parameters": {
        "server": {
          "id": "button"
        }
      },
      "args": { "color": "green", "label": "Go" }
    }
  ]
}

Story args are passed to the server as url query parameters just like params except now they can be varied on the Controls addon panel.

Just like CSF stories we can define argTypes to specify the controls used in the controls panel. argTypes can be defined at the default or story level.

{
  "title": "Buttons",
  "argTypes": {
    "color": { "control": { "type": "color" } }
  },
  "stories": [
    {
      "name": "Red",
      "parameters": {
        "server": {
          "id": "button"
        }
      },
      "args": { "color": "red", "label": "Stop" }
    },
    {
      "name": "Green",
      "parameters": {
        "server": {
          "id": "button"
        }
      },
      "args": { "color": "green", "label": "Go" }
    }
  ]
}

Addon compatibility

Storybook also comes with a lot of addons and a great API to customize as you wish. As some addons assume the story is rendered in JS, they may not work with @storybook/server (yet!).

Many addons that act on the manager side (such as backgrounds and viewport) will work out of the box with @storybook/server -- you can configure them with parameters written on the server as usual.

Controls

To configure controls, simple add args and argTypes keys to the story JSON much like you would CSF:

{
  "title": "Controls",
  "stories": [
    {
      "name": "Button",
      "parameters": {
        "server": { "id": "controls/button" }
      },
      "args": { "button_text": "Push Me", "color": "red" },
      "argTypes": { "button_text": { "control": { "type": "color" } } }
    }
  ]
}

The controls values will be added to your story URL as query parameters.

Actions

To use actions, use the parameters.actions.handles parameter:

{
  "title": "Actions",
  "stories": [
    {
      "name": "Button",
      "parameters": {
        "server": { "id": "actions/button" },
        "actions": {
          "handles": ["mouseover", "click .btn"]
        }
      }
    }
  ]
}

Advanced Configuration

fetchStoryHtml

For control over how @storybook/server fetches Html from the server you can provide a fetchStoryHtml function as a parameter. You would typically set this in .storybook/preview.js but it's just a regular Storybook parameter so could be overridden at the stories or story level.

// .storybook/preview.js

const fetchStoryHtml = async (url, path, params, context) => {
  // Custom fetch implementation
  // ....
  return html;
};

export const parameters = {
  server: {
    url: `http://localhost:${port}/storybook_preview`,
    fetchStoryHtml,
  },
};

fetchStoryHtml should be an async function with the following signature

type FetchStoryHtmlType = (
  url: string,
  id: string,
  params: any,
  context: StoryContext
) => Promise<string | Node>;

• url: Server url configured by the parameters.server.url
• id: Id of the story being rendered given by parameters.server.id
• params: Merged story params parameters.server.paramsand story args
• context: The context of the story

Changelog

7.0.0-alpha.28 (September 2, 2022)

Features

• Vite: Automatically use vite.config.js #19026

Bug Fixes

• CLI: Fix race condition in sb init #19083
• Vite: Fix framework option checks, and SSv6 #19062
• Core: Fix WebProjectAnnotations export in preview-web for back-compat #19048
• Blocks: Fix Checkbox control update when using useArgs hook

Maintenance

• Update to new TS reference format (?) #19072
• Build: Conditionally force vite rebuilds in sandbox #19063
• Build: Fix CRA bench #19066