Actualmente, no tenemos ningún plan para implementar eso. Eso es porque dificulta la navegación. Puede utilizar tipos de historias de espacios de nombres con puntos como "ui.core", "ui.app". Luego, puede filtrarlos según sus necesidades.

Si hay muchas historias, puede comenzar con algunas instancias de libros de cuentos. Puede hacerlo teniendo dos directorios de configuración de libro de cuentos. Pero, de todos modos, ese es un caso extremo.

Estoy dispuesto a admitir este punto, y pensé en hacer una configuración diferente y ejecutarla en un puerto diferente y todo eso ...

Pero creo que sería mucho mejor permitir que Storybook tome varios archivos de configuración ... y luego alternar entre archivos de configuración con nombre, tal vez recargando ...

En cuanto a la interfaz de usuario para cambiar de configuración, solo aparecerá si su archivo de configuración "cargó" otros archivos de configuración, y podrían ser elementos de la barra lateral en la parte superior o inferior de la barra de navegación lateral.

De todos modos, creo que para aplicaciones más grandes, si no puede (o no) dividir las configuraciones, es un poco loco.

Agregar configuraciones adicionales parece ser demasiado complejo. ¿Qué tal un interruptor para la vista clásica / jerárquica? Estoy feliz de aumentar una implementación en los próximos días.

Esta también sería una característica muy valiosa para mí, pero para la organización de tipos de componentes dentro de una sola aplicación en lugar de para múltiples aplicaciones.

Estaría más que feliz de brindar cualquier ayuda para dar forma a una implementación que podría funcionar para ambos casos de uso si esto puede avanzar.

@travi Una de nuestras otras ideas es proporcionar un menú desplegable justo debajo del cuadro de filtro para seleccionar la categoría.

Se asigna una categoría en config.js y un conjunto diferente de archivos. Entonces, podemos tener otra capa de agrupamiento.

Creo que ese tipo de solución sería suficiente para satisfacer mis necesidades en este momento. Además, creo que la convención de espacio de nombres mencionada anteriormente podría ser una forma razonable de asignar la categoría que podría interpretarse en las opciones del menú desplegable. Una solución de este tipo permitiría que la vinculación entre categorías también siguiera siendo simple.

La forma en que estamos solucionando esto en la aplicación que estoy construyendo (cientos de componentes, organizados dentro de áreas de "pilares" sueltos) es con un guión que escribe dinámicamente las historias para el área en la que estamos trabajando actualmente.

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

Esto significa que Storybook ni siquiera tiene que construir los otros componentes. Me encantaría algún nivel de soporte para esto como una opción incorporada.

201 podría ayudar en esto.

¿alguna actualización en este?

+1

Soy argee, ¡esa es una característica muy útil!

+1

+1

+1

+1

+1

+1

Hola @arunoda , ¿ha habido algún progreso en el frente de implementación de categorías?

Si no es así, ¿alguien más tiene una aplicación de ejemplo que alterna entre dos configuraciones de libro de cuentos?

+1 Necesito absolutamente un nivel adicional de anidación: /

+1

+1

+1

+1

+1

+1

Bueno, parece que mientras tu aplicación crece, la lista de componentes también crece y necesitas más anidación. 1 nivel más ya cubriría muchos casos

+1

¡Hola chicos!

A pesar de que esta característica no está planeada en un futuro cercano, esto no significa que no podamos obtener tal comportamiento a través de la API de Storybook Addons.

Aquí hay un complemento de este tipo:

Capítulos de libros de cuentos

Agrega niveles ilimitados de anidación para (sub) historias

Para agregar un nivel de anidación más, simplemente coloque .chapter(name) en sus historias:

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

Características

• La estructura jerárquica de las subhistorias
• Compatible con Knobs , addWithInfo y otros complementos
• Use storyDecorator para envolver todos los capítulos

Página de demostración

Proyecto

Ejemplo

¡Cualquier comentario será muy apreciado! :)

@UsulPro ¡Niza!

@UsulPro Storybook Chapters es una solución brillante. ¡Gracias!

