问题

Context

默认情况下，Storybook.js 已经与我的现有 Create-React-App 项目集成，创建了两个新文件夹：

• .storybook
• src/stories

我不喜欢这样，因为感觉它混合了不同的利益。Storybook 的目的是将应用程序的业务逻辑完全分开。

Problem

我尝试将 stories 目录移动到 .storybook 内。现在，尽管终端或浏览器控制台中没有列出错误，但出现了无限加载的旋转器。

有时候，如果我等足够长的时间，我会在控制台中收到以下错误消息：

Loading chunk vendors-node_modules_babel_runtime_helpers_esm_assertThisInitialized_js-node_modules_babel_ru-6be1ea failed.

(timeout: http://localhost:6006/vendors-node_modules_babel_runtime_helpers_esm_assertThisInitialized_js-node_modules_babel_ru-6be1ea.iframe.bundle.js)

Current Situation

以下是我当前目录结构的摘要：

• .storybook
  • /stories
  • /assets
  • main.ts

以下是我在 main.ts 内的配置与目录相关的部分。

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


const config: StorybookConfig = {
  stories: ["./stories/**/*.mdx", "./stories/**/*.stories.@(js|jsx|ts|tsx)"],
  staticDirs: ["./assets"],
};

Attempted Solutions

Create a shared parent directory

我尝试创建一个父文件夹，想着也许我可以将 .storybook 和 stories 存储在一个文件夹内，而不是将 stories 嵌套在 .storybook 内，但是然后我在尝试运行 npm run storybook 脚本时遇到了问题。

我已经阅读了关于 WebPack（我正在使用 v5）的各种文章，但我还没有能够理解它。

Loading chunk vendors-node_modules_babel_runtime_helpers_esm_assertThisInitialized_js-node_modules_babel_ru-6be1ea failed.

(timeout: http://localhost:6006/vendors-node_modules_babel_runtime_helpers_esm_assertThisInitialized_js-node_modules_babel_ru-6be1ea.iframe.bundle.js)

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


const config: StorybookConfig = {
  stories: ["./stories/**/*.mdx", "./stories/**/*.stories.@(js|jsx|ts|tsx)"],
  staticDirs: ["./assets"],
};

答案1

得分: 1

Honestly, I also considered this for a while. 我也曾考虑过一段时间。

I had originally even setup storybook as a separate npm/yarn workspace. 最初，我甚至将storybook设置为单独的npm/yarn工作区。

However, now that we are deeper into storybook and that we have embraced their interaction testing (visual component testing), I appreciate having the stories next to the component they document/test. 但是，现在我们更深入地使用storybook，并且我们已经采用了它们的交互测试（视觉组件测试），我很感激将故事放在它们文档/测试的组件旁边。

This comes also from a move that I am driving in my team to refactor our code to follow a more domain based structure. 这也源自我在团队中推动的一项举措，即将我们的代码重构为更具领域基础结构的形式。

So far, I have seen a lot of react projects being structured based on technical grouping (which I personally find to be an anti-pattern - it goes against encapsulation and code-cohesion). 到目前为止，我看到很多React项目都是基于技术分组进行结构化的（我个人认为这是一种反模式——它违反了封装和代码内聚性）。

I like having everything that has to do with the component, within that components folder (aside from shared dependencies of course). 我喜欢将与组件有关的所有内容都放在该组件文件夹中（当然，除了共享的依赖项）。

Funnily enough, in our backend projects we do have domain based structuring with ArchUnit tests (and soon Spring Modulith, there is an interesting talk about it here). 而有趣的是，在我们的后端项目中，我们确实采用了基于领域的结构化方式，并使用了 ArchUnit 测试（而且很快会使用 Spring Modulith，这方面有一个有趣的讨论在这里）。

We are not as far as to introducing ArchUnit-style tests for the frontend yet, but that would be the goal. 目前，我们在前端还没有引入类似 ArchUnit 的测试，但这是我们的目标。

We have setup this folder structure: 我们已经设置了这个文件夹结构：

  Component.tsx
  __storybook__
    Component.stories.tsx
    Component.stories-docs.tsx
    // depending on the size of the component, we may have other files here, like fixtures and page-objects (yes, I know they are controversial)```

<details>
<summary>英文:</summary>

To be honest, I also considered this for a while. I had originally even setup storybook as a separate npm/yarn workspace.

However, now that we are deeper into storybook and that we have embraced their interaction testing (visual component testing), I appreciate having the stories next to the component they document/test. 

This comes also from a move that I am driving in my team to refactor our code to follow a more domain based structure. So far, I have seen a lot of react projects being structured based on technical grouping (which I personally find to be an anti-pattern - it goes against encapsulation and code-cohesion). I like having everything that has to do with the component, within that components folder (aside from shared dependencies of course).

Funnily enough, in our backend projects we do have domain based structuring with [ArchUnit](https://www.archunit.org/) tests (and soon [Spring Modulith](https://spring.io/projects/spring-modulith), there is an interesting talk about it [here](https://www.youtube.com/watch?v=SjSjBZ7mo1g)). We are not as far as to introducing ArchUnit-style tests for the frontend yet, but that would be the goal.

We have setup this folder structure:

• component
  Component.tsx
  storybook
  Component.stories.tsx
  Component.stories-docs.tsx
  // depending on the size of the component, we may have other files here, like fixtures and page-objects (yes, I know they are controversial)

</details>