Forem: Mirco Kraenz

Run Storybook with NX Expo and React Native Paper

Mirco Kraenz — Tue, 17 Dec 2024 21:06:38 +0000

tl;dr: Add vite-plugin-react-native-web to your storybook config in {projectRoot}/.storybook/main.ts and you should be good to go. Scroll to end for the full config.

After several days of finally getting this running, while stumbling onto this NX issue several times, I thought I might as well share my solution, and an approach of how to debug if things go haywire (which they did - a lot).

I am assuming you have a working NX workspace with an Expo project and React Native Paper installed.

Outline

Add Storybook
Make DOM elements in Storybook work
Make React Native elements in Storybook work
Make React Native Paper elements in Storybook work

Add Storybook

Tested under version

@nx/expo@20.1.4
yarn@1.22.19
node@22.11.0
ubuntu 22.04

Let's get started.

yarn nx add @nx/storybook
yarn nx g @nx/react:storybook-configuration PROJECT_NAME
# I answered all questions with the default selection

In my case, this installed

    "@nx/storybook": "20.1.4",
    "@nx/vite": "20.1.4",
    "@nx/web": "20.1.4",
    "@storybook/addon-essentials": "^8.2.8",
    "@storybook/addon-interactions": "^8.2.8",
    "@storybook/core-server": "^8.2.8",
    "@storybook/jest": "^0.2.3",
    "@storybook/react-vite": "^8.2.8",
    "@storybook/test-runner": "^0.13.0",
    "@storybook/testing-library": "^0.2.2",
    "@vitejs/plugin-react": "^4.2.0",
    "storybook": "^8.2.8",
    "vite": "^5.0.0"

Depending on your components it should generate at least one *.stories.tsx file, in my case App.stories.tsx.

If you start this and it renders perfectly for you. Congratz. You don't need to read further. If you're anything like me, then it doesn't render and here's how I debugged it.

Make DOM elements in Storybook work

I check that at least the most basic setup works by editing App.stories.tsx and replace the file contents with the most limited I can think of

import { expect } from "@storybook/jest";
import type { Meta, StoryObj } from "@storybook/react";
import { within } from "@storybook/testing-library";
import { App } from "./App";

const XComp = () => <div>Hi</div>;

const meta: Meta<typeof App> = {
  component: XComp,
  title: "App",
};
export default meta;
type Story = StoryObj<typeof App>;

export const Primary = {
  args: {},
};

Running yarn nx storybook PROJECT_NAME should open the browser and you should see the text 'Hi'.

Make React Native elements in Storybook work

Next up is including something from React Native.

So I change the component definition in App.stories.tsx to

import { Text } from "react-native";

const MyComponent = () => <Text>Hi</Text>;

This already starts to fail.
The webapp displays an error Failed to fetch dynamically imported module: http://localhost:35021/src/app/App.stories.tsx while the console shows

✘ [ERROR] Unexpected "typeof"

    ../../node_modules/react-native/index.js:14:7:
      14 │ import typeof ActionSheetIOS from './Libraries/ActionSheetIOS/ActionSheetIOS';
         ╵        ~~~~~~

9:15:52 PM [vite] error while updating dependencies:
Error: Build failed with 1 error:
../../node_modules/react-native/index.js:14:7: ERROR: Unexpected "typeof"

