Updating all pngs

storybookjs · Jun 14, 2024 · c849517 · c849517
1 parent 5843fe3
commit c849517
Show file tree

Hide file tree

Showing 67 changed files with 134 additions and 134 deletions.
diff --git a/docs/addons/addon-types.mdx b/docs/addons/addon-types.mdx
@@ -15,7 +15,7 @@ UI-based addons allow you to customize Storybook's UI with the following element
 
 Panel addons allow you to add your own UI in Storybook's addon panel. This is the most common type of addon in the ecosystem. For example, the official [`@storybook/actions`](../essentials/actions.md) and [`@storybook/a11y`](https://github.com/storybookjs/storybook/tree/next/code/addons/a11y) use this pattern.
 
-![Storybook panel](./storybook-panel.png)
+![Storybook panel](../_assets/addons/storybook-panel.png)
 
 Use this boilerplate code to add a new `Panel` to Storybook's UI:
 
@@ -29,7 +29,7 @@ Use this boilerplate code to add a new `Panel` to Storybook's UI:
 
 Toolbar addons allow you to add your own custom tools in Storybook's Toolbar. For example, the official [`@storybook/backgrounds`](../essentials/backgrounds.md) and the [`@storybook/addon-outline`](../essentials/measure-and-outline.md#outline-addon) use this pattern.
 
-![Storybook toolbar addon](./storybook-toolbar.png)
+![Storybook toolbar addon](../_assets/addons/storybook-toolbar.png)
 
 Use this boilerplate code to add a new `button` to Storybook's Toolbar:
 
@@ -51,7 +51,7 @@ Use this boilerplate code to add a new `button` to Storybook's Toolbar:
 
 Tab addons allow you to create your own custom tabs in Storybook. For example, the official [@storybook/addon-docs](../writing-docs/index.md) uses this pattern.
 
-![Storybook tab addon](./storybook-tab.png)
+![Storybook tab addon](../_assets/addons/storybook-tab.png)
 
 Use this boilerplate code to add a new `Tab` to Storybook's UI:
 

diff --git a/docs/addons/index.mdx b/docs/addons/index.mdx
@@ -24,7 +24,7 @@ The **Manager** is the UI responsible for rendering the:
 
 The **Preview** area is an `iframe` where your stories are rendered.
 
-![Storybook detailed window](./manager-preview.png)
+![Storybook detailed window](../_assets/addons/manager-preview.png)
 
 Because both elements run in their own separate `iframes`, they use a communication channel to keep in sync. For example, when you select a story in the Manager an event is dispatched across the channel notifying the Preview to render the story.
 

diff --git a/docs/addons/install-addons.mdx b/docs/addons/install-addons.mdx
@@ -45,7 +45,7 @@ Next, update `.storybook/main.js|ts` to the following:
 
 When you run Storybook, the accessibility testing addon will be enabled.
 
-![Storybook addon installed and registered](./storybook-addon-installed-registered.png)
+![Storybook addon installed and registered](../_assets/addons/storybook-addon-installed-registered.png)
 
 ### Removing addons
 

