目前，我们没有实施该计划的计划。 那是因为它使导航变得更加困难。 您可以使用点命名故事类型，例如“ui.core”、“ui.app”。 然后您可以根据需要过滤它们。

如果有很多故事，您可以开始一些故事书实例。 您可以通过拥有两个 storybook 配置目录来做到这一点。 但是，无论如何，这是一个极端的情况。

我愿意承认这一点，并认为我只是做一个不同的配置并在不同的端口上运行它等等......

但我认为允许故事书采用多个配置文件会好得多......然后在命名配置文件之间切换，也许重新加载......

至于切换配置的 UI，它只会在您的配置文件“加载”其他配置文件时出现，并且它可能是侧边栏导航顶部或底部的侧边栏项目。

无论如何 - 我认为对于较大的应用程序，如果您不能（或不）拆分配置，那就有点疯狂了。

添加额外的配置似乎过于复杂。 经典/层次视图的切换怎么样？ 我很高兴在接下来的几天内推出一个实现。

这对我来说也是一个非常有价值的功能，但对于在单个应用程序中组织组件类型而不是多个应用程序。

如果能够继续推进，我将非常乐意提供任何帮助来塑造一个适用于这两个用例的实现。

@travi我们的另一个想法是在过滤器框下方提供一个下拉菜单来选择类别。

在 config.js 和不同的文件集中分配了一个类别。 所以，我们可以有另一层分组。

我认为这种类型的解决方案足以满足我此时的需求。 另外，我认为上面提到的命名空间约定仍然是一种合理的方式来分配可以解释为下拉列表中的选择的类别。 这样的解决方案将使跨类别的链接仍然保持简单。

我们在我正在构建的应用程序中解决这个问题的方法（数百个组件，组织在松散的“支柱”区域内）是使用一个脚本动态地写出我们当前正在处理的区域的故事。

find.file(
  /\.story\.js/,
  path.resolve(__dirname, '../src/app/components', targetComponentPath),
  function(files) {
    var requires = files.map(function(file) {
      return "require('" + path.relative(__dirname, file) + "');";
    });
    fs.writeFileSync(path.resolve(__dirname, '../.storybook/stories.js'), requires.join("\n"));
  }
);

这意味着 Storybook 甚至不必构建其他组件。 作为内置选项，我希望对此提供某种程度的支持。

201 可以帮助解决这个问题。

关于这一点的任何更新？

+1

我很高兴，这是一个非常有用的功能！

+1

+1

+1

+1

+1

+1

嘿@arunoda ，类别实施方面有任何进展吗？

如果没有，是否还有其他人有可以在两个故事书配置之间切换的示例应用程序？

+1 我绝对需要一层额外的嵌套：/

+1

+1

+1

+1

+1

+1

看起来随着你的应用程序的增长，组件列表也在增长，你需要更多的嵌套。 1 级以上已经涵盖了很多情况

+1

大家好！

尽管在不久的将来没有计划这样的功能，但这并不意味着我们不能通过 Storybook Addons API 获得这样的行为

这是一个这样的插件：

故事书章节

为（子）故事添加无限级别的嵌套

要再添加一层嵌套级别，只需将.chapter(name)放入您的故事中：

// stories.js:

storiesOf('React App', module)
    .chapter('Left panel')
        .add('Button 1', fn(1))
        .add('Button 2', fn(2))
        .chapter('Bottom Panel')
            .add('Input 3', fn(3))
            .add('Input 4', fn(4))
            .endOfChapter()
        .chapter('Header Panel')
            .add('Input 5', fn(5))
            .add('Input 6', fn(6))
            .endOfChapter()
        .endOfChapter()
    .chapter('Right panel')
        .add('Button 7', fn(7))
        .add('Button 8', fn(8))
        .endOfChapter()

特征

• Substories的层次结构
• 兼容Knobs , addWithInfo和其他插件
• 使用storyDecorator包装所有章节

演示页面

项目

例子

任何反馈将不胜感激！ :)

@UsulPro不错！

@UsulPro Storybook Chapters 是一个绝妙的解决方案。 谢谢！

@UsulPro似乎正是我要找的，谢谢！

大家好！ 不想与@UsulPro竞争（他用storybook-chapters做了很棒的工作），但我想出了一个小的、略有不同的解决方案，它允许您使用preview的按钮在不同的故事分组之间切换related components view引导程序文档）和detailed components view故事书非常适合的内容）之间轻松切换，我们有大量的组件可以炫耀。 我认为这是设置多个故事书实例的轻量级版本：

