Derzeit planen wir nicht, dies umzusetzen. Das liegt daran, dass es die Navigation erschwert. Sie können Story-Arten mit Punkten wie "ui.core", "ui.app" benennen. Dann können Sie sie nach Bedarf filtern.

Wenn es viele Geschichten gibt, können Sie einige Bilderbuchinstanzen starten. Sie können dies tun, indem Sie zwei Storybook-Konfigurationsverzeichnisse haben. Aber das ist sowieso ein Extremfall.

Ich bin bereit, diesen Punkt zuzugeben, und dachte, ich würde einfach eine andere Konfiguration erstellen und sie auf einem anderen Port ausführen und so weiter...

Aber ich denke, es wäre viel besser, Storybook zu erlauben, mehrere Konfigurationsdateien zu verwenden ... und dann zwischen benannten Konfigurationsdateien umzuschalten, vielleicht neu zu laden ...

Die Benutzeroberfläche zum Wechseln der Konfigurationen wird nur angezeigt, wenn Ihre Konfigurationsdatei andere Konfigurationsdateien "geladen" hat und es sich um Seitenleistenelemente am oberen oder unteren Rand der Seitenleistennavigation handeln könnte.

Wie auch immer - ich denke, für größere Apps ist es ziemlich verrückt, wenn Sie die Konfigurationen nicht aufteilen können (oder nicht).

Das Hinzufügen zusätzlicher Konfigurationen scheint zu komplex zu sein. Wie wäre es mit einem Umschalter für die klassische Ansicht/Hierarchieansicht? Ich freue mich, in den nächsten Tagen eine Implementierung durchführen zu können.

Dies wäre auch für mich eine sehr wertvolle Funktion, jedoch eher für die Organisation von Komponententypen innerhalb einer einzelnen App als für mehrere Apps.

Ich würde mich sehr freuen, Ihnen bei der Gestaltung einer Implementierung zu helfen, die für beide Anwendungsfälle funktionieren könnte, wenn dies vorangetrieben werden kann.

@travi Eine unserer anderen Ideen ist es, ein Dropdown-Menü direkt unter dem Filterfeld bereitzustellen, um die Kategorie auszuwählen.

Eine Kategorie wird in der config.js und verschiedenen Dateien zugewiesen. Wir können also eine weitere Gruppierungsebene haben.

Ich denke, dass diese Art von Lösung ausreichen würde, um meine Bedürfnisse zu diesem Zeitpunkt zu befriedigen. Außerdem denke ich, dass die oben erwähnte Namespace-Konvention immer noch eine vernünftige Möglichkeit sein könnte, die Kategorie zuzuweisen, die in den Auswahlmöglichkeiten im Dropdown-Menü interpretiert werden könnte. Eine solche Lösung würde es ermöglichen, auch die kategorieübergreifende Verknüpfung weiterhin einfach zu halten.

Die Art und Weise, wie wir dies in der App, die ich baue, umgehen (Hunderte von Komponenten, die in losen "Säulen" -Bereichen organisiert sind) ist mit einem Skript, das die Geschichten für den Bereich, an dem wir gerade arbeiten, dynamisch schreibt.

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"));
  }
);

Das bedeutet, dass Storybook nicht einmal die anderen Komponenten erstellen muss. Ich würde mich über ein gewisses Maß an Unterstützung dafür als integrierte Option freuen.

201 könnte dabei helfen.

irgendwelche Updates zu diesem?

+1

Ich bin argee, das ist eine sehr nützliche Funktion!

+1

+1

+1

+1

+1

+1

Hey @arunoda , gab es Fortschritte bei der Implementierung der Kategorien?

Wenn nicht, hat jemand eine Beispiel-App, die zwischen zwei Storybook-Konfigurationen umschaltet?

+1 Ich brauche unbedingt eine zusätzliche Verschachtelungsebene :/

+1

+1

+1

+1

+1

+1

Nun, während Ihre App wächst, wächst auch die Komponentenliste und Sie benötigen mehr Verschachtelung. 1 weiteres Level würde schon viele Fälle abdecken

+1

Hallo Leute!

Obwohl ein solches Feature in naher Zukunft nicht geplant ist, bedeutet dies nicht, dass wir ein solches Verhalten nicht über die Storybook Addons API erreichen können