This is still 'easy' to fix. Because we're rendering for the web, we should use react-native-web instead of react-native. Obviously, I don't want to hardcode the import to react-native-web as that would not be beneficial for my component library for expo mobile dev. We can however leverage resolve.aliases to import from react-native-web whenever our code says import ... from 'react-native'. (I assume this is what happens under the hood in Expo depending on your target platform. Maybe you can teach me or link to some references in the comments. I'd appreciate it!).

Anyway, to resolve the correct import, we go into {projectRoot}/.storybook/main.ts and replace the config by

const config: StorybookConfig = {
  stories: ["../src/app/**/*.@(mdx|stories.@(js|jsx|ts|tsx))"],
  addons: ["@storybook/addon-essentials", "@storybook/addon-interactions"],
  framework: {
    name: "@storybook/react-vite",
    options: {},
  },

  viteFinal: async (config) =>
    mergeConfig(config, {
      plugins: [react(), nxViteTsPaths()],
      resolve: {
        alias: {
          "react-native": "react-native-web",
        },
      },
    }),
};

Testing again by rerunning yarn nx storybook PROJECT_NAME should now render the text 'Hi' again. Nice!

So now we have storybook, we can theoretically use regular DOM elements, but more importantly we can use React Native components. A good point to stage and commit our changes. Then it's up to the next level.

Make React Native Paper elements in Storybook work

In my case, I am building on top of React Native Paper, so the natural next step is to change MyComponent to include

import { PaperProvider, Text } from "react-native-paper";

const MyComponent = () => (
  <PaperProvider>
    <Text>Hi</Text>
  </PaperProvider>
);

This again will fail to render, and the console shows

✘ [ERROR] Expected "from" but found "{"

    ../../node_modules/react-native-vector-icons/lib/NativeRNVectorIcons.js:3:12:
      3 │ import type { TurboModule } from 'react-native/Libraries/TurboModule/RCTExport';
        │             ^
        ╵             from

✘ [ERROR] The JSX syntax extension is not currently enabled

    ../../node_modules/react-native-vector-icons/lib/icon-button.js:116:8:
      116 │         <TouchableHighlight
          ╵         ^

  The esbuild loader for this file is currently set to "js" but it must be set to "jsx" to be able
  to parse JSX syntax. You can use "loader: { '.js': 'jsx' }" to do that.

The problem is that these files are not plain javascript files but include Flow types, and also JSX files.

While the error tells us to customize our loader to treat every js file as jsx, that won't solve the problem with the Flow types in TurboModule. At this point we could probably dive deeper to strip the flow types. But what if we simply solve both problems at once, and the problem of resolving the right import from earlier, too?

Enter vite-plugin-react-native-web!

We install it by running

yarn add -D vite-plugin-react-native-web

and then we go back to {projectRoot}/.storybook/main.ts and replace the config by

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

import { nxViteTsPaths } from "@nx/vite/plugins/nx-tsconfig-paths.plugin";
import react from "@vitejs/plugin-react";
import { mergeConfig } from "vite";
import reactNativeWeb from "vite-plugin-react-native-web";

const config: StorybookConfig = {
  stories: ["../src/app/**/*.@(mdx|stories.@(js|jsx|ts|tsx))"],
  addons: ["@storybook/addon-essentials", "@storybook/addon-interactions"],
  framework: {
    name: "@storybook/react-vite",
    options: {},
  },

  viteFinal: async (config) =>
    mergeConfig(config, {
      plugins: [react(), nxViteTsPaths(), reactNativeWeb()],
    }),
};

export default config;

Notice that we also got rid of the resolve.alias part. This is because vite-plugin-react-native-web will take care of that for us.

Now we can rerun yarn nx storybook PROJECT_NAME and the text 'Hi' should render again. (If you don't get an error but a blank canvas inside storybook, then the theme is probably off. Try switching to dark/light theme in the storybook UI and the text should become visible.)

And that's it! We now have a working storybook setup with React Native Paper components.

Kudos go to the maintainers of vite-plugin-react-native-web for making this possible.

TypeScript's `as` keyword might not be what you think

Mirco Kraenz — Mon, 10 Oct 2022 11:22:00 +0000

I've done a lot of interviews on the interviewer-side a little while ago and one thing surprised me:
Many developers get the concept of as string in TypeScript wrong; thinking they are safe now that they use it - but really aren't. 😕
So what does as string or more generally as MyType actually do? And how do I fill the gap it leaves?

tl;dr

as keyword only changes compile-time behavior. You essentially tell the compiler to stop complaining. Runtime behavior stays unchanged. If you need runtime safety, use techniques like polymorphism, in type guards, typeof type guards, instanceof type guards, or user-defined type guards, or assertion functions.

tl;dr
Contents
What as string actually does
Buggy Example
Polymorphism
Type Guards
- in Type Guard
- instanceof Type Guard
- User-Defined Type Guard
- TypeScript trusts us in writing proper User-Defined Type Guards
What about <MyType>?
What about the new satisfies keyword?
Closing
Recommended Reading

What `as string` actually does

Or: Type Assertion vs Type Casting.

Many developers know Type Casting from languages like Java. You have a double and want to turn it into an int, so you do int myInt = (int) myDouble;. In Java this is fine and actually changes the behavior at runtime. But here's the thing: TypeScript doesn't!

Instead, TypeScript's as MyType only changes compile time behavior. It's like saying to the compiler "Compiler, believe me. This is a MyType. So stop complaining." Nothing has changed for the resulting JavaScript code after compiling. In other words, we're still completely vulnerable at runtime. That's why TypeScript actually uses the term Type Assertion intead of Type Casting.

Buggy Example

Let's look at an example where things go wrong. The code will result in a addLemon is not a function runtime error. You can try by hitting the "Run" button inside the

Interactive TypeScript Playground here.

interface Tea {
  addLemon(): void;
}
interface Coffee {
  addSugar(): void;
}

function addExtra(hotBeverage: Tea | Coffee) {
  // bug report incoming
  (hotBeverage as Tea).addLemon();
}

const actuallyCoffee: Coffee = {
  addSugar: () => {
    console.log("Added sugar");
  },
};
addExtra(actuallyCoffee);

Let's walk through this code. We define interfaces Tea and Coffee with different methods on them. Next, we incidentally grab ourselves a Coffee (what a grave mistake), and pass it to the addExtra function. This function however misuses as Tea, essentially assuming/asserting everything we pass to the function is always tea. The result is a runtime error saying TypeError: hotBeverage.addLemon is not a function. Making it into production might easily cost us a few thousand bucks to fix and a lot of customer frustration because they can't drink their morning coffee. At least your customers can still drink Tea. 😉

Admittedly, this example seems slightly artificial but there are enough examples in the real world where similar things happen.

Polymorphism

Depending on what you want from a business perspective, the solution might be using Type Guards. Another approach for the above is using polymorphism.

Wikipedia's intro sentence for Polymorphism is

In programming languages and type theory, polymorphism is the provision of a single interface to entities of different types [...]

That is, instead of having an addExtra function, we might change the code into the following.

Interactive TypeScript Playground here

interface Tea {
  add(extra: string): void;
}
interface Coffee {
  add(extra: string): void;
}

const actuallyCoffee: Coffee = {
  add: (extra: string) => {
    console.log(`added ${extra}`);
  },
};
actuallyCoffee.add("sugar");

This also allows adding different things into our tea and coffee. In case, we want to restrict what can be added into the coffee, we can use TypeScript's Literal Types.

interface Coffee {
  add(extra: "sugar"): void;
}
// ...
actuallyCoffee.add("sugar"); // still works
actuallyCoffee.add("lemon"); // compile error: '"lemon"' is not assignable to parameter of type '"sugar"'

Type Guards

Type Guards are similar to as in terms of changing the compile type but additionally add a runtime check! Note however that since oftentimes we're writing the type guard ourselves, there is still some risk of getting it wrong. So be careful and add unit tests when using more advanced type guards. Let's get started with the most common type guard. The following list is not exhaustive but each one I showcase fixes our problem-case above.

`in` Type Guard

Interactive TypeScript Playground here

interface Tea {
  addLemon(): void;
}
interface Coffee {
  addSugar(): void;
}

function addExtra(hotBeverage: Tea | Coffee) {
  if ("addLemon" in hotBeverage) {
    hotBeverage.addLemon(); // TS narrows down the type to Tea
  } else {
    hotBeverage.addSugar(); // TS narrows down the type to Coffee
  }
}

const actuallyCoffee: Coffee = {
  addSugar: () => {
    console.log("added sugar");
  },
};

addExtra(actuallyCoffee); // adds sugar without any errors

The in keyword in JavaScript and TypeScript checks whether a property exists on an object. In the above example, we use it to check whether the addLemon property exists on the hotBeverage object at compile time and at runtime. If it does, TypeScript know it's a Tea because the other option Coffee does not have an addLemon property. On the other hand, if the object does not have an addLemon property it must be Coffee. Unlike as, since in is a JavaScript keyword it acts at runtime, too.

`instanceof` Type Guard

This type guard is only usable if Tea or Coffee are classes. In the above case, they are only interfaces. Let's pretend for a moment that Tea is a class anyway. In this case, we can use the instanceof type guard.

Interactive TypeScript Playground here

class Tea {
  addLemon() {}
}

interface Coffee {
  addSugar(): void;
}

function addExtra(hotBeverage: Tea | Coffee) {
  // instanceof type guard
  if (hotBeverage instanceof Tea) {
    hotBeverage.addLemon(); // TS narrows down the type to Tea
  } else {
    hotBeverage.addSugar(); // TS narrows down the type to Coffee
  }
}

const actuallyCoffee: Coffee = {
  addSugar: () => {
    console.log("added sugar");
  },
};

addExtra(actuallyCoffee); // adds sugar without any errors

User-Defined Type Guard

User-Defined Type Guards allow us to go beyond what TypeScript can infer from instanceof and in type guards.

Interactive TS Playground here.

interface Tea {
  addLemon(): void;
}
interface Coffee {
  addSugar(): void;
}

// custom type guard
function isTea(x: Tea | Coffee): x is Tea {
  if ("addLemon" in x && typeof x.addLemon === "function") {
    return true;
  }
  return false;
}

function addExtra(hotBeverage: Tea | Coffee) {
  if (isTea(hotBeverage)) {
    hotBeverage.addLemon(); // TS narrows down the type to Tea
  } else {
    hotBeverage.addSugar(); // TS narrows down the type to Coffee
  }
}

const actuallyCoffee: Coffee = {
  addSugar: () => {
    console.log("added sugar");
  },
};

addExtra(actuallyCoffee); // adds sugar without any errors

The type guard isTea is a function that receives a single parameter, returns a boolean, and is marked with x is Tea. More generally, it's marked with myParameter is MyType. TypeScript will use it to narrow down the type in the if-statement of addExtra

TypeScript trusts us in writing proper User-Defined Type Guards

The fact that TypeScript trusts us in implementing a proper user-defined type guard can be shown easily.
Take a look at the following, obviously wrong type guard. TypeScript believes in our abilities and won't budge - the executed JavaScript will.

Interactive TypeScript Playground here

function isTea(x: unknown): x is Tea {
  return true;
}

const grizzlyBear = {};
if (isTea(grizzlyBear)) {
  // gets executed
  grizzlyBear.addLemon(); // no compile error, but a runtime error
}

This simply says everything is Tea. Even though it would be a nice world to live in, that's not how it works in real life. 🙂

What about `<MyType>`?

You might have seen Type Assertions in the form const tea = <Tea>{color: 'green'} before. This is the same as as Tea. So again, it doesn't change any runtime behavior, leaving ourselves open for bad surprises.

The <MyType> syntax has been deprecated because it becomes confusing in the context of .jsx or .tsx files as you might encounter using React. Both use the same syntax. Thus, TypeScript recommends always using as MyType.

TypeScript recommends always using as MyType instead of <MyType>.

To clarify, take a look at this.

const beverage = <Tea>{ color: 'green' };
return <Tea>{beverage.color}</Tea>

Here we have a component named Tea but also a variable beverage with a type assertion of type Tea. If you are confused now, that's intended. 🙃 With as Tea it's slightly easier to identify whether we talk about a component or a type:

const beverage = { color: "green" } as Tea;
return <Tea>{beverage.color}</Tea>;

What about the new `satisfies` keyword?

The upcoming TypeScript 4.9 brings in the new keyword satisfies. Functionally, it acts very similar to as with the additional benefit of not broadening the type to something more generic. For us, the important lesson here is that satisfies leaves us just as open to runtime errors as as does. So be careful!

Closing

Wanna learn more about TypeScript? Then hit subscribe on the blog, and join me on Twitch TypeScriptTeatime! Looking forward to see you!

Forem: Mirco Kraenz

Run Storybook with NX Expo and React Native Paper

Outline

Add Storybook

Make DOM elements in Storybook work

Make React Native elements in Storybook work

Make React Native Paper elements in Storybook work

TypeScript's `as` keyword might not be what you think

tl;dr

Contents

What as string actually does

Buggy Example

Polymorphism

Type Guards

in Type Guard

instanceof Type Guard

User-Defined Type Guard

TypeScript trusts us in writing proper User-Defined Type Guards

What about <MyType>?

What about the new satisfies keyword?

Closing

Recommended Reading

What `as string` actually does

`in` Type Guard

`instanceof` Type Guard

What about `<MyType>`?

What about the new `satisfies` keyword?