如果它对你有用，你可以在这里查看 - https://github.com/majapw/storybook-addon-toggle

我在@UsulPro的很棒的storybook-chapters上构建了一个故事书加载器，它将您的组件文件层次结构镜像为故事书章节： storybook-filepath-chapters

有了这个，我可以将我的故事放在_stories文件或文件夹中，与我的组件直接内联。 加载器找到所有故事文件并将它们映射到相应的导航结构中。

感谢热心的反馈，伙计们！

看到@hadfieldn的storybook-filepath-chapters真的很酷！ 👍

我喜欢storybook-addon-toggle为例，希望有可能不仅在深度上而且在顶部建立层次结构。 实际上，从技术上讲这是可能的，但我认为很难选择最佳方式（留在插件 API 中）。 也许这可以使用装饰器（如@majapw）或通过插件面板来完成。

我不打算在故事上添加层次结构，但是storybook-chapters插件现在有一个API ，能够简化这样一个层次结构的构建：

enable / disable显示/隐藏您的故事

——

将enable() / disable()到您的故事中。 作为参数，指定控制函数将转移到的回调。

let toLight = () => {};
let toDark = () => {};

storiesOf('Heroes Lightside', module)
    .enable((en) => { toLight = en; })
    .add('Yoda', info('Yoda'))
    .add('Mace Windu', info('Mace Windu'));

storiesOf('Heroes Darkside', module)
    .disable((en) => { toDark = en; })
    .add('Darth Sidious', info('Darth Sidious'))
    .add('Darth Maul', info('Darth Maul'));

那么您可以使用toLight(false)隐藏Heroes Lightside和toDark(true)来显示Heroes Darkside故事。 您可能希望将toLight和toDark放入一些装饰器中，或者从其他故事中回调。 我将展示最简单的例子：

storiesOf('Choose Your Side', module)
    .add('Lightside', () => {
        toLight();
        toDark(false);
        return (<div>{'Lightside selected'}</div>);
    })
    .add('Darkside', () => {
        toDark();
        toLight(false);
        return (<div>{'Darkside selected'}</div>);
    });

所以现在我们有 3 组故事： Choose Your Side 、 Heroes Lightside和Heroes Darkside 。 在最后两个中，只有一个可见，第一个允许您切换。

在下一个版本中，我计划添加通过可定制的插件面板控制故事可见性的功能

——

通过启用/禁用功能，您可以使用首选逻辑构建自定义导航。

完整的例子在这里

我们将实现一个层次浏览器，但会喜欢社区认为应该如何完成的概念：

• 用户体验明智
• 如何配置组

在用户体验方面，我喜欢这个想法： http :

配置我还不知道..我们可以使用文件探索和镜像文件系统，或者我们可以这样做： https :

@ndelangen您是否考虑过（至少是可选的？）允许在故事之外定义导航？ 在我看来，将故事的外观（预览区域/iframe）以及您希望如何组织浏览（管理器）作为单独的关注点可能是有价值的。

@jackmccloy我很感兴趣，你能告诉我更多关于你的意思吗？

我在另一个问题中提到过，但我的类别目标是主要与原子设计保持一致。 模式实验室是原子设计的官方风格指南方法，但向故事书添加类别将填补最后剩余的空白。

我已经在这些类别的顶级文件夹中安排了我的组件，因此能够将组件加载到基于顶级文件夹的类别中也是一件很棒的事情。

@travi你能给我打印一下你的文件夹布局吗？

我绝对有兴趣为此目的改进故事书，但我感兴趣的是从您的文件夹结构中读取此分类在技术上需要什么。

它本质上

project root
|
+--
|  +-- atoms
|  |  +-- foo
|  |    +-- index.js // the component
|  |    +-- stories.js
...
|  +-- molecules
|  |  +-- bar
|  |    +-- index.js
|  |    +-- stories.js
...
|  +-- organisms
|  |  +-- baz
|  |    +-- index.js
|  |    +-- stories.js

这有帮助吗？ 我在每个顶级文件夹下都有多个组件，有时会按另一个文件夹级别进一步分组。 如果有帮助，很乐意提供更多细节

好的，所以我们可以做的是在config.js设置一个标志。 像autoDiscoverStories类的东西。 这意味着您不必手动导入故事，文件系统文件夹将用作类别。

