В настоящее время мы не планируем это реализовывать. Это потому, что это затрудняет навигацию. Вы можете использовать такие виды историй пространства имен с точками, как "ui.core", "ui.app". Затем вы можете фильтровать их по своему усмотрению.

Если историй много, можно начать с нескольких экземпляров сборника рассказов. Вы можете сделать это, имея два каталога конфигурации сборника рассказов. Но в любом случае это крайний случай.

Я готов согласиться с этим, и подумал, что просто сделаю другую конфигурацию и запустю ее на другом порту и еще много чего ...

Но я думаю, что было бы намного лучше позволить сборнику рассказов принимать несколько файлов конфигурации ... а затем переключаться между именованными файлами конфигурации, возможно, перезагружая ...

Что касается пользовательского интерфейса для переключения конфигураций, он появится только в том случае, если ваш конфигурационный файл "загрузит" другие конфигурационные файлы, и это могут быть элементы боковой панели вверху или внизу навигационной панели.

В любом случае - я думаю, что для более крупных приложений, если вы не можете (или не можете) разделить конфигурации, это своего рода сумасшествие.

Добавление дополнительных конфигураций кажется слишком сложным. А как насчет переключателя для классического / иерархического просмотра? Я счастлив, что в ближайшие несколько дней мы выпустим реализацию.

Для меня это тоже было бы очень ценной функцией, но для организации типов компонентов в рамках одного приложения, а не для нескольких приложений.

Я был бы более чем счастлив оказать любую помощь в формировании реализации, которая могла бы работать для обоих вариантов использования, если это будет продвигаться вперед.

@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()

Функции

• Иерархическая структура подсторий
• Совместим с 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

Я построил замечательный storybook-chapters @UsulPro, чтобы создать загрузчик сборника рассказов, который будет отражать иерархию файлов компонентов в виде глав сборника рассказов :

Благодаря этому я могу помещать свои истории в файл или папку _stories прямо вместе с моими компонентами. Загрузчик находит все файлы историй и отображает их в соответствующую структуру навигации.

Спасибо за теплый отзыв, ребята!

Действительно здорово увидеть storybook-filepath-chapters от @hadfieldn ! 👍

Мне нравится пример storybook-addon-toggle , что желательно иметь возможность выстраивать иерархию не только по глубине, но и по верху. Вообще-то технически это возможно, но я думаю, что сложно выбрать лучший способ (оставаясь в рамках API аддонов). Возможно, это можно сделать с помощью декораторов (например, @majapw) или с помощью дополнительных панелей.

Я пока не планирую добавлять иерархию к историям, но у storybook-chapters addon теперь есть 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 . Из двух последних виден только один, а первый позволяет переключаться.

в следующем выпуске я планирую добавить возможность управления видимостью историй через настраиваемую панель надстроек

-

С помощью функции включения / отключения вы можете создавать настраиваемую навигацию с вашей предпочтительной логикой.

полный пример здесь

Мы будем реализовывать браузер иерархии, но нам бы понравились концепции того, как сообщество думает, что это должно быть сделано:

• UX мудрый
• Как настроить группы

Что касается UX, мне нравится эта идея: http://multi-level-push-menu.make.rs/demo/basichtml/basichtml.html

Конфигурация, которую я еще не знаю .. Мы могли бы использовать исследование файлов и зеркалировать файловую систему, или мы могли бы сделать что-то вроде этого: https://github.com/sm-react/storybook-chapters/issues/1#issue -215446017

@ndelangen , думали ли вы (по крайней мере, необязательно?), позволяя определять навигацию вне историй? Мне кажется, что может быть полезно рассматривать то, как выглядит история (область предварительного просмотра / iframe) и как вы хотите организовать просмотр (менеджер), как отдельные задачи.

@jackmccloy Мне интересно, не могли бы вы рассказать мне больше о том, что вы имеете в виду?

Я упоминал в другом выпуске, но моя цель с категориями - это согласование в основном с атомарным дизайном . Pattern lab - это официальное руководство по стилю для атомарного дизайна, но добавление категорий в сборник рассказов восполнит последний оставшийся пробел.

Я уже размещаю свои компоненты в папках верхнего уровня для этих категорий, поэтому возможность загружать компоненты в категории, основанные на папках верхнего уровня, тоже была бы отличной вещью для съемки.

@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 компонента.

Но сообщество могло бы экспериментировать с различными способами организации своих историй, (а) добавляя дополнительные поля метаданных в stroyData и / или (б) изменяя способ отображения панели навигации на основе полей метаданных.

Некоторые идеи:

// 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, который рассматривает пользовательский интерфейс как серию «визуальных тестовых примеров» и легко определяет состояния пользовательского интерфейса как отдельные истории с помощью вызова add() каждого состояния.