Hier ist ein solches Addon:

Bilderbuchkapitel

Fügt unbegrenzte Verschachtelungsebenen für (Unter-)Geschichten hinzu

Um eine weitere Verschachtelungsebene hinzuzufügen, fügen Sie einfach .chapter(name) zu Ihren Storys hinzu:

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

Merkmale

• Die hierarchische Struktur von Substories
• Kompatibel mit Knobs , addWithInfo und anderen Addons
• Verwenden Sie storyDecorator , um alle Kapitel zu umbrechen

Demoseite

Projekt

Beispiel

Jedes Feedback wird sehr geschätzt! :)

@UsulPro Schön!

@UsulPro Storybook Chapters ist eine brillante Lösung. Vielen Dank!

@UsulPro scheint genau das zu sein, wonach ich gesucht habe, danke!

Hallo zusammen! Ich versuche nicht, mit @UsulPro zu konkurrieren (der mit storybook-chapters großartige Arbeit geleistet hat), aber ich habe eine kleine, etwas andere Lösung gefunden, mit der Sie mit einer Schaltfläche im preview zwischen verschiedenen Gruppierungen von Geschichten related components view à la Bootstrap-Dokumentation und einer detailed components view à la wofür ein Märchenbuch gut geeignet ist wechseln können und wir haben eine Menge Komponenten zu präsentieren. Ich würde dies als eine einfache Version des Einrichtens mehrerer Storybook-Instanzen betrachten:

Wenn es für Sie nützlich ist, können Sie es hier nachlesen -

Ich habe auf @UsulPros fantastischem storybook-chapters , um einen Storybook-Loader zu erstellen, der Ihre Komponentendateihierarchie als Storybook-Kapitel widerspiegelt :

Damit kann ich meine Storys in einer _stories Datei oder einem Ordner direkt mit meinen Komponenten ablegen. Der Loader findet alle Story-Dateien und ordnet sie einer entsprechenden Navigationsstruktur zu.

Danke für das herzliche Feedback, Jungs!

Wirklich cool, @hadfieldns storybook-filepath-chapters ! 👍

Ich mag storybook-addon-toggle als Beispiel dafür, dass es wünschenswert ist, eine Möglichkeit zu haben, eine Hierarchie nicht nur in der Tiefe, sondern auch nach oben aufzubauen. Eigentlich ist es technisch möglich, aber ich denke, es ist schwer, den besten Weg zu wählen (innerhalb der Addons-API zu bleiben). Vielleicht kann dies mit Dekoratoren (wie @majapw) oder über Addon-Panels erfolgen.

Ich habe noch nicht vor, eine Hierarchie über Stories hinzuzufügen, aber das storybook-chapters Addon hat jetzt eine API , die den Aufbau einer solchen Hierarchie vereinfachen kann:

enable / disable zum Anzeigen/Ausblenden Ihrer Geschichten

-

füge enable() / disable() zu deinen Stories hinzu. Geben Sie als Argument den Callback an, an den die Kontrollfunktion übergeben wird.

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'));

Dann können Sie toLight(false) , um Heroes Lightside auszublenden und toDark(true) , um Heroes Darkside Geschichten anzuzeigen. Vielleicht möchten Sie toLight und toDark in einige Dekorateure stecken oder vielleicht von anderen Geschichten zurückrufen. Ich zeige das einfachste mögliche Beispiel:

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>);
    });

Jetzt haben wir also 3 Sätze von Geschichten: Choose Your Side , Heroes Lightside und Heroes Darkside . Von den letzten beiden ist nur einer sichtbar und der erste ermöglicht das Umschalten.

In der nächsten Version plane ich, die Sichtbarkeit der Storys über ein anpassbares Add-On-Panel zu steuern

-

Mit der Funktion zum Aktivieren/Deaktivieren können Sie eine benutzerdefinierte Navigation mit Ihrer bevorzugten Logik erstellen.

komplettes Beispiel hier

Wir werden einen Hierarchiebrowser implementieren, würden uns aber über Konzepte freuen, wie die Community dies denkt:

• UX klug
• So konfigurieren Sie die Gruppen

UX-technisch gefällt mir diese Idee: http://multi-level-push-menu.make.rs/demo/basichtml/basichtml.html