@ndelangen我想我的想法是这样的：现在，我们的谈话是围绕“我们如何使导航变得更好”，但它假设每个人都会使用一个导航。 我觉得可能值得讨论一下使导航可扩展的方法，类似于插件如何扩展故事本身的功能。

一种可能：
目前，每个故事都分两步添加 - 第一步分配类别，第二步分配标题，即

storiesOf('storyCategory', module).add('storyTitle', () => <Component />)

您可以将多个故事链式添加到同一类别中，但这种结构在一定程度上限制了灵活性——所有故事都必须有一个类别和一个标题，而类别是比标题“更高的级别”。

但是如果故事可以用稍微不同的方式来定义，即

const storyData = {
  category: "category",
  title: "storyTitle",
}
stories.add(() => <Component />, storyData)

我们可以更轻松地尝试不同的导航选项。

默认导航可以保持原样。 这是一个理智的默认设置，可能对我们大多数人来说都足够好。 storyData甚至可以是可选的——没有类别的故事可以出现在顶层，没有标题的故事可以默认为组件的displayName 。

但是社区可以通过 (a) 将额外的元数据字段添加到stroyData和/或 (b) 更改导航面板基于元数据字段的呈现方式来尝试不同的方式来组织他们的故事。

一些想法：

// add an additional level to the hierarchy called subCategory
const stroyData = {
  category: "Buttons",
  subCategory: "Blue",
  title: "BlueButton",
}
stories.add(() => <BlueButton />, storyData)

// add tags to a story that you could then filter by
const stroyData = {
  category: "Buttons",
  tags: ["button", "homepage"],
  title: "HomepageButton",
}
stories.add(() => <HomepageButton />, storyData)

// have a story to appear in multiple categories
const stroyData = {
  categories: ["Buttons", "Homepage Elements"],
  title: "HomepageButton",
}
stories.add(() => <HomepageButton />, storyData)

好的！ 这是非常开箱即用的，并且确实可以扩展。 我要考虑一下。 🤔

惊人的。 让我知道你的决定 - 无论你选择哪个方向，我都会尽可能地投入 - 该项目的忠实粉丝

@jackmccloy的提议很棒，谢谢你的好主意！

然而，它似乎不鼓励 Storybooks 的一个强大用例，该用例将 UI 视为一系列“视觉测试用例”，并使用每个状态的add()调用轻松地将 UI 状态定义为单个故事。

在add()调用中注册故事元数据感觉就像在错误的级别添加了类别。 我想看到相同的提议，但使用storiesOf()函数：

storiesOf({
  title: Component,
  category: "My Category"
}, module)
  .add("when empty", () => <List items=[] />)
  .add("with items", () => <List items=["one", "two", "three"] />)
  .add("etc.", () => <List items={etc} />);

我喜欢能够从Component.displayName和所有其他关于子类别或向多个类别添加组件的想法中获取标题的想法，我只想保持添加状态的简单性。

要记住的一件事是，无论类别在哪里定义，另一个文件都应该能够添加到类别中。 如果一个类别只能从一个文件中定义，我认为这将是非常有限的

我同意@travi——这就是为什么类别只是一个字符串（我想它会映射到某个字典键）很有吸引力。

我想我可以在一个地方定义我的类别，以防止像这样的拼写错误：

// categories.js
export const Layouts = "Layouts";
export const Components = "Components";
export const Styles =  "Styles";

// DashboardLayout.story.js
import { Layouts } from "../categories";
import DashboardLayout from "./DashboardLayout";

storiesOf({
  title: DashboardLayout,
  category: Layouts
}, module)
  .add("default", () => <DashboardLayout />);

但这将是留给我的应用程序的实现细节。

@theinterned @jackmccloy我喜欢你的建议。

我正在考虑如何在任意深度的层次结构中使用您的建议。 也许不是category / subCategory它可以是带有路径组件数组的path 。 （我知道您不一定要在那里进行具体说明，只是对您的想法进行重复。）

我也喜欢使用文件系统创建导航层次结构的配置选项的想法。 启用此选项后， path参数将是可选的。

这更像是一个延伸目标，但将层次结构中的每一页故事作为单独的块加载可能会更好，以便随着故事书变大而保持轻量级。 允许故事书加载器以特定文件系统文件夹作为根上下文运行也是很酷的，这样它就可以构建一个故事书，其中只包含在该文件夹中定义的故事，而不是整个项目中的所有故事。