@UsulPro parece ser exactamente lo que estaba buscando, ¡gracias!

¡Hola a todos! No intento competir con @UsulPro (que hizo un trabajo increíble con storybook-chapters ), pero se me ocurrió una solución pequeña y ligeramente diferente que te permite alternar entre diferentes agrupaciones de historias con un botón en preview ventana. Esto es útil para nosotros en particular porque queremos poder cambiar fácilmente entre una especie de related components view al estilo de la documentación de arranque y un detailed components view al estilo para lo que el libro de cuentos es adecuado y nosotros tiene un montón de componentes para lucirse. Consideraría que esta es una versión ligera de la configuración de varias instancias de libros de cuentos:

Si le resulta útil, puede consultarlo aquí: https://github.com/majapw/storybook-addon-toggle

Me basé en el increíble storybook-chapters @UsulPro para hacer un cargador de libros de cuentos que reflejará la jerarquía de archivos de componentes como capítulos de Storybook: storybook-filepath-chapters

Con esto, puedo poner mis historias en un archivo o carpeta _stories línea con mis componentes. El cargador busca todos los archivos de historias y los asigna a la estructura de navegación correspondiente.

¡Gracias por los cálidos comentarios, chicos!

¡Realmente genial ver el storybook-filepath-chapters @hadfieldn ! 👍

Me gusta storybook-addon-toggle como ejemplo, que es deseable tener la posibilidad de construir una jerarquía no solo en profundidad sino también en la parte superior. En realidad, técnicamente es posible, pero creo que es difícil elegir la mejor manera (permanecer dentro de la API de complementos). Quizás esto se pueda hacer usando decoradores (como @majapw) o mediante paneles de complementos.

No planeo agregar una jerarquía sobre las historias todavía, pero storybook-chapters addon ahora tiene una API , pueden simplificar la construcción de dicha jerarquía:

enable / disable para mostrar / ocultar sus historias

-

agregue enable() / disable() a sus historias. Como argumento, especifique la devolución de llamada a la que se transferirá la función de control.

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

luego puede usar toLight(false) para ocultar Heroes Lightside y toDark(true) para mostrar Heroes Darkside historias. Es posible que desee poner toLight y toDark en algunos decoradores o tal vez devolver la llamada de otras historias. Mostraré el ejemplo más simple posible:

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

Así que ahora tenemos 3 conjuntos de historias: Choose Your Side , Heroes Lightside y Heroes Darkside . De los dos últimos, solo uno es visible y el primero te permite cambiar.

en la próxima versión planeo agregar la capacidad de controlar la visibilidad de las historias a través del panel de complementos personalizables

-

Con la función de habilitar / deshabilitar, puede crear una navegación personalizada con su lógica preferida.

ejemplo completo aquí

Implementaremos un navegador de jerarquía, pero nos encantaría conocer los conceptos de cómo la comunidad cree que debería hacerse:

• UX sabio
• Cómo configurar los grupos

En cuanto a UX, me gusta esta idea: http://multi-level-push-menu.make.rs/demo/basichtml/basichtml.html

Configuración que aún no sé ... Podríamos usar la exploración de archivos y reflejar el sistema de archivos, o podríamos hacer algo como esto: https://github.com/sm-react/storybook-chapters/issues/1#issue -215446017

@ndelangen ¿has pensado (¿al menos opcionalmente?) permitir que la navegación se defina fuera de las historias? Me parece que podría ser útil tratar cómo se ve la historia (el área de vista previa / iframe) y cómo desea organizar la navegación (el administrador) como preocupaciones separadas.

@jackmccloy Estoy interesado, ¿puedes contarme más sobre lo que quieres decir?

Lo he mencionado en un número diferente, pero mi objetivo con las categorías sería alinearme principalmente con el diseño atómico . pattern lab es el enfoque oficial de la guía de estilo para el diseño atómico, pero agregar categorías al libro de cuentos llenaría el último vacío restante.