Konfiguration weiß ich noch nicht.. Wir könnten die Dateiexploration verwenden und das Dateisystem spiegeln, oder wir könnten so etwas tun: https://github.com/sm-react/storybook-chapters/issues/1#issue -215446017

@ndelangen haben Sie (zumindest optional?) daran gedacht, die Navigation außerhalb der Storys definieren zu können? Mir scheint, dass es sinnvoll sein könnte, das Aussehen der Story (der Vorschaubereich / iframe) und die Art und Weise, wie Sie das Browsen (der Manager) organisieren möchten, als separate Anliegen zu behandeln.

@jackmccloy Ich bin interessiert, kannst du mir mehr darüber erzählen, was du meinst?

Ich habe es in einem anderen Thema erwähnt, aber mein Ziel mit Kategorien wäre, sich hauptsächlich am atomaren Design auszurichten. Pattern Lab ist der offizielle Styleguide-Ansatz für Atomic Design, aber das Hinzufügen von Kategorien zum Storybook würde die letzte verbleibende Lücke schließen.

Ich ordne meine Komponenten bereits in Ordnern der obersten Ebene für diese Kategorien an, daher wäre es auch eine großartige Sache, Komponenten auf der Grundlage von Ordnern der obersten Ebene in Kategorien zu laden.

@travi Können Sie mir einen Ausdruck Ihres

Ich bin auf jeden Fall daran interessiert, Storybook für genau diesen Zweck zu verbessern, aber mich interessiert, was technisch erforderlich wäre, um diese Kategorisierung aus Ihrer Ordnerstruktur zu lesen.

es ist im Wesentlichen

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

Hilft das? Ich habe mehrere Komponenten unter jedem Ordner der obersten Ebene, manchmal weiter nach einer anderen Ordnerebene gruppiert. gerne mehr Details wenn es hilfreich wäre

Okay, wir könnten also ein Flag in config.js . so etwas wie autoDiscoverStories oder so. Das würde bedeuten, dass Sie Storys nicht manuell importieren müssen und die Dateisystemordner als Kategorien verwendet werden.

@ndelangen Ich denke, was ich denke, ist ausgegangen , dass es eine einzige Navigation geben wird, die jeder verwenden wird. Ich denke, es lohnt sich, über Möglichkeiten zu sprechen, die Navigation erweiterbar zu machen, ähnlich wie Add-Ons die Funktionalität der Storys selbst erweitern.

Eine Möglichkeit:
Derzeit wird jede Geschichte in zwei Schritten hinzugefügt - einem ersten Schritt, in dem eine Kategorie zugewiesen wird, und einem zweiten Schritt, in dem ein Titel zugewiesen wird, dh

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

Sie können mehrere Geschichten in einer Kette zu derselben Kategorie hinzufügen, aber die Struktur schränkt die Flexibilität in gewissem Maße ein - alle Geschichten müssen eine Kategorie und einen Titel haben, und Kategorien sind eine "höhere Ebene" als Titel.

Aber wenn Geschichten etwas anders definiert werden könnten, z

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

Wir könnten einfacher mit verschiedenen Navigationsoptionen experimentieren.

Die Standardnavigation könnte so bleiben, wie sie ist. Es ist eine vernünftige Standardeinstellung und funktioniert wahrscheinlich für die meisten von uns gut genug. storyData könnte sogar optional sein - Stories ohne Kategorie könnten auf der obersten Ebene erscheinen und Stories ohne Titel könnten standardmäßig auf displayName der Komponente stehen.

Die Community könnte jedoch mit verschiedenen Möglichkeiten experimentieren, ihre Storys zu organisieren, indem sie (a) zusätzliche Metadatenfelder zu stroyData hinzufügt und/oder (b) die Art und Weise ändert, wie das Navigationsfeld basierend auf den Metadatenfeldern gerendert wird.

Einige Ideen:

// 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)

Schön! das ist ziemlich out of the box und in der Tat erweiterbar. Darüber werde ich ein bisschen nachdenken. 🤔

Fantastisch. Lass mich wissen, wofür du dich entscheidest - ich setze mich ein, wo ich kann, egal welche Richtung du einschlägst - großer Fan des Projekts