你们对在配置中预先定义/注册类别有什么看法？

// config.js
import { configure, addCategory } from '@kadira/storybook';

function init() {
  require('../src/stories');
  addCategory({
    id: 'atom',
    name: 'Atoms',
    index: 0
  });
  addCategory({
    id: 'molecule',
    name: 'Molecules',
    index: 1
  })
}

configure(init, module);

// component.story.js
import Component from "./Component";

storiesOf({
  title: Component,
  category: 'atom'
}, module)
  .add("default", () => <DashboardLayout />);

我们不妨支持一个数组： category: ['atom', 'deprecated'] ，为什么不呢？

这将有助于确保以正确的顺序放置类别，这在原子设计中很重要。

从配置中检索类别会很好，魔术字符串很糟糕👎

这对我来说很有意义。

此外，+1 用于从配置中定义的内容中提取故事的类别，而不是希望匹配字符串

@ndelangen 预先定义类别以便我们可以控制排序将是巨大的！ 但我认为重要的是要在配置中_可以_定义类别，而不是_必须_在那里定义它们。

我喜欢 Storybook 的一件事是，我可以通过检查是否存在与组件共存的story.jsx文件来判断一个组件是否在 Storybook 中。 那个保证——
如果story.jsx文件存在，则故事存在 - 是一个重要的故事，不应通过预先定义的类别来撤销，imo。

从这个角度来看，配置中的类别需要id和index甚至可能不是必需的 - 这样的事情（假设它使用选项插件）可以工作