Ya organizo mis componentes en carpetas de nivel superior para esas categorías, por lo que poder cargar componentes en categorías basadas en carpetas de nivel superior también sería una gran cosa para la sesión.

@travi ¿Puedes darme una copia impresa del diseño de tu carpeta?

Definitivamente estoy interesado en mejorar el libro de cuentos para este propósito exacto, pero estoy interesado en lo que se requeriría técnicamente para leer esta categorización desde la estructura de su carpeta.

es esencialmente

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

¿Eso ayuda? Tengo varios componentes en cada carpeta de nivel superior, a veces agrupados por otro nivel de carpeta. feliz de proporcionar más detalles si sería útil

ok, entonces lo que podríamos hacer es poner una bandera en config.js . algo como autoDiscoverStories o menos. Lo que significaría que no tiene que importar historias manualmente y las carpetas del sistema de archivos se usarían como categorías.

@ndelangen Supongo que lo que estoy pensando es esto: ahora mismo, nuestra conversación

Una posibilidad:
Actualmente, cada historia se agrega en dos pasos: un primer paso donde se asigna una categoría y un segundo paso donde se asigna un título, es decir

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

Puede agregar varias historias en cadena a la misma categoría, pero la estructura limita la flexibilidad hasta cierto punto: todas las historias deben tener una categoría y un título, y las categorías tienen un "nivel superior" que los títulos.

Pero si las historias pudieran definirse de una manera ligeramente diferente, es decir,

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

podríamos experimentar con diferentes opciones de navegación más fácilmente.

La navegación predeterminada podría permanecer como está. Es un valor predeterminado sensato y probablemente funcione lo suficientemente bien para la mayoría de nosotros. storyData incluso podría ser opcional: las historias sin una categoría podrían aparecer en el nivel superior, y las historias sin un título podrían tener por defecto el displayName del componente.

Pero la comunidad podría experimentar con diferentes formas de organizar sus historias (a) agregando campos de metadatos adicionales a stroyData y / o (b) cambiando la forma en que el panel de navegación se representa en función de los campos de metadatos.

Algunas ideas:

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

¡Bonito! eso está bastante listo para usar y, de hecho, es extensible. Voy a pensar un poco en esto. 🤔

Impresionante. Déjame saber lo que decidas. Yo colaboraré donde pueda, independientemente de la dirección que elijas, gran fan del proyecto.

La propuesta de @jackmccloy es genial, ¡gracias por la genial idea!

Sin embargo, parece desalentar un caso de uso sólido para Storybooks que piensa en la interfaz de usuario como una serie de "casos de prueba visual" y define fácilmente los estados de la interfaz de usuario como historias individuales usando una llamada add() por estado.

Registrar los metadatos de la historia en la llamada add() parece que está agregando la categoría en el nivel incorrecto. Me gustaría ver la misma propuesta, pero usando la función 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} />);

Me gusta la idea de poder simplemente tomar el título de Component.displayName y todas las otras ideas sobre subcategorías o agregar un componente a múltiples categorías, solo me gustaría preservar la simplicidad de agregar estados.

Una cosa a tener en cuenta, independientemente de dónde se defina la categoría, es que se debería poder agregar otro archivo a la categoría. si una categoría solo pudiera definirse a partir de un solo archivo, creo que sería muy limitante

Estoy de acuerdo @travi , es por eso que la categoría que es solo una cadena (que imagino que se asignaría a alguna clave de diccionario) es atractiva.

Me imagino que podría definir mis categorías en un solo lugar para evitar errores tipográficos como este:

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

pero ese sería un detalle de implementación que quedaría en manos de mi aplicación.

@theinterned @jackmccloy Me gustan tus sugerencias.

Estoy pensando en cómo podría utilizar sus sugerencias en una jerarquía de profundidad arbitraria. Quizás en lugar de category / subCategory podría ser path con una matriz de componentes de ruta. (Sé que no tenías necesariamente la intención de dar detalles allí, simplemente riffing en tus ideas).