Der Vorschlag von

Es scheint jedoch von einem starken Anwendungsfall für Storybooks abzuraten, der die Benutzeroberfläche als eine Reihe von "visuellen Testfällen" betrachtet und UI-Zustände einfach als einzelne Geschichten mit einem add() Aufruf pro Zustand definiert.

Das Registrieren der Story-Metadaten im add() Aufruf fühlt sich an, als würde die Kategorie auf der falschen Ebene hinzugefügt. Ich möchte den gleichen Vorschlag sehen, aber mit der Funktion 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} />);

Ich mag die Idee, nur den Titel von Component.displayName und all den anderen Ideen über Unterkategorien oder das Hinzufügen einer Komponente zu mehreren Kategorien zu übernehmen, ich möchte nur die Einfachheit des Hinzufügens von Zuständen beibehalten.

Unabhängig davon, wo die Kategorie definiert ist, ist zu beachten, dass der Kategorie eine andere Datei hinzugefügt werden kann. Wenn eine Kategorie nur aus einer einzigen Datei definiert werden könnte, wäre dies meiner Meinung nach sehr einschränkend

Ich stimme @travi zu – deshalb ist die Kategorie, die nur eine Zeichenfolge ist (die meiner Meinung nach einem Wörterbuchschlüssel zugeordnet werden würde), ansprechend.

Ich stelle mir vor, dass ich meine Kategorien an einer Stelle definieren könnte, um Tippfehler wie folgt zu vermeiden:

// 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 />);

aber das wäre ein Implementierungsdetail, das meiner App überlassen bleibt.

@theinterned @jackmccloy Ich mag deine Vorschläge.

Ich überlege, wie Sie Ihre Vorschläge in einer Hierarchie beliebiger Tiefe verwenden könnten. Vielleicht könnte es statt category / subCategory path mit einem Array von Pfadkomponenten sein. (Ich weiß, dass Sie dort nicht unbedingt Einzelheiten beabsichtigt haben, sondern nur Ihre Ideen riffen.)

Ich mag auch die Idee einer Konfigurationsoption, um das Dateisystem zum Erstellen der Navigationshierarchie zu verwenden. Wenn diese Option aktiviert ist, wäre das Argument path optional.

Dies ist eher ein Stretch-Goal, aber es kann gut sein, dass jede Seite mit Storys in der Hierarchie als separater Block geladen wird, um das Storybook leicht zu halten, wenn es größer wird. Es wäre auch cool, den Storybook-Loader mit einem bestimmten Dateisystemordner als Stammkontext ausführen zu lassen, damit er ein Storybook nur mit den in diesem Ordner definierten Storys und nicht mit allen Storys im gesamten Projekt erstellen könnte.

Was halten Sie von der Definition/Registrierung von Kategorien in Ihrer Konfiguration?

// 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 />);

Wir können genauso gut ein Array unterstützen: category: ['atom', 'deprecated'] , warum nicht?

Dies würde dazu beitragen, sicherzustellen, dass Kategorien in der richtigen Reihenfolge platziert werden, was beim atomaren Design wichtig ist.

Kategorien aus der Konfiguration abzurufen wäre schön, magische Zeichenfolgen sind schlecht 👎

das macht für mich Sinn.

Außerdem +1 dafür, dass Sie die Kategorie für die Geschichte aus der Definition in der Konfiguration ziehen, anstatt zu hoffen, dass Strings übereinstimmen

@ndelangen Kategorien im

Eine Sache, die ich an Storybook liebe, ist, dass ich feststellen kann, ob sich eine Komponente in Storybook befindet oder nicht, indem ich einfach überprüfe, ob sich eine story.jsx Datei zusammen mit der Komponente befindet. Diese Garantie -
dass, wenn eine story.jsx Datei existiert, eine Geschichte existiert - ist eine wichtige, die nicht durch Vordefinieren von Kategorien rückgängig gemacht werden sollte, imo.

Aus dieser Sicht ist es möglicherweise nicht einmal notwendig, ein id und ein index für Kategorien in der Konfiguration zu benötigen - so etwas (vorausgesetzt, es verwendet das Options-Plugin) könnte funktionieren

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

