Organizar correctamente los componentes desde el inicio marca la diferencia entre un Design System mantenible y uno caótico. Cuando trabajamos con Storybook, la forma en que nombramos y estructuramos nuestras historias determina cómo se visualiza toda la librería de componentes, y aquí es donde la metodología de Atomic Design cobra un papel fundamental.
¿Cómo preparar la estructura de archivos para un componente en Storybook?
El primer paso consiste en limpiar los archivos de ejemplo que Storybook genera durante la instalación [0:42]. Una vez que la carpeta stories queda vacía, se construye desde cero la estructura necesaria para cada componente.
Para un botón, por ejemplo, se crea una carpeta llamada button y dentro de ella tres archivos principales [1:14]:
button.js para la lógica del componente.button.css para los estilos.button.stories.js para las historias de Storybook.
El archivo con la extensión .stories.js es clave porque Storybook lo detecta automáticamente gracias a la configuración del archivo main, que busca cualquier archivo que contenga la palabra stories en su nombre [1:48].
¿Qué es el nombramiento en Storybook y por qué importa?
Dentro del archivo de stories, lo primero que se hace es importar el componente desde su archivo JavaScript correspondiente [2:10]. La estructura básica luce así:
javascript
import Button from './button';
export default {
title: 'Design System/Atoms/Button',
};
La propiedad title define cómo se organiza visualmente el componente dentro de Storybook [3:00]. No se trata solo de un nombre: es una ruta jerárquica que funciona como un sistema de carpetas. Cada barra diagonal (/) crea un nivel de agrupación.
¿Cómo se aplica Atomic Design al nombramiento?
Atomic Design es una metodología que clasifica los elementos de una interfaz en categorías progresivas: átomos, moléculas, organismos, plantillas y páginas [3:35]. En el contexto de un Design System, un botón es un átomo porque representa la unidad más básica de la interfaz.
Al escribir el título como Design System/Atoms/Button, se logra una estructura desglosada [4:05]:
- Design System actúa como la carpeta padre que agrupa todo.
- Atoms agrupa todos los componentes atómicos.
- Button identifica el componente específico.
Usar el plural Atoms permite que, cuando existan más componentes del mismo tipo, todos se agrupen bajo la misma categoría de forma ordenada [4:18].
¿Por qué la arquitectura viene desde el diseño?
Esta estructura no se inventa durante el desarrollo. Proviene directamente del trabajo previo en herramientas como Figma, donde ya se establecen las variantes y la clasificación de cada componente [3:20]. Esas variantes cumplen un papel importante tanto en la construcción como en la documentación del Design System.
Respetar la misma arquitectura en código que en diseño garantiza consistencia entre equipos y facilita que cualquier persona encuentre rápidamente lo que necesita dentro de Storybook.
¿Qué sigue después de definir la arquitectura?
Hasta este punto se tiene la base para continuar construyendo: una carpeta limpia, los archivos del componente creados y un nombramiento basado en Atomic Design configurado en el archivo de stories [4:45]. Aunque el botón aún no tiene código funcional ni estilos, esta preparación es esencial para que, al momento de desarrollarlo, aparezca correctamente organizado en Storybook.
El siguiente paso natural es trabajar con tokenización, que permite convertir las decisiones de diseño en variables CSS reutilizables [5:10]. Esto conecta directamente con lo que se acaba de preparar, porque esos tokens serán los valores que alimenten los estilos del botón y de todos los componentes futuros.
Si ya estás aplicando Atomic Design en tus proyectos o tienes dudas sobre cómo nombrar componentes más complejos como moléculas u organismos, comparte tu experiencia en los comentarios.