diff --git a/docs/addons/integration-catalog.mdx b/docs/addons/integration-catalog.mdx
@@ -83,7 +83,7 @@ Use the list below as a reference when filling in the values for both the `suppo
 
 The `package.json` above appears like below in the catalog. See an example of a production package.json [here](https://github.com/chromaui/storybook-outline/blob/main/package.json).
 
-![Storybook addon in the catalog](./addon-display.png)
+![Storybook addon in the catalog](../_assets/addons/addon-display.png)
 
 #### How long does it take for my addon to show up in the catalog?
 

diff --git a/docs/addons/writing-addons.mdx b/docs/addons/writing-addons.mdx
@@ -138,7 +138,7 @@ Notice the `match` property. It allows you to control the view mode (story or do
 
 Run the `start` script to build and start Storybook and verify that the addon is registered correctly and showing in the UI.
 
-![Addon registered in the toolbar](./storybook-addon-initial-state.png)
+![Addon registered in the toolbar](../_assets/addons/storybook-addon-initial-state.png)
 
 ### Style the addon
 
@@ -270,7 +270,7 @@ Finally, run the following command to create a release for your addon. This will
 
 By default, the Addon Kit comes pre-configured with a GitHub Actions workflow, enabling you to automate the release management process. This ensures that the package is always up to date with the latest changes and that the changelog is updated accordingly. However, you'll need additional configuration to use your NPM and GitHub tokens to publish the package successfully. In your repository, click the **Settings** tab, then the **Secrets and variables** dropdown, followed by the **Actions** item. You should see the following screen:
 
-![GitHub secrets page](./github-secrets-screen.png)
+![GitHub secrets page](../_assets/addons/github-secrets-screen.png)
 
 Then, click the **New repository secret**, name it `NPM_TOKEN`, and paste the token you generated earlier. Whenever you merge a pull request to the default branch, the workflow will run and publish a new release, automatically incrementing the version number and updating the changelog.
 

diff --git a/docs/api/arg-types.mdx b/docs/api/arg-types.mdx
@@ -11,7 +11,7 @@ You can also use argTypes to “annotate” args with information used by addons
 
 The most concrete realization of argTypes is the [`ArgTypes` doc block](./doc-block-argtypes.md) ([`Controls`](./doc-block-controls.md) is similar). Each row in the table corresponds to a single argType and the current value of that arg.
 
-![ArgTypes table](./doc-block-argtypes.png)
+![ArgTypes table](../_assets/api/doc-block-argtypes.png)
 
 ## Automatic argType inference
 

diff --git a/docs/api/doc-blocks/doc-block-argtypes.mdx b/docs/api/doc-blocks/doc-block-argtypes.mdx
@@ -13,7 +13,7 @@ The `ArgTypes` block can be used to show a static table of [arg types](./argtype
   If you’re looking for a dynamic table that shows a story’s current arg values for a story and supports users changing them, see the [`Controls`](./doc-block-controls.md) block instead.
 </Callout>
 
-![Screenshot of ArgTypes block](./doc-block-argtypes.png)
+![Screenshot of ArgTypes block](../_assets/doc-blocks/doc-block-argtypes.png)
 
 {/* prettier-ignore-start */}
 

diff --git a/docs/api/doc-blocks/doc-block-canvas.mdx b/docs/api/doc-blocks/doc-block-canvas.mdx
@@ -9,7 +9,7 @@ sidebar:
 
 The `Canvas` block is a wrapper around a [`Story`](./doc-block-story.md), featuring a toolbar that allows you to interact with its content while automatically providing the required [`Source`](./doc-block-source.md) snippets.
 
-![Screenshot of Canvas block](./doc-block-canvas.png)
+![Screenshot of Canvas block](../_assets/doc-blocks/doc-block-canvas.png)
 
 When using the Canvas block in MDX, it references a story with the `of` prop:
 

diff --git a/docs/api/doc-blocks/doc-block-colorpalette.mdx b/docs/api/doc-blocks/doc-block-colorpalette.mdx
@@ -9,7 +9,7 @@ sidebar:
 
 The `ColorPalette` block allows you to document all color-related items (e.g., swatches) used throughout your project.
 
-![Screenshot of ColorPalette and ColorItem blocks](./doc-block-colorpalette.png)
+![Screenshot of ColorPalette and ColorItem blocks](../_assets/doc-blocks/doc-block-colorpalette.png)
 
 {/* prettier-ignore-start */}
 

diff --git a/docs/api/doc-blocks/doc-block-controls.mdx b/docs/api/doc-blocks/doc-block-controls.mdx
@@ -13,7 +13,7 @@ The `Controls` block can be used to show a dynamic table of args for a given sto
   If you’re looking for a static table that shows a component's arg types with no controls, see the [`ArgTypes`](./doc-block-argtypes.md) block instead.
 </Callout>
 
-![Screenshot of Controls block](./doc-block-controls.png)
+![Screenshot of Controls block](../_assets/doc-blocks/doc-block-controls.png)
 
 {/* prettier-ignore-start */}
 

diff --git a/docs/api/doc-blocks/doc-block-description.mdx b/docs/api/doc-blocks/doc-block-description.mdx
@@ -9,7 +9,7 @@ sidebar:
 
 The `Description` block displays the description for a component, story, or meta, obtained from their respective JSDoc comments.
 
-![Screenshot of Description block](./doc-block-title-subtitle-description.png)
+![Screenshot of Description block](../_assets/doc-blocks/doc-block-title-subtitle-description.png)
 
 {/* prettier-ignore-start */}
 

diff --git a/docs/api/doc-blocks/doc-block-icongallery.mdx b/docs/api/doc-blocks/doc-block-icongallery.mdx
@@ -9,7 +9,7 @@ sidebar:
 
 The `IconGallery` block enables you to easily document React icon components associated with your project, displayed in a neat grid.
 
-![Screenshot of IconGallery and IconItem blocks](./doc-block-icongallery.png)
+![Screenshot of IconGallery and IconItem blocks](../_assets/doc-blocks/doc-block-icongallery.png)
 
 {/* prettier-ignore-start */}
 

diff --git a/docs/api/doc-blocks/doc-block-markdown.mdx b/docs/api/doc-blocks/doc-block-markdown.mdx
@@ -7,7 +7,7 @@ sidebar:
 
 The `Markdown` block allows you to import and include plain markdown in your MDX files.
 
-![Screenshot of Markdown block](./doc-block-markdown.png)
+![Screenshot of Markdown block](../_assets/doc-blocks/doc-block-markdown.png)
 
 When importing markdown files, it’s important to use the `?raw` suffix on the import path to ensure the content is imported as-is, and isn’t being evaluated:
 

diff --git a/docs/api/doc-blocks/doc-block-primary.mdx b/docs/api/doc-blocks/doc-block-primary.mdx
@@ -9,7 +9,7 @@ sidebar:
 
 The `Primary` block displays the primary (first defined in the stories file) story, in a [`Story`](./doc-block-story.md) block. It is typically rendered immediately under the title in a docs entry.
 
-![Screenshot of Primary block](./doc-block-primary.png)
+![Screenshot of Primary block](../_assets/doc-blocks/doc-block-primary.png)
 
 {/* prettier-ignore-start */}
 

diff --git a/docs/api/doc-blocks/doc-block-source.mdx b/docs/api/doc-blocks/doc-block-source.mdx
@@ -9,7 +9,7 @@ sidebar:
 
 The `Source` block is used to render a snippet of source code directly.
 
-![Screenshot of Source block](./doc-block-source.png)
+![Screenshot of Source block](../_assets/doc-blocks/doc-block-source.png)
 
 {/* prettier-ignore-start */}
 

diff --git a/docs/api/doc-blocks/doc-block-stories.mdx b/docs/api/doc-blocks/doc-block-stories.mdx
@@ -9,7 +9,7 @@ sidebar:
 
 The `Stories` block renders the full collection of stories in a stories file.
 
-![Screenshot of Stories block](./doc-block-stories.png)
+![Screenshot of Stories block](../_assets/doc-blocks/doc-block-stories.png)
 
 {/* prettier-ignore-start */}
 

diff --git a/docs/api/doc-blocks/doc-block-story.mdx b/docs/api/doc-blocks/doc-block-story.mdx
@@ -15,7 +15,7 @@ In Storybook Docs, you can render any of your stories from your CSF files in the
   Typically you want to use the [`Canvas` block](./doc-block-canvas.md) to render a story with a surrounding border and the source block, but you can use the `Story` block to render just the story.
 </Callout>
 
-![Screenshot of Story block](./doc-block-story.png)
+![Screenshot of Story block](../_assets/doc-blocks/doc-block-story.png)
 
 {/* prettier-ignore-start */}
 

diff --git a/docs/api/doc-blocks/doc-block-subtitle.mdx b/docs/api/doc-blocks/doc-block-subtitle.mdx
@@ -9,7 +9,7 @@ sidebar:
 
 The `Subtitle` block can serve as a secondary heading for your docs entry.
 
-![Screenshot of Subtitle block](./doc-block-title-subtitle-description.png)
+![Screenshot of Subtitle block](../_assets/doc-blocks/doc-block-title-subtitle-description.png)
 
 {/* prettier-ignore-start */}
 

diff --git a/docs/api/doc-blocks/doc-block-title.mdx b/docs/api/doc-blocks/doc-block-title.mdx
@@ -9,7 +9,7 @@ sidebar:
 
 The `Title` block serves as the primary heading for your docs entry. It is typically used to provide the component or page name.
 
-![Screenshot of Title block](./doc-block-title-subtitle-description.png)
+![Screenshot of Title block](../_assets/doc-blocks/doc-block-title-subtitle-description.png)
 
 {/* prettier-ignore-start */}
 

diff --git a/docs/api/doc-blocks/doc-block-typeset.mdx b/docs/api/doc-blocks/doc-block-typeset.mdx
@@ -9,7 +9,7 @@ sidebar:
 
 The `Typeset` block helps document the fonts used throughout your project.
 
-![Screenshot of Typeset block](./doc-block-typeset.png)
+![Screenshot of Typeset block](../_assets/doc-blocks/doc-block-typeset.png)
 
 {/* prettier-ignore-start */}
 

diff --git a/docs/api/doc-blocks/doc-block-unstyled.mdx b/docs/api/doc-blocks/doc-block-unstyled.mdx
@@ -35,7 +35,7 @@ import { Header } from "./Header.tsx";
 
 Yields:
 
-![Screenshot of Unstyled Doc Block](./doc-block-unstyled.png)
+![Screenshot of Unstyled Doc Block](../_assets/doc-blocks/doc-block-unstyled.png)
 
 <Callout variant="info">
   The other blocks like [`Story`](./doc-block-story.md) and [`Canvas`](./doc-block-canvas.md) are already unstyled, so there’s no need to wrap those in the `Unstyled` block to ensure that Storybook’s styles don’t bleed into the stories. However, if you import your components directly in the MDX, you most likely want to wrap them in the Unstyled block.

diff --git a/docs/api/portable-stories/portable-stories-jest.mdx b/docs/api/portable-stories/portable-stories-jest.mdx
@@ -212,7 +212,7 @@ export const SUPPORTED_RENDERERS = ['react', 'vue'];
 
   To preview your stories, Storybook runs a story pipeline, which includes applying project annotations, loading data, rendering the story, and playing interactions. This is a simplified version of the pipeline:
 
-  ![A flow diagram of the story pipeline. First, set project annotations. Storybook automatically collects decorators etc. which are exported by addons and the .storybook/preview file. .storybook/preview.js produces project annotations; some-addon/preview produces addon annotations. Second, prepare. Storybook gathers all the metadata required for a story to be composed. Select.stories.js produces component annotations from the default export and story annotations from the named export. Third, load. Storybook executes all loaders (async). Fourth, render. Storybook renders the story as a component. Illustration of the rendered Select component. Fifth, play. Storybook runs the play function (interacting with component). Illustration of the renderer Select component, now open.](story-pipeline.png)
+  ![A flow diagram of the story pipeline. First, set project annotations. Storybook automatically collects decorators etc. which are exported by addons and the .storybook/preview file. .storybook/preview.js produces project annotations; some-addon/preview produces addon annotations. Second, prepare. Storybook gathers all the metadata required for a story to be composed. Select.stories.js produces component annotations from the default export and story annotations from the named export. Third, load. Storybook executes all loaders (async). Fourth, render. Storybook renders the story as a component. Illustration of the rendered Select component. Fifth, play. Storybook runs the play function (interacting with component). Illustration of the renderer Select component, now open.](../../_assets/api/story-pipeline.png)
 
   When you want to reuse a story in a different environment, however, it's crucial to understand that all these steps make a story. The portable stories API provides you with the mechanism to recreate that story pipeline in your external environment:
 

diff --git a/docs/api/portable-stories/portable-stories-playwright.mdx b/docs/api/portable-stories/portable-stories-playwright.mdx
@@ -165,7 +165,7 @@ export const SUPPORTED_RENDERERS = ['react', 'vue'];
 
   To preview your stories, Storybook runs a story pipeline, which includes applying project annotations, loading data, rendering the story, and playing interactions. This is a simplified version of the pipeline:
 
-  ![A flow diagram of the story pipeline. First, set project annotations. Storybook automatically collects decorators etc. which are exported by addons and the .storybook/preview file. .storybook/preview.js produces project annotations; some-addon/preview produces addon annotations. The rest of the steps are labeled as a group, Playwright test. Second, prepare. Storybook gathers all the metadata required for a story to be composed. Select.stories.js produces component annotations from the default export and story annotations from the named export. Third, load. Storybook executes all loaders (async). Fourth, render. Storybook renders the story as a component. Illustration of the rendered Select component. Fifth, play. Storybook runs the play function (interacting with component). Illustration of the renderer Select component, now open.](story-pipeline-playwright-ct.png)
+  ![A flow diagram of the story pipeline. First, set project annotations. Storybook automatically collects decorators etc. which are exported by addons and the .storybook/preview file. .storybook/preview.js produces project annotations; some-addon/preview produces addon annotations. The rest of the steps are labeled as a group, Playwright test. Second, prepare. Storybook gathers all the metadata required for a story to be composed. Select.stories.js produces component annotations from the default export and story annotations from the named export. Third, load. Storybook executes all loaders (async). Fourth, render. Storybook renders the story as a component. Illustration of the rendered Select component. Fifth, play. Storybook runs the play function (interacting with component). Illustration of the renderer Select component, now open.](../../_assets/api/story-pipeline-playwright-ct.png)
 
   When you want to reuse a story in a different environment, however, it's crucial to understand that all these steps make a story. The portable stories API provides you with the mechanism to recreate that story pipeline in your external environment:
 

diff --git a/docs/api/portable-stories/portable-stories-vitest.mdx b/docs/api/portable-stories/portable-stories-vitest.mdx
@@ -204,7 +204,7 @@ export const SUPPORTED_RENDERERS = ['react', 'vue', 'svelte'];
 
   To preview your stories, Storybook runs a story pipeline, which includes applying project annotations, loading data, rendering the story, and playing interactions. This is a simplified version of the pipeline:
 
-  ![A flow diagram of the story pipeline. First, set project annotations. Storybook automatically collects decorators etc. which are exported by addons and the .storybook/preview file. .storybook/preview.js produces project annotations; some-addon/preview produces addon annotations. Second, prepare. Storybook gathers all the metadata required for a story to be composed. Select.stories.js produces component annotations from the default export and story annotations from the named export. Third, load. Storybook executes all loaders (async). Fourth, render. Storybook renders the story as a component. Illustration of the rendered Select component. Fifth, play. Storybook runs the play function (interacting with component). Illustration of the renderer Select component, now open.](story-pipeline.png)
+  ![A flow diagram of the story pipeline. First, set project annotations. Storybook automatically collects decorators etc. which are exported by addons and the .storybook/preview file. .storybook/preview.js produces project annotations; some-addon/preview produces addon annotations. Second, prepare. Storybook gathers all the metadata required for a story to be composed. Select.stories.js produces component annotations from the default export and story annotations from the named export. Third, load. Storybook executes all loaders (async). Fourth, render. Storybook renders the story as a component. Illustration of the rendered Select component. Fifth, play. Storybook runs the play function (interacting with component). Illustration of the renderer Select component, now open.](../../_assets/api/story-pipeline.png)
 
   When you want to reuse a story in a different environment, however, it's crucial to understand that all these steps make a story. The portable stories API provides you with the mechanism to recreate that story pipeline in your external environment:
 

diff --git a/docs/builders/builder-api.mdx b/docs/builders/builder-api.mdx
@@ -7,7 +7,7 @@ sidebar:
 
 Storybook is architected to support multiple builders, including [Webpack](https://webpack.js.org/), [Vite](https://vitejs.dev/), and [ESBuild](https://esbuild.github.io/). The builder API is the set of interfaces you can use to add a new builder to Storybook.
 
-![Storybook builders](./storybook-builders.png)
+![Storybook builders](../_assets/builders/storybook-builders.png)
 
 ## How do builders work?
 

diff --git a/docs/builders/index.mdx b/docs/builders/index.mdx
@@ -8,7 +8,7 @@ sidebar:
 
 Storybook, at its core, is powered by builders such as Webpack and Vite. These builders spin up a development environment, compile your code—Javascript, CSS, and MDX—into an executable bundle and update the browser in real-time.
 
-![Storybook builder overview](./storybook-builder-workflow.png)
+![Storybook builder overview](../_assets/builders/storybook-builder-workflow.png)
 
 ## CLI basics
 

diff --git a/docs/configure/story-layout.mdx b/docs/configure/story-layout.mdx
@@ -17,7 +17,7 @@ You can add the parameter to your [`./storybook/preview.js`](./index.md#configur
 
 {/* prettier-ignore-end */}
 
-![Layout params centered story](./layout-params-story-centered.png)
+![Layout params centered story](../_assets/configure/layout-params-story-centered.png)
 
 In the example above, Storybook will center all stories in the UI. `layout` accepts these options:
 

diff --git a/docs/configure/user-interface/sidebar-and-urls.mdx b/docs/configure/user-interface/sidebar-and-urls.mdx
@@ -9,15 +9,15 @@ sidebar:
 
 Storybook’s sidebar lists all your stories grouped by component. When you have many components, you may also wish to group those components. To do so, you can add the `/` separator to the `title` of your CSF file, and Storybook will group the stories into groups based on common prefixes:
 
-![Storybook sidebar anatomy](./sidebar-anatomy.png)
+![Storybook sidebar anatomy](../../_assets/configure/sidebar-anatomy.png)
 
 We recommend using a nesting scheme that mirrors the filesystem path of the components. For example, if you have a file `components/modals/Alert.js`, name the CSF file `components/modals/Alert.stories.js` and title it `Components/Modals/Alert`.
 
 ## Roots
 
 By default, Storybook will treat your top-level nodes as “roots”. Roots are displayed in the UI as “sections” of the hierarchy. Lower level groups will show up as folders:
 
-![Storybook sidebar story roots](./sidebar-roots.png)
+![Storybook sidebar story roots](../../_assets/configure/sidebar-roots.png)
 
 If you’d prefer to show top-level nodes as folders rather than roots, you can set the `sidebar.showRoots` option to `false` in [`./storybook/manager.js`](./features-and-behavior.md):