wobei First Category , Second Category und Third Category garantiert an erster, zweiter und dritter Stelle erscheinen und alle anderen Kategorien, die in Geschichten deklariert sind, werden alphabetisch nach diesen drei angezeigt.

Dieser Ansatz könnte auch eine intelligente Möglichkeit sein, auch die Verschachtelung mit beliebiger Tiefe zu steuern, indem Sie Folgendes tun:

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

Stories mit der Kategorie "Buttons" würden innerhalb von Atoms -> Buttons . Geschichten mit der Kategorie "Atoms" würden innerhalb von Atoms , unterhalb von Buttons (aber nicht darin) usw.

Benutzer würden eine Tiefe ohne jegliche Konfiguration erhalten (genau wie jetzt) ​​und beliebige Tiefenebenen mit minimaler Konfiguration. Wichtig ist, dass es eher die Kategorien sind, die Tiefe haben (auf der Konfigurationsebene festgelegt) als die Storys selbst (dh die Storys würden nur ihre Kategorie festlegen - sie würden nicht definieren, wo diese Kategorie in der Hierarchie erscheint).

@theinterned Ich stimme Ihnen zu: Die Einfachheit des Hinzufügens von Zuständen muss beibehalten werden. Daran hatte ich nicht gedacht, wahrscheinlich nutze ich das Regler-Addon stark. Für mich versuche ich also, eine 1:1-Beziehung zwischen Komponenten und Storys zu haben, und meine Story-Titel beschreiben die Komponente und nicht den Zustand, in dem sich die Komponente befindet.

Eine mögliche Lösung, die für beide Anwendungsfälle funktionieren könnte, wäre, so etwas zu tun

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

wobei (a) die Reihenfolge der Storys von ihrer Deklaration aus gesteuert werden kann (im Gegensatz zu einer externen Konfiguration) und (b) der Parameter storyData das vorherige Objekt beibehalten kann und nur die Werte überschreibt, die werden explizit weitergegeben.

Nur ein Gedanke.

Obwohl ich selbst von Kategorien der obersten Ebene begeistert wäre, ist es nicht sicher, anzunehmen, dass Kategorienamen zwischen verschiedenen Kategorien eindeutig sind, wenn die Dinge weit genug gehen, um verschachtelte Kategorien zu unterstützen.

In Fortsetzung des Atomdesign-Beispiels ist es üblich, in jeder der obersten Kategorien von Atomen, Molekülen und Organismen eine Unterkategorie mit demselben Namen zu haben. In der Musterlabor-Demo sind Formulare ein gutes Beispiel dafür. einzelne Feldelemente werden unter Atome aufgelistet, die Kombination von Feld und Label wird unter Moleküle aufgelistet und mehrere Felder, die als vollständige Form gruppiert sind, werden unter Organismen angezeigt.

Ein interessanter Gedanke wäre zu überlegen, was wäre, wenn die Kategorie mit einem Callback definiert werden könnte, der den Titel, die Story und den Pfad zur Story-Datei erhält ... und auch einige Metadaten, die der Benutzer übergeben kann, um den Callback zu konfigurieren.

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

Die einzige Voraussetzung ist, dass der Callback ein Objekt zurückgeben muss, das einen Kategoriepfad zur Story definiert:

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" ];

Dies würde es den Leuten ermöglichen, jedes beliebige Kategoriesystem zu schreiben, das sie wollen.

Wenn Sie eine globale Konfiguration haben möchten, können Sie diese im Callback registrieren und die benutzerdefinierten Metadaten verwenden, um zu konfigurieren, mit welchen Kategorien / Unterkategorien Sie die Story registrieren möchten.

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
}

Wenn Sie die Kategoriestruktur basierend auf der Dateistruktur festlegen möchten, haben Sie die Pfadinformationen dafür.

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;
}

Wenn Sie nur einen einfachen Kategorienamen verwenden möchten, können Sie einfach einen verwenden! (Und vielleicht könnte category entweder einen einfachen String, ein Array, das einen Kategoriepfad beschreibt, oder einen Callback, der einen Kategoriepfad zurückgibt, annehmen).

Jetzt ist der Himmel die Grenze!