También me gusta la idea de una opción de configuración para usar el sistema de archivos para crear la jerarquía de navegación. Con esta opción habilitada, el argumento path sería opcional.

Este es un objetivo más extenso, pero podría ser bueno que cada página de historias en la jerarquía se cargue como un fragmento separado, para mantener el libro de cuentos liviano a medida que crece. También sería genial permitir que el cargador de libros de cuentos se ejecute con una carpeta del sistema de archivos específica como contexto raíz, de modo que pueda construir un libro de cuentos con solo las historias definidas en esa carpeta en lugar de todas las historias de todo el proyecto.

¿Qué piensan ustedes acerca de definir / registrar categorías al principio de su configuración?

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

También podemos admitir una matriz: category: ['atom', 'deprecated'] , ¿por qué no?

Esto ayudaría a asegurarse de que las categorías se coloquen en el orden correcto, lo que en el diseño atómico es importante.

Recuperar categorías de la configuración sería bueno, la cadena mágica es mala 👎

eso tiene sentido para mí.

también, +1 por extraer la categoría de la historia de lo que se definió en la configuración en lugar de esperar que coincidan las cadenas

@ndelangen definir categorías por adelantado para que podamos controlar los pedidos sería ENORME. Pero creo que sería importante hacerlo de modo que las categorías _puedan_ definirse en la configuración, no que _deben_ definirse allí.

Una cosa que me encanta de Storybook es que puedo saber si un componente está o no en Storybook simplemente verificando si hay un archivo story.jsx ubicado junto al componente. Esa garantía ...
que si existe un archivo story.jsx , existe una historia; es una historia importante que no debe deshacerse con categorías predefinidas, en mi opinión.

Desde esa vista, es posible que no sea necesario necesitar un id y un index para las categorías en la configuración; algo como esto (suponiendo que use el complemento de opciones) podría funcionar

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

donde se garantiza que First Category , Second Category y Third Category aparecerán en primer, segundo y tercer lugar, y cualquier otra categoría declarada en las historias aparecerá alfabéticamente después de esas tres.

Este enfoque también podría ser una forma inteligente de controlar el anidamiento de profundidad arbitraria, haciendo algo como esto:

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

Las historias con la categoría "Botones" aparecerían dentro de Atoms -> Buttons . Las historias con la categoría "Átomos" aparecerían dentro de Atoms , debajo de Buttons (pero no dentro de ella), etc.

Los usuarios obtendrían un nivel de profundidad sin ninguna configuración (como ahora) y niveles arbitrarios de profundidad con una configuración mínima. Es importante destacar que serían las categorías las que tienen profundidad (establecidas en el nivel de configuración) en lugar de las historias en sí mismas (es decir, las historias solo establecerían su categoría; no definirían dónde aparece esa categoría en la jerarquía).

@theinterned Estoy de acuerdo con usted en lo que

Una posible solución que podría funcionar para ambos casos de uso sería hacer algo como esto

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

donde (a) el orden de las historias se puede controlar desde donde se declaran (en lugar de necesitar una configuración externa) y (b) el storyData puede preservar el objeto anterior, sobrescribiendo solo los valores que se pasan explícitamente.

Solo un pensamiento.

Si bien me encantaría incluso con categorías de nivel superior, si las cosas van lo suficientemente lejos como para admitir categorías anidadas, vale la pena señalar que no es seguro asumir que los nombres de categoría serían únicos entre diferentes categorías.

Continuando con el ejemplo del diseño atómico, es común tener una subcategoría del mismo nombre en cada una de las categorías de nivel superior de átomos, moléculas y organismos. en la demostración del laboratorio de patrones , los formularios son un buen ejemplo de esto. los elementos de campo individuales se enumeran bajo átomos, la combinación de campo y etiqueta se enumeran bajo moléculas, y los campos múltiples agrupados como una forma completa se muestran bajo organismos.

Una idea interesante sería considerar qué pasaría si la categoría pudiera definirse con una devolución de llamada que obtenga el título, la historia y la ruta al archivo de la historia ... y también algunos metadatos que el usuario puede pasar para configurar la devolución de llamada.

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