При регистрации метаданных истории в вызове 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, заключается в том, что я могу определить, находится ли компонент в Storybook, просто проверив, есть ли файл story.jsx расположенный вместе с компонентом. Эта гарантия -
что, если файл 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 Я согласен с вами в отношении необходимости сохранения простоты добавления состояний. Я не думал об этом, вероятно, потому что я часто использую аддон с ручками. Поэтому я стараюсь иметь отношение 1-1 между компонентами и историями, и названия моих историй описывают компонент, а не состояние, в котором находится компонент.

Одно из возможных решений, которое может сработать для обоих вариантов использования, - это сделать что-то вроде этого

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

где (а) порядок историй может контролироваться из того места, где они объявлены (в отличие от необходимости во внешней конфигурации) и (б) параметр 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. На самом деле мы могли бы написать несколько обработчиков категорий, которые охватывают некоторые из распространенных вариантов использования, которые у нас есть (атомарный дизайн, основанный на папках ...);

Точно так же для сортировки мы можем поддерживать стратегию по умолчанию (без сомнения, альфа) по умолчанию, и, если есть необходимость, мы можем предоставить другие заранее созданные стратегии сортировки (сортировка на основе формы объекта, индексы сортировки в метаданных и т. Д. ...);

@ndelangen, что вы видите в этом направлении? Кто-нибудь над этим работает? Если нет, то с радостью попробую на выходных.

Когда я получаю уведомление, что кто-то начал работу и их решение является жизнеспособным, я удаляю метку PR needed . Итак, это в настоящее время в дорожной карте, но работа еще не проводилась.

Если вы хотите начать с этого, это было бы очень приятно!

@jackmccloy, могу ли я присоединиться и поучаствовать в этой работе, если вы не против?

@UsulPro 100%, я был бы в восторге от этого. Планирую по-настоящему взглянуть на это в воскресенье днем ​​(время Нью-Йорка). Если вы будете в сети одновременно, lmk и мы можем перевести конво в режим ожидания. В противном случае я опубликую здесь некоторые мысли после того, как немного покопаюсь

@jackmccloy @usulpro Мне определенно интересно поработать и над этим.

@theinterned Было бы здорово! Подключение в слабину?

@UsulPro извини - у меня в доме

В пятницу у меня на работе будет хакерский день, и тогда я планирую над этим поработать. У вас была возможность начать? Я был бы счастлив синхронизироваться со Slack. Я в канале SB.

Если вам нужен только один уровень вложенности, React Storybook Addon Chapters может удовлетворить ваши потребности.

Я выпустил первую версию отличной реализации иерархии историй в @ igor-dv и хотел бы получить ваши отзывы об альфа-версии, чтобы мы могли улучшить ее перед выпуском для более широкого сообщества:

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

Я заметил небольшую причуду в иерархии историй:
В зависимости от того, есть ли в каталоге подкаталоги, изменяется результат щелчка по каталогу.
Если есть подкаталоги, папка будет расширяться, но если она опущена на уровне истории, история будет выбрана автоматически.
Пользователь может захотеть просмотреть содержимое каталога, не выбирая историю внутри.

Обновлять:

Может быть связано с этой проблемой в react-treebeard
https://github.com/alexcurtis/react-treebeard/issues/33
Возможно, стоит изучить PR для репо storybooks/react-treebeard

В предыдущей реализации при выборе kind автоматически выбиралась его первая история. Так что эту функциональность я хотел сохранить. Но, возможно, с иерархией это уже похоже на ошибку.

На картинке Component 5 - это не каталог, это kind .

На самом деле мне тоже не нравится такое поведение ...

Имена длинных историй выглядят странно

При изменении размера боковой панели до очень маленького размера панель предварительного просмотра переполняется.

Можно ли объединить иерархические папки с отдельными историями? У меня есть несколько историй, которые я хочу на верхнем уровне, иначе у меня есть папка с одним элементом

В настоящее время, если вы это сделаете

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

Затем он создает 2 записи для «Что-то», одну с папкой и одну с элементом.

@TheSisb , спасибо, в официальном релизе

@psimyn , в текущей реализации это невозможно .. но может быть изменено .. @UsulPro также упомянул об этом в первоначальном PR.
ИМО, это нехорошее поведение (и приносит больше сложности). Сравнивая его с каждой IDE, есть пространства имен (каталоги / папки / пакеты) и могут быть некоторые элементы в этих пространствах имен (или рядом с ними) с тем же именем.
В любом случае, если это желаемое поведение сообщества, его следует изменить, но я бы не хотел, чтобы это было препятствием для релиза =)

Это именно то решение, которое мне нужно !!! спасибо +1

@psimyn Откройте, пожалуйста, новый выпуск с описанием этой функции? Эта проблема будет закрыта в ближайшее время с выпуском 3.2.0

Возможно ли использование нескольких уровней вложенности в новом формате CSF?

@ gaurav5430 это было возможно в течение некоторого времени, см. наш пример здесь:

CSF:

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 основных состояний. Обычно я сохраняю все состояния компонента в одном файле, но в этом случае мне понадобится отдельный файл для иерархии в историях.