In ähnlicher Weise würde ich zum Definieren der Sortierreihenfolge eine addCategorySort Funktion vorschlagen, die Sie registrieren können, die die Baumkategoriestruktur, die durch das Laden aller Storys generiert wurde, nimmt und sortiert.

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

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

configure(loadStories, module);

@travi Ich hatte die Notwendigkeit von Kategorien mit doppeltem Namen nicht in Betracht gezogen, aber ich stimme zu, dass dies wichtig ist. Irgendwelche Gedanken zu einer Lösung? Mir fällt folgendes ein, aber vielleicht gibt es eine bessere Lösung:

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 Ich mache mir aber Sorgen, dass es für typische Benutzer (die etwas brauchen/wollen, das

@jackmccloy ja ... Ich stimme zu, dass die Implementierung einer Funktion nicht für jeden erforderlich sein sollte. Aber es scheint, dass es eine Reihe von verschiedenen Anwendungsfällen gibt, die die Leute unterstützen möchten, und daher scheint ein Rückrufsystem eine gute Möglichkeit zu sein, jedem die Erweiterbarkeit zu bieten, um seinen eigenen Anwendungsfall anzupassen.

Um die Sorge zu zerstreuen, dass es den "glücklichen Weg" erschwert, empfehle ich Folgendes:

1. Lassen Sie storydData.category eine Zeichenfolge akzeptieren, in diesem Fall wäre die Kategorie eine Kategorie der obersten Ebene.
2. Lassen Sie storydData.category ein Array akzeptieren, bei dem die Elemente im Array der Pfad zur Kategorie sind:

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

1. Lassen Sie Story-Daten eine Funktion wie oben beschrieben übernehmen (https://github.com/storybooks/react-storybook/issues/151#issuecomment-292689536).
2. Wir könnten tatsächlich ein paar Kategorie-Handler schreiben, die einige der üblichen Anwendungsfälle abdecken, die wir hier haben (Atomic Design, ordnerbasiert ...);

Ebenso können wir beim Sortieren die Standardstrategie (ohne Zweifel Alpha) standardmäßig unterstützen und bei Bedarf andere vorgefertigte Sortierstrategien bereitstellen (Sortieren basierend auf einer Objektform, Sortierindizes in den Metadaten usw.);

@ndelangen was sehen Sie als den Weg in diese Richtung? Arbeitet jemand daran? Wenn nicht, probiere es gerne am Wochenende aus

Wenn ich benachrichtigt werde, dass die Arbeit von irgendjemandem begonnen hat und ihre Lösung praktikabel ist, entferne ich das Label PR needed . Dies ist derzeit also auf der Roadmap, aber es wurde noch keine Arbeit geleistet.

Wenn Sie damit anfangen möchten, wäre das super willkommen!

@jackmccloy darf ich auch bei dieser Arbeit mitmachen und teilnehmen, wenn es Ihnen nichts ausmacht?

@UsulPro 100%, darüber würde ich mich freuen. Ich plane, am Sonntagnachmittag (NYC-Zeit) einen echten Blick darauf zu werfen. Wenn Sie gleichzeitig online sind, können lmk und wir die Convo auf Slack umstellen. Ansonsten poste ich hier mit ein paar Gedanken, nachdem ich ein bisschen gegraben habe

@jackmccloy @usulpro Ich bin auf jeden Fall daran interessiert, auch daran zu arbeiten.

@theinterned Das wäre toll! Verbindung im Leerlauf?

@UsulPro Entschuldigung – schlimme heimgesucht .

Ich habe am Freitag einen Hack-Tag auf der Arbeit und ich habe vor, dann daran zu arbeiten. Hatten Sie die Chance, durchzustarten? Ich würde mich gerne über Slack synchronisieren. Ich bin im SB-Kanal.

Wenn Sie nur eine Verschachtelungsebene benötigen, können React Storybook Addon Chapters Ihren Anforderungen entsprechen.

Ich habe die erste Version von @igor-dvs hervorragender Implementierung der Story-Hierarchie veröffentlicht und würde gerne Ihr Feedback zur Alpha erhalten, damit wir sie verbessern können, bevor wir sie für die breitere Community veröffentlichen:

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

Nur eine kleine Macke, die mir bei der Story-Hierarchie aufgefallen ist:
Abhängig davon, ob ein Verzeichnis Unterverzeichnisse hat, ändert sich das Ergebnis des Anklickens eines Verzeichnisses.
Wenn Unterverzeichnisse vorhanden sind, wird der Ordner erweitert, aber wenn er sich auf der Story-Ebene befindet, wird die Story automatisch ausgewählt.
Ein Benutzer möchte möglicherweise den Inhalt von dir anzeigen, ohne eine Story darin auszuwählen.

Aktualisieren:

Könnte mit diesem Problem in react-treebeard
https://github.com/alexcurtis/react-treebeard/issues/33
Es könnte sich lohnen, die PRs dort für das storybooks/react-treebeard Repo zu erkunden

In der vorherigen Implementierung wurde bei der Auswahl eines kind seine erste Story automatisch ausgewählt. Diese Funktionalität wollte ich also erhalten. Aber vielleicht sieht es mit Hierarchie schon wie ein Bug aus.

Im Bild ist Component 5 kein Verzeichnis - es ist ein kind .

Eigentlich mag ich dieses Verhalten auch nicht...

Namen von langen Geschichten wickeln sich seltsam ein

Wenn Sie die Seitenleiste auf eine sehr kleine Größe ändern, wird der Vorschaubereich darin überlaufen.

ist es möglich, hierarchieordner mit einzelnen geschichten zu kombinieren? Ich habe einige Geschichten, die ich auf der obersten Ebene haben möchte, ansonsten habe ich einen Ordner mit einem einzelnen Element

Derzeit, wenn Sie dies tun

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

Dann erstellt es 2 Einträge für 'Etwas', einen mit einem Ordner und einen mit einem Element

@TheSisb , danke, wird in der offiziellen Veröffentlichung behoben.

@psimyn , in der aktuellen Implementierung ist dies nicht möglich.. aber möglicherweise geändert.. @UsulPro hat dies auch in der ursprünglichen PR erwähnt.
IMO ist dies kein gutes Verhalten (und bringt mehr Komplexität). Im Vergleich zu jeder IDE gibt es Namespaces (dirs/folders/packages) und könnten einige Elemente in diesen Namespaces (oder in der Nähe) mit demselben Namen sein.
Wie auch immer, wenn dies ein gewünschtes Verhalten der Community ist, sollte es geändert werden, aber ich möchte nicht, dass es ein Stopper für die Veröffentlichung ist =)

Genau diese Lösung habe ich gebraucht!!! danke +1

@psimyn Bitte öffnen Sie ein neues Problem, das die Funktion beschreibt? Dieses Problem wird in Kürze mit der Veröffentlichung von 3.2.0

Ist mit dem neuen CSF-Format jetzt eine Verschachtelung auf mehreren Ebenen möglich?

@gaurav5430 ist es schon seit einiger Zeit möglich, siehe unser Beispiel hier:

Liquor:

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';

Hey @ndelangen
Danke, das bekomme ich von hier: https://storybook.js.org/docs/basics/writing-stories/#story -hierarchy

Ich denke, was ich möchte, ist die Möglichkeit, Unterordner basierend auf story.name und nicht nur dem Standard-Exporttitel zu erstellen

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

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

würde als Other/Demo/Welcome/To/Storybook

Ich denke, eine Problemumgehung für das obige Problem wäre, mehrere Story-Dateien zu erstellen und die Standardeinstellungen mit der richtigen Hierarchie in jeder von ihnen zu exportieren.

wie in one.stories.js :

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

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

und in two.stories.js

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

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

Auf diese Weise würden beide Geschichten wie erwartet in der Ordnerstruktur des Bilderbuchs angezeigt

@ gaurav5430 das ist die empfohlene Verwendung und keine Problemumgehung. 😄

@ gaurav5430 das ist die empfohlene Verwendung und keine Problemumgehung. 😄

Ja, ich habe nur gezögert, dies zu tun, da diese beiden Dateien für unterschiedliche Zustände derselben Komponente gelten. In meinem Fall hat die Komponente 2 Hauptzustände und mehrere Unterzustände basierend auf diesen 2 Hauptzuständen. Normalerweise würde ich alle Zustände der Komponente in derselben Datei speichern, aber in diesem Fall würde ich eine separate Datei für die Hierarchie in Storys benötigen.