DEV Community: Danny

How to swap between React Native Storybook 10 and your app

Danny — Tue, 09 Dec 2025 11:43:39 +0000

This post has been updated and posted here: https://www.callstack.com/blog/how-to-cleanly-swap-between-react-native-storybook-10-and-your-app

Back in 2023 I wrote a post with a very similar title

It's been a while since I first wrote the original post on this topic, and I was quite surprised with how many people actually found that useful.

That original post has now become quite outdated though and I want to revisit this topic to show how much easier it is to do this now. Also how you can ensure that nothing leaks into your production bundle.

Whats changed?

A few different things happened that make the process simpler today.

Built in support for envs on Expo

At the time of the original post there wasn't a built in solution for environment variables on expo and we made use of expo constants. This works but requires a few more steps.

https://docs.expo.dev/guides/environment-variables

withStorybook metro helper function

In newer versions of React Native Storybook we now include a metro helper that applies some metro configuration and handles generating your story imports.

This also made it possible for us to introduce improvements to how we you enable/disable storybook.

Metro Configuration | React Native Storybook

The withStorybook function is a Metro configuration wrapper that enables Storybook functionality in your React Native app. It handles automatic story discovery, file generation, and optional WebSocket server setup.

storybookjs.github.io

Metro improved

We've also got some newer configuration options in metro such as resolver.resolveRequest that allow you to override some resolver functionality with your own logic. For example for storybook files we make sure that enablePackageExports is enabled.

https://docs.expo.dev/versions/latest/config/metro/#custom-resolving

Lets get into it

I'll split this up into expo and community cli guides, scroll down if you aren't using expo.

The Expo guide

I'm going to assume you already have a project setup to keep things simple. If you want to see how to get setup with expo router then check out my blog post on the expo blog.

I have also setup a blank typescript example app here that just has storybook setup. In the pull requests for this repo I followed the same guide so you can inspect the full code there.

Lets assume you have a project like this

.rnstorybook/
src/index.tsx
app.tsx
metro.config.js

You probably have a metro config like this:

// metro.config.js
const { getDefaultConfig } = require("expo/metro-config");
const {
  withStorybook,
} = require("@storybook/react-native/metro/withStorybook");

/** @type {import('expo/metro-config').MetroConfig} */
const config = getDefaultConfig(__dirname);

module.exports = withStorybook(config);

Right now you're just commenting out storybook and adding it back in when you need it.

// import StorybookUI from './.rnstorybook';
import { AppRoot } from './src';


export default function App() {
  // return <StorybookUI/>
  return <AppRoot />;
}

Theres a better way!

Expo now will inject environment variables into process.env like you might be used to from server or web frameworks. We can use this to simplify our life.

How To actually do it

First lets add a storybook script to our package.json

{
  "scripts": {
    "storybook": "EXPO_PUBLIC_STORYBOOK_ENABLED=true expo start",
  }
}

This is just the start command but with the EXPO_PUBLIC_STORYBOOK_ENABLED environment variable set to true.

Now lets go to our app and add a simple bit of logic.

// App.tsx
import StorybookUI from './.rnstorybook';
import { AppRoot } from './src';

const isStorybook = process.env.EXPO_PUBLIC_STORYBOOK_ENABLED === 'true';

export default function App() {
  return isStorybook ? <StorybookUI/> : <AppRoot />;
}

Now when ever you run yarn storybook you see storybook and whenever you run yarn start you see your app.

But my production bundle!

You might notice that we're importing storybook even when not using it and that will cause metro to include all the dependencies in the bundle.

This is where we bring in the new metro options.

Update your metro config to pass some options to withStorybook.

// metro.config.js
const { getDefaultConfig } = require("expo/metro-config");
const {
  withStorybook,
} = require("@storybook/react-native/metro/withStorybook");

/** @type {import('expo/metro-config').MetroConfig} */
const config = getDefaultConfig(__dirname);

module.exports = withStorybook(config, {
  enabled: process.env.EXPO_PUBLIC_STORYBOOK_ENABLED === "true", // <-
});

The enabled option when set to false in version 10 will actually strip storybook out of your bundle. I will explain a little bit how that works at the end in case you are interested.

Thats it!

Nothing else is needed, and from here you can expand on this idea and come up with more developer friendly ways to hide/show storybook. One example is to create a dev menu option and use it to toggle storybook in combination with the environment variable.

Expo router

With expo router I recommend putting Storybook in its own route and using a protected route to disable it when Storybook is not enabled.

// app/_layout.tsx

export default function RootLayout() {
  return (
    <Stack screenOptions={{ headerShown: false }}>
      <Stack.Screen name="index" />

      <Stack.Protected
        guard={process.env.EXPO_PUBLIC_STORYBOOK_ENABLED === "true"}
      >
        <Stack.Screen name="storybook" />
      </Stack.Protected>
    </Stack>
  );
}

Community Cli

If you are using the community cli or rock you can follow this guide.

I'm going to assume you already have a project setup to keep things simple. You can find an example project here

Lets assume you have a project like this

.rnstorybook/
src/index.tsx
app.tsx
metro.config.js

You probably have a metro config like this:

// metro.config.js
const { getDefaultConfig, mergeConfig } = require('@react-native/metro-config');

const {
  withStorybook,
} = require("@storybook/react-native/metro/withStorybook");

/**
 * Metro configuration
 * https://reactnative.dev/docs/metro
 *
 * @type {import('@react-native/metro-config').MetroConfig}
 */
const config = {};

const finalConfig = mergeConfig(getDefaultConfig(__dirname), config);

module.exports = withStorybook(finalConfig);

Right now you're just commenting out storybook and adding it back in when you need it.

// import StorybookUI from './.rnstorybook';
import { AppRoot } from './src';


export default function App() {
  // return <StorybookUI/>
  return <AppRoot />;
}

Theres a better way!

By using the babel plugin transform-inline-environment-variables we can get environment variables into our app bundle and start use that to make things easier.

How To actually do it

Add the babel plugin

//babel.config.js
module.exports = {
  presets: ['module:@react-native/babel-preset'],
  plugins: [
    'transform-inline-environment-variables', // <--
  ],
};

Lets add a storybook script to our package.json

{
  "scripts": {
    "storybook": "STORYBOOK_ENABLED=true react-native start",
  }
}

This is just the start command but with the STORYBOOK_ENABLED environment variable set to true.

Now lets go to our app and add a simple bit of logic.

// App.tsx
import StorybookUI from './.rnstorybook';
import { AppRoot } from './src';

const isStorybook = process.env.STORYBOOK_ENABLED === 'true';

export default function App() {
  return isStorybook ? <StorybookUI/> : <AppRoot />;
}

Now when ever you run yarn storybook you see storybook and whenever you run yarn start you see your app.

But my production bundle!

You might notice that we're importing storybook even when not using it and that will cause metro to include all the dependencies in the bundle.

This is where we bring in the new metro options.

Update your metro config to pass some options to withStorybook.

// metro.config.js
const { getDefaultConfig, mergeConfig } = require('@react-native/metro-config');

const {
  withStorybook,
} = require("@storybook/react-native/metro/withStorybook");

/**
 * Metro configuration
 * https://reactnative.dev/docs/metro
 *
 * @type {import('@react-native/metro-config').MetroConfig}
 */
const config = {};

const finalConfig = mergeConfig(getDefaultConfig(__dirname), config);

module.exports = withStorybook(finalConfig, {
  enabled: process.env.EXPO_PUBLIC_STORYBOOK_ENABLED === "true", // <-
});

The enabled option when set to false in version 10 will actually strip storybook out of your bundle.

Thats it!

How does this work

The withStorybook wrapper makes use of custom resolvers like I've mentioned earlier in this post.

First let me expand a bit on what I mean by that.

mock a module using metro resolvers

If you look at the expo docs about metro you'll find this example that I think illustrates pretty well how you can use resolvers to mock out a module.

const { getDefaultConfig } = require('expo/metro-config');

/** @type {import('expo/metro-config').MetroConfig} */
const config = getDefaultConfig(__dirname);

config.resolver.resolveRequest = (context, moduleName, platform) => {
  if (platform === 'web' && moduleName === 'lodash') {
    return {
      type: 'empty',
    };
  }

  // Ensure you call the default resolver.
  return context.resolveRequest(context, moduleName, platform);
};