El único requisito es que la devolución de llamada debe devolver un objeto que defina una ruta de categoría a la historia:

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

Esto permitiría a las personas escribir cualquier sistema de categorías que deseen.

Si desea tener una configuración global, puede registrar eso dentro de la devolución de llamada y usar los metadatos personalizados para configurar las categorías / subcategorías con las que desea registrar la historia.

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
}

Si desea establecer la estructura de categorías en función de la estructura de archivos, tiene la información de ruta para hacerlo.

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

Si solo desea usar un nombre de categoría simple, ¡puede usar uno! (Y tal vez la categoría podría tomar una cadena simple, una matriz que describe una ruta de categoría o una devolución de llamada que devuelve una ruta de categoría).

¡Ahora el cielo es el límite!

en una nota similar, para definir el orden de clasificación, sugeriría una función addCategorySort que podría registrar que toma la estructura de categoría de árbol generada al cargar todas las historias y la ordena.

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

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

configure(loadStories, module);

@travi No había considerado la necesidad de categorías con nombres duplicados, pero estoy de acuerdo en que es importante. ¿Alguna idea sobre una solución? Esto es lo que me viene a la mente, pero tal vez haya una solución mejor:

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 Me gusta el enfoque, pero me preocupa que pueda hacer las cosas más difíciles / menos intuitivas para los usuarios típicos (que necesitan / quieren algo que funcione bien fuera de la caja) en beneficio del usuario avanzado (que quiere algo que funcione perfectamente con un poco de esfuerzo).

@jackmccloy sí ... Estoy de acuerdo en que implementar una función no debería ser un requisito para todos. Pero parece que hay una serie de casos de uso diferentes que las personas buscan admitir, por lo que un sistema de devolución de llamada parece ser una buena forma de proporcionar extensibilidad para que todos puedan personalizar su propio caso de uso.

Para calmar la preocupación de que dificulta el "camino feliz", recomiendo lo siguiente:

1. Deje que storydData.category acepte una cadena, en cuyo caso la categoría sería una categoría de nivel superior.
2. Deje que storydData.category acepte una matriz donde los elementos de la matriz son la ruta a la categoría:

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