setOptions({
  categoryOrder: [
    "First Category",
    "Second Category",
    "Third Category",
});

其中First Category 、 Second Category和Third Category保证出现在第一、第二和第三，并且故事中声明的任何其他类别将按字母顺序出现在这三个类别之后。

通过执行以下操作，这种方法也可能是控制任意深度嵌套的明智方法：

categoryOrder: [
  {
    "Atoms": [
      {
        "Buttons": []
      }
    ],
  }, {
    "Molecules": [],
}],

类别为“按钮”的故事将出现在Atoms -> Buttons 。 类别为“原子”的故事将出现在Atoms ，低于Buttons （但不在其中）等。

用户将在没有任何配置的情况下获得一个深度级别（就像现在一样），以及以最少的配置获得任意级别的深度。 重要的是，它是具有深度的类别（在配置级别设置）而不是故事本身（即故事只会设置它们的类别 - 他们不会定义该类别出现在层次结构中的位置）。

@theinterned我同意你的看法：需要保持添加状态的简单性。 我没有想到这一点，可能是 b/c 我大量使用旋钮插件。 所以对我来说，我尝试在组件和故事之间建立 1-1 的关系，我的故事标题描述了组件，而不是描述了组件所处的状态。

一种可能适用于这两种用例的潜在解决方案是做这样的事情

const storyData = {
  category: "category",
  title: "first item",
}
stories.add(() => <Component />, storyData)
  .add(() => <Component />, {title: "second item"})
  .add(() => <Component />, {title: "third item"})

其中（a）故事的顺序可以从它们被声明的地方控制（而不是需要一个外部配置）和（b） storyData参数可以保留以前的对象，只覆盖那些值明确通过。

只是一个想法。

虽然即使只是顶级类别我也会很兴奋，但如果事情确实足以支持嵌套类别，值得注意的是，假设类别名称在不同类别之间是唯一的是不安全的。

继续原子设计示例，在原子、分子和有机体的每个顶级类别中都有一个同名的子类别是很常见的。 在模式实验室演示中，表单就是一个很好的例子。 单个场元素列在原子下，场和标签的组合列在分子下，分组为完整形式的多个场在有机体下显示。

一个有趣的想法是考虑是否可以使用回调来定义类别，该回调获取标题、故事和故事文件的路径......以及用户可以传递的一些元数据来配置回调。

storyData = {
  title: Component,
  category: ({ title, story, storyPath, meta }) => someCategoryPath,
  meta: { ..whateverMeta }
}

唯一的要求是回调需要返回一个定义故事类别路径的对象：

storyData.category() //=> returns the below array

// a simple category path might look like:
[ "One category" ];

// The path for a story nested three categories deep would look like:
[ "Parent Category",  "Child Category", "Grandchild category where the story lives" ];

这将允许人们编写他们想要的任何类别系统。

如果你想要全局配置，你可以在回调中注册它并使用自定义元数据来配置你想要注册故事的类别/子类别。

categories: [
  {
    "Atoms": [
      {
        "Buttons": []
      }
    ],
  }, {
    "Molecules": [],
}];

function setCategory({ meta }) {
  const { categroyPath } = meta; // maybe a dot path string like "Atoms.Buttons" ?
  const category = categroyPath.split('.'); // [ "Atoms", "Buttons" ]
  return validatePath(category, categories); // categories["Atoms"]["Buttons"] is a valid path
}

如果您想根据文件结构设置类别结构，您可以使用路径信息。

function setCategory({ storyPath }) {
  // for story path `src/components/Atoms/MyComponent.story.js`
  let folders =storyPath.split('/'); // [ "src", "components", "Atoms", "MyComponent.story.js" ];
  folders = without(folders, 'src'); // ["components", "Atoms", "MyComponent.story.js" ];
  folders.pop(); // [ "components", "Atoms" ]
  return folders;
}

如果您只想使用一个简单的类别名称，您可以只使用一个！ （也许类别可以采用简单字符串、描述类别路径的数组或返回类别路径的回调之一）。

现在天空是极限！

同样，为了定义排序顺序，我建议您可以注册一个addCategorySort函数，该函数采用通过加载所有故事生成的树类别结构并对其进行排序。

import { configure, addCategorySort } from "@kadira/storybook";

addCategorySort( categories => /* sort logic here */ );

configure(loadStories, module);

@travi我没有考虑过需要重复命名的类别，但我同意这很重要。 关于解决方案的任何想法？ 这就是我想到的，但也许有更好的解决方案：

const storyData = {
  categories: ["Buttons"],  // any category with the title "buttons"
}

const storyData = {
  categories: ["Atoms.Buttons"],  // any category with the title "buttons" that also has the parent category "atoms"
}

@theinterned我挖掘了这种方法，但担心它可能会使典型用户（他们需要/想要开箱即用的东西）使事情变得更难/不那么直观，以造福于高级用户（他们想要与它完美配合的东西）有点努力）。

@jackmccloy是的......我同意实现一个功能不应该是每个人的要求。 但似乎人们希望支持许多不同的用例，因此回调系统似乎是为每个人提供可扩展性以自定义他们自己的用例的好方法。

为了消除它使“快乐之路”变得更难的担忧，我建议如下：

1. 让storydData.category接受一个字符串，在这种情况下，类别将是顶级类别。
2. 让storydData.category接受一个数组，其中数组中的元素是类别的路径：

// given
storydData.category = ["grand parent", "parent", "story category"];
// category tree would look like:
categories = {
  "grand parent": {
    "parent": {
      "story category": /* the story lives here */
    }
  }
};

1. 让故事数据接受上述函数 (https://github.com/storybooks/react-storybook/issues/151#issuecomment-292689536)。
2. 我们实际上可以编写一些类别处理程序来涵盖我们这里的一些常见用例（原子设计、基于文件夹……）；

同样，对于排序，我们可以默认支持默认策略（毫无疑问是 alpha），如果需要，我们可以提供其他预构建的排序策略（基于对象形状排序，元数据中的排序索引等......）；

@ndelangen你认为这方面的前进道路是什么？ 有人在研究吗？ 如果没有，很高兴在周末尝试一下

当我收到任何人已经开始工作并且他们的解决方案可行的通知时，我删除了PR needed标签。 因此，这目前在路线图上，但尚未完成任何工作。

如果你想开始，那将是非常受欢迎的！

@jackmccloy如果你不介意的话，我也可以加入并参与这项工作吗？

@UsulPro 100%，我会

@jackmccloy @usulpro我也绝对有兴趣在这方面工作。

@theinterned那太好了！ 连接松弛？

@UsulPro抱歉——肠胃不好的流感袭击了我的家人。

周五我的工作即将到来，我计划在那时着手解决这个问题。 你有机会开始吗？ 我很乐意在 Slack 上同步。 我在SB频道。

如果您只需要一层嵌套， React Storybook Addon Chapters可能会满足您的需求。

我已经发布了 @igor-dv 出色的故事层次结构实现的第一个版本，并且很想得到您对 alpha 的反馈，以便我们可以在向更广泛的社区发布之前改进它：

https://gist.github.com/shilman/947a3d1d4cfdf5c3a8bb06d3d4eb84cf

@ 1i1it @andrubot @arunoda @atnovember @danielbartsch @franzihubrick @hadfieldn @iaanvn @imsnif @isuvorov @jackmccloy @joeruello @johnnyghost @lnmunhoz @majapw @markopavlovic @mystetskyivlad @mzedeler @ndelangen @nirhart @ noahprince22 @revolunet @sethkinast @theinterned @thesisb @travi @usulpro @yangshun @zeroasterisk @zvictor

我注意到故事层次结构的一个小怪癖：
根据目录是否有子目录会改变单击目录的结果。
如果有子目录，文件夹将展开，但如果它在故事级别向下，则故事将被自动选择。
用户可能希望查看 dir 的内容而不选择其中的故事。

更新：

可能与react-treebeard此问题有关
https://github.com/alexcurtis/react-treebeard/issues/33
可能值得探索storybooks/react-treebeard回购的 PR

在以前的实施方式中选择kind Story是AutoSelected的第一个故事。 所以这个功能我想保留。 但也许随着层次结构它已经看起来像一个错误。

在图片中Component 5不是目录 - 它是kind 。

其实我也不喜欢这种行为......

长故事名称奇怪地包装

将侧边栏调整得非常小会导致预览窗格溢出到其中。

是否可以将层次文件夹与单个故事结合起来？ 我在顶层有一些我想要的故事，否则我有一个包含单个项目的文件夹

目前如果你这样做

storiesOf('Something', module).add('top story');
storiesOf('Something.Chapter', module).add('substory');

然后它为“Something”创建 2 个条目，一个带有文件夹，一个带有项目

@TheSisb ，谢谢，将在正式版本中修复。

@psimyn ，在当前的实现中这是不可能的.. 但可能会改变.. @UsulPro在最初的 PR 中也提到了这一点。
IMO 这不是一个好的行为（并带来更多的复杂性）。 将它与每个 IDE 进行比较，有命名空间（目录/文件夹/包），并且这些命名空间（或附近）中可能有一些具有相同名称的项目。
无论如何，如果这是社区所期望的行为，则应该对其进行更改，但我不希望它成为发布的阻碍 =)

这是我需要的确切解决方案！！！ 谢谢+1

@psimyn请打开一个描述该功能的新问题？ 此问题将随着3.2.0的发布而真正关闭

现在可以使用新的 CSF 格式进行多层嵌套吗？

@gaurav5430已经有一段时间了，请在此处查看我们的示例：

脑脊液：

import React from 'react';
import { linkTo } from '@storybook/addon-links';
import { Welcome } from '@storybook/react/demo';

export default {
  title: 'Other/Demo/Welcome',
  component: Welcome,
};

export const ToStorybook = () => <Welcome showApp={linkTo('Other/Demo/Button')} />;
ToStorybook.storyName = 'to Storybook';

嘿@ndelangen
谢谢我从这里得到： https: //storybook.js.org/docs/basics/writing-stories/#story -hierarchy

我想我想要的是能够基于story.name而不仅仅是默认导出标题创建子文件夹

export default {
  title: 'Other/Demo/Welcome',
  component: Welcome,
};

export const ToStorybook = () => <Welcome showApp={linkTo('Other/Demo/Button')} />;
ToStorybook.story = { name: 'to/Storybook' };

将显示为Other/Demo/Welcome/To/Storybook

我认为上述问题的解决方法是创建多个故事文件并在每个文件中使用正确的层次结构导出默认值。

就像在one.stories.js ：

export default {
  title: 'Other/Demo/Welcome/One',
  component: Welcome,
};

export const ToStorybookOne = () => <Welcome showApp={linkTo('Other/Demo/Button')} />;

并在two.stories.js

export default {
  title: 'Other/Demo/Welcome/Two',
  component: Welcome,
};

export const ToStorybookTwo = () => <Welcome showApp={linkTo('Other/Demo/Button')} />;

这样，两个故事都会按预期显示在故事书文件夹结构中

@gaurav5430这是推荐的用法，而不是解决方法。 😄

@gaurav5430这是推荐的用法，而不是解决方法。 😄

是的，我只是犹豫要不要这样做，因为这两个文件都针对同一组件的不同状态。 就我而言，该组件有 2 个主要状态和基于这 2 个主要状态的多个子状态。 通常我会将组件的所有状态保存在同一个文件中，但在这种情况下，我需要一个单独的文件用于故事中的层次结构。