module.exports = config;

By return type: 'empty' metro essentially just ignore that entire codepath and you won't find it in your bundle anymore.

However this isn't limited to just 'empty', you can also swap out the file thats used.

// ...
return {
   filePath: 'path-to-file-here',
   type: 'sourceFile',
};

The implementation in Storybook

In Storybook we combine both of these to make this work, we return empty for anything in your .rnstorybook folder and replace .rnstorybook/index.tsx with a file that imports nothing and exports a component warning you that storybook is disabled.

  if (!enabled) {
    return {
      ...config,
      resolver: {
        ...config.resolver,
        resolveRequest: (context: any, moduleName: string, platform: string | null) => {
          const resolveFunction: ResolveRequestFunction = config?.resolver?.resolveRequest
            ? config.resolver.resolveRequest
            : context.resolveRequest;

          const resolved = resolveFunction(context, moduleName, platform);

          if (resolved.filePath?.includes?.(`${configPath}/index.tsx`)) {
            return {
              filePath: path.resolve(__dirname, '../stub.js'),
              type: 'sourceFile',
            };
          }

          if (resolved.filePath?.includes?.(configPath)) {
            return { type: 'empty' };
          }

          return resolved;
        },
      },
    };
  }

The reason we specifically stub out the index file is that otherwise if you have this code and StorybookUI isn't a component then its going to crash.

export default function App() {
  return isStorybook ? <StorybookUI/> : <AppRoot />;
}

By returning an empty component then this syntax still works and the original code is still removed from the bundle.

The End

I believe that covers everything, let me know if you have any questions or if I missed anything.

As always you can reach out to me on twitter:

https://x.com/Danny_H_W

Also you can sponsor me on github if you like my work:
https://github.com/sponsors/dannyhw/

React Native Web with Vite

Danny — Mon, 11 Aug 2025 11:40:08 +0000

I'd like to share with you a new Vite plugin I've been working on and encourage you to give it a try. First though I'd like to tell a story on how this came about.

A brief history

Four years ago I published a Storybook addon for React Native Web that would apply the config you need for Storybook with Webpack to display React Native components.

I got the idea from an issue someone raised on the Storybook Github where they had managed to get a custom Webpack config working for React Native. Before this I hadn't really even considered this as a possibility so I was immediately intrigued.

You can practically hear the cogs turning in my head.

Over the next few weeks I started experimenting with different Webpack configurations to figure out how to get React Native Web working. At the time Expo was also using Webpack for their React Native Web solution and I ended up taking quite a bit of that code for my plugin. Eventually I got something working and I made an addon that essentially added an extra babel-loader to your Storybook config with all the React Native Web stuff you might need.

This worked great for a while and the package has reached a decent level of popularity. However it does have a few issues and webpack is getting left behind. If you have experience configuring webpack you'll also know the pain I've been through with it.

Clearly though we're here to talk about Vite, and why even make a Webpack addon? Well there wasn't initially a way to use other bundlers with Storybook, everything worked via Webpack. However this changed in Storybook 6 and you could now pick your bundler via builders.

Vite | Storybook docs

Storybook is a frontend workshop for building UI components and pages in isolation. Thousands of teams use it for UI development, testing, and documentation. It's open source and free.

storybook.js.org

Quite quickly the Vite builder became very popular and this led to Vite becoming the recommended and default bundler for Storybook. Today most of Storybook's new features are being built on top of Vite, such as component testing features built on top of Vitest. Since this started happening I've been trying to make Vite work for React Native Web, but without much experience with Vite or web bundlers in general this took me quite a while.

What makes React Native Web different

If you look into bundling react native code for the web you'll find that things look a bit different than code you might see on the web today. In React Native projects we use a bundler called Metro that specifically targets React Native. This means it has features more focused on targeting different platforms and bundling into a single file for the React Native Javascript engine Hermes. A lot of the differences you see in React Native code is a direct result of how Metro bundling works.

Metro will transpile everything including node_modules.
Metro will take all the code no matter what it is and turn it into what is essentially es5/es6 commonjs code for Hermes.
Metro platform specific code in .web/.ios/.android
Metro doesn't have a plugin system and instead the bundling is extended via babel plugins
React Native is written in flow
Its common practice to mix ESM and commonjs require for images and import for modules

Since library developers assume Metro will bundle all your node_modules packages, many packages will ship unbundled. However when using other bundlers the node_modules folder is usually excluded for performance reasons.

So knowing these things heres what you need to consider when getting React Native Web to work.

Alias react-native to react-native-web
Resolve .web.js before .js
Add a bunch of global variables React Native and Expo expects
Transpile code with babel including node_modules
Strip flow syntax
Treat .js as .jsx
Handle mixed commonjs and esm code

This list is the result of a lot of trying and failing, honestly running React Native Web is a bit of a mystery from the outside. This might be largely because I'm often trying to run it outside of the 'normal' constraints. If you were using Expo for React Native Web its quite unlikely you'd run into any of these issues because they put in a lot of work to make it run well for metro.

Making Vite work

I had some early success with just the react Vite plugin and applying the same config I would for Webpack. After a few attempts I had something working and was getting excited, though as soon I tried to run a build everything stopped working again.

What would happen is Vite would automatically optimize the node_modules in dev mode but in production builds that doesn't happen. Even if you try to configure the React plugin to include node_modules nothing will change. Thats because the react plugin specifically bails out whenever a file comes from node_modules.