1. Deje que los datos de la historia acepten una función como se describe anteriormente (https://github.com/storybooks/react-storybook/issues/151#issuecomment-292689536).
2. De hecho, podríamos escribir algunos manejadores de categorías que cubran algunos de los casos de uso comunes que tenemos aquí (diseño atómico, basado en carpetas ...);

De manera similar, para la clasificación, podemos admitir la estrategia predeterminada (alfa sin duda) de forma predeterminada y, si es necesario, podríamos proporcionar otras estrategias de clasificación predefinidas (clasificación basada en la forma de un objeto, clasificación de índices en los metadatos, etc.);

@ndelangen, ¿cuál ve como el camino a seguir en esto? ¿Alguien está trabajando en eso? Si no, feliz de intentarlo durante el fin de semana

Cuando recibo un aviso de que alguien ha comenzado a trabajar y su solución es viable, elimino la etiqueta PR needed . Por lo tanto, esto está actualmente en la hoja de ruta, pero aún no se ha realizado ningún trabajo.

Si quieres empezar, ¡será muy bienvenido!

@jackmccloy , ¿puedo unirme y participar en este trabajo también si no le importa?

@UsulPro 100%, estaría emocionado por eso. Planeando empezar a echarle un vistazo el domingo por la tarde (hora de Nueva York). Si estará en línea al mismo tiempo, lmk y podemos mover la conversación a holgura. De lo contrario, publicaré aquí con algunas ideas después de indagar un poco.

@jackmccloy @usulpro Definitivamente también estoy interesado en trabajar en esto.

@theinterned ¡ Eso sería genial! ¿Conectando en holgura?

@UsulPro lo siento, una mala gripe estomacal afectó a mi hogar.

Tengo un día de hackeo en el trabajo el viernes y planeo trabajar en esto entonces. ¿Has tenido la oportunidad de empezar? Me encantaría sincronizarme en Slack. Estoy en el canal SB.

Si solo necesita un nivel de anidación, los capítulos del complemento React Storybook pueden satisfacer sus necesidades.

Lancé la primera versión de la excelente implementación de la jerarquía de historias de @ igor-dv y me encantaría recibir sus comentarios sobre la versión alfa para que podamos mejorarla antes de lanzarla a la comunidad en general:

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

Solo una pequeña peculiaridad que noté con la jerarquía de la historia:
Dependiendo de si un directorio tiene subdirectorios, cambia el resultado de hacer clic en un directorio.
Si hay subdirecciones, la carpeta se expandirá, pero si está en el nivel de la historia, la historia se seleccionará automáticamente.
Un usuario puede desear ver el contenido de dir sin seleccionar una historia dentro.

Actualizar:

Podría estar relacionado con este problema en react-treebeard
https://github.com/alexcurtis/react-treebeard/issues/33
Podría valer la pena explorar los RP allí para el repositorio de storybooks/react-treebeard

En la implementación anterior, al seleccionar un kind su primera historia se seleccionó automáticamente. Entonces esta funcionalidad la quería preservar. Pero tal vez con la jerarquía ya parece un error.

En la imagen, Component 5 no es un directorio, es un kind .

En realidad, tampoco me gusta este comportamiento ...

Los nombres de las historias largas se envuelven extrañamente

Cambiar el tamaño de la barra lateral para que sea realmente pequeña hace que el panel de vista previa se desborde.

¿Es posible combinar carpetas de jerarquía con historias individuales? Tengo algunas historias que quiero en el nivel superior, de lo contrario, tengo una carpeta con un solo elemento

Actualmente si haces esto

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

Luego crea 2 entradas para 'Algo', una con una carpeta y otra con un elemento

@TheSisb , gracias, se

@psimyn , en la implementación actual no es posible ... pero podría cambiarse ... @UsulPro también mencionó esto en el PR inicial.
En mi opinión, este no es un buen comportamiento (y aporta más complejidad). Comparándolo con todos los IDE, hay espacios de nombres (directorios / carpetas / paquetes) y podría haber algunos elementos en esos espacios de nombres (o cercanos) con el mismo nombre.
De todos modos, si este es un comportamiento deseado por la comunidad, debería cambiarse, pero no me gustaría que se detuviera para el lanzamiento =)

¡Esta es la solución exacta que necesitaba! gracias +1

@psimyn ¿ Abrir un nuevo número que describa la función? Este problema se cerrará muy pronto con el lanzamiento de 3.2.0

¿Es posible tener múltiples niveles de anidamiento con el nuevo formato CSF?

@ gaurav5430 ha sido posible durante algún tiempo, vea nuestro ejemplo aquí:

LCR:

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

Hola @ndelangen
Gracias, lo entiendo desde aquí: https://storybook.js.org/docs/basics/writing-stories/#story -hierarchy

Creo que lo que quiero es la capacidad de crear subcarpetas basadas en story.name y no solo en el título de exportación predeterminado

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

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

aparecería como Other/Demo/Welcome/To/Storybook

Creo que una solución para el problema anterior sería crear varios archivos de historia y exportar los valores predeterminados con la jerarquía correcta en cada uno de ellos.

como en one.stories.js :

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

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

y en two.stories.js

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

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

De esa forma, ambas historias aparecerían como se esperaba en la estructura de carpetas del libro de cuentos.

@ gaurav5430 ese es el uso recomendado, y no una solución alternativa. 😄

@ gaurav5430 ese es el uso recomendado, y no una solución alternativa. 😄

Sí, solo dudaba en hacer eso ya que ambos archivos son para diferentes estados del mismo componente. En mi caso, el componente tiene 2 estados principales y múltiples estados secundarios basados ​​en esos 2 estados principales. Por lo general, mantendría todos los estados del componente en el mismo archivo, pero en este caso necesitaría tener un archivo separado para la jerarquía en las historias.