core-client api

18 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

start() function signature and parameters

The start() function is called by a framework and takes renderToCanvas and an options object containing render and decorateStory properties. The renderToCanvas function tells Storybook how to render the result of a story function to the DOM. The render function is a default mapping of args to a story result in CSFv3. The decorateStory function tells Storybook how to combine decorators in the framework.

start() function return value

The start() function returns a configure() function, which can be re-exported to be used in preview.js (deprecated) or automatically by the main.js:stories field.

configure() function purpose

The configure() function returned by start() is used to return a list of CSF files or to make calls to the deprecated storiesOf API.

Core-Client package purpose

The Storybook Core-Client package contains browser-side functionality shared amongst all frameworks including React, React Native, Vue 3, Ember, and Angular in the old v6 story store back-compatibility layer.

Import logger from storybook/internal/client-logger

Client-side logging in Storybook should be done through the logger package. Import the logger with: import { logger } from 'storybook/internal/client-logger';

Logger methods available

The logger object provides three methods: logger.info() for info messages, logger.warn() for warning messages, and logger.error() for error messages.

Logger info, warn, and error example

Example of using the Storybook logger: ```js import { logger } from 'storybook/internal/client-logger'; logger.info('Info message'); logger.warn('Warning message'); logger.error('Error message'); ```

useArgs hook for accessing args in decorators and addons

Both @storybook/preview-api and @storybook/manager-api export a useArgs() hook that can be used to access args in decorators or addon panels. The hook returns [args, updateArgs], where args is the args of the currently rendered story and updateArgs will update its args, accepting a subset of args without changing others. Example: const [args, updateArgs] = useArgs();

useGlobals hook for accessing globals in addons

Both @storybook/preview-api and @storybook/manager-api export a useGlobals hook. The hook returns [globals, updateGlobals], where globals contains the global values and updateGlobals updates them. Example: const [globals, updateGlobals] = useGlobals();

Preview initialization parameters

The preview is initialized with three key parameters: importFn, which is an async import() function; getProjectAnnotations, which evaluates preview.js and addon config files and combines them, showing errors if they occur; and no getStoryIndex function is passed, instead the preview creates a StoryIndexClient that pulls stories.json from the node and watches the event stream for invalidation events.

Preview main responsibilities

The preview has three main responsibilities: read and update the URL via the URL Store, listen to instructions on the channel and emit events as things occur, and render the current selection to the web view in either story or docs mode.

Preview architecture components

The preview is split into three parts responsible for state management: PreviewWeb determines which story is rendered, receives events and may change/re-render stories; StoryRender imports and prepares the story and renders it through various phases; DocsRender handles rendering a story in docs mode by transforming it once known.

Story render phases

A rendering story goes through these phases in order: preparing (maybe async import the story file and prepare the story function), loading (async loaders are running), rendering (the renderToCanvas function for the framework is running), playing (the play function is running), and completed (the story is done).

Story render error states

Story rendering has two error states: aborted (the story was stopped midway) and errored (an error was thrown somewhere along the way).

UPDATE_STORY_ARGS and UPDATE_GLOBALS event behavior

When UPDATE_STORY_ARGS or UPDATE_GLOBALS events occur during render, if the story is in preparing or loading phase, the system leaves things unchanged and lets the new args or globals be picked up by the render phase. Otherwise, the system uses the result of the previous loaders run and simply re-renders over the top.

FORCE_RE_RENDER event behavior

FORCE_RE_RENDER re-renders an unchanged story. If this event happens during a render, if the story is preparing or loading, leave things unchanged and let the new args/globals be picked up by the render phase. Otherwise, use the result of the previous loaders run and simply re-render over the top.

FORCE_REMOUNT event behavior

FORCE_REMOUNT remounts or equivalent the component and re-renders. If this happens during a render, treat loading similarly to other update events. If the story is rendering, start a new render and abort the previous render immediately afterwards. If the story is playing, attempt to abort the previous play function and start a new render.

SET_CURRENT_STORY event handling

When SET_CURRENT_STORY event changes the current story, the preview checks if the storyId changed, if the viewMode changed, and if the story implementation changed via HMR. If the previous story is still preparing, it cannot determine if implementation changed, so it aborts preparing immediately and lets the new story take over. If storyId, viewMode, and implementation are all the same, do nothing. If they differ and the old story is not completed, attempt to abort it immediately; if that fails, reload the window.

Give your agent this brain