I was missing a way to transpile node_modules (#4 on our list). Luckily though there are some solutions. The first success I had with this was using the Babel Vite plugin together with the React Vite plugin. This actually was working quite well and powered the first versions of my Vite framework for Storybook. The problem is that you had to basically configure babel twice and surfacing that to the user in a sane way is pretty difficult.

I tried a few things after this but I essentially landed on making a custom Vite plugin based on the React plugin but with all the React Native configurations built in. It automatically includes modules from react-native or expo. This plugin became vite-plugin-rnw and it now powers the React Native Web Storybook framework @storybook/react-native-web-vite.

npmjs.com

With this new plugin all you need is this to get started:

// vite.config.js
import { defineConfig } from "vite";
import { rnw } from "vite-plugin-rnw";

export default defineConfig({
  plugins: [rnw()],
});

Then if you need to transpile some node_modules you can override the config and it will respect whatever you decide to include.

Heres an example of an excludes pattern you could use.

const modulesToTranspile = [
  'react-native',
  '@react-native',
  'expo',
  '@expo',
  "other-module"
];

const exclude = new RegExp(`/node_modules/(?!${modulesToTranspile.join('|')})`) 

export default defineConfig({
  plugins: [rnw({ exclude })],
});

How does it work?

From here on I'm going to dive into the Vite config I ended up with to get this all working.

Looking back at the list:

Alias react-native to react-native-web
Resolve .web.js before .js
Add a bunch of global variables React Native and Expo expects
transpile code with babel including node_modules
Strip flow syntax
Treat .js as .jsx
Handle mixed commonjs and esm code

1. Handling aliases

This is easily achieved with some resolve configuration:

{
  resolve: {
     alias: {
        "react-native": "react-native-web",
     },
  }
}

2. Resolve .web.js first

Similarly you can configure the supported file extensions quite easily.

const extensions = [
  ".web.js",
  ".web.ts",
  ".web.tsx",
  ".web.mjs",
  ".web.cjs",
  ".js",
  ".jsx",
  ".json",
  ".ts",
  ".tsx",
  ".mjs",
  ".cjs",
]

return {
  resolve: {
     extensions,
  }

  optimizeDeps: {
    esbuildOptions: {
      resolveExtensions: extensions,
    }
  }
}

3. Apply global variables

Next up is a list of frankly strange environment variables that I found to be necessary for various things. You could probably skip some of these and just apply them as you run into those edge cases.

The most important one is having __DEV__ since its widely used to determine if we're in dev mode.

const development = env.mode === "development";

return {
  define: {
    // yeah weird I know
    global: "window",
    DEV: JSON.stringify(development),
    // don't even remember anymore
    "global.__x": {},
    // reanimated stuff
    _frameTimestamp: undefined,
    // reanimated stuff
    _WORKLET: false,
    // expected by most react native code
    __DEV__: JSON.stringify(development),
    "process.env.NODE_ENV": JSON.stringify(
      process.env.NODE_ENV || env.mode
    ),
    // expected by some expo libraries
    EXPO_OS: JSON.stringify("web"),
    "process.env.EXPO_OS": JSON.stringify("web"),
    // something in reanimated seemed to need this
    "global.Error": "Error",
  },
}

4. Babel transforms

I won't go into the plugin version of this because it would be a bit too much to cover. However I'll give you the version that I had working before forking the React plugin.

To get your node_modules to transpile you can add vite-plugin-babel and have it include specifically the node_modules you need.

import react from "@vitejs/plugin-react";
import babel from "vite-plugin-babel";

plugins: [
  // handles user code
  react({
    jsxRuntime: 'automatic',
    babel: {
      babelrc: false,
      configFile: false,
    },
  }),
  // handles node modules code
  babel({
    include:[
      //include the modules you want to transpile here
      /node_modules\/(react-native|@react-native|expo|@expo)/,
    ],
    babelConfig: {
      babelrc: false,
      configFile: false,
      presets: [
        [
          '@babel/preset-react',
          {
            development: isDevelopment,
            runtime: 'automatic',
          },
        ],
      ],
      plugins: [
        [
          // this is a fix for reanimated not working in production
          '@babel/plugin-transform-modules-commonjs',
          {
            strict: false,
            strictMode: false, // prevent "use strict" injections
            allowTopLevelThis: true, // don't rewrite global `this` -> `undefined`
          },
        ],
      ],
    },
  }),
]

5. strip flow syntax

This one was a bit weird, I had assumed I could just apply a babel parser or plugin and just ignore flow, however it turned out to be a bit more difficult. The thing that worked best for me was to use this plugin: @bunchtogether/vite-plugin-flow.

import { esbuildFlowPlugin } from "@bunchtogether/vite-plugin-flow";
// ...
optimizeDeps: {
  esbuildOptions: {
    loader: {
      ".js": "jsx",
    },
    plugins: [
      esbuildFlowPlugin(
        new RegExp(/\.(flow|jsx?)$/),
        (_path: string) => "jsx"
      ),
    ],
  },
},

Then include this Vite plugin

import { flowPlugin } from "@bunchtogether/vite-plugin-flow";
// ...
plugins: [
  flowPlugin({
     // to include more packages add them here like 
     // `/\/node_modules\/(?!react-native|@react-native|other_package)/`
     exclude:/\/node_modules\/(?!react-native|@react-native)/,
  }),
]

6. Treat .js as .jsx

Honestly I expected this would be enough, but I've found that its often not.

return {
  optimizeDeps: {
    esbuildOptions: {
      loader: {
        ".js": "jsx",
      },
      plugins: [
        esbuildFlowPlugin(
          new RegExp(/\.(flow|jsx?)$/),
          (_path: string) => "jsx"
        ),
      ],
    },
  },
}

You can add a custom Vite plugin like this that will handle it if you run into issues with the approach above.

plugins: [
    {
      name: "treat-js-files-as-jsx",
      async transform(code, id) {
        if (!id.match(/\.js$/)) return null;
        return vite.transformWithEsbuild(code, id, {
          loader: "jsx",
          jsx: "automatic",
        });
      },
    },
]

7. Handle mixed commonjs and ESM code

This one is another case where its a bit awkward to solve because usually you can only have CJS or ESM in a file, but as we know thats not the case with most React Native projects.

What I've found is that this plugin works really well to solve this for most cases vite-plugin-commonjs

import commonjs from "vite-plugin-commonjs";
plugins: [
 commonjs()
]

A working config file

So yeah thats a lot and I hope to keep finding simpler ways to do this. However you don't need to do that (unless you want to) since I've published the plugin for the purpose of simplifying the configuration

// vite.config.js
import { defineConfig } from "vite";
import { rnw } from "vite-plugin-rnw";

export default defineConfig({
  plugins: [rnw()],
});

Or alternatively to find a version of the config discussed here all put together check out this repository:

https://github.com/dannyhw/rn-web-vite-example/blob/main/vite.config.ts

Wrapping up

If you want to help improve the plugin please checkout the repository here:

https://github.com/dannyhw/vite-plugin-rnw

Hopefully this helps someone out there, let me know if you try it out or have any suggestions.

You can contact me at https://x.com/Danny_H_W if you have questions.
Heres my Github if you want to follow my work: https://github.com/dannyhw.

Thanks to Shilman and others on the storybook core team for the pairing sessions as always and thanks to @anishamalde for reviewing this post.

What is a reproduction

Danny — Sat, 14 Dec 2024 12:37:51 +0000

I made this post to serve as a quick explainer that I or other maintainers can send to newcomers to give them a quick overview of what a reproduction is and why its important.

TLDR: A reproduction is a minimal recreation of the problem in a public repository that does not require including any private code.

In the world of GitHub and open source, a reproduction refers to a minimal, self-contained example that demonstrates a specific issue or bug in software. Think of it as a focused test case that clearly illustrates the problem you’re experiencing without including unnecessary or unrelated code.

Providing a reproduction typically involves creating a small project or code snippet that isolates the issue, making it easy for maintainers or collaborators to understand and investigate. This could be as simple as a single file, a GitHub repository, or even a code sandbox that replicates the issue.

Why Is Providing a Reproduction Important?

1. Facilitates Problem Solving

Maintainers often have limited time to address issues, especially in popular open-source projects. A well-prepared reproduction eliminates guesswork, allowing them to focus directly on diagnosing and fixing the problem.

2. Avoids Miscommunication

Detailed descriptions of an issue are helpful, but written explanations can be subjective or ambiguous. A reproduction removes this ambiguity by showing exactly what the problem looks like in a controlled environment.

3. Speeds Up the Debugging Process

Without a reproduction, maintainers may need to ask follow-up questions, dig through your description, or try to simulate your environment—steps that can significantly delay resolution. A reproduction cuts through this noise.

4. Improves Collaboration

By providing a reproduction, you’re contributing directly to the problem-solving process. It shows respect for the time and effort of maintainers and fosters a collaborative spirit in the open-source community.

How to Create a Reproduction Without Sharing Private Code

A common concern is that sharing a reproduction might expose sensitive or proprietary information. Fortunately, creating a reproduction doesn’t require sharing any private code. Here’s how you can do it safely:

1. Isolate the Problem

Extract only the relevant parts of your code that trigger the issue. For example, if you’re dealing with a React bug, isolate the specific components or logic involved.

2. Use Mock Data

Replace sensitive data with mock or placeholder data. For instance, instead of real API keys or database entries, use dummy values like FAKE_API_KEY or test@example.com.

3. Create a Minimal Example

Strip away anything unnecessary. The goal is to create the simplest possible setup that still reproduces the issue. This reduces complexity and helps maintainers quickly pinpoint the problem.

4. Leverage Public Tools

Tools like CodeSandbox, Replit, or even a minimal GitHub repository can host your reproduction without exposing your private environment. Ideally a public Github repository should be included.

5. Document Your Steps

Clearly describe how to set up and run the reproduction. Include instructions for installing dependencies, running scripts, and observing the issue. This ensures that anyone reviewing the reproduction can easily follow along.

Example of a Minimal Reproduction

Let’s say you’re reporting a bug in a React library where a certain prop causes a crash. Instead of linking your entire app repository, you might create a small project using a simple template and add just the code that reproduces your bug:

import React from 'react';
import { LibraryComponent } from 'example-library';


export default function App() {
  return <LibraryComponent buggyProp="trigger" />;
}

Accompany this with instructions like:

Clone the repository.
Run npm install to install dependencies.
Run npm start and observe the error in the console.

The Bottom Line

Providing a reproduction is an essential part of contributing to open-source projects. It demonstrates respect for the maintainers’ time, improves the likelihood of a speedy resolution, and fosters collaboration. By isolating the issue and avoiding private code, you can provide an effective reproduction while keeping sensitive information safe.

Next time you encounter a bug, consider how you can create a minimal reproduction—it’s a small effort that makes a big difference in the open-source community!

Manual setup for a minimal Storybook

Danny — Mon, 13 May 2024 12:45:17 +0000

If you're having issues with the cli or you just want to know what you're installing then this is for you. I've put together what I consider the minimal setup. From there you can browse addons and docs to see how to enhance your setup.

Heres a video of me following the same steps:

I'll use bun here but replace with any package manager.

Also this example uses react with vite. If you're using a different framework you can swap @storybook/react and @storybook/react-vite for the alternative.

Packages

Heres the minimal packages you'll need to get started with a react storybook.



bun add @storybook/react @storybook/react-vite @storybook/addon-essentials storybook

Scripts

Add to your scripts in package.json



"storybook": "storybook dev -p 6006",
"build-storybook": "storybook build"

Configuration files

Add a .storybook folder with a main.ts and preview.ts.

main.ts

Find the docs here



// .storybook/main.ts
import type { StorybookConfig } from "@storybook/react-vite";

const config: StorybookConfig = {
  stories: ["../src/**/*.mdx", "../src/**/*.stories.@(js|jsx|mjs|ts|tsx)"],
  addons: ["@storybook/addon-essentials"],
  framework: {
    name: "@storybook/react-vite",
    options: {},
  },
  docs: {
    autodocs: "tag",
  },
};
export default config;

preview.ts

Start here to learn about the preview



// .storybook/preview.ts
import type { Preview } from "@storybook/react";

const preview: Preview = {
  parameters: {
    controls: {
      matchers: {
        color: /(background|color)$/i,
        date: /Date$/i,
      },
    },
  },
};

export default preview;

Example story

Lets add a component file



// src/Button.tsx
export const Button = ({ text }: { text: string }) => {
  return <button>{text}</button>;
};

Then we create a stories file and import it there.

Look here to learn about writing stories



// src/Button.stories.tsx
import { Button } from "./Button";

export default {
  component: Button,
};

export const Primary = {
  args: {
    text: "Primary Button",
  },
};

Run it!

Now run this to see your storybook in action.



bun run storybook

The final product should look like this:

All done!

Thats the basics, now I recommend you explore the docs to learn more about how to customize storybook for your needs. Especially look into interactions they are really nice.

Find me here:
twitter: @Danny_H_W
github: dannyhw

Apple privacy manifest for React Native

Danny — Mon, 22 Apr 2024 13:37:45 +0000

If you've been shipping to the app store in the past month you will probably have seen this warning from apple

This looks scary and confusing but its actually a lot simpler than it looks.

What those docs mean

If you follow one of the links in the email it will take you to a wall of text about the required reason API.

All this means is that now for apis that could be used to identify a user you must provide a reason for its use.

In the documentation here you will find the different apis that match this description.

For example for file access these are the apis that would need a reason



creationDate
modificationDate
fileModificationDate
contentModificationDateKey
creationDateKey
getattrlist(_:_:_:_:_:)
getattrlistbulk(_:_:_:_:_:)
fgetattrlist(_:_:_:_:_:)
stat
fstat(_:_:)
fstatat(_:_:_:_:)
lstat(_:_:)
getattrlistat(_:_:_:_:_:_:)

Heres where you can see that in the docs

What to do

For most people though you probably aren't using any of these directly and you just need to add reasons for the apis that React Native uses internally.

A member of the community already found out the reasons required and shared them here

// Detect dark theme var iframe = document.getElementById('tweet-1780335853794951423-793'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1780335853794951423&theme=dark" }

If you're using expo you can update to 50.0.17 and add this to your app.json (or equivalent app.config.js etc)



"ios": {
  "privacyManifests": {
    "NSPrivacyAccessedAPITypes": [
      {
        "NSPrivacyAccessedAPIType": "NSPrivacyAccessedAPICategoryFileTimestamp",
        "NSPrivacyAccessedAPITypeReasons": [
          "C617.1"
        ]
      },
      {
        "NSPrivacyAccessedAPIType": "NSPrivacyAccessedAPICategorySystemBootTime",
        "NSPrivacyAccessedAPITypeReasons": [
          "35F9.1"
        ]
      },
      {
        "NSPrivacyAccessedAPIType": "NSPrivacyAccessedAPICategoryDiskSpace",
        "NSPrivacyAccessedAPITypeReasons": [
          "E174.1"
        ]
      },
      {
        "NSPrivacyAccessedAPIType": "NSPrivacyAccessedAPICategoryUserDefaults",
        "NSPrivacyAccessedAPITypeReasons": [
          "CA92.1"
        ]
      }
    ]
  }
}

Check the gist in the tweet above for the full example.

There is also a guide from expo on how to do this in case you're still stuck https://docs.expo.dev/guides/apple-privacy/

Expo pre v50

For earlier versions of expo check out this comment from @getKonstantin:

Comment for #27796

kliakhovskii-brex commented on Apr 16, 2024

UPDATE: We just updated the implementation to this version of code as the prev implementation was placing privacy config into source build phase instead of bundle resources.

RE: Pre-Expo 50

For ppl who aren't on Expo 50 yet. We've taken the new plugin from official Expo, stripped types to simplify to easily runnable one JS file. And we also added a safeguard to fail in case if you're upgrading to Expo 50 (we usually use defensive checks to just rid of things once we know official support is there).

And got it working for Expo 48 version that we're running ⬇️

Copy the file to your project
Add it to config.plugins (as it's a custom plugin you need to apply)
Define config.ios.privacyManifest in your config as per new Expo docs.

Run npx expo prebuild --clean (and --no-install for ppl like me who don't like to wait for CocoaPods to be installed), it should generate the PrivacyInfo.xcprivacy to your project.

Plugin:

const plist = require("@expo/plist").default;
const fs = require("fs");
const path = require("path");

const {
  addResourceFileToGroup,
  getProjectName,
} = require("@expo/config-plugins/build/ios/utils/Xcodeproj");
const { withXcodeProject } = require("@expo/config-plugins");

function withPrivacyInfoInternal(config) {
  const privacyManifests = config.ios?.privacyManifests;
  if (!privacyManifests) {
    return config;
  }

  return withXcodeProject(config, (projectConfig) => {
    return setPrivacyInfo(projectConfig, privacyManifests);
  });
}

function setPrivacyInfo(projectConfig, privacyManifests) {
  const { projectRoot, platformProjectRoot } = projectConfig.modRequest;

  const projectName = getProjectName(projectRoot);

  const privacyFilePath = path.join(
    platformProjectRoot,
    projectName,
    "PrivacyInfo.xcprivacy",
  );

  const existingFileContent = getFileContents(privacyFilePath);

  const parsedContent = existingFileContent
    ? plist.parse(existingFileContent)
    : {};
  const mergedContent = mergePrivacyInfo(parsedContent, privacyManifests);
  const contents = plist.build(mergedContent);

  ensureFileExists(privacyFilePath, contents);

  if (!projectConfig.modResults.hasFile(privacyFilePath)) {
    projectConfig.modResults = addResourceFileToGroup({
      filepath: privacyFilePath,
      groupName: projectName,
      project: projectConfig.modResults,
      isBuildFile: true,
      verbose: true,
    });
  }

  return projectConfig;
}

function getFileContents(filePath) {
  if (!fs.existsSync(filePath)) {
    return null;
  }
  return fs.readFileSync(filePath, { encoding: "utf8" });
}

function ensureFileExists(filePath, contents) {
  if (!fs.existsSync(path.dirname(filePath))) {
    fs.mkdirSync(path.dirname(filePath), { recursive: true });
  }
  fs.writeFileSync(filePath, contents);
}

function mergePrivacyInfo(existing, privacyManifests) {
  let {
    NSPrivacyAccessedAPITypes = [],
    NSPrivacyCollectedDataTypes = [],
    NSPrivacyTracking = false,
    NSPrivacyTrackingDomains = [],
  } = structuredClone(existing);
  // tracking is a boolean, so we can just overwrite it
  NSPrivacyTracking =
    privacyManifests.NSPrivacyTracking ?? existing.NSPrivacyTracking ?? false;
  // merge the api types – for each type ensure the key is in the array, and if it is add the reason if it's not there
  privacyManifests.NSPrivacyAccessedAPITypes?.forEach((newType) => {
    const existingType = NSPrivacyAccessedAPITypes.find(
      (t) => t.NSPrivacyAccessedAPIType === newType.NSPrivacyAccessedAPIType,
    );
    if (!existingType) {
      NSPrivacyAccessedAPITypes.push(newType);
    } else {
      existingType.NSPrivacyAccessedAPITypeReasons = [
        ...new Set(
          existingType?.NSPrivacyAccessedAPITypeReasons?.concat(
            ...newType.NSPrivacyAccessedAPITypeReasons,
          ),
        ),
      ];
    }
  });
  // merge the collected data types – for each type ensure the key is in the array, and if it is add the purposes if it's not there
  privacyManifests.NSPrivacyCollectedDataTypes?.forEach((newType) => {
    const existingType = NSPrivacyCollectedDataTypes.find(
      (t) =>
        t.NSPrivacyCollectedDataType === newType.NSPrivacyCollectedDataType,
    );
    if (!existingType) {
      NSPrivacyCollectedDataTypes.push(newType);
    } else {
      existingType.NSPrivacyCollectedDataTypePurposes = [
        ...new Set(
          existingType?.NSPrivacyCollectedDataTypePurposes?.concat(
            ...newType.NSPrivacyCollectedDataTypePurposes,
          ),
        ),
      ];
    }
  });
  // merge the tracking domains
  NSPrivacyTrackingDomains = [
    ...new Set(
      NSPrivacyTrackingDomains.concat(
        privacyManifests.NSPrivacyTrackingDomains ?? [],
      ),
    ),
  ];

  return {
    NSPrivacyAccessedAPITypes,
    NSPrivacyCollectedDataTypes,
    NSPrivacyTracking,
    NSPrivacyTrackingDomains,
  };
}

/**
 * This was added at a time before Expo supported privacy manifests in versions below Expo 50.
 *
 * Copied from https://github.com/expo/expo/blob/97ca37377d70507d2ce30545f0a35ac73d172dcc/packages/%40expo/config-plugins/src/ios/PrivacyInfo.ts
 */
function withPrivacyInfo(config) {
  if (config.sdkVersion.startsWith("50")) {
    throw new Error(
      `withPrivacyInfo plugin is unneeded for Expo SDK 50+, official support was added: https://github.com/expo/expo/pull/28005`,
    );
  }

  return withPrivacyInfoInternal(config);
}

module.exports = withPrivacyInfo;

View on GitHub

RN CLI

If you're not using expo then you can follow the steps to create a privacy manifest in XCode.

Open your ios project in Xcode
Choose File > New File.
Scroll down to the Resource section, and select App Privacy File type.
Click Next.
Check your app target in the Targets list.
Click Create.
under NSPrivacyAccessedAPITypes add the apis and reasons from above

Your PrivacyInfo.xcprivacy file should get something like this



<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>NSPrivacyCollectedDataTypes</key>
  <array>
  </array>
  <key>NSPrivacyAccessedAPITypes</key>
  <array>
    <dict>
      <key>NSPrivacyAccessedAPIType</key>
      <string>NSPrivacyAccessedAPICategoryFileTimestamp</string>
      <key>NSPrivacyAccessedAPITypeReasons</key>
      <array>
        <string>C617.1</string>
      </array>
    </dict>
    <dict>
      <key>NSPrivacyAccessedAPIType</key>
      <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
      <key>NSPrivacyAccessedAPITypeReasons</key>
      <array>
        <string>CA92.1</string>
      </array>
    </dict>
    <dict>
      <key>NSPrivacyAccessedAPIType</key>
      <string>NSPrivacyAccessedAPICategorySystemBootTime</string>
      <key>NSPrivacyAccessedAPITypeReasons</key>
      <array>
        <string>35F9.1</string>
      </array>
    </dict>
  <dict>
      <key>NSPrivacyAccessedAPIType</key>
      <string>NSPrivacyAccessedAPICategoryDiskSpace</string>
      <key>NSPrivacyAccessedAPITypeReasons</key>
      <array>
        <string>E174.1</string>
      </array>
    </dict>
  </array>
  <key>NSPrivacyTracking</key>
  <false/>
</dict>
</plist>

This is a modified version of the file from the react native cli template

What do those values mean?

These values come from the apple documentation, heres what they mean

File access time

API Name: NSPrivacyAccessedAPICategoryFileTimestamp

C617.1: Declare this reason to access the timestamps, size, or other metadata of files inside the app container, app group container, or the app’s CloudKit container.

System boot time

API Name: NSPrivacyAccessedAPICategorySystemBootTime

35F9.1: Declare this reason to access the system boot time in order to measure the amount of time that has elapsed between events that occurred within the app or to perform calculations to enable timers.

Disk space

API Name: NSPrivacyAccessedAPICategoryDiskSpace

E174.1: Declare this reason to check whether there is sufficient disk space to write files, or to check whether the disk space is low so that the app can delete files when the disk space is low. The app must behave differently based on disk space in a way that is observable to users.

User defaults

API Name: NSPrivacyAccessedAPICategoryUserDefaults

CA92.1: Declare this reason to access user defaults to read and write information that is only accessible to the app itself.

Summary

Hopefully you should now be able to get your application warning free, but do make sure you check these values for yourself since you may be using other apis.

Let me know if this works for you or if I got anything wrong here.

twitter: @Danny_H_W
github: dannyhw

React Native Storybook 7

Danny — Mon, 05 Feb 2024 16:53:00 +0000

Storybook is an industry-leading, open source workshop for developing, documenting, and testing frontend applications in isolation. It helps you develop hard-to-reach states and edge cases without needing to run the whole app.

Today, we’re thrilled to announce our latest major release for React Native users: React Native Storybook 7! This aligns RN Storybook to core Storybook 7.6, enhances code re-use between @storybook/react and @storybook/react-native, and builds the foundations for more frequent and streamlined future releases.

📖 Storybook 7 compatibility
🧩 Improved support for Component Story Format 3
🔒 TypeScript-first
💨 Automatic story loading
🛡️ Improved error handling
📝 Enhanced markdown support
🎛️ Auto-generation for controls

Storybook 7 compatibility

Storybook 7 overhauled its core data structures to optimize bundling, which enabled code splitting and lazy compilation. It also made the code easier to reuse outside of a web context.

While RN Storybook 6.5 shared much of the same code with the core, RN Storybook 7 is based on the core entirely. This means that RN storybook will inherit core improvements as they become available, and makes it easier for RN Storybook to keep up with core in the future. Spoiler alert: Storybook 8 is coming very soon. Watch this space!

Improved support for Component Story Format 3

RN Storybook 7 stories now look exactly the same as Storybook core. Story types now derive directly from @storybook/react.

import type { Meta, StoryObj } from "@storybook/react"
import Button from "./Button"

const meta = {
  component: Button,
}

satisfies Meta<typeof Button>

export default meta;

type Story = StoryObj<typeof meta>;

export Basic: Story = {}

At the same time, you can use the same StoryObj and Meta types as core Storybook. This follows improved support for CSF3 and provides stronger type safety and autocompletion. Learn more.

TypeScript-first configuration

TypeScript has become the language of choice across Storybook users and the JS ecosystem. RN Storybook 7 follows suit by updating all config files and templates to be TypeScript-first.

RN Storybook 7’s main.ts:

// .storybook/main.ts
import { StorybookConfig } from '@storybook/react-native';

const main: StorybookConfig = {
  stories: [
    '../components/**/*.stories.?(ts|tsx|js|jsx)',
  ],

  addons: [
    '@storybook/addon-ondevice-notes',
    '@storybook/addon-ondevice-controls',
    '@storybook/addon-ondevice-backgrounds',
    '@storybook/addon-ondevice-actions',
  ],
};

export default main;

Automatic story loading

RN Storybook 7 capitalizes on Metro’s new support for require.context to automate story loading and dramatically reduce the steps needed to create stories.

In RN Storybook 6, you had to run storybook-generate each time you added a story. Now, with require.context, you only need to run generation when you update the stories field of main.ts. This is because require.context imports files dynamically based on a file glob (regex for file paths).

This feature was added in React Native 0.72. Use it by enabling transformer.unstable_useRequireContext in Metro:

// metro.config.js

const config = {
  transformer: {
    unstable_allowRequireContext: true,
  },
}

Significantly improved error handling

RN Storybook 7 fixes the issue of Storybook crashing upon story errors. Now, we wrap each story in an error boundary, which catches those errors instead. Note that you may still have to dismiss the RN Error LogBox.

Enhanced markdown support

In the past, the Notes addon broke text in the wrong places, and didn’t behave as you’d expect. RN Storybook 7 replaces the markdown renderer with a more battle-tested alternative, react-native-markdown-display, which works significantly better!

Auto-generation for controls

RN Storybook 7 now automatically generates controls from types using docgen analysis!

Configure auto-generated controls by adding babel-plugin-react-docgen-typescript to your Babel config:

Get started

Get started with RN Storybook 7 in an existing project with:

npx storybook@latest init

If you’re creating a fresh project, use the Storybook template:

# Expo
npx create-expo-app --template expo-template-storybook AwesomeStorybook

# React Native CLI
npx react-native init MyApp --template react-native-template-storybook

How to upgrade

There are some breaking changes in this release. Since there’s a lot to go through, please check out the full migration guide.

What’s next?

Work on RN Storybook 8 is already underway. The basics are functional, but we have plans for many more improvements in the months ahead. Here’s what you can look forward to:

Redesigned UI
Improved support for testing
More control types to better match the web experience
…and much more!

Bringing it all together

This release aligns RN Storybook with core Storybook and paves the way for many further improvements in our next major release.

There’s still a massive amount of potential with RN Storybook project and we’d love new contributors to help us get there. Find the project here and share your feedback, interest, or support.

You can find me on Twitter or GitHub. If you’d like to support my work, consider sponsoring me via GitHub sponsors.

// Detect dark theme var iframe = document.getElementById('tweet-1753388817925705862-718'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1753388817925705862&theme=dark" }

Getting started with React Native Storybook 6

Danny — Fri, 11 Aug 2023 10:41:36 +0000

This guide is a written version of a video I recently made and will show you how to get started with react native storybook on an existing project. This assumes that you already have a react native project to start with. For my purposes I'm starting with the expo typescript template but you can use react native cli if you prefer.

Heres the video if you want to watch me do it and talk through the process

The first thing you'll want to do is open the terminal in your project folder and run



npx sb@latest init --type react_native

This will create all the files and install all the packages you need to get started.

As you can see from the message here the setup isn't fully automated and the next step is to get storybook to render by replacing your entry point with the Storybook component.

Lets now take a look at what got added to our project

There were some new packages installed, two new scripts and a .storybook folder which contains all the storybook config. The .storybook/index.js file exports the Storybook component which we need to render to get storybook working.

Now in your editor open up App.tsx (or js/jsx) or wherever your app entrypoint and import and export the component .storybook/index.js like you would normally export the App component. For now you can comment out your existing default export but later you can setup a way to swap between storybook and your app.



import StorybookUI from "./.storybook";

export default StorybookUI;

Next we'll make one quick change to our metro config.

If you're on expo you'll need to generate that file with



npx expo customize metro.config.js

Then in that file add sb modern to the start of the resolver.resolverMainFields array. In expos generated file you can do it like this.



// Learn more https://docs.expo.io/guides/customizing-metro
const { getDefaultConfig } = require("expo/metro-config");

/** @type {import('expo/metro-config').MetroConfig} */
const config = getDefaultConfig(__dirname);

config.resolver.resolverMainFields.unshift("sbmodern");

module.exports = config;

note: you'll be happy to know sbmodern won't be needed in v7 of storybook

Now you can run yarn ios or yarn android and when the app opens up you should see the storybook UI.

Why aren't my new stories showing up?

When you add new stories you might notice that they don't immediately show up, thats because currently you need to run yarn storybook-generate each time you add a new story.

I like to add it to the start command like this so that I never forget

"start": "yarn storybook-generate && expo start",

This is needed because until recently react native didn't support dynamic imports and we generate a list of story imports based on your main.js config. You can see this in the storybook.requires.js file. This is something that we'll be changing in the future but for now make sure that you run storybook-generate whenever your new stories aren't showing up.

Thats it folks

Thanks for reading this post, if you're wondering where to go from here I recommend taking a look at some of my other posts or following the tutorial I wrote for react native storybook.

You can find me on twitter here @Danny_H_W
You can find my work on github here dannyhw

My DM's are open on twitter in case you want to get in touch.

Dynamic imports supported in react native

Danny — Wed, 26 Jul 2023 13:04:54 +0000

With the release of react native 0.72 and the latest metro changes we now have access to require.context which powers expo router and has potential to power other developer tooling or libraries.

This got me really excited because I can finally solve one of the biggest problems with react native storybook which is that you needed to generate imports for your stories. I wanted to talk a bit about what this new feature is and why I think its really cool.

Shout out to @Baconbrix for contributing this feature to metro!

What is require.context?

From the webpack documentation:

It allows you to pass in a directory to search, a flag indicating whether subdirectories should be searched too, and a regular expression to match files against.

Historically for react native we've never been able to do dynamic imports, neither based on a variable or a regex. However this kind of functionality has been in webpack and other web bundlers for some time. Now that we have access to require.context we can build tools like storybook and expo router without needing to generate imports at build time, we can instead dynamically import them at runtime.

Heres some examples:

require.context(
  directory,
  (useSubdirectories = true),
  (regExp = /^\.\/.*$/),
  (mode = 'sync')
);

require.context('../', true, /\.stories\.js$/);

The result of require context is a object like interface (RequireContext) that has two main functions.

keys: returns an array of keys (ids) which will correspond to a file path
An accessor (id) => module which given one of the keys returns the module

note: the metro implementation of require context doesn't include the resolve and id functionalities that webpack does.

For example

const req = require.context("components", true, /\.stories\.tsx$/);

req.keys().forEach((filename: string) => {
   const module = req(filename)

   // you could then access the exported fields
   // if I had a default export like
   // export default { title: "hello" }
   console.log(module.default.title)
})

For details on the implementation you can see Evan's PR to metro here.

Why?

The main driver for this feature seems to have been Expo router. The router is a file based routing library for react native and it will define your routes implicitly based on the file directory structure and the files you have. If you didn't have dynamic imports then to implement this you would have to generate a file of static exports/config that the router would read. Thats also the exactly what we've been doing in react native storybook 6.5 before require context was introduced.

Now that we have require context, the router uses a require.context call with a clever regex and the routes can all be figured out at runtime. This also comes with the benefit that fast refresh and other metro features will work since its built in.

This is really exciting for me because now I can remove lots of code and improve the developer experience of react native storybook.

I also imagine that this opens the door to other developer tools that can take advantage of dynamic imports in other ways.

Mini Storybook reimplementation

To further illustrate my point I'll show how easily you can now implement a simplified version of storybook in react native. Note that I simplified the code snippet slightly by removing imports etc (full repo linked at the end).

For context a story written using the CSF syntax looks like this:

import MyComponent from "./MyComponent" 

export default {
  title: "MyCoolComponent"
  component: MyComponent,
}

export const MyStory = {
  args: {
    text: "hello"
  }
}

We'll be dynamically importing any .stories.tsx file in our components folder and rendering the component with the props listed in its args.

Heres the code, make sure to look at the comments I added so you can follow whats going on.

// get all story files
const req = require.context("components", true, /\.stories\.tsx$/);

// we create a map with id: story-title and value: module
let storiesMap = new Map<StoryTitle, ModuleExports>();

// for every module found lets add it to the storiesMap
req.keys().forEach((filename: string) => {
  try {
    // fileExports contains all exports, including default and named 
    const fileExports = req(filename) as ModuleExports;

    // now we set an entry in the map like 'title' => module
    storiesMap.set(fileExports.default.title, fileExports);
  } catch (e) {}
});


let firstModule = "";

// get everything from our map as an array so we can access the first element
const entries = Array.from(storiesMap.entries());

if (entries.length) {
  const [title, exports] = entries[0];

  // each non 'default' export is a story
  const namedExports = Object.keys(exports).filter((key) => key !== "default");

  // we'll use title-storyname as an id 
  firstModule = `${title}-${namedExports[0]}`;
}


const Content = () => {
  // we track the current componentId with this
  const [currentComponent, setCurrentComponent] = useState<string>(firstModule);

  const { Component, props } = useMemo(() => {
    if (currentComponent) {
      // we split our title-storyname id to get the key we need to access the map
      const [title, exportName] = currentComponent.split("-");

      // this gives us all the exports
      const exports = storiesMap.get(title);

      // get this current export (the story)
      const story = exports?.[exportName];

      return {
        // in csf the default export has a component field
        Component: exports?.default?.component,

        // a story's args represent our props
        props: story?.args,
      };
    }

    return {
      Component: null,
      props: {},
    };

  }, [currentComponent]);

  // we use gorhoms bottom sheet to display a list of stories
  const storiesBottomSheetModalRef = useRef<BottomSheetModal>(null);

  return (
    <SafeAreaView style={{ flex: 1, padding: 16 }}>
      {/* Render the current story with props from the args */}
      {Component && <Component {...props} />}

      {/* A button to open our story list */}
      <Button
        text="Stories"
        onPress={() => storiesBottomSheetModalRef.current?.present()}
        icon={icons.stories}
        style={{ flex: 1 }}
      />

      {/* A bottom sheet holding the list of stories */}
      <BottomSheet stackBehavior="replace" ref={storiesBottomSheetModalRef}>
        <StoryList
          setStory={setCurrentComponent}
          stories={Array.from(storiesMap.entries())}
          selectedStory={currentComponent}
        />
      </BottomSheet>
    </SafeAreaView>
  );
};

If you're curious then heres a repo with the full code https://github.com/dannyhw/sb-ui-experiment

Also heres the pr where I'm adding support for require.context to React Native Storybook https://github.com/storybookjs/react-native/pull/501

So what do you think? What could you build now that dynamic imports are possible?

Thanks for reading!

Get in touch with me at: @Danny_H_W
Check out my work on github: https://github.com/dannyhw

React Native and React Native Web Storybook together

Danny — Tue, 04 Jul 2023 20:12:00 +0000

Storybook for react native allows you to develop your components in isolation on their native platforms, but its not the easiest to share with stakeholders or team members. Running your components on the web using react native web can be a nice way to make your components more shareable and you can integrate with lots of web tooling built around storybook for the web. It's possible to merge the setup for react native storybook together with the react native web storybook.

Its not been the easiest setup process for new users so I've made this quick guide for those with an existing project wanting to integrate @storybook/react-native and @storybook/addon-react-native-web in the same project.

If you are creating a fresh project it would be easier to start with one of the templates I've already created.

I'll be starting with a basic expo template generated with yarn create expo-app

Ondevice setup

Now to add @storybook/react-native I'll run the following command:
npx sb@latest init --type react_native

Then in my App.js file I'll make some changes to import the storybook ui from .storybook and export it as the the entry point of the app.

// App.js
import StorybookUI from "./.storybook";

export default StorybookUI;

Now I'm going to customize metro config to complete the setup

This command will generate the config file: npx expo customize metro.config.js

// metro.config.js
const { getDefaultConfig } = require("expo/metro-config");

const config = getDefaultConfig(__dirname);

config.resolver.resolverMainFields.unshift("sbmodern");

module.exports = config;

Add a folder called components and lets add a basic component called Button

// components/Button.js
import { Text, TouchableOpacity } from "react-native";

export const Button = ({ onPress, text }) => {
  return (
    <TouchableOpacity
      onPress={onPress}
      style={{
        borderColor: "lightgrey",
        borderWidth: 1,
        borderRadius: 2,
        paddingVertical: 8,
        paddingHorizontal: 32,
        alignSelf: "flex-start",
      }}
    >
      <Text>{text}</Text>
    </TouchableOpacity>
  );
};

// components/Button.stories.js
import { Button } from "./Button";

export default {
  title: "Button",
  component: Button,
  argTypes: {
    onPress: { action: "onPress" },
  },
};

export const Base = {
  args: { text: "Hello World" },
};

lets update the main.js config file to look for stories in this folder

// .storybook/main.js
module.exports = {
  stories: ["../components/**/*.stories.?(ts|tsx|js|jsx)"],
  addons: [
    "@storybook/addon-ondevice-controls",
    "@storybook/addon-ondevice-actions",
  ],
};

Lets also update the preview.js to add some padding to our stories

// .storybook/preview.js
import { View } from "react-native";

export const parameters = {};

export const decorators = [
  (Story) => (
    <View style={{ padding: 8 }}>
      <Story />
    </View>
  ),
];

Next I'll run storybook-generate to make sure the storybook.requires.js file has been generated.

yarn storybook-generate

This file is generated based on your config and handles importing all the necessary story files.

This concludes the on-device part of the setup. You should be able to run yarn ios or yarn android and see storybook render your button story.

Web setup

The best react-native-web Storybook experience will come from using @storybook/addon-react-native-web on top of a ReactJS storybook setup. This is a slightly more complex setup because it requires you to have two sets of storybook config and scripts. However those tradeoffs give you the ability to use all the features of web storybook and tooling that comes with it.

Since React Native Storybook is currently at compatibility with 6.5 we'll be using that version for both web and on-device.

First install the dependencies

yarn add -D @storybook/addon-react-native-web @storybook/addon-essentials@^6.5 @storybook/builder-webpack5@^6.5 @storybook/manager-webpack5@^6.5 @storybook/react@^6.5 babel-plugin-react-native-web react-native-web @babel/plugin-proposal-export-namespace-from

Now add the scripts to package.json

"storybook:web": "start-storybook -p 6006 -c .storybook-web",
"build-storybook": "build-storybook -c .storybook-web"

Create a new folder called .storybook-web and add the files main.js and preview.js

// ./storybook-web/main.js
module.exports = {
  stories: [
    "../components/**/*.stories.mdx",
    "../components/**/*.stories.@(js|jsx|ts|tsx)",
  ],
  addons: [
    "@storybook/addon-essentials",
    "@storybook/addon-react-native-web",
  ],
  core: {
    builder: "webpack5",
  },
  framework: "@storybook/react",
};

// ./storybook-web/preview.js
import { View } from "react-native";

export const parameters = {
  actions: { argTypesRegex: "^on[A-Z].*" },
  controls: {
    matchers: {
      color: /(background|color)$/i,
      date: /Date$/,
    },
  },
};

export const decorators = [
  /* by wrapping everything in a view the parent container is always using flexbox and behaves like a react-native-web component would  */
  (Story) => (
    <View>
      <Story />
    </View>
  ),
];

Now if you run yarn storybook:web you should see something like this.

Likely this won't be the end of the configuring and setup you'll need to do but this should get you most of the way.

Thanks for reading.

I'm on twitter at @Danny_H_W and github at dannyhw

How to use React Native Storybook Server with webpack 5

Danny — Sat, 18 Mar 2023 18:09:00 +0000

This is a quick guide for the prerelease version (6.5.0-rc.6) with a stable release coming out soon for React Native Storybook 6.5.

The React Native Storybook Server is an optional companion app for react native storybook that lets you control the storybook on your mobile device via a web interface.
Until recently webpack 5 was not supported in the react native storybook server. Recently that support was added by a contributor @leonardo-fc and is now available in the release candidate version of the server.

The Guide

First bootstrap an app with react native storybook

yarn create expo-app --template expo-template-storybook AwesomeStorybook

Go to the directory of the new app

cd AwesomeStorybook

Add the react native storybook server package and some webpack5 dependencies to your project

yarn add -D @storybook/react-native-server@next webpack @storybook/builder-webpack5 @storybook/manager-webpack5

Make sure you add all of these packages otherwise it won't work.

Add the following script to your package.json file

{
  "scripts": {
    "start-server": "react-native-storybook-server"
  }
}

Create a folder called .storybook_server and add a main.js file with the following content

module.exports = {
  stories: [
    "../components/**/*.stories.mdx",
    "../components/**/*.stories.@(js|jsx|ts|tsx)",
  ],
  env: () => ({}),
  core: {
    builder: "webpack5",
  },
  addons: ["@storybook/addon-essentials"],
};

By setting the builder to webpack5 we are telling the storybook server to use webpack 5 instead of the default webpack 4.

In this bootstrapped project the ondevice storybook is configured in the .ondevice folder.
In the index.tsx file we need to update some options so that websockets are enabled.

const StorybookUIRoot = getStorybookUI({
  enableWebsockets: true,
});

Now you can start the server with yarn start-server and open the storybook on your mobile device with yarn storybook.

Make sure you restart the app on your device so that the server can pick up the stories sent over the websockets (sent on app startup).

At this point you should be running the react native server with webpack 5.

Thanks for reading. If you have any questions or feedback please tweet or send me a message @Danny_H_W.

How to use React Native Web with Storybook v7 beta

Danny — Thu, 16 Feb 2023 14:45:57 +0000

You may have heard that Storybook is getting close to a v7 release. If you're using addon-react-native-web you might be wondering how to try out the beta. In this quick guide I will show you how to setup a new project and add @storybook/addon-react-native-web Storybook to the project.
This enables you to use the web Storybook with your react native components.

If you already have this setup in an existing project it should be pretty straight forward to get updated. Change the version of @storybook/addon-react-native-web to next and update all your other relevant storybook dependencies to the latest v7 beta version (you can use next here too). Then you should check this migration guide to see if you need to update anything to get your project ready for v7.

To setup a fresh new project you can follow this guide:

First I'll generate a project.

yarn create expo-app

Next I'll open up the project and in the root of the project run

npx sb@next init --type react

After its done add @storybook/addon-react-native-web@next and the dependencies for it.

yarn add --dev react-dom react-native-web babel-plugin-react-native-web @storybook/addon-react-native-web@next

Add the addon to .storybook/main.js as follows:

const config = {
  /* existing config */
  addons: [/*existing addons,*/ "@storybook/addon-react-native-web"],
  /* more config here */
};
export default config;

If you're familiar with the Storybook config you'll notice there are some slight differences in the main.js file. One cool new feature is that you can now get benefits of autocomplete even if you aren't using typescript for your config files. This change comes from the comment above the config object that looks like this

/** @type { import('@storybook/react-webpack5').StorybookConfig } */
const config = {

Now that the setup is done, let's add a React Native component and a story in the stories folder.

You may want to delete the ReactJS example components. To do that delete everything inside of the stories folder.

rm -rf stories/*

Then in that folder you can add this example button component.

Inside stories/ create Button.jsx

// stories/Button.jsx
import React from "react";
import { StyleSheet, Text, TouchableOpacity, View } from "react-native";

const styles = StyleSheet.create({
  button: {
    paddingVertical: 8,
    paddingHorizontal: 16,
    borderRadius: 4,
    alignSelf: "flex-start",
    flexGrow: 0,
    backgroundColor: "purple",
  },
  buttonText: {
    color: "white",
    fontSize: 16,
    fontWeight: "bold",
  },
  buttonContainer: {
    alignItems: "flex-start",
    flex: 1,
  },
});

export const Button = ({ text, onPress, color, textColor }) => (
  <View style={styles.buttonContainer}>
    <TouchableOpacity
      style={[styles.button, !!color && { backgroundColor: color }]}
      onPress={onPress}
      activeOpacity={0.8}
    >
      <Text style={[styles.buttonText, !!textColor && { color: textColor }]}>
        {text}
      </Text>
    </TouchableOpacity>
  </View>
);

Now add the files Button.stories.jsx in the stories folder with this content:

// stories/Button.stories.jsx
import { Button } from "./Button";

export default {
  component: Button,
};

export const Basic = {
  args: {
    text: "Hello World",
    color: "purple",
  }
}

One of the really cool updates in V7 is the introduction of CSF3 which you can see above. There is now much less boilerplate needed to write a story!

At this point all thats left to do is run yarn storybook and get to work building your components!

Thanks for reading.

Follow me on twitter @Danny_H_W

How to swap between React Native Storybook and your app

Danny — Mon, 06 Feb 2023 12:13:57 +0000

EDIT: This post is now outdated, please refer to https://dev.to/dannyhw/how-to-swap-between-react-native-storybook-10-and-your-app-e9e

Storybook in react native is a component that you can slot into your app and isn't its own separate runtime which you might be used to on the web.

If you want to run storybook in the same environment as your app we're going to need a simple way to switch between them.

To access an environment variable with expo we can follow their documentation here. If you aren't using expo I recommend following this guide instead.

Note: This guide assumes you have an expo application setup for storybook (see the github readme for info on how to get setup).

Using Expo constants

First rename app.json to app.config.js and edit the file so it looks something like this:

module.exports = {
  name: "my-app",
  slug: "my-app",
  version: "1.0.0",
  orientation: "portrait",
  ...
};

Now add the extra config option like this

module.exports = {
  name: 'MyApp',
  version: '1.0.0',
  extra: {
    storybookEnabled: process.env.STORYBOOK_ENABLED,
  },
  ...
};

Now we can access the storybookEnabled variable from our app using expo constants like this:

import Constants from 'expo-constants';
const apiUrl = Constants.expoConfig.extra.storybookEnabled;

Earlier I said to comment out the app function in the App.js file and this where we go back and fix that.

Edit App.js so that it looks like this:

import { StatusBar } from 'expo-status-bar';
import { StyleSheet, Text, View } from 'react-native';
import Constants from 'expo-constants';

function App() {
  return (
    <View style={styles.container}>
      <Text>Open up App.js to start working on your app!</Text>
      <StatusBar style="auto" />
    </View>
  );
}

let AppEntryPoint = App;

if (Constants.expoConfig.extra.storybookEnabled === 'true') {
  AppEntryPoint = require('./.storybook').default;
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    backgroundColor: '#fff',
    alignItems: 'center',
    justifyContent: 'center',
  },
});

export default AppEntryPoint;

Now in package.json we can add a script like this

"scripts": {
    "storybook": "STORYBOOK_ENABLED='true' expo start",
}

We've added a new command that will run our app with the STORYBOOK_ENABLED flag set to true.

When you run yarn start you should see the app code and yarn storybook should show you storybook.

Removing storybook from the bundle

If you want to remove storybook from your bundle when its disabled you can also add this code to your metro config.

metroConfig.resolver.resolveRequest = (context, moduleName, platform) => {
  const defaultResolveResult = context.resolveRequest(context, moduleName, platform);

  if (
    process.env.STORYBOOK_ENABLED !== 'true' &&
    defaultResolveResult?.filePath?.includes?.('.storybook/')
  ) {
    return {
      type: 'empty',
    };
  }

  return defaultResolveResult;
};

Using entryPoint (expo go <48 only)

This solution won't work in v48 of expo or with expo dev clients.

First we want to rename our app.json to app.config.js and edit the file so it looks something like this:

module.exports = {
  name: "my-app",
  slug: "my-app",
  version: "1.0.0",
  orientation: "portrait",
  ...
};

Add the entryPoint config option like this

module.exports = {
  name: 'MyApp',
  version: '1.0.0',
  entryPoint: process.env.STORYBOOK_ENABLED
      ? "index.storybook.js"
      : "node_modules/expo/AppEntry.js",
  ...
};

Add a file called index.storybook.js in the root of the project with the following content

import { registerRootComponent } from "expo";

import Storybook from "./.storybook";

// registerRootComponent calls AppRegistry.registerComponent('main', () => App);
// It also ensures that whether you load the app in Expo Go or in a native build,
// the environment is set up appropriately
registerRootComponent(Storybook);

Now in package.json we can add a script like this

"scripts": {
  "storybook": "STORYBOOK_ENABLED='true' expo start",
}

Which will run our app with the STORYBOOK_ENABLED flag set to true.

Now when you run yarn start you should see the app and yarn storybook should show you storybook.

You can pass the option --ios or --android to have the simulator autmatically open up otherwise press i or a after the command finishes running to open the simulator.

Summary

As you can see there are multiple potential approaches here and I've tried to offer some possible solutions. Each of these have some potential drawbacks but you should assess your projects needs to see what fits for you.

If you are using Expo Go on version 47 or below the entryPoint might be an interesting option for you but it will be removed in 48. The version using expo constants has the possibility increase your bundle size however will work in expo 48.

Heres some comments from Evan Bacon about the entryPoint field:

// Detect dark theme var iframe = document.getElementById('tweet-1624817071291858944-864'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1624817071291858944&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1624817852023701506-223'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1624817852023701506&theme=dark" }

Other possible approaches include using env variables in metro config to change the project root or using storybook as a separate app outside of your project. You could also manually alternate the main field of the package.json between two different entry point paths (similar to the entryPoint option).

As I find better solutions I will add to this post to showcase the best options.

Thanks for reading.

You can follow me on twitter here: https://twitter.com/Danny_H_W