Atomic Design en React Native

Trabajar por componentes no garantiza que una app sea coherente. Sin unas reglas claras, cada componente se hace a su manera y con el tiempo se van desalineando entre sí. El código acaba sin parecerse mucho al diseño: lo que en Figma es una cosa, en el código es otra con otro nombre y otros valores.

Atomic Design es la forma que uso para evitarlo. Empecé a trabajar con él en DoGood. Desde entonces lo aplico siempre que me parece oportuno, en proyectos freelance y en side projects.

Qué es Atomic Design

Es una metodología de Brad Frost para construir interfaces de lo pequeño a lo grande. Tiene cinco niveles: átomos, moléculas, organismos, plantillas y páginas.

Yo suelo usar los tres primeros dentro de components. Las páginas son las pantallas de la app y viven en su propia carpeta. El papel de plantilla lo hacen unos contenedores de layout, por ejemplo una lista paginada con pull to refresh que comparten varias pantallas.

Cómo organizo las carpetas

src/components/
├── atoms/
├── molecules/
├── organisms/
└── layout/

Cada componente tiene su carpeta con un index.tsx y, si hace falta, styles.ts, types.ts y su test. Cada nivel exporta sus componentes, así los imports siempre tienen la misma forma.

Qué va en cada nivel

Esta es la parte que más dudas genera, así que conviene tener un criterio claro:

• Átomo: no depende de ningún otro componente. Los tokens de diseño (colores, tipografía, espaciado), que luego usan las moléculas y todo lo que hay por encima, y elementos básicos como un icono, una imagen o las piezas de un skeleton.
• Molécula: un control reutilizable que combina átomos y se configura con props de tipo, estado y tamaño. Botones, inputs, checkbox, chips, tabs, badges, toast… No deberia saber nada del producto.
• Organismo: un bloque con significado de producto. Compone moléculas y trabaja con datos del dominio: una tarjeta de contenido, un comentario con su input, una cabecera, un estado vacío.

1. Átomotokens, icono

2. Moléculabotón

3. Organismotarjeta

4. Pantallalista de tarjetas

Las variantes de una molécula las resuelvo con enums compartidos y un mapa de estilos. Simplificado, un botón queda así:

interface ButtonProps {
  type?: Type;
  state?: State;
  size?: Size;
  onPress: () => void;
  style?: StyleProp<ViewStyle>;
  children: string;
}

const variantStyles: Record<string, ViewStyle> = {
  [Type.PRIMARY + State.ACTIVE]: { backgroundColor: Colors.brand.primary.h700 },
};

export const Button = ({
  type = Type.PRIMARY,
  state = State.ACTIVE,
  size = Size.M,
  onPress,
  style,
  children,
}: ButtonProps) => (
  <TouchableOpacity
    disabled={state === State.INACTIVE}
    onPress={onPress}
    style={[variantStyles[type + state], sizeStyles[size], style]}
  >
    <Text style={Typo.body.b6}>{children}</Text>
  </TouchableOpacity>
);

Los tokens

La base de todo es la coherencia entre diseño y código. Los tokens son esa conexión. Si el Figma está montado con la misma estructura se puede pasar a código tal cual:

• Colores: agrupados por familia (marca, neutros, estados) con escala.
• Tipografía: presets header y body listos para usar.
• Espaciado: una escala con base fija. Lo habitual es 4 u 8.

export const Spacing = { sp1: 4, sp2: 8, get: (n: number) => 4 * n };

const styles = StyleSheet.create({
  card: { padding: Spacing.sp3, backgroundColor: Colors.neutral.background.h300 },
});

Todo pasa por una función que escala los valores según el tamaño de pantalla. Así nadie escribe un 16 a mano: si diseño dice sp3, en el código es sp3.

Dónde entra el estado

Con Redux la regla es sencilla: átomos y moléculas no tocan el store. Los organismos y las pantallas sí. Leen con useSelector y despachan actions.

const Card = ({ id }: { id: string }) => {
  const item = useSelector(getItemById(id), isEqual);
  const dispatch = useDispatch();
  return <Molecule title={item.title} onPress={() => dispatch(openDetail(id))} />;
};

Así las moléculas se pueden reutilizar en cualquier pantalla, o incluso en otro proyecto, sin arrastrar dependencias.

Lo que gano

Lo primero, velocidad. Con los átomos y buena parte de las moléculas hechos, una feature nueva solo pide las moléculas u organismos que falten. Lo demás se reutiliza. En DoGood eso nos llevó a reducir alrededor de un 30% el tiempo de implementación de nuevas features.

Lo segundo, coherencia. Cuando diseño y código usan las mismas piezas y los mismos nombres, compartes un contexto: los dos sabéis exactamente de qué estáis hablando. Si diseño pide cambiar el espaciado de una tarjeta a sp4 o usar el botón secundario, no hay que interpretar nada ni buscar a qué corresponde en el código. Eso se traduce en menos cosas que aclarar y mucho menos que corregir.

Errores que conviene evitar

Atomic Design no se mantiene solo. Estos son algunos problemas que he visto:

• Moléculas que saben demasiado. Si cada uno decide por su cuenta qué es una molécula, acabas con moléculas que leen del store y dejan de ser reutilizables. Hay que ser concienzudo y tener claro dónde va cada cosa: si necesita el store, no es una molécula.
• Migraciones a medias. Al empezar a usarlo en un proyecto existente, las carpetas viejas conviven con las nuevas y aparecen duplicados. Si no puedes migrarlo todo de golpe, hazlo por partes completas: si migras los checkbox, migras todos y borras el antiguo.
• Dos fuentes de verdad para los tokens. Un sistema nuevo, uno antiguo y algún hexadecimal suelto. Asegúrate de que todo tira de tokens y de que están definidos en un único sitio.

Cuándo lo usaría y cuándo no

Lo recomiendo para cualquier proyecto que quiera mantener unos tokens comunes en todo el código.

Puede parecer que sin equipo de diseño, o sin un Figma que seguir, no tiene mucho sentido. Pero creo que, aunque estés tú solo, ayuda bastante: desarrollas más rápido y un cambio se aplica a todo el proyecto desde un solo sitio.

En proyectos muy pequeños puede ser un poco overkill. Pero si parece que quiere crecer en componentes, lo aplicaría desde el principio. Al final, Atomic Design no va de carpetas: va de que diseño y código hablen el mismo idioma. Si eso lo tienes, lo demás se ordena casi solo.